path: root/2a/c70b175d6068b22a3a76e10a8c0998061aa00c

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A9D2DC8D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Dec 2018 20:09:05 +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 E175B764
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Dec 2018 20:09:04 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545077342; cv=none; d=zoho.com; s=zohoarc; 
	b=mPTfn5fgX4L0BaV9bXGKF+P9Lc0oCSmv7xRF46Ukm9lG67oelVCO9RSsdgANHParteKoYdpnmCot/WJkp1tra8G6mdXQg6nCrwe083ikoNzV8DqqWM25jEpY5oh0ldFf23xexWz7WDfqP+1kdIDsOHBL4yd7Sa4mHSDKPlmaRgQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1545077342;
	h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=XfG7u9SZfjVoab3v7j4uKUPHcgU0txFL/1XJC5go1/8=; 
	b=YuRWZ/T+Yd0C7o/UHf2Q+cHPcdjW+sA1awhH8EyNPYGs3QMyl7hf9teKOF9OkOiwTEg4BUR4juWoUxXl8XXH4gk9Eb48JNw+CldeVFfg2wLwRJFHuzJYsUgihduq3M1Vdo6Qgr4d60DgbnAOV/1/2b41BvCPiAY7RF0bl9CDQjI=
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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
	by mx.zohomail.com with SMTPS id 154507733902958.098872757710524;
	Mon, 17 Dec 2018 12:08:59 -0800 (PST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
Date: Tue, 18 Dec 2018 04:08:55 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4234D7B-B1AA-41C3-B60B-F1E89E90A47D@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
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: Tue, 18 Dec 2018 02:18:08 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Mon, 17 Dec 2018 20:09:05 -0000



> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen@gmail.com> wrote:
>=20
> Hi Johnson,
>=20
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].

Yes, but the =E2=80=9Ctagging=E2=80=9D emphasises more on the payer=E2=80=99=
s side: if the payer cannot guarantee that the payee would never reuse =
the key, the payer could avoid any NOINPUT-related trouble by tagging =
properly.

>=20
>> While this seems fully compatible with eltoo, is there any other =
proposals require NOINPUT, and is adversely affected by either way of =
tagging?
>=20
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>=20
> 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?

For the design considerations I mentioned above, the tags must be =
explicit and configurable by the payer. So it couldn=E2=80=99t be hidden =
in taproot.

If you don=E2=80=99t care about fungibility, you can always tag your =
setup output, and makes it ready for NOINPUT spending. Every update will =
need 2 signatures: a NOINPUT to spend the setup output or an earlier =
update output, and a NOINPUT to settle the latest update output.

If you care about fungibility, you can=E2=80=99t tag your setup output. =
Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to =
spend the setup output, a NOINPUT to spend an earlier update output, and =
a NOINPUT to settle the latest update output.

(Actually, as soon as you made the first update tx with SINGLEINPUT, you =
don=E2=80=99t strictly need to make any SINGLEINPUT signatures in the =
later updates again, as the first update tx (or any update with a =
SINGLEINPUT signature) could be effectively the trigger tx. While it =
makes the settlement more expensive, it also means accidentally missing =
a SINGLEINPUT signature will not lead to any fund loss. So security-wise =
it=E2=80=99s same as the always-tagging scenario.)

The most interesting observation is: you never have the need to use =
NOINPUT on an already confirmed UTXO, since nothing about a confirmed =
UTXO is mutable. And every smart contract must anchor to a confirmed =
UTXO, or the whole contract is double-spendable. So the ability to =
NOINPUT-spend a setup output should not be strictly needed. In some (but =
not all) case it might make the protocol simpler, though.

So the philosophy behind output tagging is =E2=80=9Cavoid NOINPUT at all =
cost, until it is truly unavoidable"

>=20
> Cheers,
> Ruben Somsen
>=20
> [1] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.ht=
ml
> [2]  =
https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechai=
ns_offchain_transfer_of/
>=20
> On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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)
>>=20
>> 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:
>>=20
>> 1. A certain bit in the tx version must be set
>> 2. A certain bit in the scriptPubKey must be set
>>=20
>> I will analyse the pros and cons later.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> While this seems fully compatible with eltoo, is there any other =
proposals 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