Nostr notes by

📅 Original date posted:2015-08-29 📝 Original message:On ...

2023-06-07T19:37:58+02:00

In reply to nevent1q…m02n
_________________________

📅 Original date posted:2015-08-29
📝 Original message:On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear from recent events that miners are willing to collaborate
> together for the greater good of their industry. Miners have also
> publicly shown support for raising the blocksize collaboratively.
>

When have miners shown a willingness to make sacrifices for miners as a
whole when they've been in a "public good"[1] situation? Miners
collaborating to release statements to the public about which BIPs they
support is very different from miners incurring costs only to themselves in
order to help the entire group. They might do so, but it isn't clear.

I agree with Jorge and Mark that allowing miners to vote on the block size
is not ideal. Miners interests are somewhat aligned with those of the
broader community, but not perfectly aligned. The block size level that
maximizes miner revenue is not necessarily desirable overall. More miner
revenue is only good if the marginal extra security that it buys is worth
the extra cost. In addition to the cost of higher user fees, there's
another hidden cost. In Bitcoin's early stages trying to maximize revenue
too soon can slow growth and result in less revenue when it's more needed
(when block rewards are much lower).

[1] https://en.wikipedia.org/wiki/Public_good
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/9386d2f4/attachment.html>;

📅 Original date posted:2015-08-15 📝 Original message:On ...

2023-06-07T19:34:47+02:00

In reply to nevent1q…a6cg
_________________________

📅 Original date posted:2015-08-15
📝 Original message:On Fri, Aug 14, 2015 at 3:55 PM, Jorge Timón <jtimon at jtimon.cc> wrote:

> On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds at gmail.com>
> wrote:
>
> -Reduce the utility of people using the network, even if the higher fees
> > don't reduce their amount of transactions.
>
> "Utility" like "value" is always subjective and very vague. I prefer
> to identify more concrete ways in which "utility is reduced".

Change 'utility' to 'money.' I'm just saying that paying more money for the
same thing is worse for users. If I'm a user who is used to making txns for
1 cent each and suddenly all my txns cost 1 dollar each. then the benefit I
get for each of my transactions that I still make is reduced by 99 cents
per tx. This is as concrete a negative effect as I can imagine. It might
seem obvious that this is a cost, but it seems to be ignored by a lot of
participants.

> > -Make some use cases nonviable, depriving people of Bitcoin's
> decentralized
> > benefits.
>
> It is clear that not all use cases fit the blockchain, but it's still
> unclear which ones don't fit yet.
> But the amount of use cases supported is not a valid metric for
> decentralization.
>

Not sure what you mean by "valid metric for decentralization." I thought
the goal here was to list all negative consequences of high fees. Not just
consequences to decentralization. We're trying to figure out how to trade
off risks to decentralization against these other things we're listing
which aren't necessarily about decentralization (such as reduced use cases).

> In any case, it would be interesting if we could list some concrete
> cases that would be lost.
>

If tx fees rise to $1, then I'll stop making on-blockchain purchases of
less than about $100, meaning pretty much all retail purchases are
eliminated. It's hard to list a lot of use cases that will be lost because
Bitcoin usage is very low right now. I assume most of us believe that there
are lots of interesting use cases that have not developed yet. Just because
they don't exist now doesn't mean we should ignore the fact that high fees
might make them nonviable.

Some examples of stuff that doesn't exist now but might be prevented or
significantly harmed by high fees: small international remittances, machine
to machine payments, decentralized prediction markets (maybe people like
making lots of small bets). Just take any potential use case you can think
of: if the per-tx benefit to the person is less than $1, then $1 tx fees
will prevent it. See below for another example.

> > -Discourage experimentation with new Bitcoin use cases, making it more
> > unlikely that such cases are discovered/improved/popular before Bitcoin's
> > security relies on having many users.
>
> Experimentation can be done with worthless testchains. I'm not sure
> I'm following on this one.
>

I think this is one of the most important costs to worry about. So much of
experimentation can't be done on a testchain, because most experiments that
are being done by early stage companies are about product market fit, and
which services are valuable to users.

Let's say that you and I start a company that allows people to charge money
to people who want to email/message them. There are so many things that we
need to figure out that can't be figured out without participating in the
actual market, with real people, who are really trying to use our service.
It might take us years of making little tweaks to the product before we hit
on some solution that people finally like enough to use in large numbers.

Let's say that right now tx fees are $1, and imagine that the highest
amount that most people are willing to pay to email people is 25 cents. If
we are experimenting in a market with $1 tx fees, perhaps our company will
just die and we'll never figure out how to bring people this service that
they want. Perhaps there are a lot of other innovations relating to 'pay to
message' that would have otherwise been developed (maybe celebrities like
doing AMAs via pay-to-message and devote the funds to charities. Maybe this
becomes a huge source of charitable giving in the future), but because
Bitcoin's high fee environment didn't allow us to explore these ideas, this
whole service category goes undeveloped for many years.

> -Reduce the amount of time we have between now and when tx fees need to
> pay
> > for a significant portion of Bitcoin's security, by keeping the exchange
> > rate and thus the value of block rewards low
> > (https://en.wikipedia.org/wiki/Equation_of_exchange)
>
> Related to exchange rate.
>

Elsewhere you write "I believe 'fear of exchange rate declining' can
probably be added to any concern/risk 'leaf', so we should probably leave
that for the end or just omit it."

It's true that you could tell some indirect story about how pretty much
anything could affect the exchange rate, but separate from all the
hypothetical stories there is a strong theoretical reason to believe that
the exchange rate will be higher the more value is transacted in the
Bitcoin ecosystem. See the wiki link on the equation of exchange. More
people using Bitcoin for transactions will drive up the price, all else
being equal. Perhaps many people care about the price for irrelevant
reasons (they just want to be rich), but as long as Bitcoin's security is
tied to the exchange rate via block rewards, it's also an important
consideration for security.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/99104c9c/attachment.html>;

📅 Original date posted:2015-08-12 📝 Original message:On ...

2023-06-07T19:34:46+02:00

In reply to nevent1q…yp3y
_________________________

📅 Original date posted:2015-08-12
📝 Original message:On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I believe all concerns I've read can be classified in the following groups:
>
> > 1) Potential indirect consequence of rising fees.
>

I'd rephrase this as "Consequences of high fees." It's the level of fees
that is the main issue, not their movement. Moving from 0 satoshi to 1
satoshi fees makes no real difference. Moving from $0 to $1 fees makes a
huge difference. Some consequences are indirect, but others are not (the
first three below are not indirect). Some of the consequences are
uncertain, but others we can have very high confidence in (again: the first
three) and it's only their effect size that can be reasonably disputed.

Here are lots of reasons that you're missing. High fees do the following:

-Reduce the utility of people using the network, even if the higher fees
don't reduce their amount of transactions.
-Make some use cases nonviable, depriving people of Bitcoin's decentralized
benefits.
-Makes level 2 infrastructure like Lightning less valuable by increasing
the minimum value of anchor txns that make sense, and increasing the amount
of pain suffered when your counterparty misbehaves.
-Discourage experimentation with new Bitcoin use cases, making it more
unlikely that such cases are discovered/improved/popular before Bitcoin's
security relies on having many users.
-Makes Bitcoin more vulnerable to regulation by keeping its user base from
growing, meaning regulators face less pressure to keep it unregulated (see:
Uber)
-Reduce the amount of time we have between now and when tx fees need to pay
for a significant portion of Bitcoin's security, by keeping the exchange
rate and thus the value of block rewards low (
https://en.wikipedia.org/wiki/Equation_of_exchange)
-By slowing usage growth, make it less likely that we have a large enough
base of transactions by the time we need to fund network security via tx
fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150812/486116ac/attachment-0001.html>;

📅 Original date posted:2015-08-20 📝 Original message:On ...

2023-06-07T19:34:45+02:00

In reply to nevent1q…cnkr
_________________________

📅 Original date posted:2015-08-20
📝 Original message:On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> To be clear, these two are just my personal lists of arguments on
> "each side" to clear my mind and try to be perfectly objective.
> [...]
> Here's the updated both-thread lists:
>
>
> http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb

I thought this was a good idea, so I turned my personal notes into a site
attempting to list all the strongest arguments and counterarguments on the
block size debate. I made mine a bit more detailed.

Here's the site: https://sites.google.com/site/bitcoinblocksizedebate/

Feedback welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/d24c2727/attachment.html>;

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T19:33:53+02:00

In reply to nevent1q…nkr8
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Tue, Aug 11, 2015 at 9:47 PM, Venzen Khaosan <venzen at mail.bihthai.net>
wrote:
>
> On 08/12/2015 10:35 AM, Elliot Olds via bitcoin-dev wrote:
> > It depends on which use case's reliability that you focus on. For
> > any specific use case of Bitcoin, that use case will be more
> > reliable with a larger block size (ignoring centralization
> > effects).
>
> I read through your message and see the point you're trying to make,
> but would like to point out that it is not useful to talk about
> hypothetical scenarios involving Bitcoin that include the supposition
> "ignoring centralization effects".
>

Pieter was arguing for the existence of an effect on reliability that was
orthogonal to centralization risk. When arguing that this effect doesn't
really exist, it's appropriate to hold centralization risk constant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/880ef259/attachment.html>;

📅 Original date posted:2015-08-12 📝 Original message:On ...

2023-06-07T19:33:52+02:00

In reply to nevent1q…k8x0
_________________________

📅 Original date posted:2015-08-12
📝 Original message:On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber <mickeybob at gmail.com>
> wrote:
>
>> Bitcoin would be better money than current money even if it were a bit
>> more expensive to transact, simply because of its other great
>> characteristics (trustlessness, limited supply, etc). However... it is not
>> better than something else sharing all those same characteristics but which
>> is also less expensive. The best money will win, and if Bitcoin doesn't
>> increase capacity then it won't remain the best.
>>
>
> If it is less expensive, it is harder to be reliable (because it's easier
> for a sudden new use case to outbid the available space), which is less
> useful for a payment mechanism.
>

It depends on which use case's reliability that you focus on. For any
specific use case of Bitcoin, that use case will be more reliable with a
larger block size (ignoring centralization effects).

The effect that I think you're talking about is that with lower fees, some
use cases will exist that otherwise wouldn't have been possible with higher
fees / smaller blocks, and these "low fee only" use cases will not be as
reliable as the use cases you'd see with high fees. But that puts you in a
position or arguing that it's better that low fee use cases never exist at
all, than existing at some high risk of being priced out eventually. Do we
know with high confidence how high tx fees will be in the future? Should it
be up to us discourage low fee use cases from being tried, because we think
the risk that they'll later be priced out is too great? Shouldn't we let
the people developing those use cases make that call? Maybe they don't mind
the unreliability. Maybe it's worth it to them if their use case only lasts
for a few months.

The important point to note is that the reliability of a use case is
determined by the fees that people are willing to pay for that use case,
not the fees that are actually paid. If big banks are willing to pay $1 /
tx for some use case right now, but they only need 200 of these txns per
block, then they might be paying only 5 cents / tx because no one is
forcing them to pay more. The fact that they're only paying 5 cents / tx
now doesn't make them any more vulnerable to new use cases than if they
were paying $1 / tx now. If a new use case started bidding up tx fees, the
banks would just increase their tx fees as high as they needed to (up to
$1).

The reason that larger block sizes increase reliability for any given use
case is that (a) You will never be priced out of blocks by a use case that
is only willing to pay lower fees than you. This is true regardless of the
block size. At worst they'll just force you to pay more in fees and lose
some of your consumer surplus. (b) If a use case is willing to pay higher
fees than you, then they're basically stepping ahead of you in line for
block space and pushing you closer to the edge of not being included in
blocks. The more space that exists between your use case and the marginal
use cases that are just barely getting included in blocks, the less
vulnerable you are to getting pushed out of blocks by new use cases.

If this is tricky to understand, here's an example that will make it clear:

Assume blocks can hold 2000 txns per MB. Before the new use case is
discovered, demand looks like this:

500 txns will pay $1 fees
1000 txns will pay 50 cent fees
2000 txns will pay 5 cent fees
8000 txns will pay 2 cent fees
15,000 txns will pay 1 cent fees.
100,000 txns will pay 0.01 cent fees.

So at a block size of 1MB, fees are 5 cents and user surplus is $925 per
block ($0.95 * 500 + 0.45 * 1000).
At a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per
block ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).

