rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2015-10-28 📝 Original message: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 at mattcorallo.com > <mailto:lf-lists at 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. > 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). > > > Agreed x3: This is a good point, it is correct, and the tweak is dangerous. > Do you perceive this as a significant practical issue? It is not a practical issue today because no one does it, but it is a massive issue in that the splitting of pool rewards and transaction selection is one of the few easy wins we have left in the fight against mining centralization. Mining centralization today is absolutely awful, and closing off our only big win would be tragic. > On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev > <bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote: > > > On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure at gmail.com > <mailto:kanzure at gmail.com>> wrote: > > On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer > <bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >