Support new Bulletproof rewind scheme #48
Conversation
jaspervdm
changed the title
|
This one is now ready for review. Requesting review from @yeastplume and @garyyu, but I welcome others as well :) |
| for (i=0; i<16; i++) { | ||
| vals_bytes[i+8] = message[i]; | ||
| for (i=0; i<20; i++) { | ||
| vals_bytes[i+4] = message[i]; |
There was a problem hiding this comment.
vals_bytes[i+4]
here still should be [i+8]. why you want to lose the half of the value bytes?
There was a problem hiding this comment.
No, the value is encoded in 24-31. See also in the rewind function
There was a problem hiding this comment.
Ah, indeed, values are in 24-31 (i write a tiny test code to verify that).
Sorry for wrong alarm :-)
|
Bad news. Early versions of Grin++ had a bug where it would generate blinding factors a little differently than grin. The only reason you could restore old outputs when switching between the two was it would rewind the actual blinding factor, not just Keychain path. If we don't continue to use the old rewind method for old-style bulletproofs, early Grin++ outputs won't be restoreable in Grin. I can solve it with custom logic for those that continue to use Grin++, but I would like to be able to support it for a time in Grin, as well. |
|
@jaspervdm pointed out that we are already ignoring the rewound blinding factor today, so this change does not make the problem worse. |
This PR does a few things to enable support for mimblewimble/grin-wallet#105
muare 0. For legacy proofs the first 4 bytes of the message should also be 0, this will be checked at the wallet levelgamma*G + v*H == commit, this will be replaced by a re-derivation of the commitment using the recovered amount and message at the wallet levelThere are accompanying changes in rust-libsecp and grin that need to be merged at the same time to not break backwards compatibility.