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: <201902192024.13243.luke@dashjr.org>
Date: Wed, 20 Feb 2019 04:36:51 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AFB2D9C-73E9-45F4-AB21-6899F55AAA94@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
	<201902191904.04412.luke@dashjr.org>
	<B58087BD-50F2-40DF-BDF0-8D1FDFDCDE03@xbt.hk>
	<201902192024.13243.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


> On 20 Feb 2019, at 4:24 AM, Luke Dashjr <luke@dashjr.org> wrote:
>=20
> Even besides NOINPUT, such a wallet would simply never show a second =
payment=20
> to the same address (or at least never show it as confirmed, until=20
> successfully spent).

This is totally unrelated to NOINPUT. You can make a wallet like this =
today already, and tell your payer not to reuse address.


>=20
> 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 so=20
> is.

It sounds like you actually want to tag such outputs as scriptPubKey, so =
you could encode this requirement in the address?

If we allow NOINPUT unconditionally (i.e. all v1 addresses are spendable =
with NOINPUT), you may only create a different proposal to indicate such =
special requirements=20

>=20
> 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 =
developers=20
> can do who actually want the features.
>=20
> Luke
>=20
>=20
> 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. 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.
>>=20
>> 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.
>>=20
>>> 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 everything, including normal L1 payments. For example, =
in the
>>> 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.
>>>=20
>>> Luke
>=20