-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bulletproofs HF tracking issue #934
Comments
Does the third point mean that the encoding of blinded outputs (value commitments) will be different after HF, so a covenant that puts restriction on blinded outputs (with deterministic random) before HF, will be unspendable after HF ? (the encoding of the outputs will be different, and there will be no way to produce the blinding that will result in output data that covenant expects) |
Ah, yes -- but this will be true regardless because the signature hash will change after the BP hardfork (since we will move the rangeproof sidechannel data out of the rangeproof into a separate blob which needs to be signed). We will need to be very careful about how to execute this fork to make sure that we don't force people to update to new-style transactions, to avoid breaking covenants. The new encoding will only differ in the first byte, so it is possible to design covenants which will continue working (by just ignoring that byte and accepting 1 bit of security loss). I edited the OP to mention the new data blob. |
If old-style transactions are still possible after HF, the old-covenant-encumbered outputs can be spent in these old-style transactions, so there would be no problem, AFAIU |
@sanket1729 noticed that our |
When we add bulletproofs we should also add a global transaction-wide 32-byte "scalar offset" field which is used to make the blinding factors all add to 0. This would greatly simplify cooperative coinjoining (or multiparty blinding of any form) and eliminate the "add an extra |
Opening this issue so we have a checklist of what we want to change when we HF for bulletproofs
MoneyRange
bug for explicit transactions (see comments)The text was updated successfully, but these errors were encountered: