Topic: Adjustable Blocksize Cap: Why not? - page 3. (Read 1392 times)

The scarce space is the "commodity" being sold in the fee market. If you increase and decrease the supply depending on your price, I doubt there will be any customers who will want to buy your product for long. Can you think of a commodity that acts this way except the commodities that have middlemen traders hoarding capacity? Are those the best examples of the kind of market we want a bitcoin fee-market to be?

This solution seems to fail on the simplest of economic model. Someone accustomed to actual financial modelling can comment better on this.

In addition, this also opens up a situation where people will be waiting and speculating on the transaction fees.

Isn't verification of target size limit a thing while producing blocks. How do you calculate the average transaction fee for the current block when you haven't decided the block size and hence the topmost transactions to keep in it? Or do you propose to just calculate all the fees in all the transactions in mempool?

So I assume that you haven't seen or attempted an implementation of this sort on a test net etc. That would be the best way to go i suppose.

That's not the only metric people use to measure the overall success of the network, though.  If, for example, BCH's nodecount dropped to single digits, I wouldn't care how many millions of transactions it could process per day.



If you can find a way to distinguish at protocol level between "natural growth" and "malicious growth", then let's hear it.  I get the part where encouraging a fee market is something many users are not fond of, but I see the sense behind it.  If something is valuable but there is very little cost to use it, people will simply abuse it.  That's just the nature of things.

As an analogy, I work in a call centre dealing with insurance.  I basically listen to people every day moaning about there being an administration fee to make changes to their car insurance policy.  None of them seem to grasp the fact that if there wasn't a fee, more people would call in more frequently to make superfluous changes.  Instead of paying the cost of adding a driver to a car insurance policy for the remainder of the policy term, you know some tightwads would be calling every other week to add a driver and then calling back a few days later to remove them again.  Then they'd tell their friends to do it because it would save them money and suddenly everyone is doing it.  People would take the piss if given the opportunity.  So if we didn't hire more staff, more customers would be stuck on hold for longer trying to get through to speak to someone.  The service would deteriorate and people would complain when they have something important or urgent to do and they can't even get through to us because the lines are jammed with skinflints.

Sometimes discouraging volume is the wiser course of action.


//EDIT:


My belief was that I was engaging with someone who understood the distinction between the number of nodes and the number of people transacting.  Someone who knew what SPV was.  Perhaps I was mistaken? 

Missed your post, but can you show source about exponential growth? What i know is only about quadratic growth verification time for certain signature, but SegWit already fix it.

Source : https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations


At least the number isn't entirely arbitrary picked.


The number you chose have some obvious problem, have you considered the possibility of
1. Miner mine 2 blocks at once, where the 2nd block usually are empty.
2. Analysis which shows certain days allows you move Bitcoin quickly with lower fees. See https://bitcointalksearch.org/topic/bitcoin-transaction-fees-in-satskb-sunday-saturday-are-best-to-move-btc-5250569.
3. Messing with various transaction fee estimation algorithm, which leads user pays too much or waiting too long.


You can't include external data without oracle or someone who you must trust.


Does that mean you found data used for BIP 103? I skimmed https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/thread.html#9763, but couldn't find any link of data supporting it.

“feel” exponential - this is something new in cost estimation.

My computer, bought 5 years ago, processes a new block in less than 1 second. a 10mb block will process less than 10 seconds. And blocks appear once every 10 minutes. The only expense is disk space. At 10MB block - 0.5 TB per year. 2tb. hard disk ~$ 60 and this is for 4 years. The cost per year is $ 15, per month ~ $ 1.2. And now that I make a modest 12 transactions a year, look at the size of the average fee, and estimate how much I have costs due to 1MB. block.

You understand that it is your "concern" for the user that only brings them extra costs.

Even if we take the more expensive option, together hdd ssd. 2tb ssd - ~ $ 240. Divide by 48 months - $ 5 per month. The fee for one transaction per month is about the same level, and I will not pay this fee. That is, I will be at the same level in terms of costs. But in return, I get a 10-fold increase in the Bitcoin system. (10x! , Karl).

