{"type":"rich","version":"1.0","author_name":"npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jw","author_url":"https://nostr.ae/npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:What is the advantage of this proposal over just orphaning the block with\ndouble spends?\n\nThere's currently a set of rules which government what constitutes a valid\nblock. Miners don't build on blocks that don't accord with those rules out\nof fear that a major won't follow and they will waste hashing power.\n\nIf there was a rule supported by the majority that considered blocks with\ndouble spends (defined in some fashion) as invalid miners wouldn't build on\nthem for the same reason they wouldn't build on a block with a coinbase\nover 25 btc, say. It seems that would accomplish the same without the other\nissues.\nOn Apr 23, 2014 12:04 PM, \"Christophe Biocca\" \u003cchristophe.biocca at gmail.com\u003e\nwrote:\n\n\u003e It's not necessary that this \"coinbase retribution\" be either\n\u003e profitable or risk-free for this scheme to work. I think we should\n\u003e separate out the different layers of the proposal:\n\u003e\n\u003e 1. Attacking the coinbase instead of orphaning allows for 100 blocks'\n\u003e time for a consensus to be reached, rather than 10 minutes. This\n\u003e allows for human verification/intervention if needed (orphaning\n\u003e decisions would almost always need to be automated, due to the short\n\u003e timeframe). This is a useful insight, and I don't think it's been\n\u003e brought up before.\n\u003e\n\u003e 2. The original specification of how it's done (redistribution, no\n\u003e cost to voting) does seem exploitable. This can be fixed by reducing\n\u003e the incentive (burning instead of redistributing) and/or adding a risk\n\u003e to the orphaning attempts (a vote that fails destroys X bitcoins'\n\u003e worth from each voting block's own coinbase). The incentives can be\n\u003e tailored to mirror those of orphaning a block, to reduce the risk of\n\u003e abuse. Then the only difference from orphaning are 1) More limited\n\u003e rewriting of history (only the coinbase, vs all transactions in the\n\u003e block), and 2) More time to coordinate a response.\n\u003e\n\u003e 3. This proposal may be used for things other than punishing\n\u003e double-spend pools. In fact it might be used to punish miners for\n\u003e doing anything a significant percentage of hashpower dislikes (large\n\u003e OP_RETURNs, large blocks, gambling transactions, transactions banned\n\u003e by a government). But we can make the threshold higher than 51%, so\n\u003e that this doesn't turn into a significant risk (if 75% of hashpower is\n\u003e willing to enforce a rule, we're already likely to see it enforced\n\u003e through orphaning).\n\u003e\n\u003e On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi \u003calex.mizrahi at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e And it still would. Non-collusive miners cast votes based on the outcome\n\u003e \u003e\u003e of their own attempts to double spend.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Individually rational strategy is to vote for coinbase reallocation on\n\u003e every\n\u003e \u003e block.\n\u003e \u003e\n\u003e \u003e Yes, in that case nobody will get reward. It is similar to prisoner's\n\u003e \u003e dilemma: equilibrium has worst pay-off.\n\u003e \u003e In practice that would mean that simple game-theoretic models are no\n\u003e longer\n\u003e \u003e applicable, as they lead to absurd results.\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e I'm using it in the same sense Satoshi used it. Honest miners work to\n\u003e \u003e\u003e prevent double spends. That's the entire justification for their\n\u003e existence.\n\u003e \u003e\u003e Miners that are deliberately trying to double spend are worse than\n\u003e useless.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Miners work to get rewards.\n\u003e \u003e It absolutely doesn't matter whether they are deliberately trying to\n\u003e \u003e double-spend or not: they won't be able to double-spend without a\n\u003e collusion.\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Start Your Social Network Today - Download eXo Platform\n\u003e \u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e \u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e \u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e \u003e http://p.sf.net/sfu/ExoPlatform\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/48d8a89a/attachment.html\u003e"}