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