rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-09-18 📝 Original message:On Fri, Sep 18, 2015 at 08:06:23PM +0000, Matt Corallo via bitcoin-dev wrote: > I did not intend to imply that there was agreement on a desire to > schedule a second hardfork. My wording may have been a bit too loose. > Instead, I believe there was much agreement that doing a short-term > hardfork now, with many agreeing that a second would hopefully be > entirely unnecessary/impossible, while others thought that a second > would be necessary and would have to happen. While this may set up a > similar controversy again in several years, I think everyone agreed that > we cannot predict the future and I, personally, think none of us should > be committing to a viewpoint for what should be done at that time. > > Personally, I think it is also critical that there be no messaging that > people should rely on or assume there will be a future increase after a > short-term bump (which I also do not believe people should be relying on > now). Agreed! We still seem to be in a possition where there is fundemental disagreements about the threat model we should design for, and ultimately, what we want Bitcoin to be. For instance, yesterday I was on a blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and miner BitFury - stated that he thought we needed to setup a system of large, high-bandwidth, high-powered, Bitcoin nodes at institutions such as universities and large companies to allow the Bitcoin blocksize to be raised multiple orders of magnitude. (e.g. hundreds of megabytes, or even multiple gigabytes) In discussion with him he seemed to expect that we'd have just a few hundred Bitcoin nodes at most, with SPV being the standard way of using Bitcoin. While to many of us that sounds crazy, if you're threat model assumes Bitcoin is a legal/regulated service provided by a highly trusted mining community it's a reasonable design. Mike Hearn recently posted his threat model, which specifically argues we should assume governments are not a threat. (and Hearn has previously argued that the design of Bitcoin assumes a majority of miners are "honest" rather than merely economically rational) Similarly Gavin Andresen was also on that panel, and stated that he believes the idea that Bitcoin has O(n^2) scaling is wrong, implying he doesn't think a large % of the Bitcoin user base will continue to run fully validating nodes. (note that there are other possibilities he could be referring to here, although again with different security assumptions and/or unproven tech) The main objection I raised during the committer/contributor discussions to the idea of a "short term bump" was messaging. I think it's fair to say that nearly all the support for a small blocksize increase stemmed from the (perceived) need to give Bitcoin users and Bitcoin infrastructure some more time to adapt to a world where the blocksize does not grow sufficiently to meet demand, resulting in higher transaction fees and the practical requirement to use the Bitcoin blockchain more efficiently. (or of course the development of genuinely scalable blockchain technology) With that in mind, it's important that we properly communicate that fact, or as Hearn replied, we'll run into the same problem all over again in a few years, but with even less safety margin in the system. My second objection was one of science. Any bump should be accompanied by some kind of model describing scientifically what we were trying to achieve and where the numbers chosen came from. For instance, Pieter Wuille's BIP103 proposes 17% per year based on a bandwidth growth model, the assumption that bandwidth is the bottleneck we're trying to keep constant, and the design criteria to keep centralization roughly constant. (all else being equal) Sure there's lots of potential flaws in that proposal, but the _message_ that we're basing it on science rather than political "horse-trading" is very important. As for the disagreements, it's quite likely that we can't come to genuine consensus in the fact of those fundemental disagreements about what Bitcoin should be. I don't have any good way to resolve that, and I'm open to suggestions! -- 'peter'[:-1]@petertodd.org 000000000000000000da942d1651d405c157821a3fa55bd0c11cd9b39321e574 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/d4413b8f/attachment-0001.sig>