diff options
| author | Elliot Olds <elliot.olds@gmail.com> | 2015-08-06 16:09:49 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-06 23:09:52 +0000 |
| commit | 16c9f42522acd5a7ce206a7ae97d1247bdcfeb02 (patch) | |
| tree | cb0d84a7617b07d2b3407185cb399bee995ae78f | |
| parent | 03bdf86b771d0be1e71252d135b9913f80255ead (diff) | |
| download | pi-bitcoindev-16c9f42522acd5a7ce206a7ae97d1247bdcfeb02.tar.gz pi-bitcoindev-16c9f42522acd5a7ce206a7ae97d1247bdcfeb02.zip | |
Re: [bitcoin-dev] Block size following technological growth
| -rw-r--r-- | aa/9de04b206332df935d893a8062a10985c18f4a | 526 |
1 files changed, 526 insertions, 0 deletions
diff --git a/aa/9de04b206332df935d893a8062a10985c18f4a b/aa/9de04b206332df935d893a8062a10985c18f4a new file mode 100644 index 000000000..d85025e92 --- /dev/null +++ b/aa/9de04b206332df935d893a8062a10985c18f4a @@ -0,0 +1,526 @@ +Return-Path: <elliot.olds@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 81BB68D3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 23:09:52 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com + [209.85.213.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEC28153 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 23:09:50 +0000 (UTC) +Received: by igbij6 with SMTP id ij6so21018397igb.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 06 Aug 2015 16:09:50 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=DLO1RTjTqnDQyMtVwx5i+R+DoGRf0h2MyTd5/J0zSYY=; + b=0lTonyVvnyshbYKXyt6vynXPu9kMCX8oVe7QJiu212JpAHn9CNiG8aacaQBuiZDcUx + 9Jwm2wn8Qjn7tyRTmzNiZTgRWwd3CLmiVOM0BPBuILyEAjSurr910XF/Z7Q/BoNPWq8D + c49HmHJ6lk10x4F3cy+qEEvokHjZYzjB02xLmsCeDgIZjnz/PQ/HmVgElQCKVJr96dfA + Qs1SsioKDR8Mj76zCxbfChGtpvsvTh/hrT9jdGk0VeKz9Pa1frYRF/pyITgpGcvQU29j + 38BJM1pgVcUaMxy1IA+34ZK3lI1Xex4In01ErdBwdMX/PZg0HU4l8jkalSYuM61uvaVn + +nqw== +MIME-Version: 1.0 +X-Received: by 10.50.25.226 with SMTP id f2mr295615igg.87.1438902590277; Thu, + 06 Aug 2015 16:09:50 -0700 (PDT) +Received: by 10.79.97.4 with HTTP; Thu, 6 Aug 2015 16:09:49 -0700 (PDT) +In-Reply-To: <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@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> +Date: Thu, 6 Aug 2015 16:09:49 -0700 +Message-ID: <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com> +From: Elliot Olds <elliot.olds@gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=047d7bd75b40c29028051cac9d10 +X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_40,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.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: Thu, 06 Aug 2015 23:09:52 -0000 + +--047d7bd75b40c29028051cac9d10 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +On Wed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote: +> +> +> Given that for any non-absurdly-big size some transactions will +> eventually be priced out, and that the consensus rule serves for +> limiting mining centralization (and more indirectly centralization in +> general) and not about trying to set a given average transaction fee, +> I think the current level of mining centralization will always be more +> relevant than the current fee level when discussing any change to the +> consensus rule to limit centralization (at any point in time). +> In other words, the question "can we change this without important +> risks of destroying the decentralized properties of the system in the +> short or long run?" should be always more important than "is there a +> concerning rise in fees to motivate this change at all?". +> + +I agree with you that decentralization is the most important feature of +Bitcoin, but I also think we need to think probabilistically and concretely +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. +For instance, people will generally not accept a 100% probability of death +in exchange for any amount of money. However anyone who understands +probability and has the preferences of a normal person would play a game +where they accept a one in a billion chance of instant death to win one +billion dollars if they don't die. + +Similarly we shouldn't accept a 100% probability of Bitcoin being +controlled by a single entity for any guarantee of cheap tx fees no matter +how low they 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 somehow allowed us to dramatically increase +usability. (Imagine something like the Lightning Network but even better +was developed, but it could only work with 1.01 MB blocks). + + + +> > Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow +> knew +> > with certainty that increasing to 4MB would result in a 20 cent/tx +> > equilibrium that would last for a year (otherwise fees would stay aroun= +d +> $5 +> > for that year), would you be in favor of an increase to 4MB? +> +> As said, I would always consider the centralization risks first: I'd +> rather have a $5/tx decentralized Bitcoin than a Bitcoin with free +> transactions but effectively validated (when they validate blocks they +> mine on top of) by around 10 miners, specially if only 3 of them could +> easily collude to censor transactions [orphaning any block that +> doesn't censor in the same manner]. Sadly I have no choice, the later +> is what we have right now. And reducing the block size can't guarantee +> that the situation will get better or even that fees could rise to +> $5/tx (we just don't have that demand, not that it is a goal for +> anyone). All I know is that increasing the block size *could* +> (conditional, not necessarily, I don't know in which cases, I don't +> think anybody does) make things even worse. +> + +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 if +there are any risks that you think don't matter at 4 MB but that you would +be worried about at higher block size levels. I also don't know if we have +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. + +For the record, I think these are the main harms of $5 tx fees, along with +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 get +immediate benefit from it now. +(b) Prevent developers from experimenting with new Bitcoin use-cases, which +might eventually lead to helpful services. +(c) Prevent regular people from using Bitcoin and experimenting with it and +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. + +Changing the block size to 4 MB would: +(1) Probably reduce the number of full nodes by around 5%. Most of the drop +in full nodes over the past few years is probably due to Bitcoin Core being +used by fewer regular users for convenience reasons, but the extra HD space +required and extra bandwidth would probably make some existing people +running full nodes stop. +(2) Not hinder low bandwidth miners significantly, because of the relay +network. +(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. + +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. + +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 thought +process and about the hypothetical situation results in much better +discussions. + +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). If +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 over +to being a 1 MB advocate. Getting that same info from you tells me exactly +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 increase +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 the +block size to 1.01 MB, I would be really surprised. + +Gavin is the only other person who I've seen who has defined at what block +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 pretty +good connection couldn't run a full node). + + +> On the other hand, I could understand people getting worried if fees +> where as high as $5/tx or even 20 cent/tx but we're very far away from +> that case. How can low subsidies (a certainty) be "too far in the +> future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an +> urgent concern? + + +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 +their home countries. This could result in $5 tx fees very soon (not that I +think 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 that time frame, aside from the price of Bitcoin completely +collapsing. But if that happens in the near term (specifically, with very +low tx volume) a fee market won't help. + + +> For all I know, 5 cent/tx may not happen in the next +> 25 years: it may never happen. And if it happens, to me it will be a +> symptom of Bitcoin success, even for others it means that Bitcoin has +> become a "high value settlement network". +> + +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 the +cases where people need even cheaper txns. + + + +> 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 about +a fee market now: + +There is nothing particularly special about a fee market in Bitcoin. We +know how markets work, and we have no reason to suspect a fee market in +Bitcoin will have any new properties of markets that we can't foresee. When +demand becomes higher, there will be some equilibrium level of fee that +people have 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. + +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. + +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 eventually. +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 +about insisting on a fee market right now is that usage is so small and the +block 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 say about the potential for a huge spike. Fees could become $10 per tx +or higher 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, it'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 such +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 that +might be an issue in 10+ years. + +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 adjusting +block size so that it resulted in enough total fees / security. Until that +point, we should care a lot about Bitcoin being widely used so that when we +do need a fee market, it's more like lots of people paying 5 cents per tx +instead of fewer people paying $10/tx. I think the former situation is much +more likely to sustainable, and we're more likely to get there if we +encourage low fee use cases now. + +You've been arguing that 0 fee transactions will have to disappear someday, +but this isn't necessarily true. As long as enough people care about having +their txns confirm relatively quickly, there's no reason to make sure that +people who pay 0 fees never have their txns confirmed. + +--047d7bd75b40c29028051cac9d10 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= +ed, Aug 5, 2015 at 6:26 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href= +=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></sp= +an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= +er-left:1px #ccc solid;padding-left:1ex"><span><br> +</span>Given that for any non-absurdly-big size some transactions will<br> +eventually be priced out, and that the consensus rule serves for<br> +limiting mining centralization (and more indirectly centralization in<br> +general) and not about trying to set a given average transaction fee,<br> +I think the current level of mining centralization will always be more<br> +relevant than the current fee level when discussing any change to the<br> +consensus rule to limit centralization (at any point in time).<br> +In other words, the question "can we change this without important<br> +risks of destroying the decentralized properties of the system in the<br> +short or long run?" should be always more important than "is ther= +e a<br> +concerning rise in fees to motivate this change at all?".<br></blockqu= +ote><div><br></div><div>I agree with you that decentralization is the most = +important feature of Bitcoin, but I also think we need to think probabilist= +ically and concretely about when risks to decentralization are worthwhile.= +=C2=A0</div><div><br></div><div>Decentralization is not infinitely valuable= + in relation to low fees, just like being alive is not infinitely valuable = +in relation to having money. For instance, people will generally not accept= + a 100% probability of death in exchange for any amount of money. However a= +nyone who understands probability and has the preferences of a normal perso= +n would play a game where they accept a one in a billion chance of instant = +death to win one billion dollars if they don't die.=C2=A0</div><div><br= +></div><div>Similarly we shouldn't accept a 100% probability of Bitcoin= + being controlled by a single entity for any guarantee of cheap tx fees no = +matter how low they are, but there should be some minuscule risk of decentr= +alization that we'd be willing to accept (like raising the block size t= +o 1.01 MB) if it somehow allowed us to dramatically increase usability. (Im= +agine something like the Lightning Network but even better was developed, b= +ut it could only work with 1.01 MB blocks).</div><div><br></div><div>=C2=A0= +</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= +eft:1px #ccc solid;padding-left:1ex"><span> +> Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow= + knew<br> +> with certainty that increasing to 4MB would result in a 20 cent/tx<br> +> equilibrium that would last for a year (otherwise fees would stay arou= +nd $5<br> +> for that year), would you be in favor of an increase to 4MB?<br> +<br> +</span>As said, I would always consider the centralization risks first: I&#= +39;d<br> +rather have a $5/tx decentralized Bitcoin than a Bitcoin with free<br> +transactions but effectively validated (when they validate blocks they<br> +mine on top of) by around 10 miners, specially if only 3 of them could<br> +easily collude to censor transactions [orphaning any block that<br> +doesn't censor in the same manner]. Sadly I have no choice, the later<b= +r> +is what we have right now. And reducing the block size can't guarantee<= +br> +that the situation will get better or even that fees could rise to<br> +$5/tx (we just don't have that demand, not that it is a goal for<br> +anyone). All I know is that increasing the block size *could*<br> +(conditional, not necessarily, I don't know in which cases, I don't= +<br> +think anybody does) make things even worse.<br></blockquote><div><br></div>= +<div>I agree that we don't have good data about what exactly a 4 MB inc= +rease would do. It sounds like you think the risks are too great / uncertai= +n to move from 1 MB to 4 MB blocks in the situation I described. I'm no= +t clear though on which specific risks you'd be most worried about at 4= + MB, and if there are any risks that you think don't matter at 4 MB but= + that you would be worried about at higher block size levels. I also don= +9;t know if we have similar ideas about the benefits of low tx fees. If we = +discussed exactly how we were evaluating this scenario, maybe we'd disc= +over 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 disagreeme= +nt boiled down to our estimate of one specific risk.=C2=A0</div><div><br></= +div><div><div><div>For the record, I think these are the main harms of $5 t= +x fees, along with the main risks I see from moving to 4 MB:</div><div><br>= +</div><div>Fees of $5/tx would:</div><div>(a) Prevent a lot of people who c= +ould otherwise benefit from Bitcoin's decentralization from having an o= +pportunity to reap those benefits. Especially people in poor countries with= + corrupt governments who could get immediate benefit from it now.=C2=A0</di= +v><div>(b) Prevent developers from experimenting with new Bitcoin use-cases= +, which might eventually lead to helpful services.</div><div>(c) Prevent re= +gular people from using Bitcoin and experimenting with it and getting invol= +ved, because they think it's unusable for txns under many hundreds of d= +ollars in value, so it doesn't interest them. Not having the public on = +our side could make us more vulnerable to regulators.=C2=A0</div><div><br><= +/div><div>Changing the block size to 4 MB would:</div><div>(1) Probably red= +uce the number of full nodes by around 5%. Most of the drop in full nodes o= +ver the past few years is probably due to Bitcoin Core being used by fewer = +regular users for convenience reasons, but the extra HD space required and = +extra bandwidth would probably make some existing people running full nodes= + stop.=C2=A0</div><div>(2) Not hinder low bandwidth miners significantly, b= +ecause of the relay network.</div><div>(3) Not introduce any tx verificatio= +n issues, because processors are fast and tx processing is ridiculously che= +ap and we'd need way more than 4 MB of txs for it to be a bottleneck.</= +div><div><br></div><div>So (1) is the only risk that gives me any significa= +nt concern, but I don't think that the number of full nodes now is at a= + dangerous level.</div></div><div><br></div><div>Anyway, the point isn'= +t for you and I to actually discuss this particular hypothetical in more de= +tail (although I would be curious to see similar lists from you). I haven&#= +39;t studied the risks enough to actually put this forth to the list as a g= +ood argument for what to do in this situation. My main point is that being = +very specific and concrete both about our thought process and about the hyp= +othetical situation results in much better discussions.=C2=A0<br></div><div= +><br></div><div>There's one more piece of information that I can give y= +ou which will help you understand my position much better, and also force m= +e 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). If tx fees would only rise to 60 cents or lower if we sta= +yed at 1 MB, then I would be against a move to 4 MB. Or, keeping the hypoth= +etical 1 MB fee at $5, I think moving to 12 MB or higher is the point at wh= +ich I'd switch over to being a 1 MB advocate. Getting that same info fr= +om you tells me exactly 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 increase 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 the block size to 1.01 MB, I would be really = +surprised.=C2=A0</div><div><br></div><div>Gavin is the only other person wh= +o I've seen who has defined at what block size he'd switch to the o= +ther side (maybe not with a concrete number, but with a rough range: the bl= +ock size such that a normal person with a pretty good connection couldn'= +;t run a full node).</div><div>=C2=A0<br></div></div><blockquote class=3D"g= +mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= +eft:1ex"> +On the other hand, I could understand people getting worried if fees<br> +where as high as $5/tx or even 20 cent/tx but we're very far away from<= +br> +that case. How can low subsidies (a certainty) be "too far in the<br> +future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an<b= +r> +urgent concern?</blockquote><div><br></div><div>I would say that in this ca= +se we know high tx fees could happen very soon because there is a clear mec= +hanism. Bitcoin just needs to become more popular quickly for any number of= + reasons. Suppose the infrastructure for remittances starts falling into pl= +ace within the next two months, and suddenly immigrants are clamoring to us= +e Bitcoin to send money back to their home countries. This could result in = +$5 tx fees very soon (not that I think it's likely). Many of these immi= +grants would still use Bitcoin because it's still better than the alter= +native for remittances, which would price out a lot of people currently usi= +ng Bitcoin for other reasons. As far as I know, there is no plausible way t= +hat subsidies could plummet in anywhere near that time frame, aside from th= +e price of Bitcoin completely collapsing. But if that happens in the near t= +erm (specifically, with very low tx volume) a fee market won't help.</d= +iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= + .8ex;border-left:1px #ccc solid;padding-left:1ex"> For all I know, 5 cent/= +tx may not happen in the next<br> +25 years: it may never happen. And if it happens, to me it will be a<br> +symptom of Bitcoin success, even for others it means that Bitcoin has<br> +become a "high value settlement network".<br></blockquote><div><b= +r></div><div>I would be extremely happy if Bitcoin could somehow sustain it= +self in the long run with 5 cent tx fees. I'm optimistic about Lightnin= +g to handle the cases where people need even cheaper txns.=C2=A0</div><div>= +<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi= +n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +I'm still missing an answer from the "big blocks size side" t= +o the<br> +following question (which I have insistently repeated with various<br> +permutations):<br> +<br> +If "not now" when will it be a good time to let fees rise above z= +ero?<br> +After the next subsidy halving? After 4 more subsidy halvings (ie<br> +about 13 years from now, subsidy =3D 1.5625 btc/block )? After your<br> +grandmother abandons her national currency and uses Bitcoin for<br> +everything? Never?<br> +<br> +ANY answer (maybe with the exception of the last one) would be less<br> +worrying than silence.<br></blockquote><div><br></div><div>Before I answer,= + here's my reasoning about why we don't need to worry about a fee m= +arket now:</div><div><br></div><div>There is nothing particularly special a= +bout a fee market in Bitcoin. We know how markets work, and we have no reas= +on to suspect a fee market in Bitcoin will have any new properties of marke= +ts that we can't foresee. When demand becomes higher, there will be som= +e equilibrium level of fee that people have to pay to give a certain probab= +ility 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 conf= +irmed.=C2=A0</div><div><br></div><div>We have seen something like this work= +ing at various points in Bitcoin's history. Look at the recent "st= +ress 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 floodin= +g 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 nothin= +g complicated here. It doesn't require a decade long preparation to pro= +ve to ourselves that a fee market will work.</div><div><br></div><div>Unles= +s in the future mining is funded mostly by charity (I think there's onl= +y a 25% chance of that happening), we will need a fee market eventually. I&= +#39;d be fine if one developed now. I think 10 cents per txn right now woul= +dn't be too bad, aside from the following reason. What concerns me abou= +t 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 coul= +d skyrocket. It's not the 10 cent fees that would worry me, but what th= +ey say about the potential for a huge spike. Fees could become $10 per tx o= +r higher very quickly. Yes, that would show that big organizations find Bit= +coin 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, it's better to not set up roadblocks (for reasons other than pre= +serving decentralization) in front of that growth which will make things ve= +ry painful if that growth happens more suddenly than we expect.=C2=A0</div>= +<div><br></div><div>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 wo= +n't have time to make the user experience good, and full nodes might no= +t be written in such a way that they gracefully handle a bunch of txns that= + might never confirm. I don't think the required software changes are t= +hat complex though, so it seems unnecessary to start adding friction for us= +ers now for something that might be an issue in 10+ years.=C2=A0</div><div>= +<br></div><div>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 f= +avor of adjusting block size so that it resulted in enough total fees / sec= +urity. Until that point, we should care a lot about Bitcoin being widely us= +ed so that when we do need a fee market, it's more like lots of people = +paying 5 cents per tx instead of fewer people paying $10/tx. I think the fo= +rmer situation is much more likely to sustainable, and we're more likel= +y to get there if we encourage low fee use cases now.</div><div><br></div><= +div>You've been arguing that 0 fee transactions will have to disappear = +someday, but this isn't necessarily true. As long as enough people care= + about having their txns confirm relatively quickly, there's no reason = +to make sure that people who pay 0 fees never have their txns confirmed.=C2= +=A0</div><div>=C2=A0</div></div></div></div> + +--047d7bd75b40c29028051cac9d10-- + |