{"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:2017-05-28\n📝 Original message:On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:\n\u003e Surprisingly, this requirement (or, more precisely, this incentive) does\n\u003e not effect miners relative to each other. The incentive to upgrade is only\n\u003e for the purpose of preventing a \"theft\" -- defined as: an improper\n\u003e withdrawal from a sidechain. It is not about miner revenues or the ability\n\u003e to mine generally (or conduct BMM specifically). The costs of such a theft\n\u003e (decrease in market price, decrease in future transaction fee levels) would\n\u003e be shared collectively by all future miners. Therefore, it would have no\n\u003e effect on miners relative to each other.\n\nThat's not at all true. If I'm a miner with a better capability than another\nminer to prevent that theft, I have reasons to induce it to happen to give me\npolitical cover to pushing that other miner off the network.\n\nThis is a very similar problem to what we had with zeroconf double-spending,\nwhere entities such as Coinbase tried to pay off miners to guarantee something\nthat wasn't possible in a geninely decrentralized system: safe zeroconf\ntransactions.\n\n\u003e Moreover, miners have other recourse if they are unable to run the node.\n\u003e They can adopt a policy of simply rejecting (\"downvoting\") any withdrawals\n\u003e that they don't understand. This would pause the withdraw process until\n\u003e enough miners understand enough of what is going on to proceed with it.\n\nWhy are you forcing miners to run this code at all?\n\nEqually, you're opening up miners to huge political risks, as rejecting all\nwithdrawals is preventing users' from getting their money, which gives other\nminers a rational for kicking those miners off of Bitcoin entirely.\n\n\u003e Finally, the point in dispute is a single, infrequent, true/false question.\n\u003e So miners may resort to semi-trusted methods to supplement their decision.\n\u003e In other words, they can just ask people they trust, if the withdrawal is\n\u003e correct or not. It is up to users to decide if they are comfortable with\n\u003e these risks, if/when they decide to deposit to a sidechain.\n\nWhy do you think this will be infrequent? Miners with a better ability to\nvalidate the drivechain have every reason to make these events more frequent.\n\n\u003e It is a matter of comparing the costs and benefits. Ignoring theft, the\n\u003e costs are near-zero, and the benefits are \u003e0. Specifically, they are: a\n\u003e higher BTC price and greater transaction fees. Theft is discouraged by\n\u003e attempting to tie a theft to a loss of confidence in the miners, as\n\u003e described in the spec/website.\n\u003e In general the incentives are very similar to those of Bitcoin itself.\n\nThis is also a very dubious security model - I would argue that Bitcoin is much\n*more* valuable if miners do everything they can to ensure that drivechains\nfail, given the huge risks involved. I would also argue that users should do\nuser-activated-soft-forks to ensure they fail.\n\nBy comparison, note Adam Back and my own efforts to ensure miners have a\nsmaller part in the ecosystem, with things like committed (encrypted)\ntransactions and my closed-seal-set/truth-list approach(1). We want to involve\nminers as little as possible in the consensus, not more.\n\nI have to ask: What use-cases do you actually see for drivechains? Why can't\nthose use-cases be done in the much safer client-side validation fashion?\n\n1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170528/c960e00a/attachment.sig\u003e"}