{"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-30\n📝 Original message:Hi Peter,\n\nResponses below.\n\nOn 5/28/2017 5:07 PM, Peter Todd wrote:\n\u003e On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:\n\u003e\u003e Surprisingly, this requirement (or, more precisely, this incentive) does\n\u003e\u003e not effect miners relative to each other. The incentive to upgrade is only\n\u003e\u003e for the purpose of preventing a \"theft\" -- defined as: an improper\n\u003e\u003e withdrawal from a sidechain. It is not about miner revenues or the ability\n\u003e\u003e to mine generally (or conduct BMM specifically). The costs of such a theft\n\u003e\u003e (decrease in market price, decrease in future transaction fee levels) would\n\u003e\u003e be shared collectively by all future miners. Therefore, it would have no\n\u003e\u003e effect on miners relative to each other.\n\u003e \n\u003e That's not at all true. If I'm a miner with a better capability than another\n\u003e miner to prevent that theft, I have reasons to induce it to happen to give me\n\u003e political cover to pushing that other miner off the network.\n\nMiners can abstain from 'voting', which is politically neutral. Or, if\nthey wish, smaller miners could acquiesce to the coercion and just copy\nthe votes of the attacking 51% group. For users who are only running\nBitcoin Core, there is nothing bad about that.\n\nAs you say, a 51% group can arbitrarily start orphaning the blocks that\nare mined by non-member rivals. This _may_ be a problem, or it may not,\nbut it is not exacerbated by drivechain.\n\nSo, what exactly is \"not at all true\"?\n\n\n\u003e \n\u003e This is a very similar problem to what we had with zeroconf double-spending,\n\u003e where entities such as Coinbase tried to pay off miners to guarantee something\n\u003e that wasn't possible in a geninely decrentralized system: safe zeroconf\n\u003e transactions.\n\nI don't see what you mean here. You can't stop Coinbase from donating\nBTC to a subset of miners. That will always be possible, and it has\nnothing to do with drivechain (as I see it).\n\n\n\u003e \n\u003e\u003e Moreover, miners have other recourse if they are unable to run the node.\n\u003e\u003e They can adopt a policy of simply rejecting (\"downvoting\") any withdrawals\n\u003e\u003e that they don't understand. This would pause the withdraw process until\n\u003e\u003e enough miners understand enough of what is going on to proceed with it.\n\u003e \n\u003e Why are you forcing miners to run this code at all?\n\nCould we not say the same thing about the code behind CLTV?\n\nThe nature of a contract, is that people are happier to be bound by some\nrules that they themselves construct (for example, a nuclear\nnon-proliferation treaty).\n\nIn this case, miners prefer sidechains to exist (as existence makes the\nBTC they mine more valuable, and provides additional tx fee revenues),\nand so they would like to run code which makes them possible.\n\n\n\u003e \n\u003e Equally, you're opening up miners to huge political risks, as rejecting all\n\u003e withdrawals is preventing users' from getting their money, which gives other\n\u003e miners a rational for kicking those miners off of Bitcoin entirely.\n\nAs I explained above, miners can abstain from voting, which is\npolitically neutral, or else they can delegate their vote to an\naggressive miner. The \"51% can orphan\" concern could be raised, even in\na world without drivechain. All that is required, is for the miners to\nbe anonymous, or in private 'dark' pools (and to thereby escape censure).\n\nBut there is a much bigger issue here, which is that our threat models\nare different.\n\nAs you may know, my threat model [1] does not include miners \"pushing\neach other off\". It only cares about the miner-experience, to the extent\nthat it impacts the user-experience.\n\nMoreover, I reject [2] the premise that we can even measure \"miner\ncentralization\", or even that such a concept exists. If someone has a\ndefinition of this concept, which is both measurable and useful, I would\nbe interested to read it.\n\n( For what it's worth, Satoshi did not care about this, either. For\nexample: \"If a greedy attacker is able to assemble more CPU power than\nall the honest nodes, he...ought to find it more profitable to play by\nthe rules.\" which implies robustness to 51% owned by one entity. )\n\n[1] http://www.truthcoin.info/blog/mining-threat-equilibrium/\n[2] http://www.truthcoin.info/blog/mirage-miner-centralization/\n\n\n\u003e \n\u003e\u003e Finally, the point in dispute is a single, infrequent, true/false question.\n\u003e\u003e So miners may resort to semi-trusted methods to supplement their decision.\n\u003e\u003e In other words, they can just ask people they trust, if the withdrawal is\n\u003e\u003e correct or not. It is up to users to decide if they are comfortable with\n\u003e\u003e these risks, if/when they decide to deposit to a sidechain.\n\u003e \n\u003e Why do you think this will be infrequent? Miners with a better ability to\n\u003e validate the drivechain have every reason to make these events more frequent.\n\nIt is part of the spec. These timing parameters must be agreed upon when\nthe sidechain is added, ie _before_ users deposit to the sidechain. Once\nthe sidechain is created, the timing is enforced by nodes, the same as\nwith any other protocol rules. Miner-validation-ability has no effect on\nthe frequency.\n\n\n\u003e \n\u003e\u003e It is a matter of comparing the costs and benefits. Ignoring theft, the\n\u003e\u003e costs are near-zero, and the benefits are \u003e0. Specifically, they are: a\n\u003e\u003e higher BTC price and greater transaction fees. Theft is discouraged by\n\u003e\u003e attempting to tie a theft to a loss of confidence in the miners, as\n\u003e\u003e described in the spec/website.\n\u003e\u003e In general the incentives are very similar to those of Bitcoin itself.\n\u003e \n\u003e This is also a very dubious security model - I would argue that Bitcoin is much\n\u003e *more* valuable if miners do everything they can to ensure that drivechains\n\u003e fail, given the huge risks involved.\n\nI don't see how. Users are free to ignore the sidechain, so it can only\nbenefit them.\n\nFortunately for you, if that is actually what miners believe, then there\nwill be no problem, as miners will just filter out drivechains (so that\nBitcoin will be \"much *more* valuable\"), which they can easily do.\n\n\n\u003e                                      I would also argue that users should do\n\u003e user-activated-soft-forks to ensure they fail.\n\nAgain, I don't think that kind of UASF can succeed, because one option\nstrictly dominates the other. But the users get the final say, of course.\n\nEmpirically, I have observed overwhelming support for sidechains among\nusers, business, and other developers. The btc-investors I spoke to were\nall very excited about the prospect of sidechains, even more so than\nthey were excited about SegWit.\n\n\n\u003e \n\u003e By comparison, note Adam Back and my own efforts to ensure miners have a\n\u003e smaller part in the ecosystem, with things like committed (encrypted)\n\u003e transactions and my closed-seal-set/truth-list approach(1). We want to involve\n\u003e miners as little as possible in the consensus, not more.\n\nI agree that miners should have as little influence as possible (and\nthey probably agree, as well). But a 51% group can filter any message\nthey like from the blockchain. For sidechains, there will need to be two\npublic networks, so concealment is not an option.\n\nAnd, I repeat, for regular users of Bitcoin Core, drivechain does not\nmake a 51% group more dangerous than they already are.\n\nMoreover, there are cases [1] where miner-involvement can make a big\n_positive_ impact. Just as it can be beneficial (essential, in fact) for\nBitcoin to filter out harmful interactions among txns (in other words,\ngood for miners to filter out double spends), I have discovered\nsituations where it is beneficial and essential for miners to filter out\nharmful interactions among multiple chains.\n\nSo I think I am actually hitting the \"as little as possible\" target.\n\n[1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts\n\n\n\u003e \n\u003e I have to ask: What use-cases do you actually see for drivechains? Why can't\n\nHere is a tentative project list:\nhttp://www.drivechain.info/projects/index.html\n\nAnd, as I say on the FAQ, \"If each individual user is free to sell\nhis/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny\nusers the opportunity to move their money between two sidechains.\"\n\nSo, in a strong way, the entire altcoin market makes the case for a\nusefulness of sidechains. Bitcoin is a form of money, and only one form\nof money can exist per currency area. So, if Bitcoin is not the winner,\nit will eventually cease to exist altogether. Altcoin-competition is an\nexistential threat to Bitcoin, one which is far more relevant than\nanything you've presented so far.\n\nSecondly, one important value of permissionless innovation is that one\ndoesn't really know, today, what cool ideas other people are going to\ncome up with tomorrow. If you did, they'd be today's ideas.\n\nThird, Core's review process has two opposite problems: on one hand it\nis slow and grueling, and on the other it is fraught with the\npossibility of catastrophic error. It would be better, for everyone, to\nallow people to try their own (non-aggressive) experiments, and to make\ntheir own mistakes. Already, I have seen the review process abused to\ncreate/maintain fiefdoms of expertise, so that the abusers can extract\nmoney from clients/employers/VCs.\n\nJust think of all of the free time you would have, Peter, if you didn't\nhave to spend it all reviewing these projects!\n\n\n\u003e those use-cases be done in the much safer client-side validation fashion?\n\n? How is drivechain _not_ within the category of client-side validation?\nWith BMM, validation is only performed by those users (\"clients\") who\nopt-in to the new features. The economic model of BMM is directly\ncomparable to that of Bitcoin's PoW -- the highest-bid chain should be\nthe healthiest one.\n\nCan you post the Github link for your most up-to-date client-side\nvalidation work so that we can compare the safety and other features?\n\nThanks,\nPaul\n\n\u003e \n\u003e 1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy\n\u003e"}