diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-08-10 21:28:48 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-10 19:28:51 +0000 |
| commit | b75a8776fda8c488f6981837237e08c90580cb39 (patch) | |
| tree | ac645ae4a6f26005d1ec2a112f889c957e35a453 | |
| parent | f15bb072877002d7601d40a437942f4ddce07338 (diff) | |
| download | pi-bitcoindev-b75a8776fda8c488f6981837237e08c90580cb39.tar.gz pi-bitcoindev-b75a8776fda8c488f6981837237e08c90580cb39.zip | |
Re: [bitcoin-dev] Block size following technological growth
| -rw-r--r-- | 93/15da16596b0a12e7466cf0b4f35c513bf3330f | 427 |
1 files changed, 427 insertions, 0 deletions
diff --git a/93/15da16596b0a12e7466cf0b4f35c513bf3330f b/93/15da16596b0a12e7466cf0b4f35c513bf3330f new file mode 100644 index 000000000..11c8f1c07 --- /dev/null +++ b/93/15da16596b0a12e7466cf0b4f35c513bf3330f @@ -0,0 +1,427 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BAF48267 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Aug 2015 19:28:51 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com + [209.85.212.169]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C2F91A4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Aug 2015 19:28:50 +0000 (UTC) +Received: by wicja10 with SMTP id ja10so39222189wic.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Aug 2015 12:28:48 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type + :content-transfer-encoding; + bh=ciL9I8HnwqwgeHVrJlgmeo03cEMNcdIfbnhPLBnmyKs=; + b=GBA1JaAZ4oFCNVoJK3kZlctc+yexu8p8M4Lpjx+Y+wHQW13EOqJAj68R6yaP+21wv2 + tM30uMDxBl8PopGJ+QF21Etoezb46rHiRGpWrrBXNmsurlnZPIuIGh11ToL78Fiau5ud + aHhO3M4+rHtuoo5IbhNm50dZoq+1K5h7KXyYW9HIbO+FaKzpbSb9/dNvZyLqkNZlrZEX + egSvJcI5pOgupOe913erwhLnmoJk3Ps1NCm6iFkcDKAEwm9pJjG3pa5R4xyG1sbEkpUh + SD2epJlBGYVeeC2n+Sz3keHRzZamnWcQSJUNWAd34KsvSnF6mVvRYlU+IG3R5XH34mdw + WXig== +X-Gm-Message-State: ALoCoQmqlGU8ip9zZu+RS72zj3F8v2zttjusBLvnYgDIJmPM0f2TTVzbnkXd6jyPdo2SRjOHfWb+ +MIME-Version: 1.0 +X-Received: by 10.194.120.198 with SMTP id le6mr47076575wjb.133.1439234928809; + Mon, 10 Aug 2015 12:28:48 -0700 (PDT) +Received: by 10.194.31.230 with HTTP; Mon, 10 Aug 2015 12:28:48 -0700 (PDT) +In-Reply-To: <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com> +References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com> + <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com> + <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com> + <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com> + <CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com> + <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com> + <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com> + <CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com> + <CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com> + <CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com> + <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com> + <CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com> + <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com> + <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com> +Date: Mon, 10 Aug 2015 21:28:48 +0200 +Message-ID: <CABm2gDpGVpb+ZYF-Cg_dFM5aoCM5mADvM5dUqKBmGX_1P6=76A@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Elliot Olds <elliot.olds@gmail.com> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Block size following technological growth +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 10 Aug 2015 19:28:51 -0000 + +On Fri, Aug 7, 2015 at 1:09 AM, Elliot Olds <elliot.olds@gmail.com> wrote: +> On Wed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote= +: +> I agree with you that decentralization is the most important feature of +> Bitcoin, but I also think we need to think probabilistically and concrete= +ly +> about when risks to decentralization are worthwhile. +> +> Decentralization is not infinitely valuable in relation to low fees, just +> like being alive is not infinitely valuable in relation to having money. +> [...] +> Similarly we shouldn't accept a 100% probability of Bitcoin being control= +led +> by a single entity for any guarantee of cheap tx fees no matter how low t= +hey +> are, but there should be some minuscule risk of decentralization that we'= +d +> be willing to accept (like raising the block size to 1.01 MB) if it someh= +ow +> allowed us to dramatically increase usability. (Imagine something like th= +e +> Lightning Network but even better was developed, but it could only work w= +ith +> 1.01 MB blocks). + +Agreed. I would just like that there was an attempt to automatically +estimate those risks before taking those risks. +Some function we're trying to optimize with simulations (based on +#6382 ) to find an ideal (according to that imperfect metric) maximum +consensus block size. +Maybe the function/simulations just take some minimum hardware +specifications and returns an block size, I don't know. + +> I agree that we don't have good data about what exactly a 4 MB increase +> would do. It sounds like you think the risks are too great / uncertain to +> move from 1 MB to 4 MB blocks in the situation I described. I'm not clear +> though on which specific risks you'd be most worried about at 4 MB, and i= +f +> there are any risks that you think don't matter at 4 MB but that you woul= +d +> be worried about at higher block size levels. I also don't know if we hav= +e +> similar ideas about the benefits of low tx fees. If we discussed exactly = +how +> we were evaluating this scenario, maybe we'd discover that something I +> thought was a huge benefit of low tx fees is actually not that compelling= +, +> or maybe we'd discover that our entire disagreement boiled down to our +> estimate of one specific risk. + +The most important thing to understand in this discussion is that it +is about a trade-off between lower fees (more maximum tx volume) and +mining (and general) centralization. +I don't know what the costs and gains curves are here (for 4MB, 1 MB +or any other number, and I don't think anybody does). +But if we can't even agree on what the advantages and disadvantages of +increasing the consensus block size maximum, it is very hard that we +can agree on a universally acceptable point or range in this trade-off +rect. + +> For the record, I think these are the main harms of $5 tx fees, along wit= +h +> the main risks I see from moving to 4 MB: +> +> Fees of $5/tx would: +> (a) Prevent a lot of people who could otherwise benefit from Bitcoin's +> decentralization from having an opportunity to reap those benefits. +> Especially people in poor countries with corrupt governments who could ge= +t +> immediate benefit from it now. +> (b) Prevent developers from experimenting with new Bitcoin use-cases, whi= +ch +> might eventually lead to helpful services. +> (c) Prevent regular people from using Bitcoin and experimenting with it a= +nd +> getting involved, because they think it's unusable for txns under many +> hundreds of dollars in value, so it doesn't interest them. Not having the +> public on our side could make us more vulnerable to regulators. + +This is all probably right, but IMO we're very far away from $5/tx. +My main point about fees is that minimum mining fees rising above zero +(theri current level) is not necessarily a bad thing or an urgent +concern. +On the other hand, we have much more data about current mining +centralization, which should be very relevant information when +discussing a block size increase. + +> Changing the block size to 4 MB would: +> (1) Probably reduce the number of full nodes by around 5%. Most of the dr= +op +> in full nodes over the past few years is probably due to Bitcoin Core bei= +ng +> used by fewer regular users for convenience reasons, but the extra HD spa= +ce +> required and extra bandwidth would probably make some existing people +> running full nodes stop. + +As Pieter has explained repeatedly, a big block count is not a goal in +itself, just a metric. +And if you ask me, I don't think it's all that interesting as a +metric. For all I know there could be a lot more full nodes being run +that for whatever reason are not seen by people collecting this data. +The block size maximum consensus rule limits mining centralization, +not just full node centralization. Gavin, for example, disagrees with +this. +Fortunately I believe at least 2 mathematical proofs can be produced +to demonstrate Gavin and those who think like him are wrong. + +> (2) Not hinder low bandwidth miners significantly, because of the relay +> network. + +I believe that even with the relay network, and even assuming all +miners are connected using something like IBLT, a mathematical proof +can be constructed to demonstrate that bigger block sizes can prevent +the worse connected miners from being profitable. +It is important to note that the worse connected miners aren't +necessarily those with less bandwidth: maybe you have the best +bandwidth but you are poorly connected to the majority of the hashrate +(for example, because the majority of the hashrate is within the same +country but that country is not very well connected to the rest of the +world). + +> (3) Not introduce any tx verification issues, because processors are fast +> and tx processing is ridiculously cheap and we'd need way more than 4 MB = +of +> txs for it to be a bottleneck. + +We're certainly far away from this being a concern in practice. +But I'm working on a mathematical proof that at some scale CPU +requirements could become a discriminating factor making the smallest +mining operations unprofitable. + +> So (1) is the only risk that gives me any significant concern, but I don'= +t +> think that the number of full nodes now is at a dangerous level. + +I don't think there's such a thing as a "dangerous full node count level". +It's just data that can be useful to build centralization metrics. +Probably hashrate distribution by pool is much more interesting (and +if you ask me that looks really bad right now without increasing the +block size consensus maximum). + +> Anyway, the point isn't for you and I to actually discuss this particular +> hypothetical in more detail (although I would be curious to see similar +> lists from you). I haven't studied the risks enough to actually put this +> forth to the list as a good argument for what to do in this situation. My +> main point is that being very specific and concrete both about our though= +t +> process and about the hypothetical situation results in much better +> discussions. + +I agree. + +> There's one more piece of information that I can give you which will help +> you understand my position much better, and also force me to think really +> carefully about this. It's the point at which I would switch to the other +> side of the argument (either by varying the tx fee, or the block size). I= +f +> tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I +> would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at +> $5, I think moving to 12 MB or higher is the point at which I'd switch ov= +er +> to being a 1 MB advocate. Getting that same info from you tells me exactl= +y +> how you weigh the risks in a way that just listing the factors can't. In +> this specific hypothetical scenario, what is the lowest block size increa= +se +> that you'd accept? It can be extremely low, like 1.01 MB. If you tell me +> that you'd rather have $5 tx fees for the next year instead of changing t= +he +> block size to 1.01 MB, I would be really surprised. + +Great. I don't think that minimum mining fees will rise above 1 usd +cent/tx anytime soon even if we maintain the limit of 1MB. +Maybe that's why I'm not worried at all about "hitting the limit". +But I'm sorry, I don't have those concrete numbers because it is a +trade-off I don't think we've studied in enough detail. +Well, I can also say I wouldn't be worried at all about moving to, +say, 1.01 MB (because the difference in centralization pressure should +be minimal) and I would just take it as a "let's proof hardforks are +possible" change similar to the one proposed in bip99. + +> Gavin is the only other person who I've seen who has defined at what bloc= +k +> size he'd switch to the other side (maybe not with a concrete number, but +> with a rough range: the block size such that a normal person with a prett= +y +> good connection couldn't run a full node). + +That would be interesting to read and I have totally missed it. +Do you have a link? + +> I would say that in this case we know high tx fees could happen very soon +> because there is a clear mechanism. Bitcoin just needs to become more +> popular quickly for any number of reasons. Suppose the infrastructure for +> remittances starts falling into place within the next two months, and +> suddenly immigrants are clamoring to use Bitcoin to send money back to th= +eir +> home countries. This could result in $5 tx fees very soon (not that I thi= +nk +> it's likely). Many of these immigrants would still use Bitcoin because it= +'s +> still better than the alternative for remittances, which would price out = +a +> lot of people currently using Bitcoin for other reasons. As far as I know= +, +> there is no plausible way that subsidies could plummet in anywhere near t= +hat +> time frame, aside from the price of Bitcoin completely collapsing. + +And for any size something similar could happen with some use case. +But this is a great example of a situation where I would understand +people panicking and clamoring to change the consensus rule as soon as +possible. +Even with much lower fees, say 1 usd/tx. +I think it would be a great problem to have and admittedly I'm not +worried about having it in the short term. +And if it happened overnight we could always deploy an emergency hardfork. + +> But if +> that happens in the near term (specifically, with very low tx volume) a f= +ee +> market won't help. + +I think it's helping by determining who is to be served first, and +that is those who benefit more from Bitcoin (and are therefore willing +to pay higher costs for using it), in this case, people doing +international remittances. + +> I would be extremely happy if Bitcoin could somehow sustain itself in the +> long run with 5 cent tx fees. I'm optimistic about Lightning to handle th= +e +> cases where people need even cheaper txns. + +Agreed. + +>> I'm still missing an answer from the "big blocks size side" to the +>> following question (which I have insistently repeated with various +>> permutations): +>> +>> If "not now" when will it be a good time to let fees rise above zero? +>> After the next subsidy halving? After 4 more subsidy halvings (ie +>> about 13 years from now, subsidy =3D 1.5625 btc/block )? After your +>> grandmother abandons her national currency and uses Bitcoin for +>> everything? Never? +>> +>> ANY answer (maybe with the exception of the last one) would be less +>> worrying than silence. +> +> +> Before I answer, here's my reasoning about why we don't need to worry abo= +ut +> a fee market now: +> +> There is nothing particularly special about a fee market in Bitcoin. We k= +now +> how markets work, and we have no reason to suspect a fee market in Bitcoi= +n +> will have any new properties of markets that we can't foresee. When deman= +d +> becomes higher, there will be some equilibrium level of fee that people h= +ave +> to pay to give a certain probability of inclusion within a certain number= + of +> blocks. There will likely be some level of fee where if you don't pay it, +> your tx will never be confirmed. + +This is what I mean by "market minimum fee". + +> We have seen something like this working at various points in Bitcoin's +> history. Look at the recent "stress tests." To get your tx confirmed in a +> reasonable time frame, you had to bump your fee a little higher than the +> txns from whoever was flooding the network. If you did, everything worked +> fine. If you didn't, your tx didn't confirm (until the test ended, maybe?= +). +> So there's nothing complicated here. It doesn't require a decade long +> preparation to prove to ourselves that a fee market will work. + +I think the code that miners use to select which transactions to +include first needs a lot of work. +As said miners are subsidizing free transactions, increasing their own +costs for nothing in exchange. +Also, yes, there is something special about this market: it is +supposed to pay for most of the global hashrate in the not-so-far +future. +If we take too long to start moving away from total seigniorage +subsidy dependence, it may be too late when we do. + +> Unless in the future mining is funded mostly by charity (I think there's +> only a 25% chance of that happening), we will need a fee market eventuall= +y. +> I'd be fine if one developed now. I think 10 cents per txn right now +> wouldn't be too bad, aside from the following reason. What concerns me ab= +out +> insisting on a fee market right now is that usage is so small and the blo= +ck +> size is so limited that if demand increases just a little bit, fees could +> skyrocket. It's not the 10 cent fees that would worry me, but what they s= +ay +> about the potential for a huge spike. Fees could become $10 per tx or hig= +her +> very quickly. Yes, that would show that big organizations find Bitcoin +> useful which is nice, but it'd also put decentralized money out of reach = +of +> many other people. While Bitcoin still has a lot of growth ahead of it, i= +t's +> better to not set up roadblocks (for reasons other than preserving +> decentralization) in front of that growth which will make things very +> painful if that growth happens more suddenly than we expect. +> +> I think the best argument for having a fee market right now is that if we +> move to such a market suddenly in the future, wallets won't have time to +> make the user experience good, and full nodes might not be written in suc= +h a +> way that they gracefully handle a bunch of txns that might never confirm.= + I +> don't think the required software changes are that complex though, so it +> seems unnecessary to start adding friction for users now for something th= +at +> might be an issue in 10+ years. + +I think you are underestimating the software costs. +And you not only have to adapt the software that we have now, but also +the software that hasn't been written yet and will be written assuming +free transactions and an underdeveloped market. +Also you are over-estimating the costs: you could hit the limit but +then rise the block size maximum as soon as you reach, say 0.00001 +usd/tx. +Even if minimum fees go again to zero after rising the block size +maximum, the software improvements will remain there. + +> So to answer your question: about two years before we think Bitcoin will +> need to rely heavily on txn fees for security, I'd be in favor of adjusti= +ng +> block size so that it resulted in enough total fees / security. + +And when do you think "Bitcoin will need to rely heavily on txn fees +for security"? +How many more halvings is that? + +> You've been arguing that 0 fee transactions will have to disappear someda= +y, +> but this isn't necessarily true. As long as enough people care about havi= +ng +> their txns confirm relatively quickly, there's no reason to make sure tha= +t +> people who pay 0 fees never have their txns confirmed. + +That's not what I've been arguing, I've just being saying that I would +be completely ok with minimum fees rising above zero (say, to 1 +satoshi/tx) tomorrow. +I don't think that's necessarily a bad thing (in fact, it has some +advantages) and certainly not something we should fear to the point of +rushing hardforks to avoid it. + |