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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WcweA-0001Yr-Ev
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 12:51:30 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wcwe9-00023E-HM
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 12:51:30 +0000
Received: by mail-ob0-f170.google.com with SMTP id vb8so959605obc.15
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 05:51:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.76.194 with SMTP id m2mr12719161oew.47.1398257484126;
Wed, 23 Apr 2014 05:51:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 05:51:24 -0700 (PDT)
In-Reply-To: <CANOOu=-9ngzfdzhred2hRkH2Zx=wfBXH0qd29xrxdcY+43AeTg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CANOOu=-9ngzfdzhred2hRkH2Zx=wfBXH0qd29xrxdcY+43AeTg@mail.gmail.com>
Date: Wed, 23 Apr 2014 14:51:24 +0200
X-Google-Sender-Auth: eTyjyn9OVMCvHgx8yAYkV5x7_cE
Message-ID: <CANEZrP1womQueQpmFJBEG6RTWMR+GJg+uL2DX1HcnPDk0Q35rA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Christophe Biocca <christophe.biocca@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33cea6a55de704f7b53064
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Wcwe9-00023E-HM
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: Wed, 23 Apr 2014 12:51:30 -0000
--047d7b33cea6a55de704f7b53064
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 2:43 PM, Christophe Biocca <
christophe.biocca@gmail.com> wrote:
> 1. This provides a very strong incentive to always vote for
> reallocating a block if it isn't yours
If everyone votes to reallocate everyone elses blocks all the time, then
you'd end up losing your own coins too, so this doesn't seem like a
workable strategy.
> a) Requiring supermajorities
> c) Burning, rather than reallocating, the coins. Miners' immediate
> incentive to attack honest pools is much reduced.
>
I'm OK with burning actually. The total amount of coins in the system
essentially defines its maximum price resolution. Ideally we'd not lose
resolution, but it's less important than having a system that does actually
work. Moreover, this sort of system is like double spending defence itself
- if it does work, it doesn't need to actually be done very frequently
because people know the safeguards work and don't try. So in practice total
loss of resolution should be limited.
> 2. BitUndo gets paid using additional txouts in the double-spend
> transaction, no by miner's fees.
Right. It's indeed an assumption that block rewards matter to miners, even
the ones that have double spend revenues.
--047d7b33cea6a55de704f7b53064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 23, 2014 at 2:43 PM, Christophe Biocca <span dir=3D"ltr"><<a hre=
f=3D"mailto:christophe.biocca@gmail.com" target=3D"_blank">christophe.biocc=
a@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">1. This provides a very strong incentive to =
always vote for<br>
reallocating a block if it isn't yours</blockquote><div>=C2=A0</div><di=
v>If everyone votes to reallocate everyone elses blocks all the time, then =
you'd end up losing your own coins too, so this doesn't seem like a=
workable strategy.=C2=A0</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0 =C2=A0 a) Requiring =
supermajorities<br>=C2=A0 =C2=A0 c) Burning, rather than reallocating, the =
coins. Miners' immediate<br>
incentive to attack honest pools is much reduced.<br></blockquote><div><br>=
</div><div>I'm OK with burning actually. The total amount of coins in t=
he system essentially defines its maximum price resolution. Ideally we'=
d not lose resolution, but it's less important than having a system tha=
t does actually work. Moreover, this sort of system is like double spending=
defence itself - if it does work, it doesn't need to actually be done =
very frequently because people know the safeguards work and don't try. =
So in practice total loss of resolution should be limited.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">2. BitUndo gets paid using =
additional txouts in the double-spend<br>
transaction, no by miner's fees.</blockquote><div><br></div><div>Right.=
It's indeed an assumption that block rewards matter to miners, even th=
e ones that have double spend revenues.</div></div></div></div>
--047d7b33cea6a55de704f7b53064--
|
