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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Return-Path: <al@pectw.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C2D56491
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Mar 2019 16:36:39 +0000 (UTC)
X-Greylist: delayed 00:35:19 by SQLgrey-1.7.6
Received: from pectw.vm.bytemark.co.uk (pectw.vm.bytemark.co.uk [80.68.92.123])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79C7E2C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Mar 2019 16:36:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pectw.net;
s=dkim_test;
h=Content-Type:Content-Transfer-Encoding:MIME-Version:
Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=TfJ/frtl4yxyc3iw4jAjxJXyYB/jn3my/9HEL0LatKI=;
b=EU9UEtrsFknYx9wHS3xcuMVyjR
lx7255AlLNdmfgTgCTRWsdAQuEkq+vxcG/uI4DDEEIMig7oRoF8hZ3za2Q9HGfr3ATzoEUthKIypQ
HkR456egkkNTEiapaJHs56lkU;
Received: from host81-140-222-88.range81-140.btcentralplus.com
([81.140.222.88] helo=svetlana.localhost)
by pectw.vm.bytemark.co.uk with esmtpsa
(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1)
(envelope-from <al@pectw.net>) id 1h3NMX-0007Wh-F0
for bitcoin-dev@lists.linuxfoundation.org;
Mon, 11 Mar 2019 16:01:13 +0000
From: Alistair Mann <al@pectw.net>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Mon, 11 Mar 2019 16:01:12 +0000
Message-ID: <12139028.TiJ4v5RR02@dprfs-d5766>
User-Agent: KMail/4.14.2 (Linux/4.4.0-18-generic; KDE/4.14.2; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU 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: Mon, 11 Mar 2019 16:43:46 +0000
Subject: [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: Mon, 11 Mar 2019 16:36:39 -0000
Greetings all,
I'm looking for thoughts on the BIPability of a relatively minor change, with
an outsize benefit, with the provisional name 'Hashed Time-Locked Bond', HTLB
for short.
The minor change is to implement HTLC without its digest element. The outsize
benefit is to incentivise against spam and other abuse. In this post I'll
introduce the script, motivation, a working proof-of-concept site, and then
round out addressing the desirability of a BIP.
Implementation of HTLB:
The script takes the form:
OP_IF
OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
Notice that this is the script of BIP-0199 with '[HASHOP] <digest>
OP_EQUALVERIFY' removed.
A worked example. Alice is the buyer and Bob the seller. Alice knows that Bob
is her father and that he doesn't know her new email address. She commits
50,000 satoshis to the above script with a 24 hour timeout, then sends proof
of that transaction along with an email reintroducing herself. Bob's MUA
recognises that the bond is good and alerts him to the email from a strange
sender: he knows that if he disagrees with the implicit assertion that he will
want that email, he has 24 hours to redeem those funds at the sender's
expense. He reads the email. Bob is incentivised not to redeem against his
daughter though, and lets the timeout expire: Alice reclaims her funds. Carol
did not bond at all, so her email was refused at the server. Dave's bond of
100 satoshis was too small to pass Bob's minimum, so his email too was refused
at the server. Erin guaranteed 50,000 satoshis each to reach Bob and ten
thousand others with an email offering triple-glazed windows: she's now well
on the way to losing them all.
Motivation:
There is a transaction class we can identify as 'Good Behaviour Bonds'
currently poorly served in Bitcoin*. Bail bonds and bar tabs are real world
exemplars. Conceptually, Alice guarantees Bob she will do or be something for
a fixed period: if she complies Bob refrains from redeeming her guarantee; if
she does not comply Bob redeems some or all of it. It's inherent to the class
that Alice is incentivised within the transaction to good behaviour outside
it. Conversely, Bob is incentivised outside the transaction to good behaviour
within it.
In essence, Alice commits funds to a penalty in advance of a connection to
Bob. Alice is incentivised by getting her funds back, Bob is incentivised by
her - and others - continued patronage.
This transaction class can protect any addressable resource. Alice can
therefore guarantee Bob that:
1. Her email to him is not spam
2. Her telephone call to him is not a robocall
3. Her posts to his website are not flamebait.
In each case this is handled by extending the protocol concerned to detect for
and change behaviour depending on Alice's proof of bond.
That Alice can guarantee her behaviour to addressable resources means she can
also guarantee her behaviour to non-addressable resources. She could
guarantee:
1. a group chat that she won't upload NSFW content
2. an IRC channel that she won't flood
3. a streamed multiplayer game that she won't swear over teamspeak.
This is accomplished by use of an addressable resource and an enforcement
mechanism such as IRC's devoice command.
Alice can also guarantee her behaviour offline in much the same way. She can
guarantee to:
1. a magistrate that she'll appear for trial by a given date (Bail bond/
Surety)
2. a houseowner that she'll cover costs incurred from cleaning up after her
(Rental/Security deposit)
3. an innkeeper that she can pay for the drinks she's ordering (Bar tab)
That a transaction has been entered into online can be proved offline, so
these can be accomplished by means of an online, addressable resource and an
offline plaintext token.
Live site:
I have put up a live proof-of-concept at http://berewic.com. This protects a
specific URL accessed through HTTP (the "demo page") whereby visitors who have
posted bond on testnet3 get different content than those who have not posted
bond, or whose bond has expired. This is accomplished through an experimental
protocol where an agent with a hot wallet speaks for a credentialed user in a
similar way to how SMTP speaks for an email's original sender. That protocol
would seem to be outside the scope of the proposed BIP but I'm happy to
elaborate if required.
A short video demonstrating live use of the HTLB is also posted there.
BIP:
Name: "Hashed Time-Locked Bond" seems a reasonable name - the script is still
hashed even if the digest is gone, and HTLB nicely scans like HTLC - 1.
It won't have escaped notice that the HTLB script can be wholly written in an
HTLC script: 'HTLB over HTLC', however there are additional reasons to
consider HTLB for a separate BIP:
1. Alternative implementations using HTLB over HTLC would need to standardise
on what the redundant [HASHOP] and <digest> should be
2. Using HTLB over HTLC is inefficient as it compels unused storage and
unnecessary processing
3. Amending or superceding BIP-0199 to recognise the digest element as
optional creates backward compatibility issues
4. Recognising the motivation onchain would help inform second-layer solutions
where HTLB would be even more useful (eg, I believe that HTLCs and HTLBs do
not have analogues in the Lightning Network)
5. Wallet support. A limiting factor for the live site above has been the lack
of wallet HTLC support to the point that the demo does not implement CHECKSIG.
HTLC & HTLB signing would ideally take place in the wallet that must be
present, and so a BIP would help bolster the case for, and inform anyone
revisiting, PR7601.
Thoughts?
* The HTLB lives in the space somewhere near
https://en.bitcoin.it/wiki/Fidelity_bonds and
https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit. The former
requires an unnecessary sacrifice, the latter does not allow for penalisation.
|
