path: root/35/a5f9b08b224137d55b318ed49a5a9ef2fbda5e

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 <ctpacia@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANOOu=85-6p-v8ZWPC=zGAY9TdjgR1WK_fOOJYnyFJMj+dvHUQ@mail.gmail.com>
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>
Date: Wed, 23 Apr 2014 12:19:52 -0400
Message-ID: <CAB+qUq4-CZ6C9hBsc9vuH=Qz61_jEQNXm=djQfLKiv1SXMBNng@mail.gmail.com>
From: Chris Pacia <ctpacia@gmail.com>
To: Christophe Biocca <christophe.biocca@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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" <christophe.biocca@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@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
>

--047d7bd6b61a34447a04f7b81a6b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">What is the advantage of this proposal over just orphaning t=
he block with double spends?</p>
<p dir=3D"ltr">There&#39;s currently a set of rules which government what c=
onstitutes a valid block. Miners don&#39;t build on blocks that don&#39;t a=
ccord with those rules out of fear that a major won&#39;t follow and they w=
ill waste hashing power.</p>

<p dir=3D"ltr">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&#39;t build on them for the same reason they wouldn&#39;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. </p>

<div class=3D"gmail_quote">On Apr 23, 2014 12:04 PM, &quot;Christophe Biocc=
a&quot; &lt;<a href=3D"mailto:christophe.biocca@gmail.com">christophe.biocc=
a@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
It&#39;s not necessary that this &quot;coinbase retribution&quot; be either=
<br>
profitable or risk-free for this scheme to work. I think we should<br>
separate out the different layers of the proposal:<br>
<br>
1. Attacking the coinbase instead of orphaning allows for 100 blocks&#39;<b=
r>
time for a consensus to be reached, rather than 10 minutes. This<br>
allows for human verification/intervention if needed (orphaning<br>
decisions would almost always need to be automated, due to the short<br>
timeframe). This is a useful insight, and I don&#39;t think it&#39;s been<b=
r>
brought up before.<br>
<br>
2. The original specification of how it&#39;s done (redistribution, no<br>
cost to voting) does seem exploitable. This can be fixed by reducing<br>
the incentive (burning instead of redistributing) and/or adding a risk<br>
to the orphaning attempts (a vote that fails destroys X bitcoins&#39;<br>
worth from each voting block&#39;s own coinbase). The incentives can be<br>
tailored to mirror those of orphaning a block, to reduce the risk of<br>
abuse. Then the only difference from orphaning are 1) More limited<br>
rewriting of history (only the coinbase, vs all transactions in the<br>
block), and 2) More time to coordinate a response.<br>
<br>
3. This proposal may be used for things other than punishing<br>
double-spend pools. In fact it might be used to punish miners for<br>
doing anything a significant percentage of hashpower dislikes (large<br>
OP_RETURNs, large blocks, gambling transactions, transactions banned<br>
by a government). But we can make the threshold higher than 51%, so<br>
that this doesn&#39;t turn into a significant risk (if 75% of hashpower is<=
br>
willing to enforce a rule, we&#39;re already likely to see it enforced<br>
through orphaning).<br>
<br>
On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi &lt;<a href=3D"mailto:alex.m=
izrahi@gmail.com">alex.mizrahi@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; And it still would. Non-collusive miners cast votes based on the o=
utcome<br>
&gt;&gt; of their own attempts to double spend.<br>
&gt;<br>
&gt;<br>
&gt; Individually rational strategy is to vote for coinbase reallocation on=
 every<br>
&gt; block.<br>
&gt;<br>
&gt; Yes, in that case nobody will get reward. It is similar to prisoner&#3=
9;s<br>
&gt; dilemma: equilibrium has worst pay-off.<br>
&gt; In practice that would mean that simple game-theoretic models are no l=
onger<br>
&gt; applicable, as they lead to absurd results.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m using it in the same sense Satoshi used it. Honest miners =
work to<br>
&gt;&gt; prevent double spends. That&#39;s the entire justification for the=
ir existence.<br>
&gt;&gt; Miners that are deliberately trying to double spend are worse than=
 useless.<br>
&gt;<br>
&gt;<br>
&gt; Miners work to get rewards.<br>
&gt; It absolutely doesn&#39;t matter whether they are deliberately trying =
to<br>
&gt; double-spend or not: they won&#39;t be able to double-spend without a =
collusion.<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Start Your Social Network Today - Download eXo Platform<br>
&gt; Build your Enterprise Intranet with eXo Platform Software<br>
&gt; Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
&gt; Get Started Now And Turn Your Intranet Into A Collaboration Platform<b=
r>
&gt; <a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p=
.sf.net/sfu/ExoPlatform</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--047d7bd6b61a34447a04f7b81a6b--