path: root/b0/98119580ee287f56c550b13e24d42992018fa2

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 E1492CB32
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Feb 2019 10:15:47 +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 D1169608
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  9 Feb 2019 10:15:46 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1549707343; cv=none; d=zoho.com; s=zohoarc; 
	b=lVnueve11Y0tM+EIriFbKYa1tQnck94NkF55vublPeRAR01dy1UXjXoNzIJ8TDgOHf/ooyqJ16YuIEdL8GFPv/3GII6w/k4Fi0Q2B7MKacMRq2kOJQj6DdJoQgOby+uCZwSzquYcLmClEG1JhdVlXazwE5F6a8KBpPIvGeuU92M=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1549707343;
	h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=OnFkvzmehS8GIeoIKFfcgR5kg1D+PBh45f/8/EAxpx0=; 
	b=kZFJjXk2zkqhKxWbl3OM5zD0UoDsaZ5XZBkR2fFpxwToi35yeM8wI/UyccnWIz3Tjz2NwtSAcOwL4ast4gl8o4ATQ+CqZ5FWxBatDjTVNzuIBBA4UtYc5B1Di/LVeSyJ2iBaV4vFAPXgKk0WqDxQ0qqDIV3sGEj9jf56uJWCyIg=
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] (pcd687179.netvigator.com [218.102.219.179]) by
	mx.zohomail.com with SMTPS id 1549707341957616.1315588495153;
	Sat, 9 Feb 2019 02:15:41 -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: <9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
Date: Sat, 9 Feb 2019 18:15:17 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB1FBB2C-D202-4583-B596-F746E20AFD3E@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com>
To: Jonas Nick <jonasdnick@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: Sat, 09 Feb 2019 14:48:51 +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: Sat, 09 Feb 2019 10:15:48 -0000

This is really interesting. If I get it correctly, I think the =
fungibility hit could be avoided, just by making one more signature, and =
not affecting the blockchain space usage.

Just some terminology first. In a 3-party channel, =E2=80=9Cmain =
channel=E2=80=9D means the one requires all parties to update, and =
=E2=80=9Cbranch channel=E2=80=9D requires only 2 parties to update.

By what you describe, I think the most realistic scenario is =E2=80=9CC =
is going to offline soon, and may or may not return. So the group wants =
to keep the main channel open, and create a branch channel for A and B, =
during the absence of C=E2=80=9D. I guess this is what you mean by being =
able to "predict in advance who will become absent=E2=80=9D

I call this process as =E2=80=9Csemi-cooperative channel closing=E2=80=9D =
(SCCC). During a SCCC, the settlement tx will have 2 outputs: one as (A =
& B), one as (C). Therefore, a branch channel could be opened with the =
(A & B) output. The channel opening must use NOINPUT signature, since we =
don=E2=80=99t know the txid of the settlement tx. With the output =
tagging requirement, (A & B) must be tagged, and lead to the fungibility =
loss you described.

However, it is possible to make 2 settlement txs during SCCC. Outputs of =
the settlement tx X are tagged(A&B) and C. Outputs of the settlement tx =
Y are untagged(A&B) and C. Both X and Y are BIP68 relative-time-locked, =
but Y has a longer time lock.

The branch channel is opened on top of the tagged output of tx X. If A =
and B want to close the channel without C, they need to publish the last =
update tx of the main channel. Once the update tx is confirmed, its txid =
becomes permanent, so are the txids of X and Y. If A and B decide to =
close the channel cooperatively, they could do it on top of the untagged =
output of tx Y, without using NOINPUT. There won=E2=80=99t be any =
fungibility loss. Other people will only see the uncooperative closing =
of the main channel, and couldn=E2=80=99t even tell the number of =
parties in the main channel. Unfortunately, the unusual long lock time =
of Y might still tell something.

If anything goes wrong, A or B could publish X before the lock time of =
Y, and settle it through the usual eltoo style. Since this is an =
uncooperative closing anyway, the extra fungibility loss due to tagging =
is next to nothing. However, it may suggest that the main channel was a =
multi-party one.

For C, the last update tx of the main channel and the settlement tx Y =
are the only things he needs to get the money back. C has to sign tx X, =
but he shouldn=E2=80=99t get the complete tx X. Otherwise, C might have =
an incentive to publish X in order to get the money back earlier, at the =
cost of fungibility loss of the branch channel.

To minimise the fungibility loss, we=E2=80=99d better make it a social =
norm: if you sign your tx with NOINPUT, always try to make all outputs =
tagged to be NOINPUT-spendable. (NOTE: you can still spend tagged =
outputs with normal signatures, so this won=E2=80=99t permanently taint =
your coins as NOINPUT-spendable) It makes sense because the use of =
NOINPUT signature strongly suggests that you don=E2=80=99t know the txid =
of the parent tx, so you may most likely want your outputs to be =
NOINPUT-spendable as well. I thought of making this a policy or =
consensus rule, but may be it=E2=80=99s just overkill.



> On 9 Feb 2019, at 3:01 AM, Jonas Nick <jonasdnick@gmail.com> wrote:
>=20
> Output tagging may result in reduced fungibility in multiparty eltoo =
channels.
> If one party is unresponsive, the remaining participants want to =
remove
> the party from the channel without downtime. This is possible by =
creating
> settlement transactions which pay off the unresponsive party and fund =
a new
> channel with the remaining participants.
>=20
> When the party becomes unresponsive, the channel is closed by =
broadcasting the
> update transaction as usual. As soon as that happens the remaining
> participants can start to update their new channel. Their update =
signatures
> must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid =
is not
> final (because update tx is not confirmed and may have to rebind to =
another
> output). Therefore, the funding output of the new channel must be =
NOINPUT
> tagged. Assuming the remaining parties later settle cooperatively, =
this loss
> of fungibility would not have happened without output tagging.
>=20
> funding output          update output                                  =
  settlement outputs              update output
> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] =
-> [ NOINPUT tagged: (A' & B'), -> ...
>                                                                        =
   C' ]
> If the expectation is that the unresponsive party returns, fungibility =
is
> not reduced due to output tagging because the above scheme can be used
> off-chain until the original channel can be continued.
>=20
> Side note: I was not able to come up with an similar, eltoo-like =
protocol that works
> if you can't predict in advance who will become absent.
>=20
> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:
>> 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
>>=20