About block size limit and transactions fees

[topcoin360]

Hi guys,

I've noticed that the transactions fees went down since a couple of weeks which I think is a good thing (but maybe not for the miners ). I thought that it might be a good time to talk about the block size limit (just an open discussion about the different options that we have). Of course we could keep the block size limit to 1MB and try to increase the network's throughput by optimizing the codes which I don't think is the best option (I must apologize to the dev team but it seems like technological progress is outperforming your work ). So I thought about something and I'd like to see what you've got.

Just like we have a DAA to maintain the block time at 10 min, we could have a dynamic block size limit algorithm to maintain the transaction fee at 1%. So basically..

If the avg transaction fee is greater than 1% then the block size limit increases;
If the avg transaction fee is lower than 1% then the block size limit decreases;

To make our calculation we would assume that the total amount of the transaction fees remains constant and that the total amount being transferred is proportional to the block size limit (we could optimize the formula if needed). The adjustment would be done every 2,016 blocks.

I'm obviously just brainstorming here. Anything you don't like about this idea or any other suggestion?

[1714632849]

1714632849

[1714632849]

1714632849

[1714632849]

1714632849

[1714632849]

1714632849

[NeuroticFish]

to maintain the transaction fee at 1%. So basically..

Sorry, but I have bad news for you. Tx fee is not related to the amount of coins transacted. One can easily pay for 100 BTC transferred less than another for 0.001 BTC. The tx size in bytes is the one that matters and I find in nowhere in your equation.
"So basically"... all you wrote is completely off and worthless.

[Wind_FURY]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

[topcoin360]

to maintain the transaction fee at 1%. So basically..

Sorry, but I have bad news for you. Tx fee is not related to the amount of coins transacted. One can easily pay for 100 BTC transferred less than another for 0.001 BTC. The tx size in bytes is the one that matters and I find in nowhere in your equation.
"So basically"... all you wrote is completely off and worthless.

May I ask are you in the dev team?

Firstly, yes it is. The fee that the sender is willing to pay depends on the amount he is transferring.
Secondly, the block size limit have a direct impact on transaction fees for obvious reasons.

So basically, what exactly is your argument?

[ranochigo]

Total fee that a transaction pays is dependent on the size, so it doesn't make sense to peg it to the avg TX fees. You would probably be looking to peg it to the fee rates, but that is assuming that it doesn't get manipulated by miners intentionally including smaller fee TXes or vice versa.

I don't think a dynamic block size really matters. It would be far more prudent to increase the current block size than have to add additional mechanisms to regulate the block size. We're talking about block limits, so if there isn't enough transactions to include, then there is no need for the blocks to at their limits.

[topcoin360]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

I fail to see what would be the incentive to launch this kind of attack as the attacker can't generate more income or reverse a transaction by increasing the block size limit.

Total fee that a transaction pays is dependent on the size, so it doesn't make sense to peg it to the avg TX fees. You would probably be looking to peg it to the fee rates, but that is assuming that it doesn't get manipulated by miners intentionally including smaller fee TXes or vice versa.

I don't think a dynamic block size really matters. It would be far more prudent to increase the current block size than have to add additional mechanisms to regulate the block size. We're talking about block limits, so if there isn't enough transactions to include, then there is no need for the blocks to at their limits.

You need 51% of the network's hashrate to manipulate the block chain. A miner with 51% of the hashrate could already manipulate the transaction fees.

[ranochigo]

You need 51% of the network's hashrate to manipulate the block chain. A miner with 51% of the hashrate could already manipulate the transaction fees.

No miners would intentionally re-org blocks, that is quite stupid. With your proposals, certain miners can influence the size of the blocks for the next epoch for whatever reason they'd like. But the point of my post is more about why should we use a dynamic block size instead of a fixed block size increment? It doesn't necessarily bring any benefits either as using a larger sample size only serves to delay the block size change... It would be quite possible that the larger block size wouldn't be required after the block size changes.

[HeRetiK]

Firstly, yes it is. The fee that the sender is willing to pay depends on the amount he is transferring.
Secondly, the block size limit have a direct impact on transaction fees for obvious reasons.

The fee a sender is willing to pay may depend on the amount they are transferring, but that's irrelevant for the protocol. How low you can set your fee and still have your transaction be included within a reasonable time depends on how many inputs are being spent, not on how many coins. So if you received a lot of small transactions you'll pay a much higher fee for the same amount of coins than if you received just one large transaction.

Of course we could keep the block size limit to 1MB [...]

Block size limit has been effectively 2-4MB since SegWit's activation in 2017.

--

The problem with dynamic block size limits is that in the end it's pretty much like having no block size at all.

Reducing blocksize limits in times of low demand will do nothing but artificially increase mining fees without saving any storage space -- the blocks would have been half empty anyways.

Increasing blocksize limits in times of high demand, based on the amount of fees paid relative to the amount being sent, would not only inflate the blocksize to whatever upper bound you'd define for the dynamic blocksize range -- which would in practice end up us the blocksize limit anyway -- you'd actually even penalize efficient transactions over inefficient ones (e.g. transactions consisting of a lot of small inputs like faucet rewards and thus take up a lot more blockspace). That is, you'd have a system that would incentivize detrimental behaviour which is rarely a good idea for something that is supposed to be self-regulating.

Also note that due to the use of change addresses it's not even possible to reliably determine the amount that is being sent. If I spend USD 10,- worth of Bitcoin with USD 90,-worth of Bitcoin going back to a change address, your proposed system would have to base the fee on the total of USD 100,- being moved.

[BlackHatCoiner]

If the avg transaction fee is greater than 1% then the block size limit increases;
If the avg transaction fee is lower than 1% then the block size limit decreases;

Please be more explanatory; 1% of what? Of the transacted amount? Of the block size? In this case, 0.065 BTC? There are lots of factors involved when you have to make such change, especially if we include Segwit and other ways to reduce your transaction's size. I think that this way, the miners will prefer some transactions despite on the fee they're paying.

I have to agree with ranochigo for the block size.

[vjudeu]

to maintain the transaction fee at 1%

That's far more expensive than today! Even in LN there are nodes where you can pay 0.1% or where you can pay one satoshi per transaction. Someone having 1 BTC in a single UTXO will pay 0.01 BTC in your proposal, but transaction size could be less than 1 kB, that means over 1000 satoshis per byte!

Edit: more than that: in your proposal that would mean everyone will have a huge incentive to use as many UTXO's as possible! Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

[pooya87]

So basically, what exactly is your argument?

Bitcoin fees are designed to work based on transaction size and not the amount. This can not change without changing everything else about bitcoin too (eg. change UTXO based to account base). Without making these fundamental changes you'd introduce easy attack vectors. For example I can create a single 4 MB weight transaction that has a small value and pays a small fee in order to fill a single block and continue that for every block.

[HeRetiK]

Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

To be fair, this loop hole would be mitigated by the current dust limit of 546 satoshis. However I'm not entirely sure whether the dust limit is wallet dependent or actually part of the protocol consensus?

Great catch though! Without a dust limit, given this fee system one would be able to DDoS Bitcoin for free.

[vjudeu]

However I'm not entirely sure whether the dust limit is wallet dependent or actually part of the protocol consensus?

It's only checked at mempool level. If you are a miner, you can send single satoshis. More than that: you can send zero satoshis, you can have a lot of inputs and outputs transferring from zero to zero satoshis and it will be valid if included in a block, but rejected if sent to other miners (unless they change their configuration to accept free transactions).

Dust limit is not consensus rule, it is only artificially set as default to one satoshi per byte for mempools, any miner can turn that off.

[Wind_FURY]

OP, but what mechanism would you propose to protect the network from the entities that would flood the mempool to increase the fees, and therefore, according to your proposal to maintain 1%, would increase the block size so much that many of the nodes that do not have the hardware and the bandwidth will not have the ability to keep up?

I fail to see what would be the incentive to launch this kind of attack as the attacker can't generate more income or reverse a transaction by increasing the block size limit.

That still doesn’t mean that it couldn’t happen. For Bitcoin, currently being a network with over a $trillion in market capitalization, the developers should NEVER risk and give any way for bad actors to exploit and disrupt the system. The network should be FULL PROOF as possible.

[topcoin360]

The fee a sender is willing to pay may depend on the amount they are transferring, but that's irrelevant for the protocol. How low you can set your fee and still have your transaction be included within a reasonable time depends on how many inputs are being spent, not on how many coins. So if you received a lot of small transactions you'll pay a much higher fee for the same amount of coins than if you received just one large transaction.

