{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-22\n📝 Original message:Good morning Paul,\n\nI read only http://www.truthcoin.info/blog/blind-merged-mining/\n\nFrom just this document, I can't see a good justification for believing that a main-\u003eside locking transaction can be safely spent into a side-\u003emain unlocking transaction. Do you have a better explanation?\n\nOP_is_h_in_coinbase, as described, does not seem to protect against a sidechain reorg in your next section of the document. If I attempt to spend a main-\u003eside locking transaction on the basis of a \"mistaken\" side block #49, what prevents me from this sequence:\n\n1. Put a side:side-\u003emain transaction into a block together with TheDAO's hacked money.\n2. Wait for a reorg to revert TheDAO.\n3. Spend my now-free-in-the-reorg funds on Lightning Network to get mainchain funds.\n4. Create a main:side-\u003emain transaction with the side:side-\u003emain transaction in the TheDAO-hacked block as witness.\n5. Get another set of mainchain funds from the same sidechain funds.\n\nSo far, the only good side-\u003emain transfer I know of is in Blockstream's original sidechains paper, with the main:side-\u003emain transaction spending into a timelocked transaction that may be burned if a reorg proof is submitted (i.e. you try to create a main:side-\u003emain transaction with the side:side-\u003emain transaction in the mistaken #49 and #50 as your proof, but someone else can come along and show a corrected #49, #50, #51 without your side:side-\u003emain transaction and burn your funds). Is your proposal at the technical level actually similar, or does it truly seem to be riskier? It seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply.\n\nAlso, blinded merge mining seems strictly inferior to proof-of-burn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007012.html\n\nProof-of-burn integrates a lottery to reduce the ability of a mainchain-rich attacker to reorg the sidechain by burning its greater funds. However it still seems to me that a rich attacker can simply make more bets in that scheme by some trivial modification of the side block. Blind merged mining seems strictly inferior as a rich attacker can simply reorg the sidechain outright without playing such games.\n\nOr is your proposal strictly for centralized sidechains, where only one entity creates side blocks? How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur?\n\nRegarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates \"Don't trust, verify\", not that allows datacenters to be slightly smaller by not including side:nodes.\n\nRegards,\nZmnSCPxj\n\nSent with ProtonMail Secure Email.\n\n-------- Original Message --------\nSubject: [bitcoin-dev] Drivechain -- Request for Discussion\nLocal Time: May 22, 2017 6:17 AM\nUTC Time: May 22, 2017 6:17 AM\nFrom: bitcoin-dev at lists.linuxfoundation.org\nTo: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\nDear list,\n\nI've been working on \"drivechain\", a sidechain enabling technology, for\nsome time.\n\n* The technical info site is here: www.drivechain.info\n* The changes to Bitcoin are here:\nhttps://github.com/drivechain-project/bitcoin/tree/mainchainBMM\n* A Blank sidechain template is here:\nhttps://github.com/drivechain-project/bitcoin/tree/sidechainBMM\n\nAs many of you know, I've been seeking feedback in person, at various\nconferences and meetups over the past year, most prominently Scaling\nMilan. And I intend to continue to seek feedback at Consensus2017 this\nweek, so if you are in NYC please just walk up and start talking to me!\n\nBut I also wanted to ask the list for feedback. Initially, I was\nhesitant because I try not to consume reviewers' scarce time until the\nauthor has put in a serious effort. However, I may have waiting too\nlong, as today it is actually quite close to a working release.\n\nScaling Implications\n---------------------\n\nThis upgrade would have significant scaling implications. Since it is\nthe case that sidechains can be added by soft fork, and since each of\nthese chains will have its own blockspace, this theoretically removes\nthe blocksize limit from \"the Bitcoin system\" (if one includes\nsidechains as part of such a system). People who want a LargeBlock\nbitcoin can just move their BTC over to such a network [1], and their\ntxns will have no longer have an impact on \"Bitcoin Core\". Thus, even\nthough this upgrade does not actually increase \"scalability\" per se, it\nmay in fact put an end to the scalability debate...forever.\n\nThis work includes the relatively new concept of \"Blind Merged Mining\"\n[2] which I developed in January to allow SHA256^2 miners to merge-mine\nthese \"drivechains\", even if these miners aren't running the actual\nsidechain software. The goal is to prevent sidechains from affecting the\nlevelness of the mining \"playing field\". BMM is conceptually similar to\nZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not\nrequired for drivechain, but it would address some of the last remaining\nconcerns.\n\nTotal Transaction Fees in the Far Future\n-----------------------------------------\n\nSome people feel that a maximum blocksize limit is needed to ensure that\nfuture total equilibrium transaction fees are non-negligible. I\npresented [4] on why I don't agree, 8 months ago. The reviewers I spoke\nto over the last year have stopped bringing this complaint up, but I am\nnot sure everyone feels that way.\n\nJuxtaposition with a recent \"Scaling Compromise\"\n-------------------------------------------------\n\nRecently, a scalability proposal began to circulate on social media. As\nfar as I could tell, it goes something like \"immediately activate\nSegWit, and then HF to double the nonwitness blockspace to 2MB within 12\nmonths\". But such a proposal is quite meager, compared to a \"LargeBlock\nDrivechain\". The drivechain is better on both fronts, as it would not\nrequire a hardfork, and could *almost immediately* add _any_ amount of\nextra blockspace (specifically, I might expect a BIP101-like LargeBlock\nchain that has an 8 MB maxblocksize, which doubles every two years).\n\nIn other words, I don't know why anyone would support that proposal over\nmine. The only reasons would be either ignorance (ie, unfamiliarity with\ndrivechain) or because there are still nagging unspoken complaints about\ndrivechain which I apparently need to hear and address.\n\nOther Thoughts\n---------------\n\nUnfortunately, anyone who worked on the \"first generation\" of sidechain\ntechnology (the skiplist) or the \"second generation\" (federated /\nLiquid), will find that this is very different.\n\nI will admit that I am very pessimistic about any conversation that\ninvolves scalability. It is often said that \"talking politics lowers\nyour IQ by 25 points\". Bitcoin scalability conversations seem to drain\n50 points. (Instead of conversing, I think people should quietly work on\nwhatever they are passionate about until their problem either is solved,\nor it goes away for some other reason, or until we all agree to just\nstop talking about it.)\n\nCheers,\nPaul\n\n[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling\n[2] http://www.truthcoin.info/blog/blind-merged-mining/\n[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log\n[4]\nhttps://www.youtube.com/watch?v=YErLEuOi3xU\u0026list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg\u0026index=4\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/b545bb82/attachment-0001.html\u003e"}