1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
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 8C44317E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Feb 2019 20:37:31 +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 064078D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Feb 2019 20:37:30 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1550608649; cv=none; d=zoho.com; s=zohoarc;
b=fasNS2GOMlD381yukNVN4U0NfPls3b7WUF7aU90QLVjTQRViRMRq3Vo1tRbNz98p2x3LwzvgRsSvneERiWrg8g8gceFfWoUIhhMUCxz5mf3h291iIKV4DZ1P47AhoEqq9XXQ0McBrwyZNY206LIJQru39LXh4WTuqbz++szOauc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1550608649;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=uFWBPhdDCMtM2/JV/wvqRzG4lX/zrTuolZ96aChD2K8=;
b=LPNchOV4oxERRGWF+79jmgvDspfP9uw4VsTTUT+q7cpDV1YbdYFipiDH4hGsSn9WEdOrwQA+2ePsN4p9nBt2I0cOIAURgpC3OVT07sxXXby5rzb94MuhOKwGgdsCm7iSC0ZLNND5bYapqPxR9DWZRt/G47G9Ivg2Kpmg8XMalng=
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.100] (n218103189223.netvigator.com [218.103.189.223])
by mx.zohomail.com with SMTPS id 1550608648281768.422468287698;
Tue, 19 Feb 2019 12:37:28 -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: <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>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Wed, 06 Mar 2019 00:22:07 +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: Tue, 19 Feb 2019 20:37:31 -0000
> 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
|