Absolutely but the idea is to keep the fee at 1% on average, the percentage could vary from one transaction to another one.

Block size limit has been effectively 2-4MB since SegWit's activation in 2017.

--

The problem with dynamic block size limits is that in the end it's pretty much like having no block size at all.

Reducing blocksize limits in times of low demand will do nothing but artificially increase mining fees without saving any storage space -- the blocks would have been half empty anyways.

Increasing blocksize limits in times of high demand, based on the amount of fees paid relative to the amount being sent, would not only inflate the blocksize to whatever upper bound you'd define for the dynamic blocksize range -- which would in practice end up us the blocksize limit anyway -- you'd actually even penalize efficient transactions over inefficient ones (e.g. transactions consisting of a lot of small inputs like faucet rewards and thus take up a lot more blockspace). That is, you'd have a system that would incentivize detrimental behaviour which is rarely a good idea for something that is supposed to be self-regulating.

Also note that due to the use of change addresses it's not even possible to reliably determine the amount that is being sent. If I spend USD 10,- worth of Bitcoin with USD 90,-worth of Bitcoin going back to a change address, your proposed system would have to base the fee on the total of USD 100,- being moved.

As you mentioned, there is a min fee that the sender has to pay to have his transaction included in a block. That min fee is determined by supply and demand, with an inelastic supply like we have right now there is no way to control that fee which is IMO problematic.

--snip--

Please be more explanatory; 1% of what? Of the transacted amount? Of the block size? In this case, 0.065 BTC?

I meant the transacted amount of all the transactions combined.

to maintain the transaction fee at 1%

That's far more expensive than today! Even in LN there are nodes where you can pay 0.1% or where you can pay one satoshi per transaction. Someone having 1 BTC in a single UTXO will pay 0.01 BTC in your proposal, but transaction size could be less than 1 kB, that means over 1000 satoshis per byte!

Edit: more than that: in your proposal that would mean everyone will have a huge incentive to use as many UTXO's as possible! Even worse: transactions for outputs containing less than 100 satoshis would be free! So, someone having 1 BTC could pay 0.01 BTC once to split that into 99 satoshi outputs and then create as many free transactions as he want, bloating blockchain size all the time!

You probably misunderstood what I said, the goal is to keep the avg fee to 1%, the block size limit is adjusted every 2,016 blocks to meet that target. I'm not proposing to force the user to pay a 1% transaction fee, I'm not even proposing to change the fee structure.

The idea of dynamic block size already proposer and rejected few years ago. But if community willing to accept dynamic block size (with specific upper/lower limit), i prefer something like BIP 104 or 106 which configure block size limit based on past block size.

We can discuss about this as well...

That still doesn’t mean that it couldn’t happen. For Bitcoin, currently being a network with over a $trillion in market capitalization, the developers should NEVER risk and give any way for bad actors to exploit and disrupt the system. The network should be FULL PROOF as possible.

Absolutely, we would have to run a series of test to see if it works and if it is safe. If you have a better idea then you're welcome to share it, we are here to talk.

[garlonicon]

You probably misunderstood what I said, the goal is to keep the avg fee to 1%

There is a way to check if that's cheaper than today or not. You can get total fees in a block by looking at coinbase transaction. You can add all outputs to know how many coins are transferred. And then, you can calculate 1% of all moving amount in that block and compare that to the current fees. So, what can you see?

Also note that changing fees is possible without any fork or things like that, all you need is just some solo miner or pool with a different rules. You can simply run some node, invoke "getblocktemplate" and get some data in that way without mining anything, just by using your CPU, then you will know how it looks like when compared with the current system.

Also notice that if your proposal makes things cheaper for users, then miners have no incentive to use that and lower their profits. But if your proposal is more expensive than today, then miners of course could switch to that, but users will reject your nodes and use currently existing ones or just switch to LN and avoid your on-chain fees (or they simply won't create many channels with you if you want to force that inside LN). Either way, you need some arguments to convince someone who will be at a loss why the currently existing system should be changed to bring your proposal into reality.

Edit: even better, you can just look at blockchair and see that without any coding or running your own nodes, they have such data: https://blockchair.com/bitcoin/blocks?#f=id,output_total,fee,fee_usd,reward

Code:

+-------------+-------------------+-----------+-------------+
| blockNumber | transferredAmount | totalFees | yourFees    |
+-------------+-------------------+-----------+-------------+
| 694,347     |   600.72 BTC      | 0.02 BTC  |  6.0072 BTC |
| 694,346     | 5,152.17 BTC      | 0.11 BTC  | 51.5217 BTC |
| 694,345     | 7,152.26 BTC      | 0.16 BTC  | 71.5226 BTC |
| 694,344     |   950.63 BTC      | 0.05 BTC  |  9.5063 BTC |
| 694,343     |   485.70 BTC      | 0.00 BTC  |  4.8570 BTC |
+-------------+-------------------+-----------+-------------+

Well, I don't want to pay 1% for my transaction, by looking at the last N blocks you should know why.

[hosseinimr93]

I'm not proposing to force the user to pay a 1% transaction fee,

vjudeu is right.
You are trying to keep the average transaction fee at 1% of the average transacted amount. With this proposal, people will have to pay 1% of the transacted amount on average to be able to compete with other people and get confirmation.

Let's say you have succeeded to keep the transaction fee at 1% of the average transacted amount.
In the next block, there are 100 transactions. Each of them is 200 bytes and transacts 1 BTC. Note that it will be impossible to get confirmation if I pay less than 0.01 BTC as transaction fee.

And what if I have a UTXO of 1 BTC and I want to send 0.001 BTC to someone and the remainder to my change address?
I will have to pay 0.01 BTC for sending 0.001 BTC.

[DannyHamilton]

The protocol already allows solo-miners (and mining pools) to choose to ignore transactions with small value and only include high value transactions in their blocks. This is fine when there are enough high-value transactions to fill a block (which provides an incentive for all users to increase their fees or to not create their transaction).  However, when there are not enough high-value transactions to fill a block, the solo-miner (or mining pool) needs to decide... Is it better to just create a smaller block and ignore the low-value transactions? Or is it better to include those low value transactions in the block to increase revenue?

Ignoring the low-value transactions will cause the average transaction fee per byte to increase a bit on future transactions since there will be an increase in total transactions waiting to be confirmed.  However, it reduces your total revenue on that particular block and gives your competitors (other solo miners and pools) the opportunity to increase their revenue faster than you since they can pick up those fees you left out.

Including those low-value transactions increases your total revenue on that specific block, and reduces the opportunity for your competitors to increase their revenue, for the same reasons. However, it reduces the average transaction fee per byte on future transactions, since there are less transactions waiting to be confirmed.

These competing incentives are self-regulating and drive the fee to be whatever the market will support.  There isn't a lot of opportunity for any single solo-miner or mining pool to manipulate this without suffering losses from the attempt.

Now, instead of allowing a miner (or pool) to create a smaller block of their own when they want to, if wee were to FORCE the block size limit to be smaller... Then it opens up a big opportunity for manipulation.  Large scale solar miners (or worse yet, mining pools) could include a single VERY small transaction in every block that they create which pays to themselves the ENTIRE bitcoin balance that they have control over and include 0 fee.  This very tiny (in terms of bytes) huge value transaction with no fee at all will skew the "average fee" for the block so that it falls significantly below 1%.  This would force the protocol to shrink the block size for ALL miners in the future (not just the miner that creates the block).  As such, the malicious miner performing this attack doesn't lose as much revenue overall (since the other blocks won't be able to pick up as many of the remaining transactions) AND it punishes those miners (and pools) that are NOT participating in the attack, since their revenue is now limited.  Furthermore, since the total size of the block is reduced, it is even easier for the attacker to reduce the size even more.  His single high-value transaction is now a greater percentage of the total value transacted in the block.  Therefore he can repeat his attack over and over until he forces EVERY transaction to pay a fee of nearly 1% of all the bitcoin he has control over!

[topcoin360]

--snip--

