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 06FCAC7C for ; Mon, 17 Dec 2018 15:48:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 379D07A4 for ; Mon, 17 Dec 2018 15:48:28 +0000 (UTC) Received: by mail-wr1-f49.google.com with SMTP id v13so12771137wrw.5 for ; Mon, 17 Dec 2018 07:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=x7AHeRYUXmnUnlfodb/Nx4WCJZO1R3QK+ULt352ct0w=; b=BU9btPD6bhmQmXYjYIbd5ROQATOJMtu0caCGaoxm87j41pcGoC39/M/YnhH1O6RJSu fLHOSYEQg1dXAZg+oNx+sjgPdTrVWZmRzKWXyxm7zlLoVgORIhfwFq7L4FtS3H2nv8JW oo8Erao+glilpvxwwmOw+c1PrVm5EXhmjLJTFV7cLnbZeIK6a8Kalh7eYgJ+fI+vEhX9 A23vdZhTbUw2Nb20fWpQ68+CrKOSHy4CZZkQBL1aLC4k0FoizFAvQUJQZ8u7v3ht3CGP H7OxNsaBveB5xPRA1EaICyFhN/MeUrweRHsjcX2BZXC/pgCkYpHjFgZqNvFae0N1q79z SqFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=x7AHeRYUXmnUnlfodb/Nx4WCJZO1R3QK+ULt352ct0w=; b=SlYxUMh4KO49ckdZMkLS7MKobfCbsJwg3rxJ8hk8Hs2g3vCEfjQ1xj8/L0nWPmK3SW e9iRzuK6zutnVsFVijM/AgMNkhVtpO/X2s/N2UCWjd4Pz8kxocP+haBqNRQ2bwD7vyHh 2V6/e48O5E783ART/1lYmNCOrSw3oNg2pRdUoa/shTfbpMNHxlkJgDsah11ONthK1qzG N4R7vFe+TsI4Mdx/P3ZsgS5vrq4BxLouUPyRKqJld0OLsqckzO+djh3KDSYJUCHzUreB n51pPcNtad2Rof391Tvetbu4K+0wyflgf3zDw8uTbqLiNxCLGoKBlt/P9JnFg/BOuVMO AD4Q== X-Gm-Message-State: AA+aEWaGHRWg3BlKBggs1Oh5KFhYzH7aFO4t9/zva3vWfkmIlmrf3J9j SWOsIho6ull1WD6ag/2Vk8K71YQEPFxzJc3TqvbvZLaO X-Google-Smtp-Source: AFSGD/XHqUnGPMhJE6fnVeJIw7DglHIqQVq5X3hFP3rgZHsTlCYm1AtegMgqgQxUvu6vBaYactpcVHlqpHXjJZo2+eQ= X-Received: by 2002:adf:8143:: with SMTP id 61mr10780834wrm.47.1545061706657; Mon, 17 Dec 2018 07:48:26 -0800 (PST) MIME-Version: 1.0 References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> In-Reply-To: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> From: Ruben Somsen Date: Tue, 18 Dec 2018 00:48:15 +0900 Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Mon, 17 Dec 2018 16:09:42 +0000 Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging 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: Mon, 17 Dec 2018 15:48:29 -0000 Hi Johnson, The design considerations here seem similar to the ML discussion of whether Graftroot should be optional [1]. >While this seems fully compatible with eltoo, is there any other proposals= require NOINPUT, and is adversely affected by either way of tagging? As far as I can tell it should be compatible with Statechains [2], since it pretty much mirrors Eltoo in setup. My understanding is somewhat lacking, so perhaps I am missing the mark, but it is not completely clear to me how this affects fungibility if taproot gets added and the setup and trigger tx for Eltoo get combined into a single transaction. Would the NOINPUT spending condition be hidden inside the taproot commitment? Cheers, Ruben Somsen [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006= .html [2] https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_state= chains_offchain_transfer_of/ On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev wrote: > > NOINPUT is very powerful, but the tradeoff is the risks of signature repl= ay. While the key holders are expected not to reuse key pair, little could = be done to stop payers to reuse an address. Unfortunately, key-pair reuse h= as been a social and technical norm since the creation of Bitcoin (the firs= t tx made in block 170 reused the previous public key). I don=E2=80=99t see= any hope to change this norm any time soon, if possible at all. > > As the people who are designing the layer-1 protocol, we could always bla= me the payer and/or payee for their stupidity, just like those people laugh= ed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The e= xisting bitcoin script language is so restrictive. It disallows many useful= smart contracts, but at the same time prevented many dumb contracts. After= all, =E2=80=9Csmart=E2=80=9D and =E2=80=9Cdumb=E2=80=9D are non-technical = judgement. The DAO contract has always been faithfully executed. It=E2=80= =99s dumb only for those invested in the project. For me, it was just a com= edy show. > > So NOINPUT brings us more smart contract capacity, and at the same time w= e are one step closer to dumb contracts. The target is to find a design tha= t exactly enables the smart contracts we want, while minimising the risks o= f misuse. > > The risk I am trying to mitigate is a payer mistakenly pay to a previous = address with the exactly same amount, and the previous UTXO has been spent = using NOINPUT. Accidental double payment is not uncommon. Even if the payee= was honest and willing to refund, the money might have been spent with a r= eplayed NOINPUT signature. Once people lost a significant amount of money t= his way, payers (mostly exchanges) may refuse to send money to anything oth= er than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without = possibility of NOINPUT) > > The proposed solution is that an output must be =E2=80=9Ctagged=E2=80=9D = for it to be spendable with NOINPUT, and the =E2=80=9Ctag=E2=80=9D must be = made explicitly by the payer. There are 2 possible ways to do the tagging: > > 1. A certain bit in the tx version must be set > 2. A certain bit in the scriptPubKey must be set > > I will analyse the pros and cons later. > > Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and s= hould not be tagged. This makes it indistinguishable from normal 1-of-1 utx= o. The trigger tx, which spends the setup utxo, should be tagged, so the up= date txs could spend the trigger utxo with NOINPUT. Similarly, all update t= xs should be tagged, so they could be spent by other update txs and settlem= ent tx with NOINPUT. As the final destination, there is no need to tag in t= he settlement tx. > > In payer=E2=80=99s perspective, tagging means =E2=80=9CI believe this add= ress is for one-time-use only=E2=80=9D Since we can=E2=80=99t control how o= ther people manage their addresses, we should never do tagging when paying = to other people. > > I mentioned 2 ways of tagging, and they have pros and cons. First of all,= tagging in either way should not complicate the eltoo protocol in anyway, = nor bring extra block space overhead. > > A clear advantage of tagging with scriptPubKey is we could tag on a per-o= utput basis. However, scriptPubKey tagging is only possible with native-seg= wit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Other= wise, *all* P2SH addresses would become =E2=80=9Crisky=E2=80=9D for payers)= This should be ok for eltoo, since it has no reason to use P2SH-segwit in = intermediate txs, which is more expensive. > > Another problem with scriptPubKey tagging is all the existing bech32 impl= ementations will not understand the special tag, and will pay to a tagged a= ddress as usual. An upgrade would be needed for them to refuse sending to t= agged addresses by default. > > On the other hand, tagging with tx version will also protect P2SH-segwit,= and all existing wallets are protected by default. However, it is somewhat= a layer violation and you could only tag all or none output in the same tx= . Also, as Bitcoin Core has just removed the tx version from the UTXO datab= ase, adding it back could be a little bit annoying, but doable. > > There is an extension to the version tagging, which could make NOINPUT ev= en safer. In addition to tagging requirement, NOINPUT will also sign the ve= rsion of the previous tx. If the wallet always uses a randomised tx version= , it makes accidental replay very unlikely. However, that will burn a few m= ore bits in the tx version field. > > While this seems fully compatible with eltoo, is there any other proposal= s require NOINPUT, and is adversely affected by either way of tagging? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev