Date: Thu, 14 Jan 2021 17:07:44 +0000
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <40f91a9a-6905-ad94-2824-16b43a0fa1fa@achow101.com>
In-Reply-To: <87a6tk9s7t.fsf@rustcorp.com.au>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
 <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
 <87wnwpabq6.fsf@rustcorp.com.au>
 <f20b7586-26b5-2250-322c-3004563f561e@achow101.com>
 <87a6tk9s7t.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] New PSBT version proposal
Precedence: list


On 1/7/21 7:40 PM, Rusty Russell wrote:
> 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 =3D 0x05
>>>>    =C2=A0 * Key: empty
>>>>    =C2=A0 * 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 omitte=
d
>>>> 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 i=
s
>>>> 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.
Changing that is a bigger change and I'd rather keep this as minimal as=20
possible. Having only new fields is simpler.

>>> 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.
I think we do need to support adding signed inputs and adding inputs to=20
signed transactions. Someone had asked for this feature before.=20
Additionally Nicolas Dorier informed me that his NTumbleBit project does=20
those things.

In that case, I will include your suggestions for=20
PSBT_GLOBAL_UNDER_CONSTRUCTION in the BIP.


Andrew Chow
>
> Cheers,
> Rusty.