BIP 174: Partially Signed Bitcoin Transaction (PSBT) Format

achow101 commented at 5:05 am on August 26, 2017: member

This proposal was submitted to the mailing list on August 18th and has received no relevant commentary, so I am now requesting a BIP number.

achow101 commented at 2:10 am on September 9, 2017: member

@luke-jr number please?

dabura667 commented at 4:26 am on September 9, 2017: none

Actually I sent a proposal to the mailing list last year…. the only person who contacted me was @dcousens the head maintainer of bitcoinjs-lib

dcousens commented at 2:42 am on September 15, 2017: contributor

Maybe we could each hop on a call to talk about a communal approach to this?

luke-jr renamed this:
~~[New BIP] Partially Signed Bitcoin Transaction format~~
BIP 174: Partially Signed Bitcoin Transaction (PSBT) Format
on Sep 16, 2017

luke-jr added the label New BIP on Sep 16, 2017

luke-jr commented at 2:50 am on September 16, 2017: member

Please use BIP number 174.

in bip-psbt.mediawiki:127 in 1d24a38caa outdated

122+| The hash160 of the redeem script
123+| A redeem script that will be needed to sign a Pay-To-Script-Hash input.
124+|-
125+| <tt>0x02</tt>
126+| Witness Script
127+| The sha256 hash of the witness script

luke-jr commented at 2:51 am on September 16, 2017:

Why not have the key data include the witness program version, so it can be non-V0?

achow101 commented at 3:59 am on September 16, 2017:

This isn’t defining witness programs. It is defining the very specific witness script of a P2WSH output.

luke-jr commented at 5:00 am on September 16, 2017:

I don’t know what you mean. The value is the specific script, but the key is the hash of it…

achow101 commented at 4:25 pm on September 16, 2017:

The key is used as a unique identifier for the script. It is not defining anything for the witness program. For future witness programs, I don’t think it is safe to assume that future witness programs will also be using the hash of something in the witness program. I also don’t think that the types should be overloaded. The key here is specifically one type: a sha256 hash. However to do what you suggest means that the key can have more than one type in the future.

sipa commented at 6:29 pm on September 17, 2017:

Perhaps instead of being specific to witness scripts (v0 P2WSH only), it could be a generic “SHA256 preimages” field, where the key is a SHA256 hash, and the value is the bytes that hash to it, independently of what it’s used for.

achow101 force-pushed on Sep 16, 2017

dabura667 commented at 7:25 am on September 16, 2017: none

https://appear.in/psbt-discussion

I went ahead and claimed this room, and will get notifications when someone enters via the app or via browser (no sign up required)

Be careful though, as the default setting has the webcam automatically turn on, so click the camera icon to disable your camera as soon as you enter.

dabura667 commented at 7:28 am on September 16, 2017: none

https://docs.google.com/spreadsheets/d/1PSnBDtu7KCzeEltXySTtFFDaXIoFk7MF7umAxooLRho/edit?usp=sharing

Here’s the google doc @dcousens and I were using in January when we discussed this. @achow101 if you make a comment on one of the cells, I’ll add your account as an editor.

dabura667 commented at 7:30 am on September 16, 2017: none

https://gist.github.com/dcousens/8e72ff7ddf1f189cb7bbe42d0aeca9ce

Also this was something @dcousens worked on prior.

Perhaps we can find a time when Japan, Australia, and wherever @achow101 lives can meet up for a call?

dabura667 commented at 7:30 am on September 16, 2017: none

I will be in SF for Scaling Bitcoin btw.

dabura667 commented at 7:42 am on September 16, 2017: none

Here are some comments I made to @dcousens

I kept thinking down the rabbit hole, and imagined an entire protocol where a wallet can just create the sighash preimage, generate the hash, generate the signature, and reencode the signature into the data so that another party could sign or complete the serialized complete transaction data.

After thinking for a while, I decided to put my goal into a single sentence.

