rich1.0npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9njumphttps://nostr.ae📅 Original date posted:2017-05-22 📝 Original message:Charlie, I'll be mostly in the tech track, of course. And I've already planned to meet RSK guys after their event tomorrow. Ryan, the more review the better. We aren't in any direct rush, other than the natural desire to have cool things as early as possible. Peter, responses below: On May 22, 2017 9:33 AM, "Peter Todd" <pete at petertodd.org> wrote: On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote: > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual > sidechain software. The goal is to prevent sidechains from affecting the > levelness of the mining "playing field". BMM is conceptually similar to > ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not > required for drivechain, but it would address some of the last remaining > concerns. Thanks for the credit, although I think the security properties of what you're proposing are very different - and much weaker - than what I proposed in Zookeyv. As you state in [2] "if miners never validate sidechains at all, whoever bids the most for the chain (on a continuous basis), can spam a 3-month long stream of invalid headers, and then withdraw all of the coins deposited to the sidechain." and "Since the mining is blind, and the sidechain-withdrawal security-level is SPV, miners who remain blind forever have no way of telling who “should” really get the funds." Finally, you suggest that in this event, miners *do* have to upgrade to a full node, an expensive and time-consuming operation (and one that may be impossible for some miners if necessary data isn't available). Surprisingly, this requirement (or, more precisely, this incentive) does not effect miners relative to each other. The incentive to upgrade is only for the purpose of preventing a "theft" -- defined as: an improper withdrawal from a sidechain. It is not about miner revenues or the ability to mine generally (or conduct BMM specifically). The costs of such a theft (decrease in market price, decrease in future transaction fee levels) would be shared collectively by all future miners. Therefore, it would have no effect on miners relative to each other. Moreover, miners have other recourse if they are unable to run the node. They can adopt a policy of simply rejecting ("downvoting") any withdrawals that they don't understand. This would pause the withdraw process until enough miners understand enough of what is going on to proceed with it. Finally, the point in dispute is a single, infrequent, true/false question. So miners may resort to semi-trusted methods to supplement their decision. In other words, they can just ask people they trust, if the withdrawal is correct or not. It is up to users to decide if they are comfortable with these risks, if/when they decide to deposit to a sidechain. It's unclear to me what the incentive is for miners to do any of this. Could you explain in more detail what that incentive is? It is a matter of comparing the costs and benefits. Ignoring theft, the costs are near-zero, and the benefits are >0. Specifically, they are: a higher BTC price and greater transaction fees. Theft is discouraged by attempting to tie a theft to a loss of confidence in the miners, as described in the spec/website. In general the incentives are very similar to those of Bitcoin itself. Paul > [2] http://www.truthcoin.info/blog/blind-merged-mining/ > [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/9bb81395/attachment.html>