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