Quote from: HeRetiK on Today at 07:38:13 AM

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.

Quote from: HeRetiK on Today at 07:38:13 AM

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.

Quote from: BlackHatCoiner on Today at 07:46:13 AM

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

Quote from: vjudeu on Today at 07:56:39 AM

Quote

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.

Quote from: ETFbitcoin on Today at 11:16:45 AM

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

Quote from: Wind_FURY on Today at 11:56:27 AM

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.