Now a new use case comes into play and this is added to demand:

3000 txns will pay $5 / tx

That demand changes the scenarios like such:

At 1 MB fees jump to $5, user surplus is $0, and the $925 of value the
previous users were getting is lost. All existing use cases are priced out,
because there wasn't enough room in the blocks to accommodate them plus
this new use case.

At 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0
in value would be lost (3000 users who were paying 1 cent for txns that
they valued only at 1 cent would stop making txns). All use cases
corresponding to the txns that were willing to pay at least 2 cents are
still viable, because there was enough space in blocks to accommodate them
plus the 3000 new high fee txns.

Let's say you're running the service that represents the 2000 txns willing
to pay 5 cents each on the demand curve specified above. Let's say you're
worried about being priced out of blocks. Which situation do you want to be
in, the one with 1 MB blocks or 8 MB blocks? It's pretty clear that your
best chance to remain viable is with larger blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/7e2e6848/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T19:33:37+02:00

In reply to nevent1q…gjr8
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Fri, Aug 7, 2015 at 9:28 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should), and
> it just takes time for the market to find a way to fill whatever is
> available - the rest goes into off-chain systems anyway. You will run out
> of capacity at any size, and acting out of fear of that reality does not
> improve the system.
>

I think the case for increasing block size can be made without appealing to
fear of unknown effects of a fee market developing. I agree with you that
the most likely outcome is that fees will rise to a new equilibrium as
competition for block space increases, and some use cases will get priced
out of the market. If fees rise high enough, the effects of this can be
pretty bad though. I get the sense that you don't think high fees are that
bad / low fees are that good.

Can you let me know which of these statements related to low fees you
disagree with?

(0) Bitcoin's security will eventually have to be paid for almost entirely
via txn fees.

(1) A future in which lots of users are making on chain txns and each
paying 5 cents/tx is more sustainable than one in which a smaller number of
users are paying $3/tx, all else being equal (pretend the centralization
pressures are very low in both instances, and each scenario results in the
same amount of total tx fees).

(2) It's important that Bitcoin become widely used to protect the network
against regulators (note how political pressure from users who like Uber
have had a huge effect on preventing Uber from being banned in many
locations).

(3) There are potentially a lot of valuable use cases that can benefit from
Bitcoin's decentralization which can work at 5 cents / tx but are nonviable
at $3 / tx. Allowing fees to stay at $3 / tx and pricing out all the viable
use cases between $3 and 5 cents / tx would likely result in a significant
loss of utility for people who want these use cases to work.

(4) The Lightning Network will be a lot less appealing at $3 / tx than 5
cents / tx, because it'll require much larger anchor txn values to
sufficiently amortize the costs of the Bitcoin tx fees, and having to pay
$3 each time your counter-party misbehaves is somewhat painful.

(5) Assuming that Bitcoin is somewhat likely to end up in the "lots of
users, lower fees" situation described in (1), it's important that people
can experiment with low fee use cases now so that these use cases have time
to be discovered, be improved, and become popular before Bitcoin's security
relies exclusively on fees.

Finally, here's a type of question that devs on this list really don't like
answering but which I think is more informative than almost any other: If
you knew that hard forking to 4 MB soon would keep fees around 5 cents
(with a fee market) for the next two years, and that remaining at 1 MB
would result in fees of around $1 for the next two years, would you be in
favor of the 4 MB hard fork? (I know our knowledge of the decentralization
risks isn't very complete now, but assume you had to make a decision given
the state of your knowledge now).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/af01b4aa/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T19:32:39+02:00

In reply to nevent1q…230z
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Mon, Aug 10, 2015 at 12:28 PM, Jorge Timón <jtimon at jtimon.cc> wrote:

> I would just like that there was an attempt to automatically
> estimate those risks before taking those risks.
>

I agree.

> 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.
>

Yes, it only gets bad when fees become "high."

I'll skip over the discussion of the pros/cons I listed since that mostly
appeared for illustrative purposes and I don't have a strong disagreement
with anything you said.

> 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".
>

My sense is that the people arguing for a hard fork now tend to envision
"hitting the limit" as tx fees being fairly high, and those arguing against
a hard fork envision tx fees staying low when 1 MB blocks start to get
full. Which of those occurs depends on how quickly and in what manner
Bitcoin gains popularity. Even if I thought there's an 95% chance that
there would be no sudden jump in Bitcoin tx demand, I would want to have
some rough plan in place for that other 5% when some previously difficult
use case becomes viable and demand spikes. Do those arguing for the "wait
and see" approach not think that a quick increase in demand is even likely
enough to warrant discussing what we'd do in that case? Greg Maxwell
mentioned doubling the max block size if there was ever a standing backlog (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html
-- I think fee level is a better metric than size of tx backlog), but I
haven't seen other devs comment on it.

> 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.
>

The question is about what you'd do in the absence of those details that
you don't have. Imagine that fees spiked to $5/tx tomorrow. You have some
model of the situation that allows you to say that 1.01 MB is something
you'd support, and that's the model that I'm trying to understand. The
answers I gave are not ones I'm confident about. I'm sure if I studied this
for a week they'd change. I sense that devs are reluctant to answer this
question because it could be taken out of context or held against them
later. Or maybe they just don't like saying things that they don't have a
high level of confidence about on principle. IMO this reluctance
contributes to a lack of understanding of each other's positions. We all
have these imperfect models in our heads that we're basing our
disagreements on, but we won't show each other these models.

