[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

Chris Pacia ctpacia at gmail.com
Wed Apr 23 16:19:52 UTC 2014


What is the advantage of this proposal over just orphaning the block with
double spends?

There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.

If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
wrote:

> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com>
> wrote:
> >
> >>
> >> And it still would. Non-collusive miners cast votes based on the outcome
> >> of their own attempts to double spend.
> >
> >
> > Individually rational strategy is to vote for coinbase reallocation on
> every
> > block.
> >
> > Yes, in that case nobody will get reward. It is similar to prisoner's
> > dilemma: equilibrium has worst pay-off.
> > In practice that would mean that simple game-theoretic models are no
> longer
> > applicable, as they lead to absurd results.
> >
> >>
> >> I'm using it in the same sense Satoshi used it. Honest miners work to
> >> prevent double spends. That's the entire justification for their
> existence.
> >> Miners that are deliberately trying to double spend are worse than
> useless.
> >
> >
> > Miners work to get rewards.
> > It absolutely doesn't matter whether they are deliberately trying to
> > double-spend or not: they won't be able to double-spend without a
> collusion.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/48d8a89a/attachment.html>


More information about the bitcoin-dev mailing list