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 D4E1B20ED for ; Tue, 19 Feb 2019 20:24:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C2DC67E9 for ; Tue, 19 Feb 2019 20:24:51 +0000 (UTC) Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 15D1638A0C83; Tue, 19 Feb 2019 20:24:16 +0000 (UTC) X-Hashcash: 1:25:190219:jl2012@xbt.hk::fDIxfMdocbKbYeW5:cDVEW X-Hashcash: 1:25:190219:bitcoin-dev@lists.linuxfoundation.org::C=up/am=kdGf/EI8:bagRC From: Luke Dashjr To: Johnson Lau Date: Tue, 19 Feb 2019 20:24:12 +0000 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <201902191904.04412.luke@dashjr.org> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201902192024.13243.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED 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: Wed, 06 Mar 2019 00:22:07 +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: Tue, 19 Feb 2019 20:24:53 -0000 Even besides NOINPUT, such a wallet would simply never show a second paymen= t=20 to the same address (or at least never show it as confirmed, until=20 successfully spent). At least if tx versions are used, it isn't possible to indicate this=20 requirement in current Bitcoin L1 addresses. scriptPubKey might not be=20 impossible to encode, but it isn't really clear what the purpose of doing s= o=20 is. If people don't want to use NOINPUT, they should just not use it. Trying to= =20 implement a nanny in the protocol is inappropriate and limits what develope= rs=20 can do who actually want the features. Luke On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote: > This only depends on the contract between the payer and payee. If the > contract says address reuse is unacceptable, it=E2=80=99s unacceptable. I= t has > nothing to do with how the payee spends the coin. We can=E2=80=99t ban ad= dress > reuse at protocol level (unless we never prune the chain), so address reu= se > could only be prevented at social level. > > Using NOINPUT is also a very weak excuse: NOINPUT always commit to the > value. If the payer reused an address but for different amount, the payee > can=E2=80=99t claim the coin is lost due to previous NOINPUT use. A much = stronger > way is to publish the key after a coin is well confirmed. > > > On 20 Feb 2019, at 3:04 AM, Luke Dashjr wrote: > > > > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote: > >> While this seems fully compatible with eltoo, is there any other > >> proposals require NOINPUT, and is adversely affected by either way of > >> tagging? > > > > Yes, this seems to break the situation where a wallet wants to use > > NOINPUT for everything, including normal L1 payments. For example, in t= he > > scenario where address reuse will be rejected/ignored by the recipient > > unconditionally, and the payee is considered to have burned their > > bitcoins by attempting it. > > > > Luke