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

From: Kevin <[email-masked]>
Date: Wed, 23 Apr 2014 12:33:56 -0400

On 4/23/2014 12:04 PM, Christophe Biocca 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 <[email-masked]> 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
>> [email-masked]
>> 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
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
This all sounds verry restrictive.  Is it possible to do a "sweep" in 
order to "clean up" double spending?  Why punish miners for the sake of 
punishing them?

-- 
Kevin