rich1.0npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58njumphttps://nostr.ae📅 Original date posted:2015-05-07 📝 Original message:100% agree, RE hard forks should be hard. However, it is the paradox of growth, morale and adoption that bitcoin might never reach the point where it is saturated & expensive to the point where larger blocks are demanded by 95%+... simply because people and companies chose not to adopt bitcoin in the first place due to an unmoving, [perceived | real] scalability roadblock. On Thu, May 7, 2015 at 11:04 AM, Alex Morcos <morcos at gmail.com> wrote: > That strikes me as a dangerous path forward. > > I don't actually think there is anything wrong with this: "everybody > eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and > we're left with the status quo" > > What gives Bitcoin value aren't its technical merits but the fact that > people believe in it. The biggest risk here isn't that 20MB blocks will > be bad or that 1MB blocks will be bad, but that by forcing a hard fork that > isn't nearly universally agreed upon, we will be damaging that belief. If > I strongly believed some hard fork would be better for Bitcoin, say > permanent inflation of 1% a year to fund mining, and I managed to convince > 80% of users, miners, businesses and developers to go along with me, I > would still vote against doing it. Because that's not nearly universal > agreement, and it changes what people chose to believe in without their > consent. Forks should be hard, very hard. And both sides should recognize > that belief in the value of Bitcoin might be a fragile thing. I'd argue > that if we didn't force through a 20MB fork now, and we ran into major > network difficulties a year from now and had no other technical solutions, > that maybe we would get nearly universal agreement, and the businesses and > users that were driven away by the unusable system would be a short term > loss in value considerably smaller than the impairment we risk by forcing a > change. > > > > On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen at gmail.com> > wrote: > >> For reference: the blog post that (re)-started this debate, and which >> links to individual issues, is here: >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks >> >> In it, I asked people to email me objections I might have missed. I would >> still appreciate it if people do that; it is impossible to keep up with >> this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and >> also have time to respond thoughtfully to the objections raised. >> >> I would very much like to find some concrete course of action that we can >> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is >> how much transaction volume the main Bitcoin blockchain will be able to >> support over the next eleven years." >> >> I've been pretty clear on what I think is a reasonable compromise (a >> one-time increase scheduled for early next year), and I have tried to >> explain why I think it it is the right set of tradeoffs. >> >> There ARE tradeoffs here, and the hard question is what process do we use >> to decide those tradeoffs? How do we come to consensus? Is it worth my >> time to spend hours responding thoughtfully to every new objection raised >> here, or will the same thing happen that happened last year and the year >> before-- everybody eventually gets tired of arguing >> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo? >> >> I AM considering contributing some version of the bigger blocksize-limit >> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a >> fast Internet connection, and assume Nelson's law to increase over time), >> and then encouraging merchants and exchanges and web wallets and >> individuals who think it strikes a reasonable balance to run it. >> >> And then, assuming it became a super-majority of nodes on the network, >> encourage miners to roll out a soft-fork to start producing bigger blocks >> and eventually trigger the hard fork. >> >> Because ultimately consensus comes down to what software people choose to >> run. >> >> -- >> -- >> Gavin Andresen >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/435a17c4/attachment.html>