Define PSBT, Re-enable PSBT functional tests

[stevenroose]

The PSBT functional tests are being disabled in #494.

[instagibbs]

renamed it so we can discuss format here.

[instagibbs]

We can extend BIP174 with these new per-input/per-output fields:

1. Amount
2. Value blinding factor
3. Asset type
4. Asset blinding factor
5. Blinding pubkeys (output only? Any reason to attach to input?)
6. rangeproof(output only)
7. surjectionproof(output only)

Each field in network serialization. These fields should be legal with or without the inputs/outputs being blinded already. I think that's about it.

[instagibbs]

One * here is that we need to be able to collaboratively make a transaction, while not revealing the particulars of an output if you don't want to, but also having a PSBT be "equal" to another PSBT(BIP174 this means it's the same unsigned transaction).

In PSBT the "Creator" makes a transaction, so we potentially need a way of users to create blinded "slots" for outputs. I suppose this could be an output with both value and asset fields being a null value. It could also just come with blinded commitment in the output a priori, but it could not come with a surjection proof(would take an "Updater" step to know what the inputs are possibly). The initially-brought blinded commitments would also require recover later, which means a wallet step is already involved before this, and if the inputs aren't already filled in, there's no way to balance the blinding factors. It will likely interact poorly with deterministic blinding factor designs.

It may make more sense to allow value/asset commitments be directly included in the transaction when privacy between counter-parties is desired, and change the PSBT equality definition internally(or define blinded equality) to allow this to "change". We would also treat null asset/amount values as "same" for this expanded definition. For signing, of course we must use the original definition(for sighash reasons if nothing else).

In the case where privacy between signers isn't desired, leave the raw transaction alone, and fill in the new fields as needed.

[instagibbs]

Something to chew on:

Some counter-parties you're ok sharing all data with(say, hww), while others you are not(trading peer).

Is it enough to have a strip option that takes out everything except maybe input asset type(for surjection proof)?

[gwillen]

FWIW the idea that having the same underlying transaction is "equality" for PSBTs was never semantically good, and I am killing the overloaded op== on PSBT object in bitcoin#14978, with no apparent objections, as being a terrible abuse of operator overloading. I think instead the right concept is "can be merged with" or "compatible with".

[instagibbs]

Good to hear. We would still need merge rules(keep the confidential commitment? Plaintext?) among other rules.

…

On Wed, Feb 13, 2019, 8:30 PM gwillen ***@***.*** wrote: FWIW the idea that having the same underlying transaction is "equality" for PSBTs was never semantically good, and I am killing the overloaded op== in bitcoin#14978 with no apparent objections, as being a terrible abuse of operator overloading. I think instead the right thing is "can be merged with" or "compatible with". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#504 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFgC0wCt17sJ-2gGiHZKlJXcX6RZVd8Sks5vNLxBgaJpZM4a0x5X> .

[gwillen]

see #600

[instagibbs]

this was completed