summaryrefslogtreecommitdiff
path: root/97/165a5b1ffa1004a723d16bbbcd984380a987a6
blob: 2a83de076b110500ecab5366979be112c000af1a (plain)
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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
Return-Path: <jimmyjack@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E3660308
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 16:29:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com
	[209.85.216.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B408884
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 16:29:30 +0000 (UTC)
Received: by mail-qt0-f172.google.com with SMTP id w38so10006315qtb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 09:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=;
	b=VuLSmJi35BgW86cpn99Uv/fczvSsBpjNO0K0iOuOzGzDVhElL/1gT72h/8Xag03Yb/
	W6/aEeZL1IIIhbEL6GofubDGgwtTgkI2irYktWaT9qVj8B3yzZgP4fqaS1ZJg3JI5OtA
	BhIWbB+PsnNu+2yH4fmTVCv8cklbhcDifgGk0kETiKTmZ3qBHIvxzRlMO8vc5j1UPdLJ
	MkaLYpDxIE4bFBww5KLtGbd20I6YACcaS/OZSmHFF1Tr5aCxj6WAwkh4Uw8OmXmreU3y
	F1ajd2jRAXK+772AK2JjL3cIlyh5SCO/CirXWjc30JmBwN+9OL5dz8mtuWH+eN75DVx7
	tMZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=;
	b=hKPvdQnooiC3MOoLbtbz92IYqt5CDJym4nbc3OOoG/wRTCuN4Bde6XsrSMUhlk4Ove
	pcgukFG5a/muT/AnsY508iniuGO5PWlJK/5ByKyaoJyLr69HAhjN2UAVCqWAjJaUQYKj
	k0VNALg5/QvV3P4hQ01jcF1j4b3FJmwwKsA70xwRbzZk0jtw5KZAYfdejJQ4YLTrsTHn
	+B6n2PF067h2nopsNQqMHyIi930WzBx8TWrXZjM4xyb80AuRdtaw/0f5+synjlGISOrM
	CO9Bs3+g/0VCJec1AWa263lQZPKr1fjuLc9r+eiwqsJNcvxRMB13ju+FKcwtPw7HUEEL
	L0UQ==
X-Gm-Message-State: AE9vXwMQqXwpHrS74d4sTr5UwKf5QMOtZXynYGuKdixNW+rTzA/l5cpq4Y5aTJxoTxlwaoDpe7v1glmrNlf17A==
X-Received: by 10.237.50.35 with SMTP id y32mr4547150qtd.98.1472056169938;
	Wed, 24 Aug 2016 09:29:29 -0700 (PDT)
MIME-Version: 1.0
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
In-Reply-To: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
From: Jimmy <jimmyjack@gmail.com>
Date: Wed, 24 Aug 2016 16:29:19 +0000
Message-ID: <CAE0GdZW-vN-kpUMATjkRQYnKH4n41HGdwQGb-JKZjcjxr6mO9g@mail.gmail.com>
To: Matthew Roberts <matthew@roberts.pm>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=94eb2c116a7a19445e053ad3c940
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: Wed, 24 Aug 2016 16:32:28 +0000
Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
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: Wed, 24 Aug 2016 16:29:33 -0000

--94eb2c116a7a19445e053ad3c940
Content-Type: text/plain; charset=UTF-8

Is this unrelated to Bitcoin Vigil idea published in 2014?

http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/





On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each server associated with a unique signature. That way, you
> don't have to split up all the coins among every server and reduce the
> incentive for an attacker yet you can still identify which server was
> hacked.
>
> It would be nice if after the attacker broke into the server that they
> were also incentivized to act on the information as soon as possible
> (revealing early on when the server was compromised.) I suppose you could
> split up the coins into different outputs that could optimally be redeemed
> by the owner at different points in the future -- so they're incentivzed to
> act lest their reward decays even more (this is of course, assuming that
> the monetary reward for this is greater than any possible legal
> consequences for the attacker -- it might not be. Thinking about this some
> more: it would also be somewhat hard to deny that this -wasn't- a honeypot
> with such a complex and unique scheme required for transactions, and I for
> one wouldn't like to reveal that I'd hacked a server if I knew it was all a
> calculated ploy. Don't honeypots rely on subtly?)
>
> What about also proving to an attacker that by breaking into a server they
> would be guaranteed a reward? I know that the use-case for this is proof of
> compromise so incentivizing a security audit would kind of fall more into
> an active invitation to audit but couldn't you also make a cryptocurrency
> that allowed coins to be moved based on a service banner existing at a
> given IP address? Attackers could then break into the server, setup a
> service that broadcasts their public key hash, and then spend coins locked
> at this special contract address to that pub key hash which miners would
> check on redemption (putting aside malicious use-cases for now.)
>
>
> On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Bitcoin-based honeypots incentivise intruders into revealing the fact
>> they have
>> broken into a server by allowing them to claim a reward based on secret
>> information obtained during the intrusion. Spending a bitcoin can only be
>> done
>> by publishing data to a public place - the Bitcoin blockchain - allowing
>> detection of the intrusion.
>>
>> The simplest way to achieve this is with one private key per server, with
>> each
>> server associated with one transaction output spendable by that key.
>> However
>> this isn't capital efficient if you have multiple servers to protect: if
>> we
>> have N servers and P bitcoins that we can afford to lose in the
>> compromise, one
>> key per server gives the intruder only N/P incentive.
>>
>> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
>> single txout protected by a 1-N tree of keys, with each server assigned a
>> specific key. Unfortunately though, tree signatures aren't yet
>> implemented in
>> the Bitcoin protocol.
>>
>> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
>> implement
>> this functionality with the existing Bitcoin protocol using the following
>> script:
>>
>>     2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>>
>> The honeypot secret key is shared among all N servers, and left on them.
>> The
>> distriminator secret key meanwhile is kept secret, however for each
>> server a
>> unique signature is created with SIGHASH_SINGLE, paying a token amount to
>> a
>> notification address. For each individual server a pre-signed signature
>> created
>> with the distriminator secret key is then left on the associated server
>> along
>> with the honeypot secret key.
>>
>> Recall the SIGHASH_SINGLE flag means that the signature only signs a
>> single
>> transaction input and transaction output; the transaction is allowed to
>> have
>> additional inputs and outputs added. This allows the thief to use the
>> honeypot
>> key to construct a claim transaction with an additional output added that
>> pays
>> an address that they own with the rest of the funds.
>>
>> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
>> being the K value used in the pre-signed transaction.
>>
>> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>>
>>
>> Censorship Resistance
>> =====================
>>
>> A potential disadvantage of using non-standard SIGHASH flags is that the
>> transactions involved are somewhat unusual, and may be flagged by
>> risk analysis at exchanges and the like, a threat to the fungibility of
>> the
>> reward.
>>
>> We can improve on the above concept from Todd/Coleman by using a
>> pre-signed
>> standard transaction instead. The pre-signed transaction spends the
>> honeypot
>> txout to two addresses, a per-server canary address, and a change
>> address. The
>> private key associated with the change addres is also left on the server,
>> and
>> the intruder can then spend that change output to finally collect their
>> reward.
>>
>> To any external observer the result looks like two normal transactions
>> created
>> in the process of someone with a standard wallet sending a small amount of
>> funds to an address, followed by sending a larger amount.
>>
>>
>> Doublespending
>> ==============
>>
>> A subtlety in the the two transactions concept is that the intruder
>> doesn't
>> have the necessary private keys to modify the first transaction, which
>> means
>> that the honeypot owner can respond to the compromise by doublespending
>> that
>> transaction, potentially recovering the honeypot while still learning
>> about the
>> compromise. While this is possible with all honeypots, if the first
>> transaction
>> is signed with the opt-in RBF flags, and CPFP-aware transaction
>> replacement is
>> not implemented by miners, the mechanics are particularly disadvantageous
>> to
>> the intruder, as the honeypot owner only needs to increase the first
>> transaction's fee slightly to have a high chance of recovering their
>> funds.
>> With CPFP-aware transaction replacement the intruder could in-turn
>> respond with
>> a high-fee CPFP second transaction, but currently no such implementation
>> is
>> known.
>>
>>
>> Scorched Earth
>> ==============
>>
>> We can use the "scorched earth" concept to improve the credibility of the
>> honeypot reward by making it costly for the honeypot owner to
>> doublespend. Here
>> a second version of the honeypot pre-signed transaction would also be
>> provided
>> which sepnds the entirety of the honeypot output to fees, and additionally
>> spends a second output to fees. An economically rational intruder will
>> publish
>> the first version, which maximizes the funds they get out of the
>> honeypot. If
>> the owner tries to dishonestly doublespend, they can respond by
>> publishing the
>> "scorched earth" transaction, encouraging the honeypot owner's honesty and
>> making CPFP-aware transaction replacement irrelevant.
>>
>> Of course, miner centralization adds complexity to the above: in many
>> instances
>> honeypot owners and/or intruders will be able to recover funds from
>> altruistic
>> miners. Equally, the additional complexity may discourage intruders from
>> making
>> use of the honeypot entirely.
>>
>> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
>> used to
>> ensure the honeypot output can only be spent with transaction replacement
>> enabled, as CSV requires nSequence to be set in specific ways in any
>> transation
>> spending the output.
>>
>>
>> References
>> ==========
>>
>> 1) https://blockstream.com/2015/08/24/treesignatures/
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c116a7a19445e053ad3c940
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is this unrelated to Bitcoin Vigil idea published in 2014?=
<div><br></div><div><a href=3D"http://www.coindesk.com/bitcoin-vigil-progra=
m-guards-against-intrusion-coin-theft/">http://www.coindesk.com/bitcoin-vig=
il-program-guards-against-intrusion-coin-theft/</a><div><br></div><div><br>=
<div><br><div><br></div></div></div></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Really nice idea. So its like a smart contra=
ct that incentivizes publication that a server has been hacked? I also real=
ly like how the funding has been handled -- with all the coins stored in th=
e same address and then each server associated with a unique signature. Tha=
t way, you don&#39;t have to split up all the coins among every server and =
reduce the incentive for an attacker yet you can still identify which serve=
r was hacked.<br><br>It would be nice if after the attacker broke into the =
server that they were also incentivized to act on the information as soon a=
s possible (revealing early on when the server was compromised.) I suppose =
you could split up the coins into different outputs that could optimally be=
 redeemed by the owner at different points in the future -- so they&#39;re =
incentivzed to act lest their reward decays even more (this is of course, a=
ssuming that the monetary reward for this is greater than any possible lega=
l consequences for the attacker -- it might not be. Thinking about this som=
e more: it would also be somewhat hard to deny that this -wasn&#39;t- a hon=
eypot with such a complex and unique scheme required for transactions, and =
I for one wouldn&#39;t like to reveal that I&#39;d hacked a server if I kne=
w it was all a calculated ploy. Don&#39;t honeypots rely on subtly?)<br><br=
>What about also proving to an attacker that by breaking into a server they=
 would be guaranteed a reward? I know that the use-case for this is proof o=
f compromise so incentivizing a security audit would kind of fall more into=
 an active invitation to audit but couldn&#39;t you also make a cryptocurre=
ncy that allowed coins to be moved based on a service banner existing at a =
given IP address? Attackers could then break into the server, setup a servi=
ce that broadcasts their public key hash, and then spend coins locked at th=
is special contract address to that pub key hash which miners would check o=
n redemption (putting aside malicious use-cases for now.)<br><br></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 24, 2016 =
at 11:46 AM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Bitcoin-based honeypots incentivise intruders into revealing the fact=
 they have<br>
broken into a server by allowing them to claim a reward based on secret<br>
information obtained during the intrusion. Spending a bitcoin can only be d=
one<br>
by publishing data to a public place - the Bitcoin blockchain - allowing<br=
>
detection of the intrusion.<br>
<br>
The simplest way to achieve this is with one private key per server, with e=
ach<br>
server associated with one transaction output spendable by that key. Howeve=
r<br>
this isn&#39;t capital efficient if you have multiple servers to protect: i=
f we<br>
have N servers and P bitcoins that we can afford to lose in the compromise,=
 one<br>
key per server gives the intruder only N/P incentive.<br>
<br>
Previously Piete Wuille proposed(1) tree signatures for honeypots, with a<b=
r>
single txout protected by a 1-N tree of keys, with each server assigned a<b=
r>
specific key. Unfortunately though, tree signatures aren&#39;t yet implemen=
ted in<br>
the Bitcoin protocol.<br>
<br>
However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can implem=
ent<br>
this functionality with the existing Bitcoin protocol using the following<b=
r>
script:<br>
<br>
=C2=A0 =C2=A0 2 &lt;honeypot-pubkey&gt; &lt;distriminator-pubkey&gt; 2 CHEC=
KMULTISIG<br>
<br>
The honeypot secret key is shared among all N servers, and left on them. Th=
e<br>
distriminator secret key meanwhile is kept secret, however for each server =
a<br>
unique signature is created with SIGHASH_SINGLE, paying a token amount to a=
<br>
notification address. For each individual server a pre-signed signature cre=
ated<br>
with the distriminator secret key is then left on the associated server alo=
ng<br>
with the honeypot secret key.<br>
<br>
Recall the SIGHASH_SINGLE flag means that the signature only signs a single=
<br>
transaction input and transaction output; the transaction is allowed to hav=
e<br>
additional inputs and outputs added. This allows the thief to use the honey=
pot<br>
key to construct a claim transaction with an additional output added that p=
ays<br>
an address that they own with the rest of the funds.<br>
<br>
Equally, we could also use SIGHASH_NONE, with the per-server discriminator<=
br>
being the K value used in the pre-signed transaction.<br>
<br>
Note that Jeff Coleman deserves credit as co-inventor of all the above.<br>
<br>
<br>
Censorship Resistance<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
A potential disadvantage of using non-standard SIGHASH flags is that the<br=
>
transactions involved are somewhat unusual, and may be flagged by<br>
risk analysis at exchanges and the like, a threat to the fungibility of the=
<br>
reward.<br>
<br>
We can improve on the above concept from Todd/Coleman by using a pre-signed=
<br>
standard transaction instead. The pre-signed transaction spends the honeypo=
t<br>
txout to two addresses, a per-server canary address, and a change address. =
The<br>
private key associated with the change addres is also left on the server, a=
nd<br>
the intruder can then spend that change output to finally collect their rew=
ard.<br>
<br>
To any external observer the result looks like two normal transactions crea=
ted<br>
in the process of someone with a standard wallet sending a small amount of<=
br>
funds to an address, followed by sending a larger amount.<br>
<br>
<br>
Doublespending<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
A subtlety in the the two transactions concept is that the intruder doesn&#=
39;t<br>
have the necessary private keys to modify the first transaction, which mean=
s<br>
that the honeypot owner can respond to the compromise by doublespending tha=
t<br>
transaction, potentially recovering the honeypot while still learning about=
 the<br>
compromise. While this is possible with all honeypots, if the first transac=
tion<br>
is signed with the opt-in RBF flags, and CPFP-aware transaction replacement=
 is<br>
not implemented by miners, the mechanics are particularly disadvantageous t=
o<br>
the intruder, as the honeypot owner only needs to increase the first<br>
transaction&#39;s fee slightly to have a high chance of recovering their fu=
nds.<br>
With CPFP-aware transaction replacement the intruder could in-turn respond =
with<br>
a high-fee CPFP second transaction, but currently no such implementation is=
<br>
known.<br>
<br>
<br>
Scorched Earth<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
We can use the &quot;scorched earth&quot; concept to improve the credibilit=
y of the<br>
honeypot reward by making it costly for the honeypot owner to doublespend. =
Here<br>
a second version of the honeypot pre-signed transaction would also be provi=
ded<br>
which sepnds the entirety of the honeypot output to fees, and additionally<=
br>
spends a second output to fees. An economically rational intruder will publ=
ish<br>
the first version, which maximizes the funds they get out of the honeypot. =
If<br>
the owner tries to dishonestly doublespend, they can respond by publishing =
the<br>
&quot;scorched earth&quot; transaction, encouraging the honeypot owner&#39;=
s honesty and<br>
making CPFP-aware transaction replacement irrelevant.<br>
<br>
Of course, miner centralization adds complexity to the above: in many insta=
nces<br>
honeypot owners and/or intruders will be able to recover funds from altruis=
tic<br>
miners. Equally, the additional complexity may discourage intruders from ma=
king<br>
use of the honeypot entirely.<br>
<br>
Note that as an implementation consideration CHECKSEQUENCEVERIFY can be use=
d to<br>
ensure the honeypot output can only be spent with transaction replacement<b=
r>
enabled, as CSV requires nSequence to be set in specific ways in any transa=
tion<br>
spending the output.<br>
<br>
<br>
References<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
1) <a href=3D"https://blockstream.com/2015/08/24/treesignatures/" rel=3D"no=
referrer" target=3D"_blank">https://blockstream.com/2015/08/24/treesignatur=
es/</a><br>
<span><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--94eb2c116a7a19445e053ad3c940--