{"type":"rich","version":"1.0","author_name":"npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","author_url":"https://nostr.ae/npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zm","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:It's not necessary that this \"coinbase retribution\" be either\nprofitable or risk-free for this scheme to work. I think we should\nseparate out the different layers of the proposal:\n\n1. Attacking the coinbase instead of orphaning allows for 100 blocks'\ntime for a consensus to be reached, rather than 10 minutes. This\nallows for human verification/intervention if needed (orphaning\ndecisions would almost always need to be automated, due to the short\ntimeframe). This is a useful insight, and I don't think it's been\nbrought up before.\n\n2. The original specification of how it's done (redistribution, no\ncost to voting) does seem exploitable. This can be fixed by reducing\nthe incentive (burning instead of redistributing) and/or adding a risk\nto the orphaning attempts (a vote that fails destroys X bitcoins'\nworth from each voting block's own coinbase). The incentives can be\ntailored to mirror those of orphaning a block, to reduce the risk of\nabuse. Then the only difference from orphaning are 1) More limited\nrewriting of history (only the coinbase, vs all transactions in the\nblock), and 2) More time to coordinate a response.\n\n3. This proposal may be used for things other than punishing\ndouble-spend pools. In fact it might be used to punish miners for\ndoing anything a significant percentage of hashpower dislikes (large\nOP_RETURNs, large blocks, gambling transactions, transactions banned\nby a government). But we can make the threshold higher than 51%, so\nthat this doesn't turn into a significant risk (if 75% of hashpower is\nwilling to enforce a rule, we're already likely to see it enforced\nthrough orphaning).\n\nOn Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi \u003calex.mizrahi at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e And it still would. Non-collusive miners cast votes based on the outcome\n\u003e\u003e of their own attempts to double spend.\n\u003e\n\u003e\n\u003e Individually rational strategy is to vote for coinbase reallocation on every\n\u003e block.\n\u003e\n\u003e Yes, in that case nobody will get reward. It is similar to prisoner's\n\u003e dilemma: equilibrium has worst pay-off.\n\u003e In practice that would mean that simple game-theoretic models are no longer\n\u003e applicable, as they lead to absurd results.\n\u003e\n\u003e\u003e\n\u003e\u003e I'm using it in the same sense Satoshi used it. Honest miners work to\n\u003e\u003e prevent double spends. That's the entire justification for their existence.\n\u003e\u003e Miners that are deliberately trying to double spend are worse than useless.\n\u003e\n\u003e\n\u003e Miners work to get rewards.\n\u003e It absolutely doesn't matter whether they are deliberately trying to\n\u003e double-spend or not: they won't be able to double-spend without a collusion.\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"}