Also notice that if your proposal makes things cheaper for users, then miners have no incentive to use that and lower their profits. But if your proposal is more expensive than today, then miners of course could switch to that, but users will reject your nodes and use currently existing ones or just switch to LN and avoid your on-chain fees (or they simply won't create many channels with you if you want to force that inside LN). Either way, you need some arguments to convince someone who will be at a loss why the currently existing system should be changed to bring your proposal into reality.

Absoluletly, I think 1% is affordable for most people (and cheaper than most other options like Visa). If you make large transactions then your avg fee will be less than 1% but if you make small transactions then your avg fee will be more than 1% which is not unfair considering the space you're using. Maybe collectively we'd be paying a little more or a little less, after all miners need to get paid to secure the network right?  

--snip--

Ignoring the low-value transactions will cause the average transaction fee per byte to increase a bit on future transactions since there will be an increase in total transactions waiting to be confirmed.  However, it reduces your total revenue on that particular block and gives your competitors (other solo miners and pools) the opportunity to increase their revenue faster than you since they can pick up those fees you left out.

As I responded to Wind_FURY, I don't see what would be the incentive for a miner to play with the block size limit (assuming they have enough hashrate to do that);

If they increase the limit then the transaction fees will go down.
If they decrease the limit then the transaction fees will go up but they can validate fewer transactions.

In any case, they are not guaranteed a higher income and their competitors can still validate the next block, the avg transaction fee should sooner or later reach 1% no matter what is the volume of transactions on the network.

[PrimeNumber7]

As I responded to Wind_FURY, I don't see what would be the incentive for a miner to play with the block size limit (assuming they have enough hashrate to do that);

If they increase the limit then the transaction fees will go down.
If they decrease the limit then the transaction fees will go up but they can validate fewer transactions.

If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.

As Danny explained, a miner can send a large (in terms of value) transaction to himself with zero transaction fee, effectively lowering the average transaction fee for that block at a very low cost.

If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease. This would make the mechanism for changing the block size to be consistent with how transactions are priced today. It would also make the manipulation as described by Danny less effective, although said manipulation would still be possible, as a miner could fill 30% of his block with zero-fee transactions to himself (or with transactions whose on-chain fee is zero, one party to the transaction has paid the miner via some off-chain means).

[Wind_FURY]

That still doesn’t mean that it couldn’t happen. For Bitcoin, currently being a network with over a $trillion in market capitalization, the developers should NEVER risk and give any way for bad actors to exploit and disrupt the system. The network should be FULL PROOF as possible.

Absolutely, we would have to run a series of test to see if it works and if it is safe. If you have a better idea then you're welcome to share it, we are here to talk.

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

[topcoin360]

--snip--
If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.[...]

In this case the network's hashrate will increase and it will be harder to maintain the attack. If the avg fee goes above 1% then the block size limit will increase in the next epoch.

If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease.

The problem with this proposal is that we don't know the real value of the fee, if the price of btc is high then the fee will be too expensive, if the price of btc is low then the price per vByte will be too low, we can determine a percentage but we can't determine btc's price.

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

Didn't say any of that, I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

[Wind_FURY]

Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.

Didn't say any of that,

That I’m the stupid one? I said it, and I don’t mind if I am. Believe me. Haha.

I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

I believe you should do a thorough research of the counter-arguments in why those ideas are “not being pursued” first, before assuming that they were feasible ideas but ignored ideas.

Plus how would you define scaling. I’m curious.

[PrimeNumber7]

--snip--
If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.[...]

In this case the network's hashrate will increase and it will be harder to maintain the attack. If the avg fee goes above 1% then the block size limit will increase in the next epoch.

There is nothing in this scenario that would cause the network hashrate to increase on its own. You are describing this as an attack, however it is something that would benefit all miners. As such, there is little reason why all miners would not participate via a cartel (something similar to how OPEC works for the oil markets).

If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease.

The problem with this proposal is that we don't know the real value of the fee, if the price of btc is high then the fee will be too expensive, if the price of btc is low then the price per vByte will be too low, we can determine a percentage but we can't determine btc's price.

The price of transaction always has been, and always will be measured in terms of BTC. If the price of BTC is too high, the market will respond accordingly.

I would also point out that your 1% transaction fee target is very high, even by traditional banking system standards. The cost of sending a wire transfer is at most $15 or $25 (if not waived), but it would be very unusual for someone to send a $2500 wire transfer. It is far more common for someone to send a six-figure wire transfer. It might cost $0.20 to write a check, but it would be very unusual to write a check for $20.

[topcoin360]

I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Writing a BIP is something I might consider...

I believe you should do a thorough research of the counter-arguments in why those ideas are “not being pursued” first, before assuming that they were feasible ideas but ignored ideas.

Plus how would you define scaling. I’m curious.

Scaling is increasing the currency's utility by allowing more people to make transactions or allowing people to make more transactions.

The equation I found may not be accurate but I'll explain my reasoning;

If we assume that the user base is not going to change much in the short term AND people's habits are not going to change much in the short term then;

a) the volume of transactions on the network is proportional to the block size limit.

b) the price people are willing to pay to make a transaction when the limit is reached stays the same.