> > 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).
>
> That would be interesting to read and I have totally missed it.
> Do you have a link?

Sorry, I see how what I wrote was misleading. You've seen the email I'm
referring to. I was talking about when he defined the criteria he used
qualitatively and suggested that's how he arrived at 20 MB:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html.
I think he talks about it in a little more detail elsewhere. I inferred
from that that he wouldn't support 40 MB or 80 MB, but that may be wrong.

I should also have given credit to Pieter, as he even more explicitly
specified a level where he'd turn into a hard fork advocate, via his own
hard fork proposal. Neither of these statements specifies exactly where the
switch-over point is, but they're the closest I've seen.

> > 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.
>
> 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.
>

Don't you think the devs should have some rough plan that they discuss
ahead of time about what to do in the situation of high fees? Even if it
happened gradually -- suppose fees crept to 20 cents, then 50 cents, then
75 over the next year -- I don't think I've ever seen a discussion of how
that should be handled, and what sort of fees people regard as high enough
to justify considering a hard fork.

I think it would prevent many people from supporting an urgent hard fork if
they knew how the core devs would handle that situation (assuming there was
some willingness to increase the block size if fees got too high).

> > 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.
>
> [...]
> 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.
>

I see that 'special' feature of this market as more strongly supporting the
need to encourage fast adoption.

Let's say block rewards are $7000 per block, and we think this gives a good
level of security (as Bitcoin grows, we'll probably want a lot more).

Suppose a 1MB block can hold 2000 txns. Then to pay for the same level of
security we have right now with only tx fees, assuming 1 MB blocks, the
average tx fee would have to be $3.50. Now suppose blocks are 100 MB in the
future. The average tx fee is then only 3.5 cents. I think the former
situation will not actually work, and the only way that Bitcoin can survive
is to eventually get into something more like the later situation. Let me
know if you want me to delve into why. I'll just note that even Lightning
doesn't work well when tx fees are that high, because channels need to be
opened and closed pretty often and if my counterparty is uncooperative, his
making me pay $3.50 starts to actually hurt.

So if we accept that, we need to end up in a situation where we eventually
have lots of people making on-blockchain txns, and paying relatively small
fees. Encouraging lots of use and experimentation of Bitcoin between now
and then seems pretty important for reaching that goal.

We're in a race with the block reward halving schedule, to see if we can
get usage high enough to pay for security (while maintaining enough
decentralization) before all of the security burden falls on transactions.
If there aren't enough transactions at that time, the burden will be too
high (or security will be too low) and people will find other solutions.

We seem to disagree about how hard it'll be to change wallet and node
software to cope with a fee market. As I've said I don't see very small
nonzero fees (for instance one tenth of a cent) as a problem though. So if
a solution that traded off usage and decentralization in a way that I
agreed with could be modified to ensure a fee market developed soon with
very low fees, I'd still support it.

>
> > 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.
>
> 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
> adjusting
> > 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
> 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.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/b88fe9a2/attachment-0001.html>;

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T19:32:37+02:00

In reply to nevent1q…vch7
_________________________

📅 Original date posted:2015-08-06
📝 Original message:On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon at 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 around
> $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 = 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/6e7770c5/attachment-0001.html>;

📅 Original date posted:2015-08-05 📝 Original message:On ...

2023-06-07T19:32:31+02:00

In reply to nevent1q…6z09
_________________________

📅 Original date posted:2015-08-05
📝 Original message:On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.

I don't think merely hitting the limit is bad. The level of tx fees in
equilibrium give some clue as to the level of harm being done. If fees are
at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

There is NO criterion based on mining centralization to decide between
> 2 sizes in favor of the small one.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
> I think its the proponents of a blocksize change who should propose
> such a criterion and now they have the tools to simulate different
> block sizes.
>

In the absence of harder data, it might be interesting to use these
simulations to graph centralization pressure as a function of bandwidth
cost over time (or other historical variables that affect centralization).
For instance, look at how high centralization pressure was in 2009
according to the simulations, given how cheap/available bandwidth was then,
compared to 2010, 2011, etc. Then we could figure out: given today's
bandwidth situation, what size blocks right now would give us the same
centralization pressure that we had in 2011, 2012, 2013, etc?

Of course this doesn't mean we should blindly assume that the level of
centralization pressure in 2012 was acceptable, and therefore any block
size increase that results in the same amount of pressure now should be
acceptable. But it might lead to a more productive discussion.

> I want us to simulate many blocksizes before rushing into a decision
> (specially because I disagree that taking a decision there is urgent
> in the first place).

IMO it is not urgent if the core devs are committed to reacting to a huge
spike in tx fees with a modest block size increase in a relatively short
time frame, if they judge the centralization risks of that increase to be
small. Greg Maxwell posted on reddit a while back something to the effect
of "the big block advocates are overstating the urgency of the block size
increase, because if there was actually a situation that required us to
increase block size, we could make the increase when it was actually
needed." I found that somewhat persuasive, but I am concerned that I
haven't seen any discussion of what the "let's wait for now" camp would
consider a valid reason to increase block size in the short term, and how
they'd make the tradeoff with tx fees or whatever else was necessitating
the increase.

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 around $5
for that year), would you be in favor of an increase to 4MB?

For those familiar with the distinction between near/far mode thinking
popularized by Robin Hanson: focusing on concrete examples like this
encourages problem solving and consensus, and focusing on abstract
principles (like decentralization vs. usability in general) leads to people
toward using argument to signal their alliances and reduce the status of
their opponents. I think it'd be very helpful if more 1MB advocates
described what exactly would make them say "OK, in this situation a block
size increase is needed, we should do one quickly!", and also if
Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
would make them want to stick with 1MB blocks for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/0913c1b2/attachment.html>;

