diff options
author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-05-07 07:55:35 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-07 11:55:51 +0000 |
commit | c88d8d4b9d04f6f81fbfb988e305771d6868dc35 (patch) | |
tree | 90ddd56fba39f9d84f9f4897b09683d97dadd037 | |
parent | 410b9f5874d687a210e0bac1a320d016101b2d08 (diff) | |
download | pi-bitcoindev-c88d8d4b9d04f6f81fbfb988e305771d6868dc35.tar.gz pi-bitcoindev-c88d8d4b9d04f6f81fbfb988e305771d6868dc35.zip |
Re: [bitcoin-dev] Adding SIGHASH to TXID
-rw-r--r-- | 65/faf7b229b1231cdbe13ac526c5612118ae5cc1 | 244 |
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'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've yet to fully load in exactly how the applications of it = +work, but I'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 <<a href=3D"mailto:bitcoin-dev@list= +s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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: "I don't care about in-between address= +es, 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 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 "vout". 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 "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 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-- + |