Bulletproofs HF tracking issue

[apoelstra]

Opening this issue so we have a checklist of what we want to change when we HF for bulletproofs

• Replace rangeproofs by bulletproofs :)
• Add signed blob entry to CTxOut to replace data sidechannel (Perhaps we just replace nNonce?)
• Increase max surjection proof size (cf abort when blinding very large transaction #880 ) or even replace surjectionproofs with alternate proof
• Change quad/nonquad encoding of commitments to even/odd to match BIP-schnorr and make schnorr-verifiable proofs of value
• Fix MoneyRange bug for explicit transactions (see comments)

[dgpv]

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)

[apoelstra]

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.

[dgpv]

don't force people to update to new-style transactions, to avoid breaking covenants.

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

[apoelstra]

@sanket1729 noticed that our MoneyRange check does not take differing assets into account, so you cannot create a transaction with more than 21MM total units of all assets. This is a bug, but a HF to fix, and we should bundle it in with the BPs hardfork (even though it exclusively affects explicit outputs, while BPs exclusively affect confidential ones).

[apoelstra]

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 OP_RETURN output when there are blinded inputs but no blinded output" edgecase in wallet blinding.