rich1.0npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjthttps://nostr.ae/npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtnjumphttps://nostr.ae📅 Original date posted:2015-02-12 📝 Original message:Den 12 feb 2015 16:15 skrev "Mike Hearn" <mike at plan99.net>: > > The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a "double spend this" button, to make the scheme work the dishonest miners must create and distribute such a wallet that implements the whole scorched-earth protocol. At that point it's easy for miners to reward the payment fraudster with some of the stolen money the merchant lost, meaning it now makes sense for the fraudster to always do this. The situation isn't stable at all. > > The second is that it incentivises competitors to engage in payment fraud against each other. A big rich coffee shop chain that is facing competition from a small, scrappy newcomer can simply walk into the new shop and buy things, then trigger the "scorched earth". Even with no miner collaboration, this means the big company is down the cost of the product but so is the little company who lost everything. Whoever can outspend the other wins. > > We don't really need game theory to tell us that this plan is a bad idea. Just imagine trying to explain it to an actual shop keeper. They would think you were crazy. Bitcoin is already a hard enough concept to understand without throwing into the mix "anyone can burn the money they gave you after walking out of the shop". I see no fundamental difference in outcome from miner collusion in scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner collusion in knowingly mining a doublespend transaction. Both outcomes pay the miner and thief equally when successful. The merchant loses in both. Zero-conf needs something else for security. A guarantee it can not be doublespent in the relevant time frame. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/1da9aa24/attachment.html>