Bitcoin full node and query server
Apr 3, 2018
View in context in the libbitcoin Slack #general mirror.
N
narodnik14:21
to prove something is either 2 or 0, you need ring signatures because they have the property that you know the signature came from a set of keys, but you don't know which key, so a signature is provided proving that the value is either 0 (using public key derived from first equation) or 2 (using public key derived from second equation) but you don't know which key specifically, just that it's either of them.
🤔 1👍 1
7 replies · James C., neillm · last Apr 06, 2018
James C.14:19
Got it now. That's a lot of ring signatures, one for each of the 64 on/off "bit" pairs which together represent a single committed input/output/fee value. wow ... I see the need for compact bulletproofs more than before 🙂
James C.14:32
Q' tho: I dont understand how amounts are kept consistent between transactions. Since all hidden, with a different blinding factor for every tx, how do I know how much was actually previously sent to me? I need to know the prev. blinding factor + amount of the prev. tx, right?
neillm17:00
I'm new to this so may have it all wrong, but I think the blinding factor is still your priv key, and the tx output is just like any other tx. the difference is that the amount is encoded via the ring, and determining the amount relies on you checking every bit in the range to determine the final amount using the provided commitment and your priv key
neillm17:34
This is definitely incorrect, skimming more material now. Sorry @James C., can't help at the moment
👍 1
James C.19:51
Hi @neillm, from what I understand, each confidential tx will have individual input, output, fee amounts all individually commited as Cin, Cout, Cfee. For all of them to sum up to 0, the blinding factor for a given transaction has to be consistent for all commitments, and provably non-negative amounts via Ring Signatures. So I don't quite get how a given hidden output amount makes it into the next spending transaction as the new hidden input amount, since the two transactions (prev vs spending) will likely have different blinding factors...
(edited)neillm00:50
Does anyone know if the secp256k1-zkp fork will be merged upstream? Shaping an API around the existing might be a good idea, for example: https://github.com/ElementsProject/secp256k1-zkp/pull/16/commits/2a89dbc89c58319ea6facd2a0e5835570d22db04
GitHub
Based on rebase of strauss-multiexp from upstream onto -zkp TODO rangeproof aggregation TODO const time proving TODO pippenger support TODO 48-bit (and generally non-power-of-2) rangeproofs and agg...