{"type":"rich","version":"1.0","author_name":"npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","author_url":"https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-22\n📝 Original message:Charlie, I'll be mostly in the tech track, of course. And I've already\nplanned to meet RSK guys after their event tomorrow.\n\nRyan, the more review the better. We aren't in any direct rush, other than\nthe natural desire to have cool things as early as possible.\n\nPeter, responses below:\n\nOn May 22, 2017 9:33 AM, \"Peter Todd\" \u003cpete at petertodd.org\u003e wrote:\n\nOn Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:\n\u003e This work includes the relatively new concept of \"Blind Merged Mining\"\n\u003e [2] which I developed in January to allow SHA256^2 miners to merge-mine\n\u003e these \"drivechains\", even if these miners aren't running the actual\n\u003e sidechain software. The goal is to prevent sidechains from affecting the\n\u003e levelness of the mining \"playing field\". BMM is conceptually similar to\n\u003e ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not\n\u003e required for drivechain, but it would address some of the last remaining\n\u003e concerns.\n\nThanks for the credit, although I think the security properties of what\nyou're\nproposing are very different - and much weaker - than what I proposed in\nZookeyv.\n\n\nAs you state in [2] \"if miners never validate sidechains at all, whoever\nbids\nthe most for the chain (on a continuous basis), can spam a 3-month long\nstream\nof invalid headers, and then withdraw all of the coins deposited to the\nsidechain.\" and \"Since the mining is blind, and the sidechain-withdrawal\nsecurity-level is SPV, miners who remain blind forever have no way of\ntelling\nwho “should” really get the funds.\"\n\nFinally, you suggest that in this event, miners *do* have to upgrade to a\nfull\nnode, an expensive and time-consuming operation (and one that may be\nimpossible\nfor some miners if necessary data isn't available).\n\n\nSurprisingly, this requirement (or, more precisely, this incentive) does\nnot effect miners relative to each other. The incentive to upgrade is only\nfor the purpose of preventing a \"theft\" -- defined as: an improper\nwithdrawal from a sidechain. It is not about miner revenues or the ability\nto mine generally (or conduct BMM specifically). The costs of such a theft\n(decrease in market price, decrease in future transaction fee levels) would\nbe shared collectively by all future miners. Therefore, it would have no\neffect on miners relative to each other.\n\nMoreover, miners have other recourse if they are unable to run the node.\nThey can adopt a policy of simply rejecting (\"downvoting\") any withdrawals\nthat they don't understand. This would pause the withdraw process until\nenough miners understand enough of what is going on to proceed with it.\n\nFinally, the point in dispute is a single, infrequent, true/false question.\nSo miners may resort to semi-trusted methods to supplement their decision.\nIn other words, they can just ask people they trust, if the withdrawal is\ncorrect or not. It is up to users to decide if they are comfortable with\nthese risks, if/when they decide to deposit to a sidechain.\n\n\nIt's unclear to me what the incentive is for miners to do any of this. Could\nyou explain in more detail what that incentive is?\n\n\nIt is a matter of comparing the costs and benefits. Ignoring theft, the\ncosts are near-zero, and the benefits are \u003e0. Specifically, they are: a\nhigher BTC price and greater transaction fees. Theft is discouraged by\nattempting to tie a theft to a loss of confidence in the miners, as\ndescribed in the spec/website.\nIn general the incentives are very similar to those of Bitcoin itself.\n\nPaul\n\n\n\n\u003e [2] http://www.truthcoin.info/blog/blind-merged-mining/\n\u003e [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log\n\n--\nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/9bb81395/attachment.html\u003e"}