Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAD5xwhjqF3b896vV=w7BPDMAnhe49qJO-KgPyAW+5qKjZywEhQ@mail.gmail.com>
Date: Sun, 03 Jul 2022 07:45:48 +0200
Message-Id: <163978583-4822df8d32d6f90c80179ca227a2320a@pmq5v.m5r2.onet>
Subject: Re: [bitcoin-dev] Adding SIGHASH to TXID
Precedence: list

> Have you seen the inherited ID proposal from John Law on this list?

I didn't see that before posting, I'm still trying to get more familiar wit=
h that (and with proposals, where every single field in each transaction is=
 controlled for inclusion or exclusion).

> Honestly, I've yet to fully load in exactly how the applications of it wo=
rk, but I'd be interested to hear your thoughts.

The main use case is to control transaction flow. If you have everything si=
gned with SIGHASH_ALL, then it is obvious that you can just use txid, and e=
verything works. But on the other hand, if you use other sighashes, for exa=
mple SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then you should be able to make a=
 new transaction spending your signed output, no matter which inputs and ou=
tputs will be added to the previous one. And that's why SIGHASH_PREVOUT_SOM=
ETHING is needed, to control, which parts of the previous transaction are s=
igned, and which are not. And to do that, it is needed to take the previous=
 transaction, referenced by txid, and to modify it, based on provided SIGHA=
SH_PREVOUT_SOMETHING sighashes.

To push things one step further, I think different sighashes should be prop=
osed by default, that would make users more familiar with the whole concept=
 of sighashes. Because now, the default behavior is to sign everything with=
 SIGHASH_ALL. I think it should be changed, the Core client should propose =
different sighashes, based on created transaction, just to allow transactio=
n joining. To start with, it could be just a simple checkbox "allow transac=
tion joining", that would enable it, to see if it will be simple enough for=
 most users.

SIGHASH_ANYONECANPAY - used for every input (because it allows fee bumping =
without changing signatures)
SIGHASH_SINGLE - used only when there is any corresponding output, and only=
 when it has higher or equal amount than the corresponding input
SIGHASH_ALL - used when there is no corresponding output, or when the corre=
sponding output is smaller, to prevent detaching it

In general, I think the transaction should be displayed like it is visible =
in many block explorers, and after clicking each input, users should see, w=
hat is signed, and what is not, so they should control sighashes in a simil=
ar user interface, as they use to choose coins. Inputs and outputs should b=
e grayed or highlighted, based on sighashes selected by user, to allow unde=
rstanding them better.


On 2022-05-07 13:55:48 user Jeremy Rubin <jeremy.l.rubin@gmail.com> wrote:
Have you seen the inherited ID proposal from John Law on this list?


It's a pretty thorough treatment of this type of proposal, curious if you t=
hink it overlaps what you had in mind?


Honestly, I've yet to fully load in exactly how the applications of it work=
, but I'd be interested to hear your thoughts.


On Sat, May 7, 2022, 4:55 AM vjudeu via bitcoin-dev <bitcoin-dev@lists.linu=
xfoundation.org> wrote:
For now, we have txid:vout as a previous transaction output. This means tha=
t to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just t=
o prevent any transaction modifications that can happen during adding some =
inputs and outputs. But it seems that new sighashes could be far more power=
ful than we expected: it is technically possible to not only remove previou=
s transaction output by using SIGHASH_ANYPREVOUT. We can do more and do it =
better, we could decide, how to calculate this txid at all!

So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE (a=
pplied to the previous transaction, taken from txid). To have SIGHASH_ANYPR=
EVOUT, we need to remove absolutely everything, I don't know any such sigha=
shes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at least=
 to some fields, for example to the locktime. But, if we introduce SIGHASH_=
PREVOUT_XYZ flags for all existing sighashes, we would have this:

SIGHASH_PREVOUT_NONE
SIGHASH_PREVOUT_SINGLE
SIGHASH_PREVOUT_ALL
SIGHASH_PREVOUT_ANYONECANPAY

Then, the procedure is as follows: we use txid:vout to find our previous tr=
ansaction. Then, we apply those sighashes to this previous transaction, to =
form a new txid, that will be checked during every OP_CHECKSIG-based opcode=
. In this way, our txid:vout is used just to do transaction lookup, after t=
hat, sighashes can be applied to the previous transaction, so our txid coul=
d remain stable, even if someone will add some inputs and outputs.

By default, we could use SIGHASH_PREVOUT_ALL, that would mean our txid:vout=
 remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously mean, that=
 we want to commit only to this particular previous transaction output. Tha=
t would allow adding any new outputs to the previous transaction, without a=
ffecting our replaced txid, but also without blindly accepting any txid, be=
cause some data of the previous transaction would be still hashed.

Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean th=
at no outputs of the previous transaction are checked. But still, the input=
s will be! That would mean: "I don't care about in-between addresses, but I=
 care that it was initiated from these inputs". In this case, it is possibl=
e to choose some input without those flags, and then apply SIGHASH_PREVOUT_=
NONE many times, to make sure that everything started from that input, but =
everything in-between can be anything.

All of those three SIGHASH_PREVOUT_XYZ flags could be combined with SIGHASH=
_PREVOUT_ANYONECANPAY. That would mean all inputs of the previous transacti=
on are discarded, except from the input number matching "vout". Or we could=
 just use SIGHASH_PREVOUT_ANY instead and discard all inputs from that prev=
ious transaction, that could also be combined with other sighashes.

So, to sum up, by applying sighashes to the previous transaction, instead o=
f allowing for any transaction, we could still have some control of our txi=
d, and I think it could be better than just saying "give me any txid, I wil=
l accept that". I think in most cases we don't want to allow any txid: we w=
ant to only "control the flow", just to make sure that our signatures will =
sign what we want and will not be invalidated by changing some transaction =
inputs and outputs, unrelated to the currently-checked signature.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev