Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 785EDCDDE for ; Sat, 9 Feb 2019 17:44:18 +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 67A82F4 for ; Sat, 9 Feb 2019 17:44:16 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1549734255; cv=none; d=zoho.com; s=zohoarc; b=CPhQ9R7MSfZdKSQBaKA68oDM9CbK8uEF5KLL0XRMAfSIUDkv8ol+vO3cJl3yTPokBP0VqkNzvYbZLkoyOY9xw9AsgagIH5UXL7TYkrncQydo0dNjXJGwaPEcdrbg/xFDg9TZjK8/WtjtcmYMi8nfl46NBeB+waeIHEoZJNyr2tc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1549734255; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=8YonJKITK67jS+nNn8kSxPTXEn2LDz9yb0kesCIXBFo=; b=YttmMNEsrgA9gxiZBnouxFnxdxLnonukrNcvcjCnJwBGRnog+8uBqYppquzAHSISkIvnenMyXd3HaiyFxd9bOfj7rPhDYbBHP6+nC7P3MAClv77HQD7oip8V59UfrdWGLWvmL3+bf0qtrm6b5XaOxe02AnVDGFcsfs2Q6jnV98M= 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] (pcd687179.netvigator.com [218.102.219.179]) by mx.zohomail.com with SMTPS id 1549734252609906.235060406095; Sat, 9 Feb 2019 09:44:12 -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 In-Reply-To: <3567673f-e12b-c107-2a33-0b23b5518c96@gmail.com> Date: Sun, 10 Feb 2019 01:43:50 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <9bae18fa-3266-61ce-0b62-6ee429198260@gmail.com> <3567673f-e12b-c107-2a33-0b23b5518c96@gmail.com> To: Jonas Nick 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 18:49:52 +0000 Cc: bitcoin-dev 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: Sat, 09 Feb 2019 17:44:18 -0000 And this scheme could be generalised to the combinatorial settlement = model in my earlier post. Let=E2=80=99s say the settlement tx has 3 outputs: (A&B),(B&C),(A&C). = There will be 4 versions of this tx: tx-X: all 3 outputs are tagged, signed by all 3 parties tx-Y-AB: output (A&B) is untagged, the other 2 outputs are tagged. = Signed only by C tx-Y-AC: output (A&C) is untagged, the other 2 outputs are tagged. = Signed only by B tx-Y-BC: =E2=80=A6=E2=80=A6=E2=80=A6 All 4 txs will have the same relative-lock-time If C is missing at the time of settlement, A and B will settle upon = tx-Y-AB with a simple signature If B and C are missing, A will settle upon tx-X However, I think this is just an overkill, and hardly improves = fungibility. It is very clear that this is an uncooperative eltoo = closing (due to the update tx of the main channel), and this is a = multi-party channel (due to multiple settlement outputs). There is = little doubt that the remaining parties would like to continue trading. = So there is actually no secret to hide, and it might be easier to just = tag all outputs Nonetheless, this example shows that the fungibility impact of output = tagging is quite manageable. Most likely you just need to prepare more = versions of intermediate txs, and only use the tagged one when things go = against you. > On 10 Feb 2019, at 12:52 AM, Jonas Nick wrote: >=20 > Johnson's modification solves the issue I pointed out. >=20 > Moreover, as Johnson and I discussed in private, using different = locktimes for > X and Y is not necessary. They can have the same relative locktime. If = A and B > would only sign Y as soon as the update tx is confirmed, there is no = risk of Y > changing its txid and therefore invalidating updates built on it. >=20 >=20 > On 2/9/19 10:15 AM, Johnson Lau wrote: >> 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. >>=20 >> 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. >>=20 >> 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=20 >>> On 9 Feb 2019, at 3:01 AM, Jonas Nick 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 >>=20 >>=20