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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Wd48t-0004Mb-7Z
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:51:43 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd48s-0005Zu-D5
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:51:43 +0000
Received: by mail-oa0-f43.google.com with SMTP id eb12so1651231oac.2
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 13:51:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr2413479oeb.81.1398286297038;
Wed, 23 Apr 2014 13:51:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 13:51:36 -0700 (PDT)
In-Reply-To: <CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
<CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
<CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
<CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
Date: Wed, 23 Apr 2014 22:51:36 +0200
X-Google-Sender-Auth: iGZrvBtOxsjMJb1ZotjYc8cJ9P4
Message-ID: <CANEZrP0pJgjCzEZg19-Xnf20PD7FCRqF8=jQ_VBrznq=w_vQGQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Ritter <aritter@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41cd280786b204f7bbe61b
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: 1Wd48s-0005Zu-D5
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 20:51:43 -0000
--047d7b41cd280786b204f7bbe61b
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter <aritter@gmail.com> wrote:
> Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> the problem? If there would be a safe way for 0-confirmation transactions,
> the Bitcoin blockchain wouldn't even be needed.
>
The 10 minute average comes from a desire to balance wasted work due to
natural chain splits with latency. With a very fast block interval you end
up with lots of forks and things take longer to converge, also, it can make
attacks easier because an attacker is building on his own blocks so he
doesn't suffer propagation delays and the attendant splits.
It's not clear you can just make a faster block chain. 10 minutes is
somewhat arbitrary, it could be 5 minutes and the system would still work,
but it probably can't be 5 seconds.
Unfortunately for best physical-world usability you really need very fast
payments. A few seconds is competitive with modern credit cards. The new
contactless cards seem to be able to reliably manage <1 sec which is
impressive. Waiting for blocks in a block chain can't really work. Waiting
for propagation can work and has been working so far. Hence, the question
of how that mechanism can be kept working in the face of malicious miners,
before you end up having to fall back to trusted third parties and
recentralisation.
--047d7b41cd280786b204f7bbe61b
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 10:44 PM, Adam Ritter <span dir=3D"ltr"><<a href=3D"=
mailto:aritter@gmail.com" target=3D"_blank">aritter@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"><div dir=3D"ltr">Isn't a faster blockcha=
in for transactions (maybe as a sidechain) solving the problem? If there wo=
uld be a safe way for 0-confirmation transactions, the Bitcoin blockchain w=
ouldn't even be needed.</div>
</blockquote><div><br></div><div>The 10 minute average comes from a desire =
to balance wasted work due to natural chain splits with latency. With a ver=
y fast block interval you end up with lots of forks and things take longer =
to converge, also, it can make attacks easier because an attacker is buildi=
ng on his own blocks so he doesn't suffer propagation delays and the at=
tendant splits.</div>
<div><br></div><div>It's not clear you can just make a faster block cha=
in. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system =
would still work, but it probably can't be 5 seconds.=C2=A0</div><div><=
br>
</div><div>Unfortunately for best physical-world usability you really need =
very fast payments. A few seconds is competitive with modern credit cards. =
The new contactless cards seem to be able to reliably manage <1 sec whic=
h is impressive. Waiting for blocks in a block chain can't really work.=
Waiting for propagation can work and has been working so far. Hence, the q=
uestion of how that mechanism can be kept working in the face of malicious =
miners, before you end up having to fall back to trusted third parties and =
recentralisation.</div>
</div></div></div>
--047d7b41cd280786b204f7bbe61b--
|
