Oops, just realized I never responded to this...
On 10/15/15 15:09, Ittay wrote:
> Thanks, Matt. Response inline.
>
> On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists@mattcorallo.com
> <mailto:lf-lists@mattcorallo.com>> wrote:
>
> 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 :(.
>
>
> If NG is to be used efficiently, microblocks are going to be very
> frequent, and so such forks should occur at almost every key-block
> publication. Short reorgs as you described are the norm. A user should
> wait before accepting a transaction to make sure there was no key-block
> she missed. The wait time is chosen according to the network propagation
> delay (+as much slack as the user feels necessary). This is similar to
> the situation in Bitcoin when you receive a block. To be confident that
> you have one confirmation you should wait for the propagation time of
> the network to make sure there is no branch you missed.
I think you're overstating how short the wait times can be. They need to
be much longer than the network propagation delay.
> As for the malicious case: the attacker has to win the key-block, have
> the to-be-inverted transaction in the previous epoch, and withhold his
> key-block for a while. That being said, indeed our fraud proof scheme
> doesn't catch such an event, as it is indistinguishable from benign
> behavior.
The attacker does not need to withold their keyblock at all. All the
attacker does is, for every transaction they ever send, after it is
included in a microblock, set their hashpower to start mining a keyblock
immediately prior to this microblock. When they find a keyblock, they
immediately announce it and start creating microblocks, the first of
which double-spends the previous transaction. If they dont win the key
block, oh well, their payment went through normally and they couldn't
double-spend.
In chatting with Glenn about this, we roughly agreed that the
confirmation time for microblocks possibly doesn't need to be a full
key-block, but it needs to be a reasonable period after which such an
attacker would lose more in fees than the value of their double-spend
(ie because the key-block afterwards gets 20% more in fees than the
key-block before hand). In any case, the game theory here starts to get
rather complicated and it doesn't make me want to suggest accepting
microblocks as confirmations is safe.