You are more careful with your desires. If the Bitcoin Cache develops to the point that users will make 2.5 million transactions a day, and bitcoin will remain at its 350 thousand, then I do not think that this is a a good outcome for Bitcoin..

People call it linear growth or O(n)

Sorry, I’m wrong. Growth will not be exponential, BUT a one time block size increase to 10MB, and with current Bitcoin on-chain usage keeping those blocks full, would make each node process 10 times the data, and make it “feel” exponential. I want to see Bitcoin Cash’s blocks full, everyday, for a whole year.

Good.

No. Unfortunately such a switch for miners neither by going solo (because of the variance) nor even by joining honest pools (at least fast enough, and again because of the variance) is practical.

YES! It'd be so better if you haven't made the comment before this one, what a waste.


P.S.
I was following Greg's sent merits, just like a normal stalker   noticing that he has merited this post. Now, I'm confused:
Which part of the post deserves big Maxwell's appreciation?

It'll be a total surprise, actually the second in the last couple of weeks, if it turns out to be the right part, Because @gmaxwell has not been there for a LONG time, though, it isn't too late, and he is making moves, IMHO.

It's about 1.29x higher in ETH! Although fees are computed differently in ethereum but working with raw bytes and amount paid we have

____________________	ETH	BTC
Average tx size in kBytes	0.230	0.707
Average tx fee	0.005500000	0.00042000
fee/byte	0.000023910	0.00000059
fee/byte in USD	$0.029	$0.022
Ratio	1.29

I’ll stop you there. Full node hardware, and bandwidth requirements plus costs won’t increase as the block size increase? Then explain Ethereum. It’s simply a common-sense statement. The proof is all there, plain for you to see.

isn't it because ETH tx is much smaller(roughly 1/3 bitcoin tx)? the Fee/byte is still roughly the same

---

https://bitcoin.stackexchange.com/questions/43675/why-do-bigger-blocks-make-it-more-expensive-to-run-a-full-node

The miners could make blocks look full with their own fake transactions that appear to pay high transaction fees, and leave only a small number of actually paying transactions outstanding. This would make it appear the market transaction fee rate is higher than it actually is.
Correct. A miner with a small percentage of total mining capacity could potentially broadcast valid spam transactions, and end up with more mining revenue after accounting for the transaction fees from the spam transactions.

It is an arbitrary figure, and I haven't studied the data supporting it. I would prefer that the rate be too high than too low. If the rate is too high, a soft fork can be implemented to reduce the rate, but if it is too low, a hard fork would be required. It is much easier, almost trivial, to implement a soft fork, while a hard fork is at least an order of magnitude more difficult.

I never agree with the number (plan next 40+ years or 17.7% as average growth rate), but the idea of BIP 103 isn't bad and more likely accepted considering Bitcoin community care about running full node at low-cost.
Besides, comparing predicting Bitcoin price and predicting computer/internet growth are like comparing apples and oranges.


If you want to call it proposal, there are many missing technical details,
1. What's the reason behind 0.1MB as min and 10MB as max?
2. How many previous block should be considered to calculate average transaction fee?
3. How often should block limit changed?
4. Do you have proposed formula/logic/code to set block size? Here's a very quick example of mine

There's is the cost of running a full node but there's also the cost of making an on chain transaction which seems to go up as btc gains in popularity. My point is just that it's still too early to plan on the long term. We should try new stuffs and learn from our mistakes, it's the only way we can improve a new tech such as btc.


I think we're making progress here. Ok, let's just call it an idea for now.. I'll answer your questions.

1. What's the reason behind 0.1MB as min and 10MB as max?
The transaction fees will eventually be the only source of income for the miners so we need a system that will force the user to "tip the miner" but which will also allow more block space for peak periods. A 10MB limit seems reasonable, the max yearly storage space that could be required would be approximately 0.5TB. A 0.1MB min gives enough space for most transactions.
2. How many previous block should be considered to calculate average transaction fee?
One.
3. How often should block limit changed?
On every block.
4. Do you have proposed formula/logic/code to set block size?
No. We can discuss it first then move on to the next step. I will review your codes..



