summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJonas Nick <jonasdnick@gmail.com>2018-09-26 09:36:57 +0000
committerbitcoindev <bitcoindev@gnusha.org>2018-09-26 09:34:45 +0000
commitbbfbbc524240f5428115d65e29272f0387986416 (patch)
tree096f0420dcc172f8f5918b022b5a42a530938c8b
parentc295db0e6789510269b1e43ec219d37c6ae52d6e (diff)
downloadpi-bitcoindev-bbfbbc524240f5428115d65e29272f0387986416.tar.gz
pi-bitcoindev-bbfbbc524240f5428115d65e29272f0387986416.zip
Re: [bitcoin-dev] BIP sighash_noinput
-rw-r--r--48/ec03202a12baf33d65eb87ae3b366ed6aafa80268
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
+>
+