📅 Original date posted:2015-08-29 📝 Original message:On ...

2023-06-07T17:49:22+02:00

In reply to nevent1q…g9dz
_________________________

📅 Original date posted:2015-08-29
📝 Original message:On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear from recent events that miners are willing to collaborate
> together for the greater good of their industry. Miners have also
> publicly shown support for raising the blocksize collaboratively.
>

When have miners shown a willingness to make sacrifices for miners as a
whole when they've been in a "public good"[1] situation? Miners
collaborating to release statements to the public about which BIPs they
support is very different from miners incurring costs only to themselves in
order to help the entire group. They might do so, but it isn't clear.

I agree with Jorge and Mark that allowing miners to vote on the block size
is not ideal. Miners interests are somewhat aligned with those of the
broader community, but not perfectly aligned. The block size level that
maximizes miner revenue is not necessarily desirable overall. More miner
revenue is only good if the marginal extra security that it buys is worth
the extra cost. In addition to the cost of higher user fees, there's
another hidden cost. In Bitcoin's early stages trying to maximize revenue
too soon can slow growth and result in less revenue when it's more needed
(when block rewards are much lower).

[1] https://en.wikipedia.org/wiki/Public_good
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/9386d2f4/attachment.html>;

📅 Original date posted:2015-08-15 📝 Original message:On ...

2023-06-07T17:46:41+02:00

In reply to nevent1q…mp6u
_________________________

📅 Original date posted:2015-08-15
📝 Original message:On Fri, Aug 14, 2015 at 3:55 PM, Jorge Timón <jtimon at jtimon.cc> wrote:

> On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds at gmail.com>
> wrote:
>
> -Reduce the utility of people using the network, even if the higher fees
> > don't reduce their amount of transactions.
>
> "Utility" like "value" is always subjective and very vague. I prefer
> to identify more concrete ways in which "utility is reduced".

Change 'utility' to 'money.' I'm just saying that paying more money for the
same thing is worse for users. If I'm a user who is used to making txns for
1 cent each and suddenly all my txns cost 1 dollar each. then the benefit I
get for each of my transactions that I still make is reduced by 99 cents
per tx. This is as concrete a negative effect as I can imagine. It might
seem obvious that this is a cost, but it seems to be ignored by a lot of
participants.

> > -Make some use cases nonviable, depriving people of Bitcoin's
> decentralized
> > benefits.
>
> It is clear that not all use cases fit the blockchain, but it's still
> unclear which ones don't fit yet.
> But the amount of use cases supported is not a valid metric for
> decentralization.
>

Not sure what you mean by "valid metric for decentralization." I thought
the goal here was to list all negative consequences of high fees. Not just
consequences to decentralization. We're trying to figure out how to trade
off risks to decentralization against these other things we're listing
which aren't necessarily about decentralization (such as reduced use cases).

> In any case, it would be interesting if we could list some concrete
> cases that would be lost.
>

If tx fees rise to $1, then I'll stop making on-blockchain purchases of
less than about $100, meaning pretty much all retail purchases are
eliminated. It's hard to list a lot of use cases that will be lost because
Bitcoin usage is very low right now. I assume most of us believe that there
are lots of interesting use cases that have not developed yet. Just because
they don't exist now doesn't mean we should ignore the fact that high fees
might make them nonviable.

Some examples of stuff that doesn't exist now but might be prevented or
significantly harmed by high fees: small international remittances, machine
to machine payments, decentralized prediction markets (maybe people like
making lots of small bets). Just take any potential use case you can think
of: if the per-tx benefit to the person is less than $1, then $1 tx fees
will prevent it. See below for another example.

> > -Discourage experimentation with new Bitcoin use cases, making it more
> > unlikely that such cases are discovered/improved/popular before Bitcoin's
> > security relies on having many users.
>
> Experimentation can be done with worthless testchains. I'm not sure
> I'm following on this one.
>

I think this is one of the most important costs to worry about. So much of
experimentation can't be done on a testchain, because most experiments that
are being done by early stage companies are about product market fit, and
which services are valuable to users.

Let's say that you and I start a company that allows people to charge money
to people who want to email/message them. There are so many things that we
need to figure out that can't be figured out without participating in the
actual market, with real people, who are really trying to use our service.
It might take us years of making little tweaks to the product before we hit
on some solution that people finally like enough to use in large numbers.

Let's say that right now tx fees are $1, and imagine that the highest
amount that most people are willing to pay to email people is 25 cents. If
we are experimenting in a market with $1 tx fees, perhaps our company will
just die and we'll never figure out how to bring people this service that
they want. Perhaps there are a lot of other innovations relating to 'pay to
message' that would have otherwise been developed (maybe celebrities like
doing AMAs via pay-to-message and devote the funds to charities. Maybe this
becomes a huge source of charitable giving in the future), but because
Bitcoin's high fee environment didn't allow us to explore these ideas, this
whole service category goes undeveloped for many years.

> -Reduce the amount of time we have between now and when tx fees need to
> pay
> > for a significant portion of Bitcoin's security, by keeping the exchange
> > rate and thus the value of block rewards low
> > (https://en.wikipedia.org/wiki/Equation_of_exchange)
>
> Related to exchange rate.
>

Elsewhere you write "I believe 'fear of exchange rate declining' can
probably be added to any concern/risk 'leaf', so we should probably leave
that for the end or just omit it."

It's true that you could tell some indirect story about how pretty much
anything could affect the exchange rate, but separate from all the
hypothetical stories there is a strong theoretical reason to believe that
the exchange rate will be higher the more value is transacted in the
Bitcoin ecosystem. See the wiki link on the equation of exchange. More
people using Bitcoin for transactions will drive up the price, all else
being equal. Perhaps many people care about the price for irrelevant
reasons (they just want to be rich), but as long as Bitcoin's security is
tied to the exchange rate via block rewards, it's also an important
consideration for security.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/99104c9c/attachment.html>;

📅 Original date posted:2015-08-12 📝 Original message:On ...

2023-06-07T17:46:41+02:00

In reply to nevent1q…hvx0
_________________________

📅 Original date posted:2015-08-12
📝 Original message:On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I believe all concerns I've read can be classified in the following groups:
>
> > 1) Potential indirect consequence of rising fees.
>

