BIP174 / PSBT extensions
3 messages, 6 to 8 Mar 2019. Started by Andrew Poelstra.
Andrew Poelstra, Andrew Chow, Gregory Maxwell
Hi all,
I'd like to start initial discussion about an extension to BIP174 [1] to add some fields that I've found myself wanting when using PSBT in practice. For now I'll just list the things that I'd like to see, and if we can come up with a stable list then I'll try to write up a more formal draft.
Basically I'd just like to add some more fixed data fields.
1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains just a txid of the unsigned transaction, for bandwidth savings in case signers have already seen the tx or can construct it themselves.
This field would be fixed 32 bytes.
(This would actually be a breaking change since the current PSBT rules require PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for that reason alone.)
2. Add a version field to the global table.
3. Add fields to the per-input tables for
(a) confirmed depth of the referenced txout; this is useful for finalizers
trying to create optimized witnesses, for e.g. cases when CSV timeouts
expire and some signatures become unnecessary.
This field must be a varint.
(b) a map from SHA2 hashes to their 32-byte preimages; this field must be
fixed 32 bytes. This, plus the CSV thing, would allow writing finalizers
that work with all of Miniscript [2].
(c) a map from public keys to 32-byte "tweaks" that are used in the pay-to-contract
construction. Selfishly I'd like this to be a variable-length bytestring
with the semantics that (a) the first 33 bytes represent an untweaked
pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G and
added to the untweaked pubkey, result in the target key. This matches the
algorithm in [3] which is deployed in Blockstream's Liquid, but I'd be
happy with a more efficient scheme which e.g. used SHA256 rather than
HMAC-SHA256.
(d) maps from public keys to partial nonce commitments, partial nonces, and
partial signatures, for MuSig [4] support.
(e) a map from signatures (or signature nonces?) to sign-to-contract tweaks.
Same semantics as (c) above.
The last two suggestions are probably premature and need further development and standardization of the related protocols. But I'm throwing them in to see if other people have strong feelings about this.
4. Add fields to the per-output tables for pay-to-contract, like in (c) above.
5. Add a field (or rather, family of fields) to every table which is "proprietary use" and guaranteed not to be defined by any future PSBT extension. Specifically every field with key-type 0xFF could be considered "proprietary".
5a. The special field in the global table whose key is only 0xFF should be a
"proprietary version field" with unspecified semantics but an understanding
that specific users might stick a GUID or something in there as a way to
recognize their own PSBTs.
[1] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding [2] http://bitcoin.sipa.be/miniscript/miniscript.html [3] https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/validation.cpp [4] https://eprint.iacr.org/2018/068
Hi Andrew,
I think having some of these extensions would be great.
On 3/6/19 1:08 PM, Andrew Poelstra via bitcoin-dev wrote:
Quoted text (9 lines)
> 1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains > just a txid of the unsigned transaction, for bandwidth savings in case > signers have already seen the tx or can construct it themselves. > > This field would be fixed 32 bytes. > > (This would actually be a breaking change since the current PSBT rules require > PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for that > reason alone.)
I feel like this breaks the central idea of PSBT that a PSBT contains everything you need to construct a transaction. This would rely on parties in the transaction having state and remembering things which I don't think is something that we can assume.
Quoted text (1 line)
> 2. Add a version field to the global table.
For what purpose?
The rest of the proposed extensions I think are fine.
Regards,
Andrew Chow
Quoted text (68 lines)
> 3. Add fields to the per-input tables for > (a) confirmed depth of the referenced txout; this is useful for finalizers > trying to create optimized witnesses, for e.g. cases when CSV timeouts > expire and some signatures become unnecessary. > > This field must be a varint. > > (b) a map from SHA2 hashes to their 32-byte preimages; this field must be > fixed 32 bytes. This, plus the CSV thing, would allow writing finalizers > that work with all of Miniscript [2]. > > (c) a map from public keys to 32-byte "tweaks" that are used in the pay-to-contract > construction. Selfishly I'd like this to be a variable-length bytestring > with the semantics that (a) the first 33 bytes represent an untweaked > pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G and > added to the untweaked pubkey, result in the target key. This matches the > algorithm in [3] which is deployed in Blockstream's Liquid, but I'd be > happy with a more efficient scheme which e.g. used SHA256 rather than > HMAC-SHA256. > > (d) maps from public keys to partial nonce commitments, partial nonces, and > partial signatures, for MuSig [4] support. > > (e) a map from signatures (or signature nonces?) to sign-to-contract tweaks. > Same semantics as (c) above. > > The last two suggestions are probably premature and need further development > and standardization of the related protocols. But I'm throwing them in to see > if other people have strong feelings about this. > > 4. Add fields to the per-output tables for pay-to-contract, like in (c) above. > > 5. Add a field (or rather, family of fields) to every table which is "proprietary > use" and guaranteed not to be defined by any future PSBT extension. Specifically > every field with key-type 0xFF could be considered "proprietary". > > 5a. The special field in the global table whose key is only 0xFF should be a > "proprietary version field" with unspecified semantics but an understanding > that specific users might stick a GUID or something in there as a way to > recognize their own PSBTs. > > [1] > https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding > [2] > http://bitcoin.sipa.be/miniscript/miniscript.html > [3] > https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/validation.cpp > [4] > https://eprint.iacr.org/2018/068 > -- > Andrew Poelstra > Director of Research, Blockstream > Email: apoelstra at wpsoftware.net > Web: > https://www.wpsoftware.net/andrew > "There are some mornings when the sky looks like a road > There are some dragons who were built to have and hold > And some machines are dropped from great heights lovingly > And some great bellies ache with many bumblebees > And they sting so terribly" > --Joanna Newsom > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Thu, Mar 7, 2019 at 11:49 PM Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (3 lines)
> I feel like this breaks the central idea of PSBT that a PSBT contains everything you need to construct a transaction. > This would rely on parties in the transaction having state and remembering things which I don't think is something > that we can assume.
I think it's perfectly fine for someone to have a propritary extension to PSBT that isn't going to work right unless used only between their own stuff or need a translator to talk to ordinary PSBT stuff.
For that purpose, having some kind of versioning field that you can use to indicate what weird PSBT dialect you're speaking might be helpful, if only to allow for more reasonable error messages.