“By parsing the data alone, a compliant wallet will know exactly what they need to sign, where to put the signatures, and how to serialize the completed transaction in the event of completion without ant prior agreed upon template.”

By doing so, it would be possible for a wallet that is single sig only to just implement the standard, and be able to sign a multisig without even knowing it is a part of a multisig. It just follows the rules, creates the tx for signing and signs, then adds the signature binary data to the data chunk (URI or otherwise)

After thinking a lot, there should also be perhaps two separate related BIPs on relay methods and initialization methods.

ie. Which methods are supported? If we recommend a JSON API, what are the necessary endpoints? Do we support IP direct connection or not? etc. Should there be voluntary discovery like Electrum nodes? Etc etc

ie. How do you set up the configuration and share it between wallets? How do you “backup” the configurations (having such freedom means that private keys are not our only worry anymore, we must remember which private key was a member of what type of wallet and where is the metadata stored if any (a la Copay stores in BWS)

I think we could make these three BIPs encompass a large possibility space to allow for true wallet interoperability rather than just have it be a way to encode the same old cookie cutter transactions by using previous knowledge of a popular template etc.

achow101 force-pushed on Sep 16, 2017

achow101 commented at 4:17 pm on September 16, 2017: member

Perhaps we can find a time when Japan, Australia, and wherever @achow101 lives can meet up for a call?

That may be hard to do. I live on the East coast of the US.

dcousens commented at 11:57 pm on September 16, 2017: contributor

How about 2000 EDT tomorrow? (1000 AEST, 0900 JST) @junderw

achow101 commented at 2:06 am on September 17, 2017: member

How about 2000 EDT tomorrow? (1000 AEST, 0900 JST)

OK

junderw commented at 2:58 am on September 17, 2017: contributor

Sounds good to me. Just hop in the appear.in and we should be good

dabura667 commented at 0:02 am on September 18, 2017: none

https://appear.in/psbt-discussion @dcousens We’re in the chat now.

achow101 commented at 1:50 am on September 18, 2017: member

Some TODOs before merging:

Sighash type for inputs
Include more information about adding new types (appendix of new types)
Include number of inputs for future extensibilty with more blocks of data
Examples/basic format/pipe format for each key-value pair

achow101 force-pushed on Sep 18, 2017

achow101 commented at 2:53 am on September 18, 2017: member

@junderw @dcousens I have made the changes that we talked about in the call. Does this look good to you guys?

I’ll add the test vectors and full breakdown examples once this is merged and after I update my reference implementation.

in bip-0174.mediawiki:156 in 87fc97244b outdated

151+| The public key
152+| The master key fingerprint concatenated with the derivation path of the public key. The
153+derivation path is represented as 32 bit unsigned integer indexes concatenated
154+with each other. This must omit the index of the master key.
155+| <pre>
156+    <key length>|0x03|<public key>|<value length>|<master key fingerprint>|<32-bit int>|...|<32-bit int>

dcousens commented at 3:00 am on September 18, 2017:

value length being the number of 32-bit int indexes?

if so, why <master key fingerprint> in between the <value length> and <values ...>

achow101 commented at 3:06 am on September 18, 2017:

The value length is the length in bytes of the concatenation of <master key fingerprint>|<32-bit int>|...|<32-bit int>. The next commit should make this clearer.

dcousens commented at 3:07 am on September 18, 2017:

@achow101 isn’t master key fingerprint fixed size anyway? or is this part of the <key length> <key> <value length> <value> approach?

achow101 commented at 3:08 am on September 18, 2017:

this part of the <key length> <key> <value length> <value> approach?

^That

in bip-0174.mediawiki:164 in 87fc97244b outdated

159+| <tt>0x04</tt>
160+| Number of inputs
161+| None. The key must only contain the 1 byte type.
162+| A compact size unsigned integer representing the number of inputs that this transaction has
163+| <pre>
164+    <0x01>|0x04|<number of inputs>

dcousens commented at 3:01 am on September 18, 2017:

what is the difference between <0x01> and 0x01, you fluctuate between both styles?

achow101 commented at 3:07 am on September 18, 2017:

Fixed.

achow101 force-pushed on Sep 18, 2017

in bip-0174.mediawiki:257 in 87fc97244b outdated

205+| The 32-bit unsigned integer recommending a sighash type to be used for this input.
206+The sighash type is only a recommendation and the signer does not need to use
207+the sighash type specified.
208+| <pre>
209+    0x01|0x03|<sighash type>
210+  </pre>

dcousens commented at 3:06 am on September 18, 2017:

to clarify, to omit 50/51 inputs, leaving the 51st input to be signed, you’d have to include 50x 0x00 separators? Could there by an optional vin type?

achow101 commented at 3:13 am on September 18, 2017:

Added

achow101 force-pushed on Sep 18, 2017

in bip-0174.mediawiki:191 in 843b5d7cd5 outdated

186+| <tt>0x01</tt>
187+| Witness UTXO
188+| None. The key must only contain the 1 byte type.
189+| The entire transaction output in network serialization which the current input spends from.
190+| <pre>
191+    <key length(0x01)>|0x01|<hash160>|<redeem script length>|<redeem script>

dcousens commented at 3:10 am on September 18, 2017:

you say TXO, but you have only redeem script (and no satoshis/amount?)

achow101 commented at 3:13 am on September 18, 2017:

Oops. bad copy paste.

achow101 force-pushed on Sep 18, 2017

in bip-0174.mediawiki:146 in 1b03e5a0f8 outdated

141+| <tt>0x02</tt>
142+| Witness Script
143+| The sha256 hash of the witness script
144+| A witness script that will be needed to sign a Pay-To-Witness-Script-Hash input.
145+| <pre>
146+    <key length>|0x02|<sha256>|<witness script length>|<witness script>

dcousens commented at 3:17 am on September 18, 2017:

maybe <key length> should include the type prefix, then you can simply define <key length> as a the length of the <key>, and interpreters interpret the first byte of a key as a type. That way there is less back-and-forth over the definition, and its consistent. I suspect this is how your implementation would work internally anyway.

For example, as your definition:

0<key length> | <key(0x02 | sha256(<witness script>)) | <value length> | <value(witness script)>

Hell, then you could simplify the entire defintion to simply key and value, with a line at the top here saying key and length are both prefixed by their length as a varint (or whatever).

Then , this would simply be:

0key: <0x02 | sha256({witness script})>
1value: <witness script>

<...> indicates length prefixed {} indicates raw data

With both key and value always prefixed by varint length.

dcousens commented at 3:19 am on September 18, 2017:

If you want to move past this now, and we’re on the same page, I could submit this as a PR later if you’d like.

achow101 commented at 3:39 am on September 18, 2017:

That is what I originally meant. The latest changes should make that clearer.

achow101 force-pushed on Sep 18, 2017

Specify the Partially Signed Bitcoin Transaction format in a BIP 958641741b

achow101 force-pushed on Sep 18, 2017

dcousens commented at 4:27 am on September 18, 2017: contributor

^ Why are outputs’ redeem scripts and witness scripts included? Redeem scripts and witness scripts spent to by an output in this transaction are included so that the user can verify that the transaction they are signing is creating the correct outputs that have the correct redeem and witness scripts. This is best used when the PSBT creator is not trusted by the signers.

:heart:

ACK, as discussed on IRC, with this added I don’t think an outputs extension is as necessary as you can now verify what outputs might be (P2WSH etc).

The negotiation of the outputs themselves is still out of band, but I think we have agreed for now that that may be out of scope, and or could easily be added in an extension.

dcousens approved

luke-jr merged this on Sep 18, 2017

luke-jr closed this on Sep 18, 2017

BIP 174: Partially Signed Bitcoin Transaction (PSBT) Format #583