public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew Chow <achow101-lists@achow101•com>
To: Andrew Poelstra <apoelstra@wpsoftware•net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 / PSBT extensions
Date: Thu, 07 Mar 2019 15:34:26 +0000	[thread overview]
Message-ID: <dSmKNsbsqQaRCPeT2EYOwhAvBXUvtSVJZVPLSAeYnSElB0WM7iY3nKQJfQAj3AWfP-oFpTqKk9OvrQtlM6W3c_2tv9HwGN5cYy_XgZuDiGM=@achow101.com> (raw)
In-Reply-To: <20190306180800.GC10453@boulet>

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

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

>

[-- Attachment #2: Type: text/html, Size: 5772 bytes --]

  reply	other threads:[~2019-03-07 15:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 18:08 Andrew Poelstra
2019-03-07 15:34 ` Andrew Chow [this message]
2019-03-08  0:40   ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='dSmKNsbsqQaRCPeT2EYOwhAvBXUvtSVJZVPLSAeYnSElB0WM7iY3nKQJfQAj3AWfP-oFpTqKk9OvrQtlM6W3c_2tv9HwGN5cYy_XgZuDiGM=@achow101.com' \
    --to=achow101-lists@achow101$(echo .)com \
    --cc=apoelstra@wpsoftware$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox