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
139
140
141
142
143
144
145
146
147
148
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 81E742DDF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Mar 2019 00:22:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86A44608
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Mar 2019 00:22:33 +0000 (UTC)
Date: Tue, 19 Mar 2019 00:22:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1552954951;
bh=o6npnJuI308SWzUSv+T7p1L5ZcdYxrvNCnta0gaQ6QA=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=vDzAiU3QUdc+/UOZJprEZBl2/vFsSGxlGJBqaGKamh+W19KwZmeoULb76FTetajNZ
zPCjQarfGbmPA40kO7u/6yOo+eR4hhJVkYycR2E0CyX+NUtzQuj+NCFOxew4w4/gKF
Wt48OB90GUhV1CZxv+Ey51bWXIWP9ecrBHoajwDM=
To: Alistair Mann <al@pectw.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <l4BUfzuidK4XBlGw5eVQI5ZTL5I8i_UurXFU4IwrORvTJjhPjA9B3HLUw7MctfL0rk2r-wfSantKTPkNqX9vaN97vpthNrYC73mgDYm3iMM=@protonmail.com>
In-Reply-To: <2800869.rK7t1eu9ik@dprfs-d5766>
References: <12139028.TiJ4v5RR02@dprfs-d5766> <2800869.rK7t1eu9ik@dprfs-d5766>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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: Tue, 19 Mar 2019 02:02:18 +0000
Subject: Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an
HTLB
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 Mar 2019 00:22:34 -0000
Good morning Alistair,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, March 18, 2019 4:27 AM, Alistair Mann via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
> This update collects community feedback on my HTLB Pre-BIP
>
> As reminder, I'm suggesting a BIP for a hitherto poorly supported class o=
f
> transactions: "Good Behaviour Bonds".
>
> 1. On this mailing list:
> ZmnSCPxj notes HTLB over HTLC can improve privacy by obscuring whethe=
r a
> transaction is, in fact, an HTLB or an HTLC. This requires that the
> 'redundant' <digest> and [HASHOP] be not standardised. I intend to fo=
llow that
>
>
> advice.
>
> 2. On Reddit at http://tinyurl.com/yxdketdo:
> /u/almkglor nudges me to consider if Bob could immediately fail the HTLB =
to
> Alice's benefit. I believe he could with something like this script:
> OP_IF
> OP_DUP OP_HASH160 <seller pubkey hash>
> OP_ELSE
> OP_IF
> [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <buyer pubkey hash>
>
> OP_ELSE
> <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
>
> OP_ENDIF
>
>
> OP_ENDIF
> OP_EQUALVERIFY
> OP_CHECKSIG
> The second OP_IF is new and would mean Bob can give Alice a [HASHOP] and
> <digest> that allows her to immediately redeem the funds. I will be modif=
ying
>
> the proof-of-concept code to investigate and prove this change.
The above is at odds with my suggestion to transport HTLBs over HTLCs.
BIP-199 already exists and defines a standard template for HTLC contracts.
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey h=
ash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
To use the above contract as HTLB:
1. Alice is the "buyer".
2. Bob is the "seller".
3. The preimage of `<digest>` is generated by Alice and given by Alice to =
Bob.
I observe that an "early return to Alice" can be implemented by Bob, by tak=
ing the first branch, but sending the money back to an address Alice contro=
ls.
Since Bob is the one who will decide whether to take the money (i.e. Alice =
is wasting Bob precious time and resource) or return to Alice (i.e. Alice s=
ent the message in good faith), this decision can be made by Bob entirely w=
ithout any input from Alice.
So the overall flow of the messages would be:
1. Alice sends preimage of `<digest>`, `[HASHOP]`, `<num>` and a new addre=
ss that Alice controls (for purpose of "early return").
2. Alice makes transaction to the above HTLC pattern.
3. Bob has until `<num> [HASHOP]` to decide:
3.1. To claim the money for itself by taking the first branch and sending =
to a new address that Bob controls.
3.2. To return the money to Alice by taking the first branch and sending t=
o the address Alice gave.
4. If Bob has not decided at the timeout, Alice can get her money back by =
taking the second branch.
Regards,
ZmnSCPxj
|