I'd rephrase this as "Consequences of high fees." It's the level of fees
that is the main issue, not their movement. Moving from 0 satoshi to 1
satoshi fees makes no real difference. Moving from $0 to $1 fees makes a
huge difference. Some consequences are indirect, but others are not (the
first three below are not indirect). Some of the consequences are
uncertain, but others we can have very high confidence in (again: the first
three) and it's only their effect size that can be reasonably disputed.

Here are lots of reasons that you're missing. High fees do the following:

-Reduce the utility of people using the network, even if the higher fees
don't reduce their amount of transactions.
-Make some use cases nonviable, depriving people of Bitcoin's decentralized
benefits.
-Makes level 2 infrastructure like Lightning less valuable by increasing
the minimum value of anchor txns that make sense, and increasing the amount
of pain suffered when your counterparty misbehaves.
-Discourage experimentation with new Bitcoin use cases, making it more
unlikely that such cases are discovered/improved/popular before Bitcoin's
security relies on having many users.
-Makes Bitcoin more vulnerable to regulation by keeping its user base from
growing, meaning regulators face less pressure to keep it unregulated (see:
Uber)
-Reduce the amount of time we have between now and when tx fees need to pay
for a significant portion of Bitcoin's security, by keeping the exchange
rate and thus the value of block rewards low (
https://en.wikipedia.org/wiki/Equation_of_exchange)
-By slowing usage growth, make it less likely that we have a large enough
base of transactions by the time we need to fund network security via tx
fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150812/486116ac/attachment-0001.html>;

📅 Original date posted:2015-08-20 📝 Original message:On ...

2023-06-07T17:46:40+02:00

In reply to nevent1q…mczv
_________________________

📅 Original date posted:2015-08-20
📝 Original message:On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> To be clear, these two are just my personal lists of arguments on
> "each side" to clear my mind and try to be perfectly objective.
> [...]
> Here's the updated both-thread lists:
>
>
> http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb

I thought this was a good idea, so I turned my personal notes into a site
attempting to list all the strongest arguments and counterarguments on the
block size debate. I made mine a bit more detailed.

Here's the site: https://sites.google.com/site/bitcoinblocksizedebate/

Feedback welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/d24c2727/attachment.html>;

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T17:45:58+02:00

In reply to nevent1q…zv4m
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Tue, Aug 11, 2015 at 9:47 PM, Venzen Khaosan <venzen at mail.bihthai.net>
wrote:
>
> On 08/12/2015 10:35 AM, Elliot Olds via bitcoin-dev wrote:
> > It depends on which use case's reliability that you focus on. For
> > any specific use case of Bitcoin, that use case will be more
> > reliable with a larger block size (ignoring centralization
> > effects).
>
> I read through your message and see the point you're trying to make,
> but would like to point out that it is not useful to talk about
> hypothetical scenarios involving Bitcoin that include the supposition
> "ignoring centralization effects".
>

Pieter was arguing for the existence of an effect on reliability that was
orthogonal to centralization risk. When arguing that this effect doesn't
really exist, it's appropriate to hold centralization risk constant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/880ef259/attachment.html>;

📅 Original date posted:2015-08-12 📝 Original message:On ...

2023-06-07T17:45:57+02:00

In reply to nevent1q…fgtk
_________________________

📅 Original date posted:2015-08-12
📝 Original message:On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber <mickeybob at gmail.com>
> wrote:
>
>> Bitcoin would be better money than current money even if it were a bit
>> more expensive to transact, simply because of its other great
>> characteristics (trustlessness, limited supply, etc). However... it is not
>> better than something else sharing all those same characteristics but which
>> is also less expensive. The best money will win, and if Bitcoin doesn't
>> increase capacity then it won't remain the best.
>>
>
> If it is less expensive, it is harder to be reliable (because it's easier
> for a sudden new use case to outbid the available space), which is less
> useful for a payment mechanism.
>

It depends on which use case's reliability that you focus on. For any
specific use case of Bitcoin, that use case will be more reliable with a
larger block size (ignoring centralization effects).

The effect that I think you're talking about is that with lower fees, some
use cases will exist that otherwise wouldn't have been possible with higher
fees / smaller blocks, and these "low fee only" use cases will not be as
reliable as the use cases you'd see with high fees. But that puts you in a
position or arguing that it's better that low fee use cases never exist at
all, than existing at some high risk of being priced out eventually. Do we
know with high confidence how high tx fees will be in the future? Should it
be up to us discourage low fee use cases from being tried, because we think
the risk that they'll later be priced out is too great? Shouldn't we let
the people developing those use cases make that call? Maybe they don't mind
the unreliability. Maybe it's worth it to them if their use case only lasts
for a few months.

The important point to note is that the reliability of a use case is
determined by the fees that people are willing to pay for that use case,
not the fees that are actually paid. If big banks are willing to pay $1 /
tx for some use case right now, but they only need 200 of these txns per
block, then they might be paying only 5 cents / tx because no one is
forcing them to pay more. The fact that they're only paying 5 cents / tx
now doesn't make them any more vulnerable to new use cases than if they
were paying $1 / tx now. If a new use case started bidding up tx fees, the
banks would just increase their tx fees as high as they needed to (up to
$1).

The reason that larger block sizes increase reliability for any given use
case is that (a) You will never be priced out of blocks by a use case that
is only willing to pay lower fees than you. This is true regardless of the
block size. At worst they'll just force you to pay more in fees and lose
some of your consumer surplus. (b) If a use case is willing to pay higher
fees than you, then they're basically stepping ahead of you in line for
block space and pushing you closer to the edge of not being included in
blocks. The more space that exists between your use case and the marginal
use cases that are just barely getting included in blocks, the less
vulnerable you are to getting pushed out of blocks by new use cases.

If this is tricky to understand, here's an example that will make it clear:

Assume blocks can hold 2000 txns per MB. Before the new use case is
discovered, demand looks like this:

500 txns will pay $1 fees
1000 txns will pay 50 cent fees
2000 txns will pay 5 cent fees
8000 txns will pay 2 cent fees
15,000 txns will pay 1 cent fees.
100,000 txns will pay 0.01 cent fees.

So at a block size of 1MB, fees are 5 cents and user surplus is $925 per
block ($0.95 * 500 + 0.45 * 1000).
At a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per
block ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).

