{"type":"rich","version":"1.0","author_name":"npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","author_url":"https://nostr.ae/npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-18\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nRegarding the bit on \"getting out in front of the need, to prevent\nsignificant negative impacts to users\" I had suggested the following:\n\nOn 06/18/2015 03:52 PM, Jeff Garzik wrote:\n\u003e On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach\n\u003e \u003cmark at friedenbach.org \u003cmailto:mark at friedenbach.org\u003e\u003e wrote:\n\u003e \n\u003e On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik \u003cjgarzik at bitpay.com \n\u003e \u003cmailto:jgarzik at bitpay.com\u003e\u003e wrote:\n\u003e \n\u003e \n\u003e The whole point is getting out in front of the need, to prevent \n\u003e significant negative impact to users when blocks are consistently\n\u003e full.\n\n\nMy thoughts on that:\n\nPossible scope narrowing to one of the following concepts (but please,\nsomeone tell me if this \"scope narrowing\" is unwise, not timely, or if\nthere is some other factors that would make it just stupid right now\nbecause other things are in the works or whatever:\n\n~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of\nHuobi's mining project Digcoin, clarified that the big Chinese mining\npools consider further adjustments to the protocol beyond the\nsuggested 8 MB block size limit adjustment — such as the Bitcoin core\ndeveloper Jeff Garzik's BIP-100 draft — to be feasible)\n   ~ Adam Back, with a simplified soft-fork one-way peg\n   ~ Gavin Andresen, developing an 8 MB block size limit adjustment in\nthe context of Core (as an example) with one or more of the above\nauthors rather than focusing on XT. (This is a big assumption but,\nroll with it)\n\nAll of this assumes that developer(s) are willing to abandon\nintentionally contentious proposals such as the \"hard fork to XT w/ 20\nMB,\" remain within the context of Core and be reasonable.\n\nHere I am being aware of the fact that \"Pushing a hard fork in the\nface of such controversy is a folly, a danger to the network, and that\ndeserves to be said.\" - Wladimir J. van der Laan\nhttps://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917\n\n\n\u003e \n\u003e To do that, you need to (a) plan forward, in order to (b) set a \n\u003e hard fork date in the future.\n\u003e \n\u003e \n\u003e Or alternatively, fix the reasons why users would have negative \n\u003e experiences with full blocks, chiefly:\n\u003e \n\u003e * Get safe forms of replace-by-fee and child-pays-for-parent \n\u003e finished and in 0.12. * Develop cross-platform libraries for\n\u003e managing micropayment channels, and get wallet authors to adopt *\n\u003e Use fidelity bonds, solvency proofs, and other tricks to minimize\n\u003e the risk of already deployed off-chain solutions as an interim\n\u003e measure until: * Deploy soft-fork changes for truly scalable\n\u003e solutions like Lightning Network.\n\u003e \n\u003e Not raising the block size limit does not mean doing nothing to \n\u003e solve the problem.\n\u003e \n\u003e \n\u003e This is a long, unreasonable list of work.  None of this exists and\n\u003e it equates to \"upgrade all wallets and websites everywhere\"  It\n\u003e requires all exchanges, payment processors, merchants, etc. to  -\n\u003e basically everybody but miners - to update.\n\u003e \n\u003e It is a far, far larger amount of work to write, test and deploy\n\u003e than simply increasing the block size limit.\n\u003e \n\u003e Think through roll-out of these ambitious suggestions, before\n\u003e suggesting as an alternative!\n\u003e \n\u003e Not a realistic alternative except in an alternate universe where\n\u003e (a) developer work at all companies is cost free, plus (b) we can\n\u003e pause the business universe while we wait for The Perfect\n\u003e Solution.\n\u003e \n\u003e \n\u003e \n\n\nSomething else I wanted to point out here in this thread is the\nsubject of the problem of \"developers going off the deep end\" which is\nwhat started this thread:\n\nSuppose you have a developer with full commit access who happens to\nstart threatening to revoking the other developers' commit access on\nthe repository, or that person doesn't even threaten, one day it just\nhappens.\n\nWhat do you have then?  Peter Todd has stated that all one \"would\nachieve by that sabotage is setting a key-value pair in a centralised\nregistry.\"  But is that what we want?\n\nThe answer, obviously, is no.\n\nThis leads to other questions. What technical mechanisms exist to keep\ndevelopers from (in some dubious emotional or psycho state) to just\ngoing off the deep and doing exactly what has been described above, if\nthey have full commit access?  Is there a process whereby that can't\nactually happen unless another developer provides a signature (e.g. a\nmultisignature type of process)?  What keeps bitcoin safe from \"The\nHearn Threat?\"\n\nIf nothing does, then how would you change that?\n\nAnd go ahead and tell me if these are dumb questions and I should just\nbe quiet, but if they are, please do explain why they are such dumb\nquestions.\n\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e -- Jeff Garzik Bitcoin core developer and open source evangelist \n\u003e BitPay, Inc.      https://bitpay.com/\n\u003e \n\u003e \n\u003e ----------------------------------------------------------------------\n- --------\n\u003e\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ Bitcoin-development\n\u003e mailing list Bitcoin-development at lists.sourceforge.net \n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVg1OFAAoJEGxwq/inSG8COpAIAJrH9Uj9bcKr+UUR7ePV6/Yj\nMmNTY2VKAtiQhwHM+Mqk2VvQANs7/uRBdZjzGnw1NRcca/m8Q0yZUHQiP8avCUOE\n3MHqGviYjfeJdu1pcf+PO2pAImM5FCFdrfbbiWUt+ZoOKTxZjsLtF4RE+mc13AXJ\ndktvy6SFdvQUgEx8pdXEDpmaUSYUr7syFP4sgHZmyMlhvCsXyE/8dC3sZTzEpVnC\nxy1dyBmXHPW3W4FfBSblwwWgJWMcIcGJn8OLQKK5pni/iSVL6IMoRI/MLwOJdRr4\nlr83g9FR/qxMqAT9UIZtATnePlkkWPU1szvak/tU/49fGioyYOF4b4KPg/bHYSc=\n=hBcE\n-----END PGP SIGNATURE-----"}