> On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > >Even when several of the experts involved in the document you refer has my > >respect and admiration, I do not agree with some of their conclusions > > I'm one of the co-authors of that study. I'd be the first to agree with your > conclusion > and argue that the 4MB size suggested in that paper should not be used without > compensation for two important changes to the network. > > Our recent measurements of the Bitcoin P2P network show that network speeds > have improved tremendously. From February 2016 to February 2017, the average > provisioned bandwidth of a reachable Bitcoin node went up by approximately > 70%. > And that's just in the last year.
4 * 144 * 30 = 17.3GB per month, or 207GB per year. Full node initialisation will become prohibitive for most users until a shortcut is made (e.g. witness pruning and UTXO commitment but these are not trust-free) > > Further, the emergence of high-speed block relay networks, like Falcon > (http://www.falcon-net.org <http://www.falcon-net.org/>) > and FIBRE, as well as block compression, e.g. BIP152 and xthin, change the > picture dramatically. Also as the co-author of the selfish mining paper, you should know all these technology assume big miners being benevolent. > > So, the 4MB limit mentioned in our paper should not be used as a protocol > limit today. > > Best, > - egs > > > > On Tue, Mar 28, 2017 at 3:36 PM, Juan Garavaglia via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > Alphonse, > > > > Even when several of the experts involved in the document you refer has my > respect and admiration, I do not agree with some of their conclusions some of > their estimations are not accurate other changed like Bootstrap Time, Cost > per Confirmed Transaction they consider a network of 450,000,00 GH and today > is 3.594.236.966 GH, the energy consumption per GH is old, the cost of > electricity is wrong even when the document was made and is hard to find any > parameter used that is valid for an analysis today. > > > > Again with all respect to the experts involved in that analysis is not valid > today. > > > > I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s > Law all has been verified for many years and support that 32 MB in 2020 are > possible and equals or less than 1 MB in 2010. > > > > Again may be is not possible Johnson Lau and LukeJr invested a significant > amount of time investigating ways to do a safe HF, and may be not possible to > do a safe HF today but from processing power, bandwidth and storage is > totally valid and Wang Chung proposal has solid grounds. > > > > Regards > > > > Juan > > > > > > From: Alphonse Pace [mailto:alp.bitc...@gmail.com > <mailto:alp.bitc...@gmail.com>] > Sent: Tuesday, March 28, 2017 2:53 PM > To: Juan Garavaglia <j...@112bit.com <mailto:j...@112bit.com>>; Wang Chun > <1240...@gmail.com <mailto:1240...@gmail.com>> > Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> > > > Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting > > > > Juan, > > > > I suggest you take a look at this paper: > http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf > <http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf> It may help you form > opinions based in science rather than what appears to be nothing more than a > hunch. It shows that even 4MB is unsafe. SegWit provides up to this limit. > > > > 8MB is most definitely not safe today. > > > > Whether it is unsafe or impossible is the topic, since Wang Chun proposed > making the block size limit 32MiB. > > > > > > Wang Chun, > > > Can you specify what meeting you are talking about? You seem to have not > replied on that point. Who were the participants and what was the purpose of > this meeting? > > > > -Alphonse > > > > On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <j...@112bit.com > <mailto:j...@112bit.com>> wrote: > > Alphonse, > > > > In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB > limit valid in next halving, from network, storage and CPU perspective or 1MB > was too high in 2010 what is possible or 1MB is to low today. > > > > If is unsafe or impossible to raise the blocksize is a different topic. > > > > Regards > > > > Juan > > > > > > From: bitcoin-dev-boun...@lists.linuxfoundation.org > <mailto:bitcoin-dev-boun...@lists.linuxfoundation.org> > [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org > <mailto:bitcoin-dev-boun...@lists.linuxfoundation.org>] On Behalf Of Alphonse > Pace via bitcoin-dev > Sent: Tuesday, March 28, 2017 2:24 PM > To: Wang Chun <1240...@gmail.com <mailto:1240...@gmail.com>>; Bitcoin > Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> > Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting > > > > What meeting are you referring to? Who were the participants? > > > > Removing the limit but relying on the p2p protocol is not really a true 32MiB > limit, but a limit of whatever transport methods provide. This can lead to > differing consensus if alternative layers for relaying are used. What you > seem to be asking for is an unbound block size (or at least determined by > whatever miners produce). This has the possibility (and even likelihood) of > removing many participants from the network, including many small miners. > > > > 32MB in less than 3 years also appears to be far beyond limits of safety > which are known to exist far sooner, and we cannot expect hardware and > networking layers to improve by those amounts in that time. > > > > It also seems like it would be much better to wait until SegWit activates in > order to truly measure the effects on the network from this increased > capacity before committing to any additional increases. > > > > -Alphonse > > > > > > > > On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
