<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo <span dir="ltr">&lt;<a href="mailto:lf-lists@mattcorallo.com" target="_blank">lf-lists@mattcorallo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Oops, just realized I never responded to this...<br>
<span class=""><br>
On 10/15/15 15:09, Ittay wrote:<br>
&gt; Thanks, Matt. Response inline.<br>
&gt;<br>
&gt; On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo &lt;<a href="mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a><br>
</span><span class="">&gt; &lt;mailto:<a href="mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     That conversation missed a second issue. Namely that there is no way<br>
&gt;     to punish people if there is a double spend in a micro block that<br>
&gt;     happens in key block which reorg&#39;d away the first transaction. eg<br>
&gt;     one miner mines a transaction in a micro block, another miner<br>
&gt;     (either by not having seen the first yet, or being malicious -<br>
&gt;     potentially the same miner) mines a key block which reorgs away the<br>
&gt;     first micro block and then, in their first micro block, mines a<br>
&gt;     double spend. This can happen at any time, so you end up having to<br>
&gt;     fall back to regular full blocks for confirmation times :(.<br>
&gt;<br>
&gt;<br>
&gt; If NG is to be used efficiently, microblocks are going to be very<br>
&gt; frequent, and so such forks should occur at almost every key-block<br>
&gt; publication. Short reorgs as you described are the norm. A user should<br>
&gt; wait before accepting a transaction to make sure there was no key-block<br>
&gt; she missed. The wait time is chosen according to the network propagation<br>
&gt; delay (+as much slack as the user feels necessary). This is similar to<br>
&gt; the situation in Bitcoin when you receive a block. To be confident that<br>
&gt; you have one confirmation you should wait for the propagation time of<br>
&gt; the network to make sure there is no branch you missed.<br>
<br>
</span>I think you&#39;re overstating how short the wait times can be. They need to<br>
be much longer than the network propagation delay.<br>
<span class=""><br>
&gt; As for the malicious case: the attacker has to win the key-block, have<br>
&gt; the to-be-inverted transaction in the previous epoch, and withhold his<br>
&gt; key-block for a while. That being said, indeed our fraud proof scheme<br>
&gt; doesn&#39;t catch such an event, as it is indistinguishable from benign<br>
&gt; behavior.<br>
<br>
</span>The attacker does not need to withold their keyblock at all. All the<br>
attacker does is, for every transaction they ever send, after it is<br>
included in a microblock, set their hashpower to start mining a keyblock<br>
immediately prior to this microblock. When they find a keyblock, they<br>
immediately announce it and start creating microblocks, the first of<br>
which double-spends the previous transaction. If they dont win the key<br>
block, oh well, their payment went through normally and they couldn&#39;t<br>
double-spend.<br>
<br>
In chatting with Glenn about this, we roughly agreed that the<br>
confirmation time for microblocks possibly doesn&#39;t need to be a full<br>
key-block, but it needs to be a reasonable period after which such an<br>
attacker would lose more in fees than the value of their double-spend<br>
(ie because the key-block afterwards gets 20% more in fees than the<br>
key-block before hand). In any case, the game theory here starts to get<br>
rather complicated and it doesn&#39;t make me want to suggest accepting<br>
microblocks as confirmations is safe.<br></blockquote><div><br></div><div style=""><div style=""><span style="font-size:12.8px">Yes, an attacker can continuously try to do this, losing all (and only) fees. </span></div><div style=""><span style="font-size:12.8px">They will succeed every time they mine a block after the to-be-double-spent </span></div><div style=""><span style="font-size:12.8px">transaction is placed by the current leader. So a microblock + delay is stronger </span></div><div style=""><span style="font-size:12.8px">than a zero-confirmation transaction, but not as strong as a first-block </span></div><div style=""><span style="font-size:12.8px">confirmation. </span></div><div style=""><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px">A game theory analysis is indeed difficult here, mainly since the assumptions </span></div><div style=""><span style="font-size:12.8px">are not entirely clear. We are working towards this, starting with formalizing </span></div><div style=""><span style="font-size:12.8px">the attacker&#39;s incentive structure. </span></div><div style="font-size:12.8px"><br></div></div></div></div></div>