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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <christophe.biocca@gmail.com>) id 1WdKw9-0004CT-TZ
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:47:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.169 as permitted sender)
client-ip=209.85.223.169;
envelope-from=christophe.biocca@gmail.com;
helo=mail-ie0-f169.google.com;
Received: from mail-ie0-f169.google.com ([209.85.223.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdKw8-00059L-KB
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:47:41 +0000
Received: by mail-ie0-f169.google.com with SMTP id to1so2483259ieb.14
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 07:47:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.26.206 with SMTP id rn14mr2266497icb.13.1398350855371;
Thu, 24 Apr 2014 07:47:35 -0700 (PDT)
Received: by 10.64.102.136 with HTTP; Thu, 24 Apr 2014 07:47:35 -0700 (PDT)
In-Reply-To: <CANEZrP0Qmmrs5dzQ8N6FGL1K3W0A0XWBqtkPTFOgU_rXDvc+sQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
<CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com>
<CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@mail.gmail.com>
<CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com>
<CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com>
<CANEZrP18=Y5EBcfR-sHumVvU3-yqYr1tuhr_J4ieG817HOpE=g@mail.gmail.com>
<20140424134441.GE16884@savin>
<CANEZrP0Qmmrs5dzQ8N6FGL1K3W0A0XWBqtkPTFOgU_rXDvc+sQ@mail.gmail.com>
Date: Thu, 24 Apr 2014 10:47:35 -0400
Message-ID: <CANOOu=8XLdS-v-xULrv8Y5XukapCafTLDGa0M0q_W1speb2Ykg@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(christophe.biocca[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WdKw8-00059L-KB
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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:47:42 -0000
Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time without losing their usefulness:
Assume a world where 75% of the hashpower is coerced into
stealing/burning the coinbases of miners who allow transactions to and
from a particular set of addresses (the actual rule isn't that
important). Then the following would be a rational behaviour from the
remaining 25%:
- Mine according to the enforced rules most of the time.
- Accept banned transactions paying you with an output (no real
miners' fees) and keep them in an ever-accumulating pool.
- When there's so much of those to make it worth your while, mine a
block filled with them.
If miners don't orphan your block, you made money. They can't
retaliate further, because you can publish the block anonymously, not
tying it to your previous identity. Hell, some of the 75% might be
able to do the same right under the authorities' noses (it would be
really hard to spot by an external observer).
Note that I, banned user, can submit to all these non-enforcing miners
at once (with a different fee txout for each). I get a severe
degradation of service, especially if I'm part of an extremely small
minority, but ultimately as long as a single miner can accumulate
enough transactions with enough fees, I'll eventually get through.
Of course, in such a dystopian future, orphaning would be the
enforcement mechanism. It would be stupid to rely on coinbase
reallocation/burning to do this task when the existing tools work so
much better.
What's interesting is that this mechanism is especially tailored to
blocking time sensitive transactions (that need to be confirmed
now/soon, or are worthless), such that their total out-of-band fees
can't build up over time. Double spending is one such category. I'm at
a loss to come up with something else, but maybe someone has a good
example?
On Thu, Apr 24, 2014 at 10:09 AM, Mike Hearn <mike@plan99.net> wrote:
>> Like I said before, that leads to the obvious next step of
>> deleting/stealing their coinbases if they don't identify themselves.
>
>
> And as I said before, that's a huge leap. A majority of miners deciding
> double spending needs tougher enforcement doesn't imply they also think all
> miners should identify themselves. Those are unrelated things.
>
> This kind of totally unsupported "obvious next step" argument can be applied
> to any proposal in any walk of life. We developed SPV clients? The obvious
> next step is that miners have to stop being anonymous. We developed floating
> fees? The obvious next step is that miners have to stop being anonymous. The
> prior arguments sound absurd exactly because they're not obvious or even
> logical - same as this.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