I'd rather have 10 persons running a full node and sharing the cost then have thousands of people using some third party services to make their transactions. As of now, the size of the block chain is controlled by a limit on the block size and by the level of difficulty to mine a block, the value of the second paramater can change depending on the network's hashrate but the value of the first paramater can't change because of the risk of a consensus problem. The system we have now benefits to speculators but does not benefit to the real users of the currency, if bitcoin isn't used as a medium of exchange then sooner or later the price of the coin will drop down to zero (or it will fall drastically to it's true value).

Using percentage also flawed since block reward changed every 4 years.

In my view the inflation is a flat fee that is charged to the hodlers, it won't affect you if you don't hold your coins.

The price of transaction always has been, and always will be measured in terms of BTC. If the price of BTC is too high, the market will respond accordingly. [...]

If btc's price is high then everyone has more money to outbid each other so I believe that the transaction fees may also increase (on top of that people tend to make more transactions when the price is high)...

I would also point out that your 1% transaction fee target is very high, even by traditional banking system standards. The cost of sending a wire transfer is at most $15 or $25 (if not waived), but it would be very unusual for someone to send a $2500 wire transfer. It is far more common for someone to send a six-figure wire transfer. It might cost $0.20 to write a check, but it would be very unusual to write a check for $20.

For someone who wants to move funds around the world OUTSIDE the banking system I think 1% is a good price.

[ranochigo]

I'd rather have 10 persons running a full node and sharing the cost then have thousands of people using some third party services to make their transactions. As of now, the size of the block chain is controlled by a limit on the block size and by the level of difficulty to mine a block, the value of the second paramater can change depending on the network's hashrate but the value of the first paramater can't change because of the risk of a consensus problem. The system we have now benefits to speculators but does not benefit to the real users of the currency, if bitcoin isn't used as a medium of exchange then sooner or later the price of the coin will drop down to zero (or it will fall drastically to it's true value).

Unfortunately, that isn't what majority of the community wants. There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

There is nothing wrong with increasing the block size to increase the on-chain capacity. However, if you want to achieve mass adoption and surpass that of the major banking systems, you can't do it without making it impossible for the average joe to run a node. There is no way this should ever happen, because we'll be at the mercy of whoever is running the few nodes.

I briefly read through the topic again. Are you still proposing a complicated dynamic block size as opposed to a simple and linear block size increase?

[dkbit98]

There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

Great explanation by @ranochigo and confirmation of this words can be seen with forks that tried to make ''better'' bitcoin and instead created more centralized junk.
For example, 3 mining pools (ViaBTC, AntPool and one more) for Bcash are having over 75% of total hashrate, and situation is even worse for bsv scam with 2 mining pools controlling all hashrate, and they are constantly under 51% attacks.
We can at least thank all those forks that serve more as testing ground so we can see what effect it could have on Bitcoin and what we should avoid doing.
It's not impossible to imagine that block size will also change for Bitcoin in future, but it must be carefully implemented after doing deep investigation as a part of some bigger change, but result will be new forks and I think that people are a bit tired of forks.

[topcoin360]

Unfortunately, that isn't what majority of the community wants. There is nothing wrong with increasing block size, but if you were to increase to that extent, then no one except a selected few can run a node because they are prohibitively expensive. Miners can only mine if they're fast enough, which would mean further centralization as they need to achieve the lowest latency possible to reduce orphans. Complete centralization of Bitcoin defeats the very purpose of it, and putting the control of it to a selected few only serves to discourage people from using it.

My apologies, I think you missed the point I was trying to make and it's probably because I did a spelling mistake. Here is the correction..

I'd rather have 10 persons running a full node and sharing the cost than have thousands of people using some third party services to make their transactions.

So what I was trying to say is 10 persons sharing the same computer is more decentralized than thousands of people using the same server. I think the majority of the community would agree with that.

I briefly read through the topic again. Are you still proposing a complicated dynamic block size as opposed to a simple and linear block size increase?

I'm still not convinced, what is your vision?

so yes fee's will be cheaper per transaction.. but the total the pool gets will be more

I agree with you but I also think that the size of the block chain should automatically adjust to the need of its users.

[ranochigo]

So what I was trying to say is 10 persons sharing the same computer is more decentralized than thousands of people using the same server. I think the majority of the community would agree with that.

Correct.

I'm still not convinced, what is your vision?

I'm against a dynamic block size because it fails to take into account the possibility of the miners intentionally colluding and manipulating the fee market, by either introducing scarcity or otherwise intentionally gaming the block size. Problem with dynamic block size is that it is difficult to accurately provision higher block size for the correct period, due to time lag mainly as the sample size is way too huge.

I would rather just proposing a predictable block size increase, than to have a dynamic block size because it is honestly quite redundant. I don't expect Bitcoin to survive solely on on-chain transactions, that isn't feasible.

[topcoin360]

I'm against a dynamic block size because it fails to take into account the possibility of the miners intentionally colluding and manipulating the fee market, by either introducing scarcity or otherwise intentionally gaming the block size. Problem with dynamic block size is that it is difficult to accurately provision higher block size for the correct period, due to time lag mainly as the sample size is way too huge.

I'd like to remind you that any miner with a lot of hashrate can inflate the fees by choosing to not pick the transactions that pay a low fee. It is actually easier for a miner to do that with an inelasic supply, if the supply was elastic then inflating the fees would also increase the block size limit which would ultimately reduce the fees (it would then be pointless to inflate the fees in the first place).

I would rather just proposing a predictable block size increase, than to have a dynamic block size because it is honestly quite redundant. I don't expect Bitcoin to survive solely on on-chain transactions, that isn't feasible.

I see but what factor would you take into account to calculate the block size limit? I believe bitcoin can only survive with on chain scaling but that's another topic...

[ranochigo]

I'd like to remind you that any miner with a lot of hashrate can inflate the fees by choosing to not pick the transactions that pay a low fee. It is actually easier for a miner to do that with an inelasic supply, if the supply was elastic then inflating the fees would also increase the block size limit which would ultimately reduce the fees (it would then be pointless to inflate the fees in the first place).

Hmm, okay I understand your argument on this.

I see but what factor would you take into account to calculate the block size limit? I believe bitcoin can only survive with on chain scaling but that's another topic...

The ideal block size should be something that still ensures that the network is sufficiently secure. It makes no sense for us to implement a dynamic size, where the size gets inflated to unrealistic limits at times just to accommodate the extra transactions. It would be far better for us to determine the specific and appropriate block size from the on-start because there isn't any downsides to that. If the demand isn't enough, then the blocks would naturally be smaller.

[topcoin360]

The ideal block size should be something that still ensures that the network is sufficiently secure. It makes no sense for us to implement a dynamic size, where the size gets inflated to unrealistic limits at times just to accommodate the extra transactions. It would be far better for us to determine the specific and appropriate block size from the on-start because there isn't any downsides to that. If the demand isn't enough, then the blocks would naturally be smaller.

I get your point but as franky1 pointed out it may not be worth the hassle of running a full node if you do not make a lot of transactions, you may in this case use some third party services to verify your transactions. If you do make a lot of transactions then you could as well pay a lower fee on your transactions and spend more money on your storage/bandwith. I want to emphasize the fact that the cost for a full node can be shared between multiple persons, however the cost of a transaction can hardly be shared so transaction fees may have a bigger impact on centralization than the cost of running a full node.

That said, I just verified the avg transaction value on https://bitinfocharts.com/bitcoin/. It says it was approx. 71,125USD in the last 24h, the avg transaction fee was 2.44USD. For now I think your proposal makes more sense...

[PrimeNumber7]

There is no technical reason why miners need to receive transaction fees via transactions themselves. This is not very common, but pools could offer "account holders" to deposit coin, and have their account balance deducted whenever the pool confirms a customer's transaction. In this case, the pool would be confirming a lot of transactions that have zero fees attached, but the pool is actually receiving transaction fees via out-of-band transactions. Miners could even require transaction fees to be paid this way.

The above would make a dynamic block size based on transaction fees attached to transactions useless.

[ranochigo]

I get your point but as franky1 pointed out it may not be worth the hassle of running a full node if you do not make a lot of transactions, you may in this case use some third party services to verify your transactions. If you do make a lot of transactions then you could as well pay a lower fee on your transactions and spend more money on your storage/bandwith. I want to emphasize the fact that the cost for a full node can be shared between multiple persons, however the cost of a transaction can hardly be shared so transaction fees may have a bigger impact on centralization than the cost of running a full node.

That said, I just verified the avg transaction value on https://bitinfocharts.com/bitcoin/. It says it was approx. 71,125USD in the last 24h, the avg transaction fee was 2.44USD. For now I think your proposal makes more sense...

I'm far more concerned about the security of the network being impacted, instead of the issue surrounding the costs of a full nodes. In this day and age, most people simply wouldn't opt for a full node as their daily driver unless they're interested in Bitcoin. Most people wouldn't run a node, no matter how much money they can save simply because it is time consuming and not very rewarding.

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again. Again, since this issue brings us to whether we scale on-chain or second layer, it doesn't make much sense to discuss it on this thread. I prefer the latter, 100MB blocks isn't really desirable for the near future.

[topcoin360]

I'm far more concerned about the security of the network being impacted, instead of the issue surrounding the costs of a full nodes. In this day and age, most people simply wouldn't opt for a full node as their daily driver unless they're interested in Bitcoin. Most people wouldn't run a node, no matter how much money they can save simply because it is time consuming and not very rewarding.

The miners are the ones securing the network and I think most of them can easily afford to buy more storage/bandwith. In this regard, less people running a full node isn't really a threat...

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again. Again, since this issue brings us to whether we scale on-chain or second layer, it doesn't make much sense to discuss it on this thread. I prefer the latter, 100MB blocks isn't really desirable for the near future.

If the demand for block space increases more than the supply then eventually the transaction fees will become so high that only the rich could afford them. Here's the problem and one solution..

In theory, the sender does not have any incentive to pay more than the "min fee" if there's no excess demand as he doesn't have to compete against other people for block space. If there's an excess demand then the block size limit willl determine how many transactions will pay more than the min fee, therefore the block size limit and the avg transaction fee are inversely related. We can balance the supply and demand with this simple equation:

new block size limit = previous block size limit x current avg fee / previous avg fee

We know that the avg fee depends on the amount of transactions that are waiting to be confirmed AND the block size limit, the demand for block space shouldn't change much in the short term.

[ranochigo]

The miners are the ones securing the network and I think most of them can easily afford to buy more storage/bandwith. In this regard, less people running a full node isn't really a threat...

It would be still ideal for a significant portion of the users to have the capabilities to run a full node. Relying on someone else for validation isn't really a good idea, and yes, I did agree that the full node numbers would probably dwindle in the future.

new block size limit = previous block size limit x current avg fee / previous avg fee

We know that the avg fee depends on the amount of transactions that are waiting to be confirmed AND the block size limit, the demand for block space shouldn't change much in the short term.

Do you think we should cap the block size with your variable block size scheme? You do realize that an increase in block size or transactions per block will inevitably result in the blocks being propagated through the network slowly or a far slower validation. This makes it unsuitable for smaller miners to be mining and will have to be directly connected to at least half of the network to achieve a lower stale rate. There is a reason why the blocks were capped at 1MB, and that any scheme should strive for a reasonable block size that doesn't compromise the security of Bitcoin. An increase in the stale rates also results in a decrease in the perceived security, as there can be multiple conflicting blocks at the same height.

I don't disagree that we need a block size increase. What I'm thinking of is a sustainable block size increase that balances the tradeoffs to the benefits.

[topcoin360]

Do you think we should cap the block size with your variable block size scheme? You do realize that an increase in block size or transactions per block will inevitably result in the blocks being propagated through the network slowly or a far slower validation. This makes it unsuitable for smaller miners to be mining and will have to be directly connected to at least half of the network to achieve a lower stale rate. There is a reason why the blocks were capped at 1MB, and that any scheme should strive for a reasonable block size that doesn't compromise the security of Bitcoin. An increase in the stale rates also results in a decrease in the perceived security, as there can be multiple conflicting blocks at the same height.

I don't disagree that we need a block size increase. What I'm thinking of is a sustainable block size increase that balances the tradeoffs to the benefits.

As you mentioned earlier..

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again.

Unless the block size limit is decided at the protocol level we will have to have this debate over and over again! By having a self-regulated system we wouldn't have that problem. So what is your solution?

I'll just bring some adjustments to mine;

new block size limit = previous block size limit + (current total fee - previous total fee)
                                                                                           current avg fee               

I know this calculation may not be very accurate but that's a starting point. I don't think we should forbid people from owning BTC because some miners aren't able to keep up with the demand.   

[ranochigo]

As you mentioned earlier..

The issue surrounding block size has really been discussed over and over again and I doubt we would reach a new conclusion by doing it again.

Unless the block size limit is decided at the protocol level we will have to have this debate over and over again! By having a self-regulated system we wouldn't have that problem. So what is your solution?

I'll just bring some adjustments to mine;

new block size limit = previous block size limit + (current total fee - previous total fee)
                                                                                           current avg fee              

I know this calculation may not be very accurate but that's a starting point. I don't think we should forbid people from owning BTC because some miners aren't able to keep up with the demand.  

I've highlighted the constraints of the network with a larger block size and why a block size that is excessively large isn't favorable for the network. I'm not concerned about your algorithm, I'm concerned about whether you think it is okay for the so called self-regulated system to regulate the block size such that it can potentially take up to minutes to propagate across the network.

Do you think the point of the block size we have today is to introduce scarcity into the block or is it ensure that the blocks are appropriately sized and thereby preventing any issues, pertaining to the security of the network or it's resources? Your self-regulated system is not going to work if it can have the potential to make the network excessively centralized or insecure. There is a very good reason why most of Bitcoin's derivatives don't have a dynamic or an unlimited block size (for which a dynamic block size without any hard cap can also be considered as an unlimited block size).

Edit: If you think that it is fine for a dynamic block size without any upperlimits, then I rest my case. I don't have anything to add on ontop of what I've mentioned and I'm not a huge proponent of increasing it to meet a level that could be compared to the TPS of a mass adoption.

[topcoin360]

I've highlighted the constraints of the network with a larger block size and why a block size that is excessively large isn't favorable for the network. I'm not concerned about your algorithm, I'm concerned about whether you think it is okay for the so called self-regulated system to regulate the block size such that it can potentially take up to minutes to propagate across the network.

I understand your point but if the limit is not high enough then many people won't even be able to spend their coins which is another problem.

Do you think the point of the block size we have today is to introduce scarcity into the block or is it ensure that the blocks are appropriately sized and thereby preventing any issues, pertaining to the security of the network or it's resources? Your self-regulated system is not going to work if it can have the potential to make the network excessively centralized or insecure. There is a very good reason why most of Bitcoin's derivatives don't have a dynamic or an unlimited block size (for which a dynamic block size without any hard cap can also be considered as an unlimited block size).

It is to protect the network and I think we must have a limit. I just think the free market should decide what that limit should be and the miners should adapt accordingly.

Edit: If you think that it is fine for a dynamic block size without any upperlimits, then I rest my case. I don't have anything to add on ontop of what I've mentioned and I'm not a huge proponent of increasing it to meet a level that could be compared to the TPS of a mass adoption.

I believe you prefer a block size increase based on technological progress and I favor a block size increase based on demand. I proposed a way to calculate the block size limit, so far you haven't. I'll briefly explain how my equation could balance supply and demand..

new limit = (current total fee - previous total fee) / current avg + previous size limit

We calulate the excess demand or excess supply relative to the previous period then we adjust the block size limit to meet a new equilibrium (assuming that the demand is constant).

Could you tell us how would you determine what the block size limit should be in the future?

[ranochigo]

Could you tell us how would you determine what the block size limit should be in the future?

Estimate the time it takes for blocks to be propagated through the majority of the network. Determine the block size that still takes a reasonable amount of time to propagate through the network and use that as the max block size.

Currently, the 4vMB blocks have a median propagation time of 6.5s (or less since the study was done a long time ago). If we can keep the expected stale rates to be <5%, then I consider it an acceptable compromise. Expected stale rate is a function of the time it takes for the block to propagate and the block intervals.

[Wind_FURY]

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

[GGUL]

Could you tell us how would you determine what the block size limit should be in the future?

Estimate the time it takes for blocks to be propagated through the majority of the network. Determine the block size that still takes a reasonable amount of time to propagate through the network and use that as the max block size.

Currently, the 4vMB blocks have a median propagation time of 6.5s (or less since the study was done a long time ago). If we can keep the expected stale rates to be <5%, then I consider it an acceptable compromise. Expected stale rate is a function of the time it takes for the block to propagate and the block intervals.

1. It is worth noting that the speed of distribution of blocks in general on the network does not play a special role for mining. The main thing is what is the speed of distribution of blocks within the subnet that covers miners. If the speed inside the subnet was at the level of 1 second, we would have ~1.6% of orphan blocks. But there are much fewer orphan blocks at the moment. Somewhere on the forum, a figure of 0.0024% was given (I can't vouch for the accuracy). This means that the speed is now much less than 1 sec.

2. When using a technology such as spv mining, the block size ceases to affect the number of orphan blocks. Miners start mining the next block almost immediately after the block appears. However, this increases the number of empty blocks. But I think this is quite a reasonable compromise: reducing the number of orphan blocks at the expense of some increase in empty blocks. Moreover, an empty block, which sometimes appears a few seconds after a non-empty block, does not cause any inconvenience to users.

From all this, we can conclude that, for example, 10-20 MB. blocks do not pose any threat to the security of the network in terms of orphan blocks.

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

As far as I understand, you do not want to allow miners to increase the block, because they will have the opportunity to hack the system. Very strange reasoning. After all, miners ALREADY have a 100% chance to hack the system. If, of course, they have such a collective desire. For example, they can start mining empty blocks. Or make a 51% attack. That's all, the system is broken.

It looks like this: a person has a full warehouse of weapons. And you : we can't give him a loaded gun. He will have the opportunity to kill someone.

The security of the bitcoin system is 99.99% dependent on the miners. And if you give them the opportunity to change the block size, nothing will change. Similarly, the security will be 99.99% dependent on the miners.

[ranochigo]

1. It is worth noting that the speed of distribution of blocks in general on the network does not play a special role for mining. The main thing is what is the speed of distribution of blocks within the subnet that covers miners. If the speed inside the subnet was at the level of 1 second, we would have ~1.6% of orphan blocks. But there are much fewer orphan blocks at the moment. Somewhere on the forum, a figure of 0.0024% was given (I can't vouch for the accuracy). This means that the speed is now much less than 1 sec.

Correct. Keep in mind that doing so would make the current mining scene more centralized, whereby miners that are not interconnected with the majority of the miners are more likely to experience more orphans, due to the lack of a direct connection.

2. When using a technology such as spv mining, the block size ceases to affect the number of orphan blocks. Miners start mining the next block almost immediately after the block appears. However, this increases the number of empty blocks. But I think this is quite a reasonable compromise: reducing the number of orphan blocks at the expense of some increase in empty blocks. Moreover, an empty block, which sometimes appears a few seconds after a non-empty block, does not cause any inconvenience to users.

From all this, we can conclude that, for example, 10-20 MB. blocks do not pose any threat to the security of the network in terms of orphan blocks.

I would prefer miners to validate the blocks first. SPV mining is not a behavior that I think we should encourage, we've had a mishap with SPV mining in the past so probably not such a good idea given that current validation speeds are sufficiently fast.

I don't think those sizes are particularly unrealistic to achieve in the future. If you don't need the majority of the network to be able to run their own nodes and that mining to be centralized with a few entities, then it should probably be fine.

[GGUL]

1. It is worth noting that the speed of distribution of blocks in general on the network does not play a special role for mining. The main thing is what is the speed of distribution of blocks within the subnet that covers miners. If the speed inside the subnet was at the level of 1 second, we would have ~1.6% of orphan blocks. But there are much fewer orphan blocks at the moment. Somewhere on the forum, a figure of 0.0024% was given (I can't vouch for the accuracy). This means that the speed is now much less than 1 sec.

Correct. Keep in mind that doing so would make the current mining scene more centralized, whereby miners that are not interconnected with the majority of the miners are more likely to experience more orphans, due to the lack of a direct connection.

You want to say that if all miners establish the highest possible exchange rate among themselves, this makes the system "more centralized". Judging by the number of orphan blocks, the miners have achieved this goal. That is, at the moment, the miners are as "centralized" as possible in terms of the exchange between them. It is simply impossible to make it "more centralized" already.

(p/s/ reasoning in terms of "increasing / decreasing centralization/decentralization" is meaningless until you determine what these indicators are:" level of decentralization / level of centralization". And how these levels are measured.)

Some miner will not want to, cannot speed up the exchange with other miners as much as possible and will lose his income because of this. And another miner can. So these are the problems of the miner. We do not solve the problems of miners in terms of the price of electricity, equipment, taxes. Why should we solve the problems of the miner in terms of its exchange rate over the network?

I would prefer miners to validate the blocks first. SPV mining is not a behavior that I think we should encourage, we've had a mishap with SPV mining in the past so probably not such a good idea given that current validation speeds are sufficiently fast.

As far as I know, there has been one failure with spv mining over the past 5 years. And besides the loss of a part of the miners ' income, there were no other losses. Yes, spv mining has risks for the miner. And the miner himself decides whether to use it or not. And if you claim that it is impossible to increase the block in order not to encourage miners to use spv mining, then this is one of the most ridiculous arguments against increasing the block.

I don't think those sizes are particularly unrealistic to achieve in the future. If you don't need the majority of the network to be able to run their own nodes and that mining to be centralized with a few entities, then it should probably be fine.

IIt is interesting that now, when it is almost free to save a full node, less than 1% of users save it. Why we set such a goal: so that most users can have a full node. If most people don't need it. To achieve this goal, we almost stopped the development and expansion of the bitcoin system 4 years ago. As for me, this is too expensive and pointless a sacrifice.

Maybe it makes sense to look at reality and change our goals. For example, so that the number of nodes is not less than a certain number, which is enough to ensure the security of the system.

[ranochigo]

You want to say that if all miners establish the highest possible exchange rate among themselves, this makes the system more centralized. Judging by the number of orphan blocks, the miners have achieved this goal. That is, at the moment, the miners are as centralized as possible in terms of the exchange between them. It is simply impossible to make it more centralized already.

Hmm. I recall certain pools don't have direct connections to each other and were resorting to running zombies on each other in the past. I find the current stale rates fairly reasonable and mining pools don't necessarily have to resort to those tactics to improve their propagation. If we were to reach the state whereby blocks takes 50 seconds to propagate, then is it possible for the major mining pools to strategically exclude others from their exclusive "subnet"?

Yes, spv mining has risks for the miner. And the miner himself decides whether to use it or not. And if you claim that it is impossible to increase the block in order not to encourage miners to use spv mining, then this is one of the most ridiculous arguments against increasing the block.

I don't think anyone has ever claimed that. On the contrary, we have proven that full validation is sufficiently fast that the benefits of SPV mining is slim to none. The problem of SPV mining is that it is two fold; the incident caused a longer than usual block re-org and the damage could've definitely extended beyond the users.

[GGUL]

You want to say that if all miners establish the highest possible exchange rate among themselves, this makes the system more centralized. Judging by the number of orphan blocks, the miners have achieved this goal. That is, at the moment, the miners are as centralized as possible in terms of the exchange between them. It is simply impossible to make it more centralized already.

Hmm. I recall certain pools don't have direct connections to each other and were resorting to running zombies on each other in the past. I find the current stale rates fairly reasonable and mining pools don't necessarily have to resort to those tactics to improve their propagation. If we were to reach the state whereby blocks takes 50 seconds to propagate, then is it possible for the major mining pools to strategically exclude others from their exclusive "subnet"?

Miners can do this right now. The main mining pools can strategically exclude others from their exclusive "subnet" by simply broadcasting a new block only among themselves, and transmitting it to the general network with some delay. If it was profitable. Judging by the fact that this is not being done, the miners do not have any benefit from this. Or they do not want to do this for the sake of a minimal and risky increase in income. Any activity of this kind is a loss of Bitcoin's reputation, which will eventually lead to much greater losses.

[Wind_FURY]

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

As far as I understand, you do not want to allow miners to increase the block, because they will have the opportunity to hack the system. Very strange reasoning. After all, miners ALREADY have a 100% chance to hack the system. If, of course, they have such a collective desire. For example, they can start mining empty blocks. Or make a 51% attack. That's all, the system is broken.

It looks like this: a person has a full warehouse of weapons. And you : we can't give him a loaded gun. He will have the opportunity to kill someone.

The security of the bitcoin system is 99.99% dependent on the miners. And if you give them the opportunity to change the block size, nothing will change. Similarly, the security will be 99.99% dependent on the miners.

Hack the system? No, that’s not the reason. I’m talking about incentives. If you give the miners the power to decide how large the blocks should be “based on demand”, then you’re giving them an incentive to fake that demand for them to earn more in fees. Especially when most of the coins are mined out.

[GGUL]

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

As far as I understand, you do not want to allow miners to increase the block, because they will have the opportunity to hack the system. Very strange reasoning. After all, miners ALREADY have a 100% chance to hack the system. If, of course, they have such a collective desire. For example, they can start mining empty blocks. Or make a 51% attack. That's all, the system is broken.

It looks like this: a person has a full warehouse of weapons. And you : we can't give him a loaded gun. He will have the opportunity to kill someone.

The security of the bitcoin system is 99.99% dependent on the miners. And if you give them the opportunity to change the block size, nothing will change. Similarly, the security will be 99.99% dependent on the miners.

Hack the system? No, that’s not the reason. I’m talking about incentives. If you give the miners the power to decide how large the blocks should be “based on demand”, then you’re giving them an incentive to fake that demand for them to earn more in fees. Especially when most of the coins are mined out.

"an attack vector, that would possibly disrupt the network"- isn't that "hacking the system"?  

The miner can increase its income due to the fact that users will pay a large commission for the transaction. This can be achieved by reducing the block. Or by setting a high commission for the right to be included in the block. And the miners ALREADY have such an opportunity. Miners can set any commission they want. To do this, they do not need to "fake demand".

A couple of years ago, a delusional idea was popular that miners fill blocks with their transactions (fake  demand) in order to artificially increase the mempool and thus earn more commissions. Miners ALREADY have such an opportunity - "to fake demand".  

Delusional ideas die very hard.

[topcoin360]

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

If you're worried about a congestion attack with a higher limit then you should also be worried about a DDoS attack with a lower limit. Idk what the exact limit should be, but I know that it should be updated more than once every 10 years.  

I didn't expect this thread to turn into a capitalism vs. communism debate (those who believe in free market and those who believe that everyone should run a full node ). The only thing I can tell you is the customers will always go to whoever can give them what they want.

Since we're talking about the possibility of a new consensus rule and not a vector of attack, I think we should discuss the technical details and see if it works in the first place. I've seen a potential flaw in the model I proposed, although it is very unlikely to happen, in theory the excess supply could exceed the actual limit which means the block size limit in the next epoch would be below 0. We can easily fix that problem by introducing a minimum of 1MB which is the current maximum value (that would be our starting point).

Open for discussion!

[pooya87]

The miners are the ones securing the network and I think most of them can easily afford to buy more storage/bandwith.

This is wrong.
Miners AND nodes are both securing the network. Miners by providing hashrate and securing the network against 51% attacks and nodes by enforcing the consensus rules and keeping Bitcoin decentralized.

In this regard, less people running a full node isn't really a threat...

When speaking of number of nodes, block size, etc. saying things like "less" is ambiguous. The real question is "by how much?".
For example when discussing block size increase it should be clarified whether we are talking about a small increase (eg. 1 to 2 MB) or a bigger increase (eg. 1 to 100 MB), there is a big difference between these two. Same with number of nodes. If you could find historical data of nodes or a chart showing the count you could see that we have had big drops and slow rises in the past. For instance back when block started becoming full and again when there was a spam attack where mempool grow to huge sizes the number of nodes decline. But when the price started rising and bitcoin adoption grew the number of nodes went back up again.

So lets put "less people running a full node" into perspective. If now that we have 50k nodes it dropped to 20k, things will still be fine but if it dropped to 1k with only a dozen listening nodes then the network will be in some trouble that will only get worse with time.

Also the thing about block size is that it doesn't matter how much you increase it, in the end it won't be enough. So the trick is to increase it in a way that it minimize the inevitable damage but not so much that it disrupts everything.

[Wind_FURY]

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

If you're worried about a congestion attack with a higher limit

Why would I be worried about network congestion when the miners can increase the block size “based on demand”. What you should be worried about is the centralizing nature of your proposal, and how a cartel of miners can exploit the system by faking demand. Like what gmaxwell mentioned, Calvin Ayre has been faking demand in BSV. Haha.

then you should also be worried about a DDoS attack with a lower limit. Idk what the exact limit should be, but I know that it should be updated more than once every 10 years.

This might be a stupid question, but does small blocks make Bitcoin more vulnerable to DDOS? I thought one of the reasons there was a 1MB cap on the block size was to help prevent DDOS.

A block size increase “based on demand”, and leaving it to the miners to decide how large the blocks should be “based on demand” is a very dangerous proposition, topcoin360. It will open an attack vector, that would possibly disrupt the network.

As far as I understand, you do not want to allow miners to increase the block, because they will have the opportunity to hack the system. Very strange reasoning. After all, miners ALREADY have a 100% chance to hack the system. If, of course, they have such a collective desire. For example, they can start mining empty blocks. Or make a 51% attack. That's all, the system is broken.

It looks like this: a person has a full warehouse of weapons. And you : we can't give him a loaded gun. He will have the opportunity to kill someone.

The security of the bitcoin system is 99.99% dependent on the miners. And if you give them the opportunity to change the block size, nothing will change. Similarly, the security will be 99.99% dependent on the miners.

Hack the system? No, that’s not the reason. I’m talking about incentives. If you give the miners the power to decide how large the blocks should be “based on demand”, then you’re giving them an incentive to fake that demand for them to earn more in fees. Especially when most of the coins are mined out.

"an attack vector, that would possibly disrupt the network"- isn't that "hacking the system"?  

“Hack” would not be the term I would use.

[BlackHatCoiner]

This might be a stupid question, but does small blocks make Bitcoin more vulnerable to DDOS? I thought one of the reasons there was a 1MB cap on the block size was to help prevent DDOS.

Isn't DDoS made in the mempool only? Essentially, an attacker broadcasts dust transactions to occupy the space and prevent from other transactions to be mined. I suppose that it doesn't matter if the block size is 1MB or 1GB, because the analogy of the median fee and the total fees the attacker has to pay remain the same.

“Hack” would not be the term I would use.

It is surely not a “hack”. Maybe “attacking” suits more properly.

Generally a hacking is when someone explores a system weakness. For example, the person who found the problematic functions from Poly's source code and decided to get advantage of it is a hacker.

[ranochigo]

This might be a stupid question, but does small blocks make Bitcoin more vulnerable to DDOS? I thought one of the reasons there was a 1MB cap on the block size was to help prevent DDOS.

Large block takes a longer time to validate, so an excessively large block can be a resource exhaustion for underpowered nodes which are incapable of validating them fast enough. Either that, or to prevent blocks being excessively large and making storage excessively expensive, at least at that point in time. That isn't really considered DOS, or at least I don't think it is.

Block caps limits the number of transactions that can be included in the blocks every 10 minutes. A DOS would be a scenario where people start to spam "useless" transactions to prevent others from getting their transactions into the blocks, without spending more in fees. It has been done before, during the whole segwit ordeal. Whether an attack like this would be viable at this day and age depends on the motives and how much they are willing to spend.

[topcoin360]

Alright, alright, guys I'll reveal some facts that may shock you..

1.A shortage of supply (block space) forces many people to leave their coins on their exchange which is a lot more dangerous than a few people not being able to run a full (who probably do not own a wallet anway).
2.Running a full node does not give you a vote, you can "listen" to what others have to say but nobody cares about what you have to say (unless you have large holdings but you guys don't seem to like PoS).
3.A faster block propagation with less transactions per block does not allow transactions to be confirmed more quickly.
4.A miner who finds a new block has an advantage on his competitors as he will start mining the next block before them but any miner who finds a new block has that advantage (which makes the orphan block argument pretty worthless).
5.A higher block size limit may increase miners expenses but it may also increase miners income, therefore small mining farms are not kicked out of the game.
6.Network congestion is no bigger problem than many transactions not being picked by a miner/paying too much fees.

So.. I can only ask, what now?

[Wind_FURY]

Alright, alright, guys I'll reveal some facts that may shock you..

1.A shortage of supply (block space) forces many people to leave their coins on their exchange which is a lot more dangerous than a few people not being able to run a full (who probably do not own a wallet anway).

Dangerous for who?

2.Running a full node does not give you a vote, you can "listen" to what others have to say but nobody cares about what you have to say (unless you have large holdings but you guys don't seem to like PoS).

I believe BIP-148/Segwit showed everyone that that’s not true. In fact, it’s the full nodes that give demand to what the miners produce, and not just any block, it should be a specific type of block with rules enforced by the full nodes.

3.A faster block propagation with less transactions per block does not allow transactions to be confirmed more quickly.

It’s about the settlement assurances, not speed. One confirmation in Bitcoin is still more secure than one confirmation of shitcoins.

5.A higher block size limit may increase miners expenses but it may also increase miners income, therefore small mining farms are not kicked out of the game.

It increases the full nodes’ expenses, not the miners. Do miners run full nodes? I believe most of them don’t. Plus aren’t small mining farms kicked out of the game simply because big mining farms increase the network’s total hashing power, increasing costs, pricing out small miners?

6.Network congestion is no bigger problem than many transactions not being picked by a miner/paying too much fees.

Isn’t the fee market good for miners?

[topcoin360]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

[Wind_FURY]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

No, there is no such equation, because any block size increase, increasing transaction thoughput, which also increases the hardware requirements, and bandwidth requirements to run a full node, will always scale the network in.

[BlackHatCoiner]

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

Well, I had tried in the past, but it was a function, not an equation. It made me feel very ambitious. 

[ABCbits]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

The harder part is testing the equation on various network condition and accepted by the community.

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

See BIP 103. The exact number and equation definitely need more research though.

[PrimeNumber7]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Your equation does nothing to address the issue I brought up previously. Miners can and do receive transaction fees in ways that are not attached to the transaction. For example, viaBTC offers a paid transaction accelerator service for people who have attached too low of fees to their transaction. They charge a fortune for this service, so it is not widely used, but if pools have incentives to show transactions having lower fees than is actually the case, you can guarantee more pools would offer this service, and the cost would be very low.

[topcoin360]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Your equation does nothing to address the issue I brought up previously. Miners can and do receive transaction fees in ways that are not attached to the transaction. For example, viaBTC offers a paid transaction accelerator service for people who have attached too low of fees to their transaction. They charge a fortune for this service, so it is not widely used, but if pools have incentives to show transactions having lower fees than is actually the case, you can guarantee more pools would offer this service, and the cost would be very low.

As you said it is not a common practice, therefore it shoudn't have a significant impact on the result of the equation.

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

Well, I had tried in the past, but it was a function, not an equation. It made me feel very ambitious.  

Yes, I think function is the right word, ultimately we want to find a function but for that we need to have an equation!

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

The harder part is testing the equation on various network condition and accepted by the community.

Absolutely, we can calculate the next limit without applying it and see if it seems to work in theory. If it does seem to work then we can give the system a test run, we would set a floor and a hard cap in the testing phase.

I'll just explain my equation to make sure everyone understands it:

total fee in the last period / avg fee in the previous period = quantity supplied (Qs) at the previous price for the total amount that was paid in the last period

Qs - space used in the last period = excess demand in the last period before considering the block occupancy rate (a negative value means there was an excess supply)

(Qs - space used in the last period) / block occupancy rate = excess demand in the last period after considering the block occupancy rate

Now I challenge you to find an equation based on "not centralizing bitcoin too much".

See BIP 103. The exact number and equation definitely need more research though.

It's an interesting proposal but it doesn't address the "market inefficiency" problem. I think this is where I and ranochigo have a disagrement, I don't think Bitcoin will ever scale as a medium of exchange because our credit cards are just too convenient (and we generally don't have to pay any conversion/transaction fee to make a purchase with a CC) but I do believe that it can answer a particular need and the block size limit can be high enough to answer that need without being too high.

[PrimeNumber7]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Your equation does nothing to address the issue I brought up previously. Miners can and do receive transaction fees in ways that are not attached to the transaction. For example, viaBTC offers a paid transaction accelerator service for people who have attached too low of fees to their transaction. They charge a fortune for this service, so it is not widely used, but if pools have incentives to show transactions having lower fees than is actually the case, you can guarantee more pools would offer this service, and the cost would be very low.

As you said it is not a common practice, therefore it shoudn't have a significant impact on the result of the equation.

It is not a common practice now, but this is primarily because miners have no reason to engage in this practice currently, other than to help the less technically inclined get their low-fee transactions confirmed. If engaging in this practice would lead to potentially higher total fees, I can guarantee miners will make this practice much more common, or potentially will not even consider transactions that don't have their fees paid this way.

What I describe is an edge case, and for something like bitcoin, it will need to be considered. You should really always consider edge cases, and corner cases (a situation in which multiple edge cases are combined into one) in production code, however with something with bitcoin, where there is literally billions of dollars potentially available if problems can be exploited, it is especially important to address, even perceived unlikely, or unusual scenarios.

[kano]

... and yet the obvious:

If you want your transaction confirmed, pay a transaction fee that should get it into a block.

If you want to skimp on the fee, you may have to wait a while to get it confirmed, or if you skimp too much, it may not ever be confirmed.

How is this a problem?

[ranochigo]

I think this is where I and ranochigo have a disagrement, I don't think Bitcoin will ever scale as a medium of exchange because our credit cards are just too convenient (and we generally don't have to pay any conversion/transaction fee to make a purchase with a CC) but I do believe that it can answer a particular need and the block size limit can be high enough to answer that need without being too high.

Yes, that is correct. I have the same sentiments actually, so not technically a disagreement because I never believed that you can ever scale on-chain, to match those of major payment processors. As you've mentioned, due to the convenience (to a certain extent also its feasibility) and the general reluctance to adopt Bitcoin as an actual currency.

The disagreements (CMIIW) that we've had is; whether we should have sustainable limits on the block size increase. Believe that I've made my point here, so it's just a clarification.

[topcoin360]

The disagreements (CMIIW) that we've had is; whether we should have sustainable limits on the block size increase. Believe that I've made my point here, so it's just a clarification.

I think a block size limit increase based on demand is more sustainable than a block size limit increase based on "what everyone can pay to run a full node" which doesn't make sense to me.

[NotFuzzyWarm]

(and we generally don't have to pay any conversion/transaction fee to make a purchase with a CC)

Actually we the consumer DO pay the tx fee. More specifically, the merchant pays it to the payment processor and their cost is added onto what we are paying for things - we just do not see it as a separate charge. The Merchants fee is generally anything from 2-6% of the transaction value. That is how/why some (local of course) merchants will give a discount for using cash vs credit/debit cards.

[topcoin360]

(and we generally don't have to pay any conversion/transaction fee to make a purchase with a CC)

Actually we the consumer DO pay the tx fee. More specifically, the merchant pays it to the payment processor and their cost is added onto what we are paying for things - we just do not see it as a separate charge. The Merchants fee is generally anything from 2-6% of the transaction value. That is how/why some (local of course) merchants will give a discount for using cash vs credit/debit cards.

Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

[NotFuzzyWarm]

(and we generally don't have to pay any conversion/transaction fee to make a purchase with a CC)

Actually we the consumer DO pay the tx fee. More specifically, the merchant pays it to the payment processor and their cost is added onto what we are paying for things - we just do not see it as a separate charge. The Merchants fee is generally anything from 2-6% of the transaction value. That is how/why some (local of course) merchants will give a discount for using cash vs credit/debit cards.

Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

Not from what I've seen in the US. I've traveled for in work in every state and in all of them have often come across signs like I just saw today in my local doughnut shop:
  All credit/debit cards are +3.5% of total

Same for the local small hardware stores like Ace, TruValue, etc along with a smattering of other small local businesses. That said, most other stores do not give the discount and pocket their usual tx fee when folks pay with cash.

Our company accepts credit cards for orders and MasterCard & VISA card companies want 3% and AMEX takes 4% of the transaction which we add to a customers order. If they pay their PO with check or direct EFT they save the 3 or 4% fee. Merchants are not going to eat that cost - it is passed on to the customer. Tx fees is how the cc companies make their money.

[kano]

...
Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

Alas they do in all cases, some obvious and some not so obvious.

Some may say it up front on a sign and request that extra % as Fuzzy mentioned.

Others it is as simple as part of their business accounting.
All businesses that aren't going broke yesterday, will know their costs.
It is simply yet another cost to cover in their price.

[topcoin360]

...
Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

Alas they do in all cases, some obvious and some not so obvious.

Some may say it up front on a sign and request that extra % as Fuzzy mentioned.

Others it is as simple as part of their business accounting.
All businesses that aren't going broke yesterday, will know their costs.
It is simply yet another cost to cover in their price.

According to https://ycharts.com/indicators/bitcoin_average_cost_per_transaction, for bitcoin, the avg cost per transaction was 231.90 USD yesterday (inflation + commissions), which is a lot higher than the avg cost for a CC transaction.

[NotFuzzyWarm]

According to https://ycharts.com/indicators/bitcoin_average_cost_per_transaction, for bitcoin, the avg cost per transaction was 231.90 USD yesterday (inflation + commissions), which is a lot higher than the avg cost for a CC transaction.

$231.90?   One little problem with stats like that - zero information as to what their average value of the transaction is. It sure as hell is not just a few dollars like the average cc Tx nor even just a few thousand. When I cashed out over $40k in BTC last December to pay off my mortgage the fee was around $30 as I recall. Fees like that require average Tx values in the 100's of k$.

In short - when the basis of data used is not given it is a useless statistic.

[PrimeNumber7]

...
Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

Alas they do in all cases, some obvious and some not so obvious.

Some may say it up front on a sign and request that extra % as Fuzzy mentioned.

Others it is as simple as part of their business accounting.
All businesses that aren't going broke yesterday, will know their costs.
It is simply yet another cost to cover in their price.

According to https://ycharts.com/indicators/bitcoin_average_cost_per_transaction, for bitcoin, the avg cost per transaction was 231.90 USD yesterday (inflation + commissions), which is a lot higher than the avg cost for a CC transaction.

Why are you adding the cost of inflation to bitcoin transactions? The cost of inflation is generally not included in credit card transactions. If you are spending coin, you are going to be unaffected by any inflation. You might argue you are affected via any coin you don’t spend, but this is also true for USD based transactions.

If you are going to compare CC to BTC transactions, you need to make apples to apples comparison.

[topcoin360]

Just found a simple equation to balance supply and demand that could be easily introduced in btc source code:

next block size limit = previous block size limit + (total fee in the last period / avg fee in the previous period - space used in the last period) / block occupancy rate for the last period

Your equation does nothing to address the issue I brought up previously. Miners can and do receive transaction fees in ways that are not attached to the transaction. For example, viaBTC offers a paid transaction accelerator service for people who have attached too low of fees to their transaction. They charge a fortune for this service, so it is not widely used, but if pools have incentives to show transactions having lower fees than is actually the case, you can guarantee more pools would offer this service, and the cost would be very low.

As you said it is not a common practice, therefore it shoudn't have a significant impact on the result of the equation.

It is not a common practice now, but this is primarily because miners have no reason to engage in this practice currently, other than to help the less technically inclined get their low-fee transactions confirmed. If engaging in this practice would lead to potentially higher total fees, I can guarantee miners will make this practice much more common, or potentially will not even consider transactions that don't have their fees paid this way.

What I describe is an edge case, and for something like bitcoin, it will need to be considered. You should really always consider edge cases, and corner cases (a situation in which multiple edge cases are combined into one) in production code, however with something with bitcoin, where there is literally billions of dollars potentially available if problems can be exploited, it is especially important to address, even perceived unlikely, or unusual scenarios.

Users will always have the option to offer a commission on their transactions, which gives the miners an incentive to include those transactions in their block. I hardly see how miners could collude to prevent that.

...
Actually, you're wrong. The merchants will usually not charge the transaction fee to the customers.

Alas they do in all cases, some obvious and some not so obvious.

Some may say it up front on a sign and request that extra % as Fuzzy mentioned.

Others it is as simple as part of their business accounting.
All businesses that aren't going broke yesterday, will know their costs.
It is simply yet another cost to cover in their price.

According to https://ycharts.com/indicators/bitcoin_average_cost_per_transaction, for bitcoin, the avg cost per transaction was 231.90 USD yesterday (inflation + commissions), which is a lot higher than the avg cost for a CC transaction.

Why are you adding the cost of inflation to bitcoin transactions? The cost of inflation is generally not included in credit card transactions. If you are spending coin, you are going to be unaffected by any inflation. You might argue you are affected via any coin you don’t spend, but this is also true for USD based transactions.

If you are going to compare CC to BTC transactions, you need to make apples to apples comparison.

In the case of btc, inflation is part of the payment system, it is not the case for the traditional banking system where account balances' and payments are separate. I guess there are different ways of seeing it.