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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WdFu2-0006qU-5O
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 09:25:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.49 as permitted sender)
client-ip=209.85.215.49; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f49.google.com;
Received: from mail-la0-f49.google.com ([209.85.215.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdFu0-0005sq-Vv
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 09:25:10 +0000
Received: by mail-la0-f49.google.com with SMTP id ec20so1468497lab.36
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 02:25:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.209.5 with SMTP id mi5mr464761lbc.30.1398331502326; Thu,
24 Apr 2014 02:25:02 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Thu, 24 Apr 2014 02:25:02 -0700 (PDT)
In-Reply-To: <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@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>
Date: Thu, 24 Apr 2014 02:25:02 -0700
Message-ID: <CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
(gmaxwell[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: 1WdFu0-0005sq-Vv
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 09:25:10 -0000
On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn <mike@plan99.net> wrote:
> It absolutely is!
> https://bitcointalk.org/index.php?topic=3D60937.0
May I direct your attention to the third post in that thread?
Luke attempting to ret-con the enforcement flag into a vote didn't
make it one, and certantly wouldn't make it a fair, just, or sane
method of one. And so much for the effectiveness=E2=80=94 you didn't implem=
ent
it for years even after it was deployed.
And yes, you can take any decision system and draw comparisons to
voting and call it a vote but that doesn't mean is serves the same
role or was intended for that purpose.
> No, coinbases are deletable. If some miners fork the chain and build a
> longer one, the others will all switch to it and the coinbases blocks the=
y
Yes, you can reorg out the blocks and actually remove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.
> I think the root of this disagreement is whether the block chain algorith=
m
> left by Satoshi is somehow immutable and itself the end, or whether it's =
(as
> I see it) just a means to an end and therefore an algorithm that can be
> tweaked and improved, to get us closer to the goal.
I don't think thats the root of the the disagreement at all. I think
all sorts of changes are interesting, especially ones that increase
flexibility or fix bugs but less so ones that would impose significant
changes on parties without their consent especially things that look
like taking someone's coins and assigning them to someone else.
I think the root is that you believe that the miners are, should be,
or even could be trustworthy in ways that I do not, and as a result
you expect to be able to extract the performance of a trusted
centralized system out of them that I do not. Bitcoin is a system
where the incentives are well enough aligned that you appear to only
need a small amount of altruism to make it reliable. ... and even
summoning that altruism is a challenge=E2=80=94 as miners hand over control=
of
their hash-power to centralized pools (some known to have behaved
poorly in the past), etc.
I would like that performance if it came at no cost: But proposals
that miners conspiring to blacklist transactions/blocks produced by
other people is something with a risk of a worse violation of the
system's promises than some disagreement of the ordering of
unconfirmed transactions. Pretty much immediately after your post
Peter Todd=E2=80=94 in his trouble making manner=E2=80=94 went and posted o=
n reddit
proposing the mechanism be used to claw back mining income from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware. While Peter's suggestion
was no doubt intentionally trouble making=E2=80=94 I'm not clear on where t=
he
line is here: Harm from reordering pretty much non-existent currently
and is highly speculative, while the harm to miners by hardware
vendors who've promised to not compete with their own customers or use
their equipment is not at all speculative and very salient to miners.
This especially in light of the fact that the system already has an
equitable method to decide what order transactions should be in... but
instead you propose an additional complex heuristic system where based
on some unspecified collusion some majority of miners take a
minorities coins and assign them to themselves.
Unlike reorginization this form of wealth transferal has no collateral
damage meaning that a majority cabal can use it to deprive a minority
outsider of some or all income without risking disrupting the network,
it would also lay the groundwork for additional forms of censorship
which I believe would be at odds with the purpose and architecture of
the system... and, as I noted above, it wouldn't actually prevent
theft, it would just mean that no single block could make its theft
services available to all comers (or even any of the public at all).
The simple mechenism of allowing only only a small number of paid
reordering transactions per block would prevent forming a quorum on
the decision to revoke the coinbase, and you'd even get additional
income from the probe transactions without even helping any real
double spends at all. The incentives seem very hard to analyze.
|
