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: <201902191904.04412.luke@dashjr.org>
Date: Wed, 20 Feb 2019 03:22:07 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B58087BD-50F2-40DF-BDF0-8D1FDFDCDE03@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<201902191904.04412.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Precedence: list

This only depends on the contract between the payer and payee. If the =
contract says address reuse is unacceptable, it=E2=80=99s unacceptable. =
It has nothing to do with how the payee spends the coin. We can=E2=80=99t =
ban address reuse at protocol level (unless we never prune the chain), =
so address reuse 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 <luke@dashjr.org> wrote:
>=20
> 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?
>=20
> Yes, this seems to break the situation where a wallet wants to use =
NOINPUT for=20
> everything, including normal L1 payments. For example, in the scenario =
where=20
> address reuse will be rejected/ignored by the recipient =
unconditionally, and=20
> the payee is considered to have burned their bitcoins by attempting =
it.
>=20
> Luke