Ok so I'll bring some modifications since we didn't agree on everything..

//n  is the block size limit formula
I = old avg transaction fee
I+ = new avg transaction fee
N = old block size limit
N+ = new block size limit
n = N * I+ / I

If n <= 0.1 then
N+ = 0.1

else
N+ = n

else if n >= 10 then
N+ = 10

The logic is there. I think that an immediate adjustment to the change in price would be the best...

As I was saying, exactly the thing I've mentioned.
I shouldn't compare the maximum 80kmh/ Trabant with a Ferrari because the Ferrari is parked.

But be it like you, next time a spike of 40$ for one transaction will happen be there and tell people it makes no sense to use Doge as it is theoretically possible for transactions on the Doge chain to cost the same.
Have fun telling people that you can fit 5l of water in a 2 littler bottle just as good as you can in a 10l bucket as it is "theoretically possible" that your 2 liters of water is actually milk and the first bottle is a can making the whole comparison impossible since we don't have the correct circumstances.


And with an x3 lower average fee which you successfully managed to omit from the equation.

I understand your moderate position.
I just can't figure out how moderate growth is better than natural growth. After all, your moderate growth implies an artificial restriction of growth. Questions appear. What for? We tell users: some of your transactions are unworthy to get into the blockchain. What do we gain by throwing out some part of the transactions? My answers to these questions are: nothing. Only slowing down the development of Bitcoin.

Unfortunately, this is simply not true. Another statement without proof.
However, users of bitcoin forums constantly use expressions such as"decrease/increase centralization/decentralization". Even bitcoin developers don't hesitate to use these expressions. Although they must have an engineering mindset.
And it's amazing! How can you claim a decrease/increase in some indicator if you do not know how to measure this indicator, if you have not determined how to measure it? This is nonsense.

Would we really be able to apply "meters" to decentralization?

For a given payment system: there are middlemen present, or they are not.
It's a binary phenomenon...

In other words, it can only be that:
1) you have the freedom to send funds to any person you choose, receive funds from anyone who chooses to send them to you, or hold funds for as long as you see fit
or,
2) you do not have this freedom.

So, for me, the factors that are important for maintaining decentralization (we assume that Bitcoin is decentralized) is the same class of factors as those describing the chance of death while performing certain activities.

Since life/death is also a binary phenomenon, and at the stake here is the loss of something indisputably valuable.

We could try to use the language/the tools of statistics here, most probably.

With 10MB blocks, costs of running a node would increase exponentially. The node operator would stop running the node eventually, centralizing the network. That’s not “scaling”. Scaling is to increase transaction-throughput without sacrificing decentralization.


"on network latency" - unsubstantiated. If you just take the calculator and take the block size of 10mb, you will see that there is no problem with this. But you didn't make any calculations, you don't need to know the truth. You need to refute the possibility of increasing the block by any effort.
"network security" - unsubstantiated.
"costs in the network transfers from the miners to the nodes" - unsubstantiated.

And you say:None of it is “pseudo-statements”.
I've been waiting for this. Pseudo-arguments such as "disk size, processor power, RAM, internet speed, etc." come to an end.
Then there is the main argument of "the increasing centralization (reduction of decentralization)".

So, for newbies. (since there is a tradition to address newbies.). When the arguments "increasing centralization (decreasing decentralization)" appear, then the constructive discussion ends. Because these statements "increasing centralization (decreasing decentralization)" are usually presented as self-sufficient. For some reason, it is considered that it is not necessary to provide any evidence.

If my opponent wanted to confirm his words with evidence, then he should have provided:
1) How it measures the level of centralization (decentralization).
2) What is the level of centralization (decentralization) now, at 1mb block.
3) What is the level of centralization (decentralization) will be if we increase the block, for example, to 10MB.