From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 52CDF10AA for ; Wed, 26 Sep 2018 20:37:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D6DF762 for ; Wed, 26 Sep 2018 20:37:51 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id s14-v6so278571wrw.6 for ; Wed, 26 Sep 2018 13:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F0PsBQtQBsUq8UBnY5BrSefoKsMmf2PIU/iSiC6xsxw=; b=pFfebHREbzL/J+3M+uBxyTsqGfNhIfFi+ik78YINbGP7Ptc239PIKaxVmR3IFnjmPT 1wxpbbHuiJZamWfVdxLeycSMqnLhSWCjGRr3DsmxgnxCKI6JkqQBQOv4EiRv7jJr/66z 63xlSNvuh9fcvfgYPoaOd/vgsZg4GJJkTwZvVUQeHqLsBJgDr15lE0l33C7xHoOR6lKi F3foQV4J2vP/ZtChqWDeCcN+qmsD79oz1Yyv/6gpTlwerjHtUhIS3JLBw8MD1hQ6sRlI B2p3ObpVaVUHZJM6xg/DigTyfwEzWocvqKFSyst2+8y1nyv09cTnASwUnv9VWanuV345 jt0A== 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:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=F0PsBQtQBsUq8UBnY5BrSefoKsMmf2PIU/iSiC6xsxw=; b=EpCZNgF3nYlZFv+ZE2pQa+q2LyFIeLAXrlCjId7WCZ6anO+Q6uPlt+fpl9vbH9of5a LhDH08LgUGjQpqZqSeXe8LWb9zbTJHUL138uA6+/fqn664NafjkYnoOVyeejg9VesK7y zmv+kTRXKA5idPDl+EATbQQA959QnzxPKMA8Ce/7TcQmi539ntrCnumWVtaIqfZuEt4o BHZctFsXd2MR0u4JNX3/ZS0ER2mOeNrQBzjbOOWb+kkmtk2QVnRlhak+uQ+mAX5B17mO NfJxFlYOuEcVoc0xNkp0VB4ZOUA0rRc1Ok3D/qCJC9rmrlIySULIFvqeqS2OSHuj+Ydj JW3A== X-Gm-Message-State: ABuFfojJS4J33H2oizpG2SQq4doAJP8GbfDO6cF+/FJzyRnNQpLVEClu 9nzV30wWCNuWAY0HWoh0/AY= X-Google-Smtp-Source: ACcGV63t+JwihgyPrRGNJYzu2GvyC8aISHjaxxzphKX5UNi6Cdq9cd9y0C+EaPDRfOoQbF9eJw5tjg== X-Received: by 2002:a5d:5342:: with SMTP id t2-v6mr6576474wrv.257.1537994269828; Wed, 26 Sep 2018 13:37:49 -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 124-v6sm620489wmk.20.2018.09.26.13.37.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 13:37:46 -0700 (PDT) From: Jonas Nick X-Google-Original-From: Jonas Nick To: Johnson Lau , Jonas Nick , bitcoin-dev References: <871sewirni.fsf@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: <7bb51255-bfe5-8f11-55ae-ddabebe76941@gmail.com> Date: Wed, 26 Sep 2018 20:40:02 +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: 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 20:40:12 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 20:37:52 -0000 Oh, I missed that that's still the case with NOINPUT - thanks for pointing it out. In that case there's no reason to sign the other inputs' sequence and that's even better because the current NOINPUT proposal already enables taprootifiability of eltoo unilateral closings. On 9/26/18 7:45 PM, Johnson Lau wrote: > In BIP143, the nSequence of the same input is always signed, with any hashtype. Why do you need to sign the sequence of other inputs? > >> On 26 Sep 2018, at 5:36 PM, Jonas Nick 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? >> >> 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? >>> >> > >