From: Rusty Russell <rusty@rustcorp•com.au>
To: Andrew Chow <achow101-lists@achow101•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] New PSBT version proposal
Date: Fri, 08 Jan 2021 11:10:06 +1030 [thread overview]
Message-ID: <87a6tk9s7t.fsf@rustcorp.com.au> (raw)
In-Reply-To: <f20b7586-26b5-2250-322c-3004563f561e@achow101.com>
Andrew Chow <achow101-lists@achow101•com> writes:
> Hi Rusty,
>
> On 1/6/21 6:26 PM, Rusty Russell wrote:
>> Hi Andrew et al,
>>
>> Very excited to see this progress; thanks for doing all the
>> work! Sorry for the delayed feedback, I didn't get to this before the
>> break.
>>
>>> Additionally, I would like to add a new global field:
>>> * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
>>> * Key: empty
>>> * Value: A single byte as a boolean. 0 for False, 1 for True. All
>>> other values ore prohibited. Must be omitted for PSBTv0, may be omitted
>>> in PSBTv2.
>>>
>>> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
>>> outputs can be added to the PSBT. This flag may be set to True when
>>> inputs and outputs are being updated, signed, and finalized. However
>>> care must be taken when there are existing signatures. If this field is
>>> omitted or set to False, no further inputs and outputs may be added to
>>> the PSBT.
>> I wonder if this can be flagged simply by omitting the (AFAICT
>> redundant) PSBT_GLOBAL_INPUT_COUNT and PSBT_GLOBAL_OUTPUT_COUNT? What
>> are the purposes of those fields?
> The purpose of those fields is to know how many input and output maps
> there are. Without PSBT_GLOBAL_UNSIGNED_TX, there is no way to determine
> whether a map is an input map or an output map. So the counts are there
> to allow that.
Ah, yeah, you need at least the number of input maps :(
It's generally preferable to have sections be self-describing;
internally if you have a function which takes all the input maps you
should be able to trivially tell if you're handed the output maps by
mistake. Similarly, it would have been nice to have an input map be a
distinctly marked type from global or output maps.
Nonetheless, that's a bigger change. You could just require a double-00
terminator between the global, input and output sections though.
>> For our uses, there would be no signatures at this stage; it's simply a
>> subdivision of the Creator role. This role would be terminated by
>> removing the under-construction marker. For this, it could be clear
>> that such an under-construction PSBT SHOULD NOT be signed.
>
> There are some protocols where signed inputs are added to transactions.
Sure, but you can't solve every problem. We've now created the
possibility that a PSBT is "under construction" but can't be modified,
*and* a very invasive requirement to determine that.
I disagree with Andrew's goal here:
> 1. PSBT provides no way to modify the set of inputs or outputs after the
> Creator role is done.
It's simpler if, "the under-construction PSBT can be used within the
Creator role, which can now have sub-roles".
If you really want to allow this (and I think we need to explore
concrete examples to justify this complexity!), better to add data to
PSBT_GLOBAL_UNDER_CONSTRUCTION:
1. a flag to indicate whether inputs are modifiable.
2. a flag to indicate whether outputs are modifiable.
3. a bitmap of what inputs are SIGHASH_SINGLE.
If you add a signature which is not SIGHASH_NONE, you clear the "outputs
modifiable" flag. If you add a signature which is not
SIGHASH_ANYONECANPAY, you clear the "inputs modifiable" flag. If you
clear both flags, you remove the PSBT_GLOBAL_UNDER_CONSTRUCTION
altogether. You similarly set the bitmap depending on whether all sigs
are SIGHASH_SINGLE.
Cheers,
Rusty.
next prev parent reply other threads:[~2021-01-08 0:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 22:25 Andrew Chow
2020-12-10 11:28 ` Sanket Kanjalkar
2020-12-16 17:44 ` Andrew Poelstra
2020-12-22 20:12 ` Andrew Chow
2020-12-23 3:30 ` fiatjaf
2020-12-23 15:22 ` Andrew Poelstra
2020-12-23 21:30 ` Andrew Chow
2021-01-02 6:34 ` Jeremy
2020-12-23 21:32 ` Andrew Chow
2021-01-15 17:28 ` Andrew Chow
2021-01-21 19:50 ` Andrew Chow
2021-01-06 23:26 ` Rusty Russell
2021-01-06 23:48 ` Andrew Chow
2021-01-08 0:40 ` Rusty Russell [this message]
2021-01-14 17:07 ` Andrew Chow
2021-03-10 0:20 ` Lloyd Fournier
2021-04-05 0:35 ` Lloyd Fournier
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=87a6tk9s7t.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=achow101-lists@achow101$(echo .)com \
--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