path: root/5c/cd19044a161f3622527a7d705738e9a58803ae

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 71382C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Jul 2022 05:55:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 455F3607B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Jul 2022 05:55:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 455F3607B0
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=InvvhC14
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id E96BWN7Klrk6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Jul 2022 05:55:58 +0000 (UTC)
X-Greylist: delayed 00:10:00 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6FE9F6077D
Received: from smtpo78.poczta.onet.pl (smtpo78.poczta.onet.pl [141.105.16.28])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6FE9F6077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Jul 2022 05:55:57 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4LbHwZ0Yqxz2K24DV;
 Sun,  3 Jul 2022 07:45:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1656827150; bh=8GcMR7/aGInn/iGSRRbaXSdch5FHzPW6f81zSbw9UNA=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=InvvhC14kWql1+DcB1HP+lk+XYibeqsZyk3t1VrePMN7eLZgGIMTAePnmmFk51AtZ
 D/MAkznnMKHrJjObnmB94/oNDohrFtMmWK4GICQxbXhOYnsl8jVz3GoEd9I13osLiw
 fGHZGqgzUushVURDLFhs0u5P6s8xldAECmDsCm7U=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.224.149] by pmq5v.m5r2.onet via HTTP id ;
 Sun, 03 Jul 2022 07:45:50 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
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>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.224.149;PL;2
X-Mailman-Approved-At: Sun, 03 Jul 2022 07:44:37 +0000
Subject: Re: [bitcoin-dev] Adding SIGHASH to TXID
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Jul 2022 05:55:59 -0000

> 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