[Bitcoin-development] Fwd: Coinbase reallocation to discourage Finney attacks

Adam Ritter aritter at gmail.com
Thu Apr 24 14:52:14 UTC 2014


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 at gmail.com>wrote:

> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/7ace8643/attachment.html>


More information about the bitcoin-dev mailing list