{"type":"rich","version":"1.0","author_name":"npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cg","author_url":"https://nostr.ae/npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-15\n📝 Original message:Thanks, Matt. Response inline.\n\nOn Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e That conversation missed a second issue. Namely that there is no way to\n\u003e punish people if there is a double spend in a micro block that happens in\n\u003e key block which reorg'd away the first transaction. eg one miner mines a\n\u003e transaction in a micro block, another miner (either by not having seen the\n\u003e first yet, or being malicious - potentially the same miner) mines a key\n\u003e block which reorgs away the first micro block and then, in their first\n\u003e micro block, mines a double spend. This can happen at any time, so you end\n\u003e up having to fall back to regular full blocks for confirmation times :(.\n\u003e\n\nIf NG is to be used efficiently, microblocks are going to be very frequent,\nand so such forks should occur at almost every key-block publication. Short\nreorgs as you described are the norm. A user should wait before accepting a\ntransaction to make sure there was no key-block she missed. The wait time\nis chosen according to the network propagation delay (+as much slack as the\nuser feels necessary). This is similar to the situation in Bitcoin when you\nreceive a block. To be confident that you have one confirmation you should\nwait for the propagation time of the network to make sure there is no\nbranch you missed.\n\nAs for the malicious case: the attacker has to win the key-block, have the\nto-be-inverted transaction in the previous epoch, and withhold his\nkey-block for a while. That being said, indeed our fraud proof scheme\ndoesn't catch such an event, as it is indistinguishable from benign\nbehavior.\n\n\n\u003e Also, Greg Slepak brought up a good point on twitter at\n\u003e https://twitter.com/taoeffect/status/654358023138209792. Noting that this\n\u003e model means users could no longer pick transactions in a mining pool which\n\u003e was set up in such a way (it could be tweaked to do so with separate\n\u003e rewards and pubkeys, but now the user can commit fraud at a much lower cost\n\u003e - their own pool reward, not the block's total reward).\n\u003e\n\nAgreed x3: This is a good point, it is correct, and the tweak is dangerous.\nDo you perceive this as a significant practical issue?\n\n\n\u003e\n\u003e On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop \u003ckanzure at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e while the whitepaper has all the nitty gritty details:\n\u003e\u003e\u003e \u003e      http://arxiv.org/abs/1510.02037\n\u003e\u003e\u003e\n\u003e\u003e\u003e Taking reward compensation back by fraud proofs is not enough to fix\n\u003e\u003e\u003e the problems associated with double spending (such as, everyone has to\n\u003e\u003e\u003e wait for the \"real\" confirmations instead of the \"possibly\n\u003e\u003e\u003e double-spend\" confirmations). Some of this was discussed in -wizards\n\u003e\u003e\u003e recently:\n\u003e\u003e\u003e http://gnusha.org/bitcoin-wizards/2015-09-19.log\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Fraud proof removes all the attacker's revenue. It's like the attacker\n\u003e\u003e sacrifices an entire block for double spending in the current system. I\n\u003e\u003e think Luke-Jr got it right at that discussion.\n\u003e\u003e\n\u003e\u003e Best,\n\u003e\u003e Ittay\n\u003e\u003e\n\u003e\u003e ------------------------------\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/784e0876/attachment.html\u003e"}