path: root/65/faf7b229b1231cdbe13ac526c5612118ae5cc1

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3087DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 11:55:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1110F60C34
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 11:55:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 z1hPaICiEs0W
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 11:55:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [IPv6:2a00:1450:4864:20::231])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 980AC60B88
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 11:55:49 +0000 (UTC)
Received: by mail-lj1-x231.google.com with SMTP id 4so11971077ljw.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 07 May 2022 04:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=l3g9AZKs/nO0nky/VpjTIPG1cTQGJb8ZkSLxUaLp/gs=;
 b=Z0I+HW5RzY5LhT3Z8I/7b3MFks6B8Edgv+XGPma6k2QdQlpTrQb89vB8LAjg3UcCYM
 cPNn1SmuiaIMIGkus2zMgItfl7hjb2rbtuZkn9iN6tn3VGTiDWHBRYRkyJ+LiBqRUrs2
 xm5A4vaNoTHI/i+BWJDVjkYWkwdfv9VIX/tf7JJbO3qJnq+fd7/tk2P9NO6CBub9eA1R
 QTH63eO5gG9Wmw3tFMMymi+Q800PCUhZg7vvRvSd+QpGhtc5SpFYjxr9DvLZte1Yxngl
 JPEsee7KXhAQ6PjeMZ+aCcZV1AqJfwP+q4nX/XbygmvetTMukrXq4BoipLWiH66XvSBv
 2NpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=l3g9AZKs/nO0nky/VpjTIPG1cTQGJb8ZkSLxUaLp/gs=;
 b=NygtwH8xZVJ1GedpDmASwORsllzmfedn038CpXQoQINcR6coD9m5JvnoqbsuZltxpI
 xxxo3HBzRtDlA8aZiySHE2JntgfktIGa0cOzUs7GtKHWKjfeUmy+gvSyaFqfXnp/NVXp
 QU8RTyu2LfJYJrLwJJ1EGjFeK/Yez+WCObufN11dg6SJA72R+f72IxyYol4qW4NHYi3J
 9rj1Xl9JdfKi1Wlp8xtPrQl4pwnPA9icgIxcfr7qzT6zddHgz5hsFyoUGKbXbvhk8quS
 X8BdmGygU+DZt+N5vvCorhHjYr6f15dETur712jmPEXSgt9U7MS+dvRqV/z+sFNF5S16
 KYqg==
X-Gm-Message-State: AOAM532KKqIWdKK4m8Gujt5KXyP0Iaznr3jEj4SNXlOMTQ45HaI/xM0K
 BcMPqPKmIxiDYA1tcwuJAzvOnUSlWsnCw29SiNY=
X-Google-Smtp-Source: ABdhPJy95RpfrjimmW4wLJnu2aFAJXRJnT87g+UVbMo1Fe3zD562yWfAMw6rEZcSbzG9XN2c7y4x7oTf/hWc+aZz7uM=
X-Received: by 2002:a2e:a555:0:b0:250:66c5:943f with SMTP id
 e21-20020a2ea555000000b0025066c5943fmr4921184ljn.376.1651924547327; Sat, 07
 May 2022 04:55:47 -0700 (PDT)
MIME-Version: 1.0
References: <75be7180-709a-b735-a27b-50d0c6a2af5b@gazeta.pl>
In-Reply-To: <75be7180-709a-b735-a27b-50d0c6a2af5b@gazeta.pl>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Sat, 7 May 2022 07:55:35 -0400
Message-ID: <CAD5xwhjqF3b896vV=w7BPDMAnhe49qJO-KgPyAW+5qKjZywEhQ@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d6db8605de6aa707"
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: Sat, 07 May 2022 11:55:51 -0000

--000000000000d6db8605de6aa707
Content-Type: text/plain; charset="UTF-8"

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
think 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.linuxfoundation.org> wrote:

> For now, we have txid:vout as a previous transaction output. This means
> that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere,
> just to prevent any transaction modifications that can happen during adding
> some inputs and outputs. But it seems that new sighashes could be far more
> powerful than we expected: it is technically possible to not only remove
> previous 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
> (applied to the previous transaction, taken from txid). To have
> SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know
> any such sighashes, 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
> transaction. 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 that, sighashes can be applied to the previous transaction, so our
> txid could 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. That would allow adding any new outputs to the previous
> transaction, without affecting our replaced txid, but also without blindly
> accepting any txid, because some data of the previous transaction would be
> still hashed.
>
> Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean
> that no outputs of the previous transaction are checked. But still, the
> inputs 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
> possible 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
> transaction are discarded, except from the input number matching "vout". Or
> we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from
> that previous transaction, that could also be combined with other sighashes.
>
> So, to sum up, by applying sighashes to the previous transaction, instead
> of allowing for any transaction, we could still have some control of our
> txid, and I think it could be better than just saying "give me any txid, I
> will accept that". I think in most cases we don't want to allow any txid:
> we want 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
>

--000000000000d6db8605de6aa707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Have you seen the inherited ID proposal from John Law on =
this list?<div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;s a pretty t=
horough treatment of this type of proposal, curious if you think it overlap=
s what you had in mind?</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Honestly, I&#39;ve yet to fully load in exactly how the applications of it =
work, but I&#39;d be interested to hear your thoughts.</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 7, =
2022, 4:55 AM vjudeu via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">For now, we have txid:vout as a pr=
evious transaction output. This means that to have a stable TXID, we are fo=
rced to use SIGHASH_ALL somewhere, just to prevent any transaction modifica=
tions that can happen during adding some inputs and outputs. But it seems t=
hat new sighashes could be far more powerful than we expected: it is techni=
cally possible to not only remove previous transaction output by using SIGH=
ASH_ANYPREVOUT. We can do more and do it better, we could decide, how to ca=
lculate this txid at all!<br>
<br>
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&#39;t know any such s=
ighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at l=
east to some fields, for example to the locktime. But, if we introduce SIGH=
ASH_PREVOUT_XYZ flags for all existing sighashes, we would have this:<br>
<br>
SIGHASH_PREVOUT_NONE<br>
SIGHASH_PREVOUT_SINGLE<br>
SIGHASH_PREVOUT_ALL<br>
SIGHASH_PREVOUT_ANYONECANPAY<br>
<br>
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.<br>
<br>
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.<br>
<br>
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: &quot;I don&#39;t care about in-between address=
es, but I care that it was initiated from these inputs&quot;. In this case,=
 it is possible to choose some input without those flags, and then apply SI=
GHASH_PREVOUT_NONE many times, to make sure that everything started from th=
at input, but everything in-between can be anything.<br>
<br>
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 &quot;vout&quot;. O=
r we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from=
 that previous transaction, that could also be combined with other sighashe=
s.<br>
<br>
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 &quot;give me any txid, =
I will accept that&quot;. I think in most cases we don&#39;t want to allow =
any txid: we want to only &quot;control the flow&quot;, just to make sure t=
hat our signatures will sign what we want and will not be invalidated by ch=
anging some transaction inputs and outputs, unrelated to the currently-chec=
ked signature.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d6db8605de6aa707--