{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:On Wed, Apr 23, 2014 at 06:04:00PM +0300, Alex Mizrahi wrote:\n\u003e This is outright ridiculous.\n\u003e \n\u003e Zero-confirmation double-spending is a small problem, and possible\n\u003e solutions are known. (E.g. trusted third party + multi-sig addresses for\n\u003e small-value transactions.)\n\nAlso replace-by-fee scorched earth.\n\n\u003e On the other hand, protocol changes like described above might have\n\u003e game-theoretical implications which are non-trivial and hard to understand.\n\nTo put it mildly. :) Beyond the obvious issues with adding mechanisms\nfor miners to vote on what blacklists they wish to apply, it's\ninteresting to consider how trying to make zeroconf transactions secure\ndirectly is quite close to changing the block interval. Like the\nblocksize that's a fundemental economic parameter of the system - how\nlow-latency and well connected you must be to be allowed to mine. Even\nin a scheme where the punishment for allowing a double-spend was somehow\napplied perfectly fairly, you'd still be favoring large well-connected\nminers in a very similar way to reducing the block interval.\n\n\u003e The above approach works as long as the majority of hashpower is honest,\n\u003e \u003e defined to mean, working to stop double spending. This is the same security\n\u003e \u003e property as described in the white paper, thus this introduces no new\n\u003e \u003e security assumptions.\n\u003e \u003e\n\u003e \n\u003e No. Bitcoin should work if miners are merely individually rational, i.e.\n\u003e they try to maximize their pay-offs without colluding with others.\n\nIt's worth noting that the academic efforts studying Bitcoin are\nspending quite a bit of effort focused on the incentive compatibility of\nvarious mechanisms in the protocol: https://github.com/citp/bitcoin-sok/issues/5\n\nThere's solid consensus in the academic community that Bitcoin can't\njust depend on notions of \"honesty\" to work.\n\n\u003e I guess word \"honest\" might have different meanings, that can be a source\n\u003e of confusing.\n\u003e 1. Honest -- not trying to destroy bitcoin\n\u003e 2. Honest -- following rules which are not required by the protocol\n\nWhat exactly those rules are is up for debate too. Right now if, say,\njust 5% of Bitcoin miners were willing to accept Colored Coin\ntransactions you could still use Colored Coins. The other 95% may want\nto block said transactions, but there's huge practical difficulties in\norganizing a reorg and ensuring that everyone co-operates; miners have\nstrong incentives to defect if the consensus isn't assured as any miners\nattempting to reorg are wasting their hashing power if it doesn't\nsucceed.\n\nOTOH with a voting scheme the cost to propose that a specific block or a\ntransaction be blacklisted is much lower. In Mike's proposed scheme to\nnot just blacklist, but actually take coinbases it's downright\nprofitable. Rather than being a last resort option, it'll be easy for\nminers to propose various things be blacklisted, if the vote goes\nthrough, great, if it doesn't, no harm done. Obviously that makes\nblacklists into a much more useful tool and greatly changes the\npolitical landscape around them.\n\nRemember, if you're operating a publicly known pool, and there's a\nvoting mechanism available to you to blacklist specific blocks, how are\nyou going to resist pressure from your local authorities to do just when\nthere's no cost to you to do so?\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/50cd1cfa/attachment.sig\u003e"}