Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.181 as permitted sender)
	client-ip=209.85.216.181;
	envelope-from=kevinsisco61784@gmail.com;
	helo=mail-qc0-f181.google.com; 
Message-ID: <5357EB74.1030806@gmail.com>
Date: Wed, 23 Apr 2014 12:33:56 -0400
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>	<CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>	<CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com>	<CAE28kUQqFJUJSiSV4PSF2QK04D3GuL1n2EF46Yo3o_-LYsgSTA@mail.gmail.com>
	<CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
In-Reply-To: <CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
 Finney attacks
Precedence: list

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 <alex.mizrahi@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@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@lists.sourceforge.net
> 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