rich1.0npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasyhttps://nostr.ae/npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasynjumphttps://nostr.ae📅 Original date posted:2017-03-29 📝 Original message:> That said, for that to be alleviated we could simply do something based on historical transaction growth (which is somewhat linear, with a few inflection points), Where do you get this? Transaction growth for the last 4 years averages to +65% per year and the last 2 is +80% per year. That's very much not linear. On Tue, Mar 28, 2017 at 10:13 AM, Matt Corallo via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Not sure what "last week's meeting" is in reference to? > > Agreed that the hard fork should be well-prepared, but I think its > dangerous to think that a hard fork as agreed upon would be a simple > relaxation of the block size. For example, Johnson Lau's previous > proposal, Spoonnet, which I think is probably one of the better ones, > would be incompatible with these rules. > > I, of course, worry about what happens if we cannot come to consensus on > a number to soft fork down to, potentially significantly risking miner > profits (and, thus, the security of Bitcoin) if a group is able to keep > things "at the status quo". That said, for that to be alleviated we > could simply do something based on historical transaction growth (which > is somewhat linear, with a few inflection points), but that number ends > up being super low (eg somewhere around 2MB at the next halving, which > SegWit itself already provides :/. > > We could, of course, focus on designing a hard fork's activation and > technical details, with a very large block size increase in it (ie > closer to 4/6MB at the next halving or so, something we at least could > be confident we could develop software for), with intention to soft fork > it back down if miner profits are suffering. > > Matt > > On 03/28/17 16:59, Wang Chun via bitcoin-dev wrote: > > I've proposed this hard fork approach last year in Hong Kong Consensus > > but immediately rejected by coredevs at that meeting, after more than > > one year it seems that lots of people haven't heard of it. So I would > > post this here again for comment. > > > > The basic idea is, as many of us agree, hard fork is risky and should > > be well prepared. We need a long time to deploy it. > > > > Despite spam tx on the network, the block capacity is approaching its > > limit, and we must think ahead. Shall we code a patch right now, to > > remove the block size limit of 1MB, but not activate it until far in > > the future. I would propose to remove the 1MB limit at the next block > > halving in spring 2020, only limit the block size to 32MiB which is > > the maximum size the current p2p protocol allows. This patch must be > > in the immediate next release of Bitcoin Core. > > > > With this patch in core's next release, Bitcoin works just as before, > > no fork will ever occur, until spring 2020. But everyone knows there > > will be a fork scheduled. Third party services, libraries, wallets and > > exchanges will have enough time to prepare for it over the next three > > years. > > > > We don't yet have an agreement on how to increase the block size > > limit. There have been many proposals over the past years, like > > BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so > > on. These hard fork proposals, with this patch already in Core's > > release, they all become soft fork. We'll have enough time to discuss > > all these proposals and decide which one to go. Take an example, if we > > choose to fork to only 2MB, since 32MiB already scheduled, reduce it > > from 32MiB to 2MB will be a soft fork. > > > > Anyway, we must code something right now, before it becomes too late. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/5cb7adbe/attachment-0001.html>