From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wcztv-0006sy-1P for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 16:19:59 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.182 as permitted sender) client-ip=209.85.214.182; envelope-from=ctpacia@gmail.com; helo=mail-ob0-f182.google.com; Received: from mail-ob0-f182.google.com ([209.85.214.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wcztt-0007Dc-S5 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 16:19:59 +0000 Received: by mail-ob0-f182.google.com with SMTP id uy5so1293229obc.27 for ; Wed, 23 Apr 2014 09:19:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.155.35 with SMTP id vt3mr43779471oeb.32.1398269992517; Wed, 23 Apr 2014 09:19:52 -0700 (PDT) Received: by 10.60.232.136 with HTTP; Wed, 23 Apr 2014 09:19:52 -0700 (PDT) Received: by 10.60.232.136 with HTTP; Wed, 23 Apr 2014 09:19:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 12:19:52 -0400 Message-ID: From: Chris Pacia To: Christophe Biocca Content-Type: multipart/alternative; boundary=047d7bd6b61a34447a04f7b81a6b X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ctpacia[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Wcztt-0007Dc-S5 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:19:59 -0000 --047d7bd6b61a34447a04f7b81a6b Content-Type: text/plain; charset=UTF-8 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" 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 > 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 > --047d7bd6b61a34447a04f7b81a6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

There's currently a set of rules which government what c= onstitutes a valid block. Miners don't build on blocks that don't a= ccord with those rules out of fear that a major won't follow and they w= ill waste hashing power.

If there was a rule supported by the majority that considere= d blocks with double spends (defined in some fashion) as invalid miners wou= ldn't build on them for the same reason they wouldn't build on a bl= ock with a coinbase over 25 btc, say. It seems that would accomplish the sa= me without the other issues.

On Apr 23, 2014 12:04 PM, "Christophe Biocc= a" <christophe.biocc= a@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<= br> 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 o= utcome
>> 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= 9;s
> dilemma: equilibrium has worst pay-off.
> In practice that would mean that simple game-theoretic models are no l= onger
> 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 the= ir 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-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-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.n= et/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7bd6b61a34447a04f7b81a6b--