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@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>