In-Reply-To: <CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
References: <CAPkFh0viwmkUvjo4Qj50TNnkA5kG3z-3dLGExjkmDacE4E49Ow@mail.gmail.com>
	<CABaSBaxWAsEG71FTy4SrVu94BXokeozmJ80tjsNU8ERpTfFaFA@mail.gmail.com>
	<CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----YMPFIUJBG0EG12QR5WNRD59SW98WRT"
Content-Transfer-Encoding: 8bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Wed, 14 Oct 2015 18:57:08 +0000
To: Ittay <ittay.eyal@cornell.edu>,
	Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail.com>
Message-ID: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Ittay Eyal <ittay.eyal@cornell.edu>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
Precedence: list

------YMPFIUJBG0EG12QR5WNRD59SW98WRT
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.

Also, Greg Slepak brought up a good point on twitter at https://twitter.com/taoeffect/status/654358023138209792. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block's total reward).

On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail.com>
>wrote:
>
>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > while the whitepaper has all the nitty gritty details:
>> >      http://arxiv.org/abs/1510.02037
>>
>> Taking reward compensation back by fraud proofs is not enough to fix
>> the problems associated with double spending (such as, everyone has
>to
>> wait for the "real" confirmations instead of the "possibly
>> double-spend" confirmations). Some of this was discussed in -wizards
>> recently:
>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>
>
>Fraud proof removes all the attacker's revenue. It's like the attacker
>sacrifices an entire block for double spending in the current system. I
>think Luke-Jr got it right at that discussion.
>
>Best,
>Ittay
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

------YMPFIUJBG0EG12QR5WNRD59SW98WRT
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg&#39;d away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the first yet, or being malicious - potentially the same miner) mines a key block which reorgs away the first micro block and then, in their first micro block, mines a double spend. This can happen at any time, so you end up having to fall back to regular full blocks for confirmation times :(.<br>
<br>
Also, Greg Slepak brought up a good point on twitter at <a href="https://twitter.com/taoeffect/status/654358023138209792">https://twitter.com/taoeffect/status/654358023138209792</a>. Noting that this model means users could no longer pick transactions in a mining pool which was set up in such a way (it could be tweaked to do so with separate rewards and pubkeys, but now the user can commit fraud at a much lower cost - their own pool reward, not the block&#39;s total reward).<br><br><div class="gmail_quote">On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <span dir="ltr">&lt;<a href="mailto:kanzure@gmail.com" target="_blank">kanzure@gmail.com</a>&gt;</span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer<br />
&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br />
&gt; while the whitepaper has all the nitty gritty details:<br />
&gt;      <a href="http://arxiv.org/abs/1510.02037" rel="noreferrer" target="_blank">http://arxiv.org/abs/1510.02037</a><br />
<br />
</span>Taking reward compensation back by fraud proofs is not enough to fix<br />
the problems associated with double spending (such as, everyone has to<br />
wait for the &quot;real&quot; confirmations instead of the &quot;possibly<br />
double-spend&quot; confirmations). Some of this was discussed in -wizards<br />
recently:<br />
<a href="http://gnusha.org/bitcoin-wizards/2015-09-19.log" rel="noreferrer" target="_blank">http://gnusha.org/bitcoin-wizards/2015-09-19.log</a></blockquote><div><br /></div><div>Fraud proof removes all the attacker&#39;s revenue. It&#39;s like the attacker sacrifices an entire block for double spending in the current system. I think Luke-Jr got it right at that discussion. </div><div><br /></div><div>Best, </div></div></div><div class="gmail_extra">Ittay </div><div class="gmail_extra"><br /></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></body></html>
------YMPFIUJBG0EG12QR5WNRD59SW98WRT--