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; 
MIME-Version: 1.0
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
Subject: [Bitcoin-development] Fwd: Coinbase reallocation to discourage
	Finney attacks
Precedence: list

--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&#39;t=
 mind having $5 of my money held at Apple/Google/VISA/Mastercard/BitPay (an=
d I wouldn&#39;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">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=
=3D"_blank">gmaxwell@gmail.com</a>&gt;</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 &lt;<a href=3D"mailto:aritter@gmail.com" target=3D"_blank">aritter@gm=
ail.com</a>&gt; wrote:<br>


&gt; Isn&#39;t a faster blockchain for transactions (maybe as a sidechain) =
solving<br>
&gt; the problem? If there would be a safe way for 0-confirmation transacti=
ons,<br>
&gt; the Bitcoin blockchain wouldn&#39;t even be needed.<br>
<br>
</div>Large scale consensus can&#39;t generally provide instantly irreversi=
ble<br>
transactions directly: Increasing the block speed can&#39;t help past the<b=
r>
point where the time starts getting close to the network diameter...<br>
you simply can&#39;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&#39;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--