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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WdKVf-0002yw-8H
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:20:19 +0000
Received: from mail-lb0-f174.google.com ([209.85.217.174])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdKVd-0001ox-EG
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:20:19 +0000
Received: by mail-lb0-f174.google.com with SMTP id u14so2034969lbd.5
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 07:20:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=tyOQvliz2xpesklYb1owwPnNUL7aR2ZDCfyN5d8bkck=;
b=WTzJg7J61jjspC6nFm7VoKmFCPve20wV/eaSgSvBbySUK774csDN/uDM9R8dLbYPQb
xuq/lQFMlGSg0OAEd0uXXoUnaoYnhAk8tGYIbMzkyDIA8zLv04o9OFYchMBw/i9kgFRo
a3an1d7ktUa3hP1nrwXbviwLe2TrMfKIoSlo5/2l+YJVVRBM0LpwctuV0R7JqgGjjK/c
TSelDzmSekgrNvR7JmruC1EGXtre6m/PlqjyghpC+9jJ1Zzngwk9fnSZmZTXtORI6TdI
OqrwVcXF2W2IrRKfeNNDhjXjWUoO/DezswpJL4YcIcK+DSY9/H3oB4628NbOitZc7jEl
/juw==
X-Gm-Message-State: ALoCoQkCzXFKac2quWMU8YUn2QkDpPKBxxAegI/MF892bQD1kR6feOZ36vDJu/3axODATI2u0w1z
MIME-Version: 1.0
X-Received: by 10.112.209.5 with SMTP id mi5mr1421686lbc.30.1398349210690;
Thu, 24 Apr 2014 07:20:10 -0700 (PDT)
Received: by 10.112.185.4 with HTTP; Thu, 24 Apr 2014 07:20:10 -0700 (PDT)
X-Originating-IP: [85.59.56.59]
In-Reply-To: <20140424125953.GC16884@savin>
References: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com>
<20140424125953.GC16884@savin>
Date: Thu, 24 Apr 2014 16:20:10 +0200
Message-ID: <CAC1+kJMREKv6ke1wQNxcHtt0G+2r7c7G7WjfVzV0tOwuLo8JNg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WdKVd-0001ox-EG
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee
and game theory
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 14:20:19 -0000
On 4/24/14, Peter Todd <pete@petertodd.org> wrote:
> ...
> With replace-by-fee scorched-earth the success rate of such
> double-spends would be significantly reduced as the attacker would need
> to get lucky with bad propagation not just once, but twice in a row.
Interesting.
>> Replace-by-fee and child-pays-for parent cannot be prohibited by a
>> protocol rule.
>> I believe all miners will eventually implement these policies because
>> it is the more rational way for them to prioritize transactions.
>> Finally I hope they do because it would make 0-confirmation
>> transactions possible as described in this post.
>> So I can't find any reasoning against replace-by-fee unless my example
>> is terribly flawed.
>> Am I missing something?
>
> A few things:
>
> 1) Replace-by-fee doesn't protect against sybil attacks; only
No worse than the current situation.
> 2) Replace-by-fee scorched earth does require you to keep private keys
> online to sign the replacements. Not a big deal, but it's yet another
> reason why you wouldn't want to use it for high-value stuff.
High-value transactions should wait for several confirmations.
> 3) It doesn't directly solve finney attacks(1) where the miner mines the
> transaction in private. However finney attacks are only relevant if
> there is high centralization of hashing power, and all other proposed
> mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
> decentralization. (just look at how coinbase reallocation lets large
> pools bully smaller miners out of business by blacklisting their blocks)
Again, no worse than the current situation. And regular double-spends
attacks are much simpler than finney attacks.
> One interesting thing with regard to finney attacks and replace-by-fee
> though is that enforcing hasher visibility of the blocks they are mining
> - what getblocktemplate was meant to do voluntarily - lets any hasher
> detect a finney attack double-spend and broadcast it. They have a weak
> incentive to do so - the scorched earth reply is a high-fee transaction
> of course and pre-broadcasting transactions makes blocks propagate
> faster - at which point you're back to a public double-spend. Enforcing
> visibility of block contents to hashers is definitely a good thing for
> decentralization.
Where can I read more about "enforcing hashing visibility of block contents"?
Sounds somewhat similar to p2pool to me but I'm not sure I understand it.
|
