rich1.0npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cghttps://nostr.ae/npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cgnjumphttps://nostr.ae📅 Original date posted:2015-10-15 📝 Original message:Thanks, Matt. Response inline. On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <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. 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. > 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? > > On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> >> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure at gmail.com> wrote: >> >>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer >>> <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 >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/784e0876/attachment.html>