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 57206CAD for ; Thu, 13 Dec 2018 12:32:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96E3FE7 for ; Thu, 13 Dec 2018 12:32:51 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1544704369; cv=none; d=zoho.com; s=zohoarc; b=iR/JZXgYcMrFfDKw6rF6q60xOXtPQp+Blcmcf4J5IQrhewEA421lLdIcM5MmyCFRADyMDY/zcmFUR2Gs2Ra9Sr4CG26htYC13TJ4lyqtbsRi7nmReRNbqDKb1nFrMd1J7vb60fzkCI9jEAFE3GY8DX5UTCa8xtX1Vcixzo2790g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1544704369; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=fwA8DmmnlFMG8DGmlRru1UG7vAjaFkFdO9PQYwhEeS0=; b=K8vxbW3org9SLATK0JM4ZY/QRnhYxReLhEHOSN/1YrbQtNygCQ5ZvNh/R9UttaLQPkNG+cZFgqn4xWyPqSkdw3vwC/SBrp+GYwQdTI7pLZkjNXbmSgTZIQEtpVK8xNk+UgeMRarmKA0ZhkBxVoWtZZOXsHiCaM6oAHp9mjmipmU= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1544704368088612.8036755128995; Thu, 13 Dec 2018 04:32:48 -0800 (PST) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> Date: Thu, 13 Dec 2018 20:32:44 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, 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: Thu, 13 Dec 2018 22:09:29 +0000 Subject: [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: Thu, 13 Dec 2018 12:32:52 -0000 NOINPUT is very powerful, but the tradeoff is the risks of signature = replay. 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 has been a social and technical norm since the creation = of Bitcoin (the first 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 = blame the payer and/or payee for their stupidity, just like those people = laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, = etc). The existing 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 comedy show. So NOINPUT brings us more smart contract capacity, and at the same time = we are one step closer to dumb contracts. The target is to find a design = that exactly enables the smart contracts we want, while minimising the = risks of 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 replayed NOINPUT signature. Once people lost a significant = amount of money this way, payers (mostly exchanges) may refuse to send = money to anything other 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 = should not be tagged. This makes it indistinguishable from normal 1-of-1 = utxo. The trigger tx, which spends the setup utxo, should be tagged, so = the update txs could spend the trigger utxo with NOINPUT. Similarly, all = update txs should be tagged, so they could be spent by other update txs = and settlement tx with NOINPUT. As the final destination, there is no = need to tag in the settlement tx. In payer=E2=80=99s perspective, tagging means =E2=80=9CI believe this = address is for one-time-use only=E2=80=9D Since we can=E2=80=99t control = how other 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-output basis. However, scriptPubKey tagging is only possible with = native-segwit, not P2SH. That means we have to disallow NOINPUT in = P2SH-segwit (Otherwise, *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 = implementations will not understand the special tag, and will pay to a = tagged address as usual. An upgrade would be needed for them to refuse = sending to tagged 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 database, adding it back could be a little bit = annoying, but doable. There is an extension to the version tagging, which could make NOINPUT = even safer. In addition to tagging requirement, NOINPUT will also sign = the version 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 more bits in the tx version field. While this seems fully compatible with eltoo, is there any other = proposals require NOINPUT, and is adversely affected by either way of = tagging?=