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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <aritter@gmail.com>) id 1WdL0f-0004Qj-G9
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:52:21 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.179 as permitted sender)
client-ip=209.85.220.179; envelope-from=aritter@gmail.com;
helo=mail-vc0-f179.google.com;
Received: from mail-vc0-f179.google.com ([209.85.220.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdL0e-0003BM-HZ
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:52:21 +0000
Received: by mail-vc0-f179.google.com with SMTP id ij19so3154630vcb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 07:52:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.221.27.8 with SMTP id ro8mr1042124vcb.30.1398351135047; Thu,
24 Apr 2014 07:52:15 -0700 (PDT)
Received: by 10.220.140.208 with HTTP; Thu, 24 Apr 2014 07:52:14 -0700 (PDT)
In-Reply-To: <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@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>
<CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com>
<CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
Date: Thu, 24 Apr 2014 16:52:14 +0200
Message-ID: <CAKuKjyVxQGezxo-2-063oMavQhi6cTOPwPacmLGkSJQ488UA2w@mail.gmail.com>
From: Adam Ritter <aritter@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Gregory Maxwell <gmaxwell@gmail.com>, Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11336baaad06fb04f7cafe78
X-Spam-Score: -0.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
(aritter[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WdL0e-0003BM-HZ
Subject: [Bitcoin-development] Fwd: 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:52:21 -0000
--001a11336baaad06fb04f7cafe78
Content-Type: text/plain; charset=UTF-8
I wouldn't mind having $5 of my money held at
Apple/Google/VISA/Mastercard/BitPay (and I wouldn't be sad of losing $5 if
any of these companies go bankrupt).
Actually I had in mind creating a centralized version of Bitcoin for
ultra-fast payments. With keeping all addresses on SSDs, asking for 1 cent
/ address month, 1 cent / transaction should be possible to reach even with
6x replication. Companies could compete in price as long as the API is
standardized. Automatic top-up should be simple as well.
On Wed, Apr 23, 2014 at 10:53 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> On Wed, Apr 23, 2014 at 1: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.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them. And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>
--001a11336baaad06fb04f7cafe78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">I wouldn't=
mind having $5 of my money held at Apple/Google/VISA/Mastercard/BitPay (an=
d I wouldn't be sad of losing $5 if any of these companies go bankrupt)=
.<br>
<div>Actually I had in mind creating a centralized version of Bitcoin for u=
ltra-fast payments. With keeping all addresses on SSDs, asking for 1 cent /=
address month, 1 cent / transaction should be possible to reach even with =
6x replication. Companies could compete in price as long as the API is stan=
dardized. Automatic top-up should be simple as well.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Wed, Apr 23, 2014 at 10:53 PM, Gregory =
Maxwell <span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=
=3D"_blank">gmaxwell@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>On Wed, Apr 23, 2014 at 1:44 PM, Adam R=
itter <<a href=3D"mailto:aritter@gmail.com" target=3D"_blank">aritter@gm=
ail.com</a>> wrote:<br>
> Isn't a faster blockchain for transactions (maybe as a sidechain) =
solving<br>
> the problem? If there would be a safe way for 0-confirmation transacti=
ons,<br>
> the Bitcoin blockchain wouldn't even be needed.<br>
<br>
</div>Large scale consensus can't generally provide instantly irreversi=
ble<br>
transactions directly: Increasing the block speed can't help past the<b=
r>
point where the time starts getting close to the network diameter...<br>
you simply can't tell what a consensus of a group of nodes is until<br>
several times the light cone that includes all of them. =C2=A0And if you<br=
>
start getting close to the limit you dilute the power working on the<br>
consensus and potentially make life easier for a large attacker.<br>
<br>
Maybe other chains with different parameters could achieve a different<br>
tradeoff which was better suited to low value retail transactions<br>
(e.g. where you want a soft confirmation fast). A choice of tradeoffs<br>
could be very useful, and maybe you can practically get close enough<br>
(e.g. would knowing you lost a zero-conf double spend within 30<br>
seconds 90% of the time be good enough?)... but I'm not aware of any<br=
>
silver bullet there which gives you something identical to what a<br>
centralized service can give you without invoking at least a little<br>
bit of centralization.<br>
</blockquote></div><br></div>
</div></div></div><br></div>
--001a11336baaad06fb04f7cafe78--
|
