[jlrubin]

Bulletproofs are significant because they allows you to check that the amount being input and output in a Bitcoin transaction is correct without revealing the amounts to non-parties to the transaction. The size of a bulletproof is small enough (and they grow with O(c + log n)) that for transactions with a couple inputs and outputs, there is minimal overhead compared to a unblinded transaction.

The link provided is to a relatively new library for doing bullet proofs written in Haskell -- the README might benefit from more disclaimer about the verification steps taken and analysis of side channels for the library (probably not ready for production)

[tromp]

In a Mimblewimble [1] blockchain, values are hidden inside Pedersen commitments, blind * G + value * H, and inputs can be seen to match outputs of a transaction if the latter minus the former is of the form blind*G (the difference in value is 0). But this form is a public key that the transactors can produce a signature for! This is way simpler than a bulletproof. BUT, bulletproofs are needed to show that the output values are in a certain range, to prevent overflow in value arithmetic.

[1] https://www.youtube.com/watch?v=BMiM0rabRjc

[jlrubin]

Correct -- the bulletproofs are only for the range proofs, but thought that was a bit too involved for my tldr :)

[infogulch]

How is that possible? Bitcoin's whole premise is a globally verifiable balance of each address after each block (aka public ledger). I could see this being very helpful for new crypto currencies, but Bitcoin is pretty set in stone on this matter, no?

[zodiac]

Well, the verification guarantees you want out of a public ledger for currency are weaker than that (no money is created out of thin air, the person you're receiving money from actually has enough money to send to you, etc). I'm not sure anyone is philosophically attached to "all balances are visible".

[infogulch]

Ok yes, in a single transaction you can prove to everyone else that the net exchange is zero, but how do you prove that you have enough money to send to them? That's global state that depends on all past transactions, even if they're hidden. Include more ZKPs for every transaction ever associated with that address? You have to prove that 1. you received enough to cover it and 2. you haven't spent it already.

Just slapping some ZKP on top of bitcoin is not enough to make it magically private. It needs deeper integration to the model than that.

[jlrubin]

You take the commitments from the outputs and use them in the next proof.

It is possible to soft fork confidentiality into Bitcoin, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016... for example

[antpls]

> I'm not sure anyone is philosophically attached to "all balances are visible".

I don't know either about others, but to me it looks like hiding balances is a regression. Why would you hide your balance, unless you want to lie about it?

I can't think of a reason hiding balances would be better, but I don't have a degree about economy so I'm open to explanation.

Same argument than personal privacy I guess, but here we are talking about currency, not personal political opinions or personal identifyable information.

[askmike]

I don't think this will ever be hardforked into bitcoin, but there are other ways of getting this in, such as via sidechains (see liquid[1] for example).

[1] https://blockstream.com/liquid/

[jlrubin]

These are publicly verifiable, they are just not plaintext values anymore. This isn't so weird -- think about what a signature is, it's a proof that I know a private key without plaintext revealing the key.