{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-28\n📝 Original message:Oops, just realized I never responded to this...\n\nOn 10/15/15 15:09, Ittay wrote:\n\u003e Thanks, Matt. Response inline. \n\u003e \n\u003e On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo \u003clf-lists at mattcorallo.com\n\u003e \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e \n\u003e     That conversation missed a second issue. Namely that there is no way\n\u003e     to punish people if there is a double spend in a micro block that\n\u003e     happens in key block which reorg'd away the first transaction. eg\n\u003e     one miner mines a transaction in a micro block, another miner\n\u003e     (either by not having seen the first yet, or being malicious -\n\u003e     potentially the same miner) mines a key block which reorgs away the\n\u003e     first micro block and then, in their first micro block, mines a\n\u003e     double spend. This can happen at any time, so you end up having to\n\u003e     fall back to regular full blocks for confirmation times :(.\n\u003e \n\u003e \n\u003e If NG is to be used efficiently, microblocks are going to be very\n\u003e frequent, and so such forks should occur at almost every key-block\n\u003e publication. Short reorgs as you described are the norm. A user should\n\u003e wait before accepting a transaction to make sure there was no key-block\n\u003e she missed. The wait time is chosen according to the network propagation\n\u003e delay (+as much slack as the user feels necessary). This is similar to\n\u003e the situation in Bitcoin when you receive a block. To be confident that\n\u003e you have one confirmation you should wait for the propagation time of\n\u003e the network to make sure there is no branch you missed. \n\nI think you're overstating how short the wait times can be. They need to\nbe much longer than the network propagation delay.\n\n\u003e As for the malicious case: the attacker has to win the key-block, have\n\u003e the to-be-inverted transaction in the previous epoch, and withhold his\n\u003e key-block for a while. That being said, indeed our fraud proof scheme\n\u003e doesn't catch such an event, as it is indistinguishable from benign\n\u003e behavior. \n\nThe attacker does not need to withold their keyblock at all. All the\nattacker does is, for every transaction they ever send, after it is\nincluded in a microblock, set their hashpower to start mining a keyblock\nimmediately prior to this microblock. When they find a keyblock, they\nimmediately announce it and start creating microblocks, the first of\nwhich double-spends the previous transaction. If they dont win the key\nblock, oh well, their payment went through normally and they couldn't\ndouble-spend.\n\nIn chatting with Glenn about this, we roughly agreed that the\nconfirmation time for microblocks possibly doesn't need to be a full\nkey-block, but it needs to be a reasonable period after which such an\nattacker would lose more in fees than the value of their double-spend\n(ie because the key-block afterwards gets 20% more in fees than the\nkey-block before hand). In any case, the game theory here starts to get\nrather complicated and it doesn't make me want to suggest accepting\nmicroblocks as confirmations is safe.\n\n\u003e     Also, Greg Slepak brought up a good point on twitter at\n\u003e     https://twitter.com/taoeffect/status/654358023138209792. Noting that\n\u003e     this model means users could no longer pick transactions in a mining\n\u003e     pool which was set up in such a way (it could be tweaked to do so\n\u003e     with separate rewards and pubkeys, but now the user can commit fraud\n\u003e     at a much lower cost - their own pool reward, not the block's total\n\u003e     reward).\n\u003e \n\u003e \n\u003e Agreed x3: This is a good point, it is correct, and the tweak is dangerous. \n\u003e Do you perceive this as a significant practical issue? \n\nIt is not a practical issue today because no one does it, but it is a\nmassive issue in that the splitting of pool rewards and transaction\nselection is one of the few easy wins we have left in the fight against\nmining centralization. Mining centralization today is absolutely awful,\nand closing off our only big win would be tragic.\n\n\u003e     On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev\n\u003e     \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e \n\u003e         On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop \u003ckanzure at gmail.com\n\u003e         \u003cmailto:kanzure at gmail.com\u003e\u003e wrote:\n\u003e \n\u003e             On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer\n\u003e             \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e             \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e             \u003e while the whitepaper has all the nitty gritty details:\n\u003e             \u003e      http://arxiv.org/abs/1510.02037\n\u003e \n\u003e             Taking reward compensation back by fraud proofs is not\n\u003e             enough to fix\n\u003e             the problems associated with double spending (such as,\n\u003e             everyone has to\n\u003e             wait for the \"real\" confirmations instead of the \"possibly\n\u003e             double-spend\" confirmations). Some of this was discussed in\n\u003e             -wizards\n\u003e             recently:\n\u003e             http://gnusha.org/bitcoin-wizards/2015-09-19.log\n\u003e \n\u003e \n\u003e         Fraud proof removes all the attacker's revenue. It's like the\n\u003e         attacker sacrifices an entire block for double spending in the\n\u003e         current system. I think Luke-Jr got it right at that discussion. \n\u003e \n\u003e         Best, \n\u003e         Ittay \n\u003e \n\u003e         ------------------------------------------------------------------------\n\u003e \n\u003e         bitcoin-dev mailing list\n\u003e         bitcoin-dev at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e"}