{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-18\n📝 Original message:On Fri, Sep 18, 2015 at 08:06:23PM +0000, Matt Corallo via bitcoin-dev wrote:\n\u003e I did not intend to imply that there was agreement on a desire to\n\u003e schedule a second hardfork. My wording may have been a bit too loose.\n\u003e Instead, I believe there was much agreement that doing a short-term\n\u003e hardfork now, with many agreeing that a second would hopefully be\n\u003e entirely unnecessary/impossible, while others thought that a second\n\u003e would be necessary and would have to happen. While this may set up a\n\u003e similar controversy again in several years, I think everyone agreed that\n\u003e we cannot predict the future and I, personally, think none of us should\n\u003e be committing to a viewpoint for what should be done at that time.\n\u003e \n\u003e Personally, I think it is also critical that there be no messaging that\n\u003e people should rely on or assume there will be a future increase after a\n\u003e short-term bump (which I also do not believe people should be relying on\n\u003e now).\n\nAgreed!\n\nWe still seem to be in a possition where there is fundemental\ndisagreements about the threat model we should design for, and\nultimately, what we want Bitcoin to be. For instance, yesterday I was on\na blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and\nminer BitFury - stated that he thought we needed to setup a system of\nlarge, high-bandwidth, high-powered, Bitcoin nodes at institutions such\nas universities and large companies to allow the Bitcoin blocksize to be\nraised multiple orders of magnitude. (e.g. hundreds of megabytes, or\neven multiple gigabytes) In discussion with him he seemed to expect that\nwe'd have just a few hundred Bitcoin nodes at most, with SPV being the\nstandard way of using Bitcoin.\n\nWhile to many of us that sounds crazy, if you're threat model assumes\nBitcoin is a legal/regulated service provided by a highly trusted mining\ncommunity it's a reasonable design. Mike Hearn recently posted his\nthreat model, which specifically argues we should assume governments are\nnot a threat. (and Hearn has previously argued that the design of\nBitcoin assumes a majority of miners are \"honest\" rather than merely\neconomically rational) Similarly Gavin Andresen was also on that panel,\nand stated that he believes the idea that Bitcoin has O(n^2) scaling is\nwrong, implying he doesn't think a large % of the Bitcoin user base will\ncontinue to run fully validating nodes. (note that there are other\npossibilities he could be referring to here, although again with\ndifferent security assumptions and/or unproven tech)\n\nThe main objection I raised during the committer/contributor discussions\nto the idea of a \"short term bump\" was messaging. I think it's fair to\nsay that nearly all the support for a small blocksize increase stemmed\nfrom the (perceived) need to give Bitcoin users and Bitcoin\ninfrastructure some more time to adapt to a world where the blocksize\ndoes not grow sufficiently to meet demand, resulting in higher\ntransaction fees and the practical requirement to use the Bitcoin\nblockchain more efficiently. (or of course the development of genuinely\nscalable blockchain technology) With that in mind, it's important that\nwe properly communicate that fact, or as Hearn replied, we'll run into\nthe same problem all over again in a few years, but with even less\nsafety margin in the system.\n\nMy second objection was one of science. Any bump should be accompanied\nby some kind of model describing scientifically what we were trying to\nachieve and where the numbers chosen came from. For instance, Pieter\nWuille's BIP103 proposes 17% per year based on a bandwidth growth model,\nthe assumption that bandwidth is the bottleneck we're trying to keep\nconstant, and the design criteria to keep centralization roughly\nconstant. (all else being equal) Sure there's lots of potential flaws in\nthat proposal, but the _message_ that we're basing it on science rather\nthan political \"horse-trading\" is very important.\n\nAs for the disagreements, it's quite likely that we can't come to\ngenuine consensus in the fact of those fundemental disagreements about\nwhat Bitcoin should be. I don't have any good way to resolve that, and\nI'm open to suggestions!\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000000da942d1651d405c157821a3fa55bd0c11cd9b39321e574\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/d4413b8f/attachment-0001.sig\u003e"}