summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy Rubin <jeremy.l.rubin@gmail.com>2022-05-07 07:55:35 -0400
committerbitcoindev <bitcoindev@gnusha.org>2022-05-07 11:55:51 +0000
commitc88d8d4b9d04f6f81fbfb988e305771d6868dc35 (patch)
tree90ddd56fba39f9d84f9f4897b09683d97dadd037
parent410b9f5874d687a210e0bac1a320d016101b2d08 (diff)
downloadpi-bitcoindev-c88d8d4b9d04f6f81fbfb988e305771d6868dc35.tar.gz
pi-bitcoindev-c88d8d4b9d04f6f81fbfb988e305771d6868dc35.zip
Re: [bitcoin-dev] Adding SIGHASH to TXID
-rw-r--r--65/faf7b229b1231cdbe13ac526c5612118ae5cc1244
1 files changed, 244 insertions, 0 deletions
diff --git a/65/faf7b229b1231cdbe13ac526c5612118ae5cc1 b/65/faf7b229b1231cdbe13ac526c5612118ae5cc1
new file mode 100644
index 000000000..eed6077b2
--- /dev/null
+++ b/65/faf7b229b1231cdbe13ac526c5612118ae5cc1
@@ -0,0 +1,244 @@
+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--
+