Now a new use case comes into play and this is added to demand:

3000 txns will pay $5 / tx

That demand changes the scenarios like such:

At 1 MB fees jump to $5, user surplus is $0, and the $925 of value the
previous users were getting is lost. All existing use cases are priced out,
because there wasn't enough room in the blocks to accommodate them plus
this new use case.

At 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0
in value would be lost (3000 users who were paying 1 cent for txns that
they valued only at 1 cent would stop making txns). All use cases
corresponding to the txns that were willing to pay at least 2 cents are
still viable, because there was enough space in blocks to accommodate them
plus the 3000 new high fee txns.

Let's say you're running the service that represents the 2000 txns willing
to pay 5 cents each on the demand curve specified above. Let's say you're
worried about being priced out of blocks. Which situation do you want to be
in, the one with 1 MB blocks or 8 MB blocks? It's pretty clear that your
best chance to remain viable is with larger blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/7e2e6848/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T17:45:44+02:00

In reply to nevent1q…xclc
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Fri, Aug 7, 2015 at 9:28 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should), and
> it just takes time for the market to find a way to fill whatever is
> available - the rest goes into off-chain systems anyway. You will run out
> of capacity at any size, and acting out of fear of that reality does not
> improve the system.
>

I think the case for increasing block size can be made without appealing to
fear of unknown effects of a fee market developing. I agree with you that
the most likely outcome is that fees will rise to a new equilibrium as
competition for block space increases, and some use cases will get priced
out of the market. If fees rise high enough, the effects of this can be
pretty bad though. I get the sense that you don't think high fees are that
bad / low fees are that good.

Can you let me know which of these statements related to low fees you
disagree with?

(0) Bitcoin's security will eventually have to be paid for almost entirely
via txn fees.

(1) A future in which lots of users are making on chain txns and each
paying 5 cents/tx is more sustainable than one in which a smaller number of
users are paying $3/tx, all else being equal (pretend the centralization
pressures are very low in both instances, and each scenario results in the
same amount of total tx fees).

(2) It's important that Bitcoin become widely used to protect the network
against regulators (note how political pressure from users who like Uber
have had a huge effect on preventing Uber from being banned in many
locations).

(3) There are potentially a lot of valuable use cases that can benefit from
Bitcoin's decentralization which can work at 5 cents / tx but are nonviable
at $3 / tx. Allowing fees to stay at $3 / tx and pricing out all the viable
use cases between $3 and 5 cents / tx would likely result in a significant
loss of utility for people who want these use cases to work.

(4) The Lightning Network will be a lot less appealing at $3 / tx than 5
cents / tx, because it'll require much larger anchor txn values to
sufficiently amortize the costs of the Bitcoin tx fees, and having to pay
$3 each time your counter-party misbehaves is somewhat painful.

(5) Assuming that Bitcoin is somewhat likely to end up in the "lots of
users, lower fees" situation described in (1), it's important that people
can experiment with low fee use cases now so that these use cases have time
to be discovered, be improved, and become popular before Bitcoin's security
relies exclusively on fees.

Finally, here's a type of question that devs on this list really don't like
answering but which I think is more informative than almost any other: If
you knew that hard forking to 4 MB soon would keep fees around 5 cents
(with a fee market) for the next two years, and that remaining at 1 MB
would result in fees of around $1 for the next two years, would you be in
favor of the 4 MB hard fork? (I know our knowledge of the decentralization
risks isn't very complete now, but assume you had to make a decision given
the state of your knowledge now).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/af01b4aa/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T17:44:56+02:00

In reply to nevent1q…fnen
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Mon, Aug 10, 2015 at 12:28 PM, Jorge Timón <jtimon at jtimon.cc> wrote:

> I would just like that there was an attempt to automatically
> estimate those risks before taking those risks.
>

I agree.

> 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.
>

Yes, it only gets bad when fees become "high."

I'll skip over the discussion of the pros/cons I listed since that mostly
appeared for illustrative purposes and I don't have a strong disagreement
with anything you said.

> 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".
>

My sense is that the people arguing for a hard fork now tend to envision
"hitting the limit" as tx fees being fairly high, and those arguing against
a hard fork envision tx fees staying low when 1 MB blocks start to get
full. Which of those occurs depends on how quickly and in what manner
Bitcoin gains popularity. Even if I thought there's an 95% chance that
there would be no sudden jump in Bitcoin tx demand, I would want to have
some rough plan in place for that other 5% when some previously difficult
use case becomes viable and demand spikes. Do those arguing for the "wait
and see" approach not think that a quick increase in demand is even likely
enough to warrant discussing what we'd do in that case? Greg Maxwell
mentioned doubling the max block size if there was ever a standing backlog (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html
-- I think fee level is a better metric than size of tx backlog), but I
haven't seen other devs comment on it.

> 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.
>

The question is about what you'd do in the absence of those details that
you don't have. Imagine that fees spiked to $5/tx tomorrow. You have some
model of the situation that allows you to say that 1.01 MB is something
you'd support, and that's the model that I'm trying to understand. The
answers I gave are not ones I'm confident about. I'm sure if I studied this
for a week they'd change. I sense that devs are reluctant to answer this
question because it could be taken out of context or held against them
later. Or maybe they just don't like saying things that they don't have a
high level of confidence about on principle. IMO this reluctance
contributes to a lack of understanding of each other's positions. We all
have these imperfect models in our heads that we're basing our
disagreements on, but we won't show each other these models.

