Andrew Chow [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-07 📝 Original message:Hi Andrew, I think having ...
📅 Original date posted:2019-03-07
📝 Original message: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:
> 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.
> 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
> 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 at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190307/2ac6f69d/attachment.html>;
📝 Original message: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:
> 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.
> 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
> 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 at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190307/2ac6f69d/attachment.html>;