diff options
author | Jonas Nick <jonasdnick@gmail.com> | 2018-09-26 09:36:57 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-09-26 09:34:45 +0000 |
commit | bbfbbc524240f5428115d65e29272f0387986416 (patch) | |
tree | 096f0420dcc172f8f5918b022b5a42a530938c8b | |
parent | c295db0e6789510269b1e43ec219d37c6ae52d6e (diff) | |
download | pi-bitcoindev-bbfbbc524240f5428115d65e29272f0387986416.tar.gz pi-bitcoindev-bbfbbc524240f5428115d65e29272f0387986416.zip |
Re: [bitcoin-dev] BIP sighash_noinput
-rw-r--r-- | 48/ec03202a12baf33d65eb87ae3b366ed6aafa80 | 268 |
1 files changed, 268 insertions, 0 deletions
diff --git a/48/ec03202a12baf33d65eb87ae3b366ed6aafa80 b/48/ec03202a12baf33d65eb87ae3b366ed6aafa80 new file mode 100644 index 000000000..30a55ac6c --- /dev/null +++ b/48/ec03202a12baf33d65eb87ae3b366ed6aafa80 @@ -0,0 +1,268 @@ +Return-Path: <jonasdnick@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E2E721184 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 26 Sep 2018 09:34:45 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com + [209.85.221.52]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CC450762 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 26 Sep 2018 09:34:44 +0000 (UTC) +Received: by mail-wr1-f52.google.com with SMTP id z3-v6so14416095wrr.13 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 26 Sep 2018 02:34:44 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=from:subject:to:references:openpgp:autocrypt:message-id:date + :user-agent:mime-version:in-reply-to:content-language + :content-transfer-encoding; + bh=t04wKvfitIUljS2lyOWqcoQllcbeJsp9Ppox8wr9PZg=; + b=oSyYekf5Zf2xY5bd9DpUHBNDlTeFKnmry6+/0BHGmz4mCALmffPloACMd+5BHeyHXR + Q74ONmrlvypWR+ApjyEKfQN4pdkF1kdsBbxqN9VfOC9OOqVLLt4OrTHtG6AmVzU3XWmh + AtefiAaRfpy9O1wGzl0/MTByHFdekCCjGbgdpI7Ll5B7RmRp8BkNrHvm6rLIU59f7eh4 + IxpTAs9DBbUOubceRSdXC5vG4GmahpqQn09m9WNFrk7JP74/nyBiB+R8nvzDotHFyyar + JfsroD7y/J3DrZ0oC2+0iaT4FbkWS7RKkhchptF2OuL4Nu9+wBH5hFrU6P/SVKnpWDY6 + 9Ggg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:from:subject:to:references:openpgp:autocrypt + :message-id:date:user-agent:mime-version:in-reply-to + :content-language:content-transfer-encoding; + bh=t04wKvfitIUljS2lyOWqcoQllcbeJsp9Ppox8wr9PZg=; + b=Zh4HTXuuMnLrHKcoHPFY8p0xz3Kro9cXqPjhZGDacQDPGTUo/+8SEBexearV1blwQh + 7JkDF82DM0mKnt8qANAcugeMjJxF/BjXqbmOWs5lfhAdphvfCl3b3Kqy48ihH0PeaB90 + UztYigFg21mIt8Zy+m0fljDVrBaNdp0Zwb8S9xE/EuDk6ZZ6mizhFZZIqbhzPqBWAU87 + fUKjp8w19M5rwsK7QqUGd4xjiD6KXe1bl6UnEH81kYrGPqfEYkLeWcjkjnn0LXayTUmB + snCtMjKO/71toh3dQar0Idr0OKtE1AU6E9elhvRscNYC9LzJ/Hy4dMQjih26ZheIpVeZ + L1bA== +X-Gm-Message-State: ABuFfojsh0LdORpuZ+fgDVhIe0sCWA2zds+EYaPGuUsi9rmZUKisf4sU + 1H9Lx2pJfm1Zc+5Ydw96wT8= +X-Google-Smtp-Source: ACcGV63TWH4/s/bcfGGURCYv7BWpBH6ixuQbr2mc1RUdFPDg5q+y92GSZhdQyRSZU41ni38WToAr/A== +X-Received: by 2002:adf:8447:: with SMTP id + 65-v6mr3991643wrf.251.1537954483079; + Wed, 26 Sep 2018 02:34:43 -0700 (PDT) +Received: from [192.168.1.21] (194-166-164-159.adsl.highway.telekom.at. + [194.166.164.159]) by smtp.googlemail.com with ESMTPSA id + k63-v6sm8214123wmd.46.2018.09.26.02.34.41 + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 26 Sep 2018 02:34:42 -0700 (PDT) +From: Jonas Nick <jonasdnick@gmail.com> +X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com> +To: Russell O'Connor <roconnor@blockstream.io>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Christian Decker <decker.christian@gmail.com> +References: <871sewirni.fsf@gmail.com> + <CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com> +Openpgp: preference=signencrypt +Autocrypt: addr=jonasd.nick@gmail.com; prefer-encrypt=mutual; keydata= + xsFNBFQ2o3oBEACv5N5WajlYk+i/4B8FmniipCB4biIKg38spMNt1EYM6RzTu+hbOrVOlJW8 + fq/ih+dvlpreGxRPQlX4jr75kwoJCykd3geywTUl3KPLeJ/JRQJ8fVkine4Wr5qB5Jwo3+wt + inDVooaaF32Y0HolNacXVzT1x9uwn83Bz/ifg+iGATn/e1Si3ga/ytY5wYDzFz6aUDRW8ulu + DcG8ARMAgtzmi66EuyQyIWwSyoWFU8wJ98slU9LKuTu23r6HdxFuV+P2H1omJm+z8cd4QBMj + I23uHst0Wx1MyTeVhZCnQAghyasA3oopwzqRf5wwECAui1oZhr59R4R1DHJjn0PeWZXBSnOo + XPQ1ERjz4nQrODiIDEabD5DClPHZ1bte0tswm1aYBtD8/me9ck+SJdoH5r0DJrXCTtNl1XG1 + 9TTUINQe0eaQUOTakZmVaneCeSrw/pKOknkzudOCNCbmngKa2oJQOynrdsBuoigIYY+NQdot + fk1nJljrBzyTh4sFktbHyA24x/hCykMX6FnIQxDnsGR+S3I+vzADBLBBMQQtZsUA+xnvPu4l + 6You5SZMVhgprQy38bKybeIGxSZtmPNtBf8ouKhAUpbIfOaq6BoP4EtueXk/vyieFxXiIkbF + N6b3pjhkG7wVG17HqCqeVeHz1ZAQJUPcqDQAPaelBf38RXPbeQARAQABzSJKb25hcyBOaWNr + IDxqb25hc2Qubmlja0BnbWFpbC5jb20+wsF/BBMBAgApAhsDBwsJCAcDAgEGFQgCCQoLBBYC + AwECHgECF4AFAlYEdT0FCQdxbEMACgkQsacOT43NA2azdhAAkylnTYtnOrXbd0IPfbTSOQN7 + fBaur/z3/CvO3H26J78tyKncZ6ZTbGWjkBHbbC0Hcer00Mz+XxJnKW9tEQBPdjZ+eWpgAoNp + mHyUDaeyy71H+zd+JGZwAIsg/e27TMymTrFPZc7Bc7b8CjK+iYjE2p+Q1bEDsAODqd2gAKT+ + DhV36NThpllDnJAmJZuF4Vh/otMn7BTBqw9WiHBPymMPyfC/f185+XSopN7za0gPN1Fc8xBd + 3JGrHTB7hi+49w3IVPs1dBLl+B46SzerlkMIpQPZ0y5WIEXae3uz8enLOI9jGIl7TQtFVFow + KAZMO77advua/ih1rq1Or41oM1HJ+VovO4cI4uhCPYUAJWrSb99VzL78hl64sEu3IOTvX1p3 + S1RhJkaF9cAF2Domc9SA9s22J5yKx4dqk7uqCmelnm5vPEc59fdpRjb+DhYq+5eNRBxypSXh + 1ZfUzvszh20TOIgU+s3eDyJMI7G3MqZr8pKiDzmOdHYwICJP4VH/lguuwg5NT147OSorYk41 + pTBhM9gT0jJl3fsqfW4axeguqfHrwyVS9bD3ZdlveA+yg+MRJkNjw6yofCYuw9iTskqXJ/7S + wjPhxd4gqLxmGNUyeqXQSytQc08gHMX6w91wVXjs3oFUHiBvaXqAis2pFA7528LI46WlZ3pf + h/OZDthBG7bOwU0EWVEx3gEQAMH7dVvWR+idYEe3OVDY/SVV80wjfOe1zTDTOQ+qB8D5Fin8 + 7v3Rpt8y0RxW3Y4Fbljoi635jhJo3/MoTHvZSes61LbnPzUjReYmIqMYprJ5HSF+IkskW9E5 + P078G6wI2hxwjRXXg4y+Z+oYk3C8GBH1Ejjs2i3lmYIPACMUKDba26ZIuxkjK5OB3tZHmTOu + YRJ9eP5KltSD4P6Y6ZTgDlvUpQeJa0w52A4dOQARmyKDiGJ5z+x8gSeCK3IrYWyt79et364R + SWZG4pFj34fnHIcHPebwOMX6gMZdPIyKNxaTwA62gnQp5loJoJJUTsgSTSOW1Dzvjjxm/4iW + M2HlS6NT0f80fSw1GnfIxSSPrx2F4Iwg8ckAWzy/EYcGr7+pHJ28AVVN4q0EG/9WvTsL9iM9 + Zqbw9cI9faDTDuJfYtcxIorMgkmDF4u14GFdzSsx5loTO+/7VFZhFDLLCC1eHCzOvLjHFg+9 + XpR0N7eArpDiYBWPFWBVthHtb6JuXqAWyZ+0LZZw2JGM4/gzUdFr+1FznJX1MqtlwtrAggM4 + xrPlnIf4qwL6B074tr00vzr4YIzl0FUGti9Qx+xozqeO2NmKltXmfBYfBJZdnfanVHp8XMDS + +z7CVKCzMkmnuyJ0QrY0jJVAxOvlwLQy363Nk5pRprrHna2R2+ZsTqf8Cw3dABEBAAHCwXwE + GAEIACYWIQQ2xxo3ydmIveglCNmxpw5Pjc0DZgUCWVEx3gIbDAUJA8JnAAAKCRCxpw5Pjc0D + ZgeWEACfP52WfyPUWMg8mZax834TW/RGBaUi9KQZc0tRX8lDrsD42aunTF+8va8t4/vw4Cfy + kloL+5mcz9orWzp+9YVO98U0O2s76zDTxBIJC5pp8ZRoqCZbRhD2w7DBNxgazeChCmsSmADn + /3ktkAztTI99I/xa/i7/PhVKn/MQJZ/vzFOwdvxaVar8W7jsWnzw43DFMVIVyWrwXeBaKVFe + vBwvnltvbmNyvx8L+3W0dPP4biVsCbT6Fteki++c3XoAooCut7ld9wP0oNiYUUFMSd2rEErd + QHPnaTGil/KAO2BMQEbcCXbDX7L9PX6rjonPwQIbaP3zNbuRfZj8LRKzz7ih+gOJRMPGGYX1 + eMUVXwoi8EQeofLM7wmOQikXlDbVR0a3+kKj/g6yKsBFvRbtSx73DeLg2Zp4EodoUnF/0W3V + JqZCWeI794kfk6NFvKKn1GLfxdyj82wiqzzCNFnYe6H4l78kGCZ7E0yg0u0M0kCjtDfBlxHJ + r1FDbWf3e4yX76QwxsQwR5yiY9mpWWo6Z6XFDT2Jz6HQX7y9oJhV/cLyAMzVz3Y7BSLm9tX5 + /pX1TjOC7jsEBBPYFk1XyLQ+Ip6ZT0TZx7nXNoF08GhTXFLLx7tSNzx1IE+Go0FXcA0vmYUy + Ex981QeJInExpznDYCvx7pHU1PzImXcSLzWzqR8Anw== +Message-ID: <feff454d-2cc2-2104-5c6c-69630506bd56@gmail.com> +Date: Wed, 26 Sep 2018 09:36:57 +0000 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 + Thunderbird/60.0 +MIME-Version: 1.0 +In-Reply-To: <CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com> +Content-Type: text/plain; charset=utf-8 +Content-Language: en-US-large +Content-Transfer-Encoding: 7bit +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 26 Sep 2018 10:42:40 +0000 +Subject: Re: [bitcoin-dev] BIP sighash_noinput +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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: Wed, 26 Sep 2018 09:34:46 -0000 + +> At the risk of bikeshedding, shouldn't NOINPUT also zero out the +> hashSequence so that its behaviour is consistent with ANYONECANPAY? + +There is a good reason for not doing that. If NOINPUT would sign the +hashSequence then it would be possible to get rid of OP_CSV in eltoo update +scripts. As a result update scripts could be taprootified because the more +common branch (settlement) would be just a 2-of-2 multisig. Applying taproot +would then make unilateral settlement look like a single pubkey spend and avoid +having to reveal the unexecuted (update) branch. + +Eltoo update transaction outputs consist of two branches, update and +settlement, where the update branch can be spend by a more recent update +transaction if an obsolete update transaction ends up spending the funding +output. The settlement branch is a 2-of-2 multisig with a relative timelock +using OP_CSV. Removing OP_CSV is possible because both parties signature is +required to spend the update transaction. They will only sign if the input has +the right sequence numbers which is sufficient to enforce the timeout (BIP68) - +assuming they are covered by the signature. + +There's a catch: hashSequence includes the sequence numbers of all transaction +inputs. That's not a problem for eltoo because settlement transactions only +have one input. The update mechanism with update transactions relies on being +able to bump the fee by unilaterally adding inputs and and change outputs to +the transaction. That's also not a problem because update spends do not use +relative timelocks and they are signed with SINGLE. So whenever NOINPUT is +combined SINGLE the hashSequence should be zeroed. This is in fact what a +minimal change to the current NOINPUT implementation would naturally do (see +below). However, that's error-prone when using NOINPUT in other contexts so in +general it would be better if NOINPUT would only sign the sequence number of +the corresponding input. + +Another downside of this approach is that you can never rebind to an output +with an OP_CSV that requires a larger sequence number, unless you also sign +with SIGHASH_SINGLE. It's difficult to imagine application where this would be +an issue. + +This is the modification to the NOINPUT implementation +(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo +unilateral closes taprootifiable: ++++ b/src/script/interpreter.cpp +@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const CTransaction& txTo, unsig + hashPrevouts = cacheready ? cache->hashPrevouts : GetPrevoutHash(txTo); + } + +- if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) { ++ if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + hashSequence = cacheready ? cache->hashSequence : GetSequenceHash(txTo); + } + +On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote: +> At the risk of bikeshedding, shouldn't NOINPUT also zero out the +> hashSequence so that its behaviour is consistent with ANYONECANPAY? +> +> On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> Hi all, +>> +>> I'd like to pick up the discussion from a few months ago, and propose a new +>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the +>> previous +>> output. This was previously mentioned on the list by Joseph Poon [1], but +>> was +>> never formally proposed, so I wrote a proposal [2]. +>> +>> We have long known that `SIGHASH_NOINPUT` would be a great fit for +>> Lightning. +>> They enable simple watch-towers, i.e., outsource the need to watch the +>> blockchain for channel closures, and react appropriately if our +>> counterparty +>> misbehaves. In addition to this we just released the eltoo [3,4] paper +>> which +>> describes a simplified update mechanism that can be used in Lightning, and +>> other +>> off-chain contracts, with any number of participants. +>> +>> By not committing to the previous output being spent by the transaction, +>> we can +>> rebind an input to point to any outpoint with a matching output script and +>> value. The binding therefore is no longer explicit through a reference, but +>> through script compatibility, and the transaction ID reference in the +>> input is a +>> hint to validators. The sighash flag is meant to enable some off-chain +>> use-cases +>> and should not be used unless the tradeoffs are well-known. In particular +>> we +>> suggest using contract specific key-pairs, in order to avoid having any +>> unwanted +>> rebinding opportunities. +>> +>> The proposal is very minimalistic, and simple. However, there are a few +>> things +>> where we'd like to hear the input of the wider community with regards to +>> the +>> implementation details though. We had some discussions internally on +>> whether to +>> use a separate opcode or a sighash flag, some feeling that the sighash flag +>> could lead to some confusion with existing wallets, but given that we have +>> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown +>> flags, we decided to go the sighash way. Another thing is that we still +>> commit +>> to the amount of the outpoint being spent. The rationale behind this is +>> that, +>> while rebinding to outpoints with the same value maintains the value +>> relationship between input and output, we will probably not want to bind to +>> something with a different value and suddenly pay a gigantic fee. +>> +>> The deployment part of the proposal is left vague on purpose in order not +>> to +>> collide with any other proposals. It should be possible to introduce it by +>> bumping the segwit script version and adding the new behavior. +>> +>> I hope the proposal is well received, and I'm looking forward to discussing +>> variants and tradeoffs here. I think the applications we proposed so far +>> are +>> quite interesting, and I'm sure there are many more we can enable with this +>> change. +>> +>> Cheers, +>> Christian +>> +>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ +>> 2016-February/012460.html +>> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki +>> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html +>> [4] https://blockstream.com/eltoo.pdf +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + |