On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo wrote: > 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 > > 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. > Yes, an attacker can continuously try to do this, losing all (and only) fees. They will succeed every time they mine a block after the to-be-double-spent transaction is placed by the current leader. So a microblock + delay is stronger than a zero-confirmation transaction, but not as strong as a first-block confirmation. A game theory analysis is indeed difficult here, mainly since the assumptions are not entirely clear. We are working towards this, starting with formalizing the attacker's incentive structure.