> > 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).
>
> That would be interesting to read and I have totally missed it.
> Do you have a link?

Sorry, I see how what I wrote was misleading. You've seen the email I'm
referring to. I was talking about when he defined the criteria he used
qualitatively and suggested that's how he arrived at 20 MB:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html.
I think he talks about it in a little more detail elsewhere. I inferred
from that that he wouldn't support 40 MB or 80 MB, but that may be wrong.

I should also have given credit to Pieter, as he even more explicitly
specified a level where he'd turn into a hard fork advocate, via his own
hard fork proposal. Neither of these statements specifies exactly where the
switch-over point is, but they're the closest I've seen.

> > 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.
>
> 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.
>

Don't you think the devs should have some rough plan that they discuss
ahead of time about what to do in the situation of high fees? Even if it
happened gradually -- suppose fees crept to 20 cents, then 50 cents, then
75 over the next year -- I don't think I've ever seen a discussion of how
that should be handled, and what sort of fees people regard as high enough
to justify considering a hard fork.

I think it would prevent many people from supporting an urgent hard fork if
they knew how the core devs would handle that situation (assuming there was
some willingness to increase the block size if fees got too high).

> > 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.
>
> [...]
> 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.
>

I see that 'special' feature of this market as more strongly supporting the
need to encourage fast adoption.

Let's say block rewards are $7000 per block, and we think this gives a good
level of security (as Bitcoin grows, we'll probably want a lot more).

Suppose a 1MB block can hold 2000 txns. Then to pay for the same level of
security we have right now with only tx fees, assuming 1 MB blocks, the
average tx fee would have to be $3.50. Now suppose blocks are 100 MB in the
future. The average tx fee is then only 3.5 cents. I think the former
situation will not actually work, and the only way that Bitcoin can survive
is to eventually get into something more like the later situation. Let me
know if you want me to delve into why. I'll just note that even Lightning
doesn't work well when tx fees are that high, because channels need to be
opened and closed pretty often and if my counterparty is uncooperative, his
making me pay $3.50 starts to actually hurt.

So if we accept that, we need to end up in a situation where we eventually
have lots of people making on-blockchain txns, and paying relatively small
fees. Encouraging lots of use and experimentation of Bitcoin between now
and then seems pretty important for reaching that goal.

We're in a race with the block reward halving schedule, to see if we can
get usage high enough to pay for security (while maintaining enough
decentralization) before all of the security burden falls on transactions.
If there aren't enough transactions at that time, the burden will be too
high (or security will be too low) and people will find other solutions.

We seem to disagree about how hard it'll be to change wallet and node
software to cope with a fee market. As I've said I don't see very small
nonzero fees (for instance one tenth of a cent) as a problem though. So if
a solution that traded off usage and decentralization in a way that I
agreed with could be modified to ensure a fee market developed soon with
very low fees, I'd still support it.

>
> > 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.
>
> 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
> adjusting
> > 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
> 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.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/b88fe9a2/attachment-0001.html>;

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T17:44:55+02:00

In reply to nevent1q…udx6
_________________________

📅 Original date posted:2015-08-06
📝 Original message:On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon at 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 around
> $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 = 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/6e7770c5/attachment-0001.html>;

📅 Original date posted:2015-08-05 📝 Original message:On ...

2023-06-07T17:44:50+02:00

In reply to nevent1q…2fwk
_________________________

📅 Original date posted:2015-08-05
📝 Original message:On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.

I don't think merely hitting the limit is bad. The level of tx fees in
equilibrium give some clue as to the level of harm being done. If fees are
at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

There is NO criterion based on mining centralization to decide between
> 2 sizes in favor of the small one.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
> I think its the proponents of a blocksize change who should propose
> such a criterion and now they have the tools to simulate different
> block sizes.
>

In the absence of harder data, it might be interesting to use these
simulations to graph centralization pressure as a function of bandwidth
cost over time (or other historical variables that affect centralization).
For instance, look at how high centralization pressure was in 2009
according to the simulations, given how cheap/available bandwidth was then,
compared to 2010, 2011, etc. Then we could figure out: given today's
bandwidth situation, what size blocks right now would give us the same
centralization pressure that we had in 2011, 2012, 2013, etc?

Of course this doesn't mean we should blindly assume that the level of
centralization pressure in 2012 was acceptable, and therefore any block
size increase that results in the same amount of pressure now should be
acceptable. But it might lead to a more productive discussion.

> I want us to simulate many blocksizes before rushing into a decision
> (specially because I disagree that taking a decision there is urgent
> in the first place).

IMO it is not urgent if the core devs are committed to reacting to a huge
spike in tx fees with a modest block size increase in a relatively short
time frame, if they judge the centralization risks of that increase to be
small. Greg Maxwell posted on reddit a while back something to the effect
of "the big block advocates are overstating the urgency of the block size
increase, because if there was actually a situation that required us to
increase block size, we could make the increase when it was actually
needed." I found that somewhat persuasive, but I am concerned that I
haven't seen any discussion of what the "let's wait for now" camp would
consider a valid reason to increase block size in the short term, and how
they'd make the tradeoff with tx fees or whatever else was necessitating
the increase.

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 around $5
for that year), would you be in favor of an increase to 4MB?

For those familiar with the distinction between near/far mode thinking
popularized by Robin Hanson: focusing on concrete examples like this
encourages problem solving and consensus, and focusing on abstract
principles (like decentralization vs. usability in general) leads to people
toward using argument to signal their alliances and reduce the status of
their opponents. I think it'd be very helpful if more 1MB advocates
described what exactly would make them say "OK, in this situation a block
size increase is needed, we should do one quickly!", and also if
Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
would make them want to stick with 1MB blocks for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/0913c1b2/attachment.html>;