I've read over the algorithm description a few times now, and searched some terms to try and get my head around what is being proposed. I thought I would post my commentary here for others to read in the hopes that it helps clarify precisely what this proposal is meant to achieve.
I'm a software engineer, so reasonably technical, but certainly not an expert on cryptographic primitives. I may well have misunderstood a few details, I'm hoping that OP will correct me where necessary.
Part 1: Hiding transaction amounts for better privacy
To get better privacy in Nano, one thing that would be very helpful is if individual transactions/blocks did not reveal the amounts being transferred. One way to achieve this is by including a "range proof" with the transaction data instead of a simple amount. A "range proof" is a piece of data generated by clever crypto math that proves the amount is within a certain range of values. In a cryptocurrency transaction, a range proof can be used to prove that no new coins were created by a transaction. The author of the proposal has used a range-proof scheme called "Bulletproofs" for this proof-of-concept implementation. Bulletproofs are already being used in production to hide amounts being transferred in the Monero network, so this seems like a great choice. You can read more about Bulletproofs here: https://www.getmonero.org/2017/12/07/Monero-Compatible-Bulletproofs.html
Part 2: A Challenge for Open Representative Voting
Nano uses a consensus mechanism called "Open Representative Voting" or "ORV". In this scheme, Nano addresses all nominate a representative. That representative then votes on whether each new transaction will be accepted by the network. The representative is allocated voting "weight" based on the total amount of Nano held by the addresses that have nominated that representative to vote on their behalf.
This is a great idea for a consensus algorithm, and it is one of Nano's core innovations. However, it obviously relies on the nodes in the network knowing how much weight each representative has been assigned, which in turn means knowing how much Nano is held by all the addresses that have nominated that representative to vote for them.
Part 3: Pedersen Comitments - proving the total voting weight of each representative
The big idea of this proposal is to get around the challenge in Part 2 by using something called a "Pedersen Commitment". A Pedersen Commitment uses some clever crypto math to allow someone to "commit" to a particular piece of information without revealing that information in advance. Later, they can reveal that information and others are able to verify that it is the same information to which the person previously "committed".
As applied in this case, each representative would provide a Pedersen commitment representing the amount of voting weight that they have assigned to them. These commitments are shared with all the other representatives. Because of the clever way that Pedersen commitments work, each representative is able to verify that the total amount of voting weight made up from all the committments combined is the correct amount (the same as the total amount of Nano that exist in the network). But they are not able in this process to identify the particular amounts that each representative contributes to the total amount.
By doing this, the representative nodes are able to verify that each representative is only voting with as much voting weight as they have actually been assigned by Nano holders, since all of their committed amounts add up to the correct total (and no one would ever say they are representing less weight than they really are). But they can verify this without knowing the specific weights each rep represents.
Part 4: Extra Goodies
There are also some bells and whistles mentioned in the algorithm description. The exchange of this information between representative nodes is done with a secret-sharing algorithm. This means that if one of the representatives goes offline during the process, or if they seem to be cheating (because they provided a Pedersen commitment about their amount, but that amount did not pass verification), a subset of the remaining nodes are able to co-operate to reveal the information shared by the misbehaving representative. This is similar to how a 3-of-4 multisig wallet in Bitcoin would allow 3 remaining family members to move inheritance funds if the 4th family member has died and no one knows their private key.
There is also mention of some nice security inclusions borrowed from the MuSig algorithm (from BTC) that prevent the players choosing keys that let them fudge the numbers on their cryptographic commitments after they are made.
I think that basically covers it. I wish I understood better how Pedersen committments and Bulletproofs work "under the hood". Then I would have a much better shot at evaluating whether this scheme can actually work. But it sounds very clever, and I would very much like to see it put into a trial. Maybe it would make sense to start it out in Banano or something first. It is admittedly complex, and it would require some very careful coding, testing and auditing in order to be considered trustworthy.
One issue worth noting is that including Bulletproofs with transactions is a pretty big deal for Nano. Nano strives to keep bandwidth low and transaction data size small ("less than a UDP packet" and all of that). On Monero, bulletproofs brought them from 13kB transactions down to 2.5kB transactions. But for Nano, adding bulletproofs would mean significantly larger transactions, which would significantly decrease potential throughput. That may be a trade-off worth making, since Nano throughput is already a lot higher than most other coins. But then again, maybe that's just not what Nano users/holders/reps want.
To the original author of the proposal: you have my deep respect, this is a really interesting proposal. I hope it pans out. Please do step in and correct any mistakes I've made in trying to describe how this works.