How to give btc users no transaction fees.

[larry_vw_1955]

I still don't understand though, haven't we convinced you that a system where the user doesn't pay a 'toshi for their transactions has drawbacks?

Yes, I think you have convinced me that having no-fee transactions is very problematic. It's not just as easy as saying "poof, free transactions everyone!". Not at all.

[1715011423]

1715011423

[1715011423]

1715011423

[1715011423]

1715011423

[1715011423]

1715011423

[larry_vw_1955]

I have literally never paid that much to transfer bitcoin ever. If that is the average amount you are paying to transfer bitcoin, then you either need to educate yourself about fees, use a better wallet which lets you set your own fee, or both.

Between June and July of this year, average btc transaction fees was in the range of $5. https://bitinfocharts.com/comparison/bitcoin-transactionfees.html

And how do you stop them from abusing it, short of charging a fee? As soon as you do it on an "honor" system or something similar, then it will be abused almost immediately.

Thus the need for a large set of metrics/rules which would act as sort of an AI to decide whether a transaction could be done without a fee or not. I updated my initial posting with such a set of rules but if that doesn't look complicated then I don' t know what does! Even if those rules were enough to prevent abuse and make things work how I wanted, I don't think nodes are set up to be able to have that much ability to look into history of individual addresses/utxos/etc. It might be a drag on their resources to have to try. So it's probably not feasible what I proposed there at all.

those were just some rules i came up with off the cuff. it feels like trying to use a hammer to solve a problem that should only need a much more delicate tool 

After realizing all of that, I thought maybe the simpler way is to just assign a flag to each utxo that says "yes" or "no". Yes you can be used in a free transaction or "no" you can't. But then how do you construct the logic to decide? And even then it still seems as though you would have to have some type of ability to understand the past transaction history of an address too. I don't know if nodes could have that type of capabilities. It's kind of doubtful.

[vjudeu]

In the old times, there was something called "coinage", when you could calculate how old your coin is, in this way if you had old enough coins, you could spend them for free. Repeating that was not an option, because after each transaction coin age dropped, so older transactions had higher priority. In code it was expressed as:

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

Edit: also see https://en.bitcoin.it/wiki/Miner_fees#Historic_rules_for_free_transactions

[o_e_l_e_o]

Between June and July of this year, average btc transaction fees was in the range of $5.

Average fees include all the transactions made by exchanges and other big services with grossly overestimated fees. They are not indicative of what you actually need to pay. If you look at the mempool for June and July, more often than not you could pay 1 sat/vbyte and still get a fast confirmation.

After realizing all of that, I thought maybe the simpler way is to just assign a flag to each utxo that says "yes" or "no".

I'm not sure this would work either. Either you allow the person broadcasting the transaction to set the flag and nodes don't check it, in which case everyone can flag every output as "allowed to be spent for free", or you make nodes check or assign the flag themselves, in which case they need to perform a deep dive in to the history of every transaction they receive, which is a huge amount of additional work. And every node needs to repeat this work on every broadcast transaction.

[larry_vw_1955]

In the old times, there was something called "coinage", when you could calculate how old your coin is, in this way if you had old enough coins, you could spend them for free. Repeating that was not an option, because after each transaction coin age dropped, so older transactions had higher priority. In code it was expressed as:

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

Edit: also see https://en.bitcoin.it/wiki/Miner_fees#Historic_rules_for_free_transactions

I guess miners were not incentivized enough to keep doing that so it stopped. Once there was enough people willing to fill their blocks with paying customers, that whole thing disappeared off the face of the planet I bet! But it was kind of ingenious though in its simplicity.

[NeuroticFish]

Between June and July of this year, average btc transaction fees was in the range of $5. https://bitinfocharts.com/comparison/bitcoin-transactionfees.html

This only shows how many use centralized wallets and services, which are known for overestimating the fees big time.
I've been following the blocks and I do know how many blocks were not full or just. In many occasions one would have had the same result with 3 sat/vbyte (or even 1!) and still paid 400 sat/vbyte. Here's where these numbers come from.

[larry_vw_1955]

Between June and July of this year, average btc transaction fees was in the range of $5. https://bitinfocharts.com/comparison/bitcoin-transactionfees.html

This only shows how many use centralized wallets and services, which are known for overestimating the fees big time.
I've been following the blocks and I do know how many blocks were not full or just. In many occasions one would have had the same result with 3 sat/vbyte (or even 1!) and still paid 400 sat/vbyte. Here's where these numbers come from.

Ok well I appreciate you guys pointing out that, I wasn't aware of that. I just was going by the chart but if you say so then ... I'm the kind of guy that would want to pay 1 satoshi per byte or even less than that if possible 

[o_e_l_e_o]

I'm the kind of guy that would want to pay 1 satoshi per byte or even less than that if possible 

Then just keep an eye on the mempool and make your transaction when it is empty. Or just pay 1 sat/vbyte and be patient - over the last month it has never taken more than a day for a 1 sat/vbyte confirmation to confirm, but the majority of the time it confirms within the hour.

For transactions which fit all of your rules - especially not having a large number of inputs or outputs - then you are looking at somewhere in the region of 200 - 500 vbytes, meaning 1 sat/vbyte works out at around 10 to 20 cents at current prices. Is that really too much to pay for a transaction? It's probably less than the electricity cost would be for the proof of work you want people to do to earn a free transaction. If that is still too much for you, then open a Lightning channel for 10 cents and make as many transactions as you like essentially for free.

[larry_vw_1955]

I'm not sure this would work either. Either you allow the person broadcasting the transaction to set the flag and nodes don't check it, in which case everyone can flag every output as "allowed to be spent for free", or you make nodes check or assign the flag themselves, in which case they need to perform a deep dive in to the history of every transaction they receive, which is a huge amount of additional work. And every node needs to repeat this work on every broadcast transaction.

If you assigned a value to each utxo which represented how good or bad it was, and only let good ones be used as inputs to free transactions, that's what I was thinking. And yeah, it can't require "deep diving" it has to be fast and quick to compute the number. If anyone knows that the formula is...

Then you could incentivize miners to include this type of transactions by adding extra amounts to their coinbase reward to make up for the missing transaction fee. Well I know that would require some type of hard fork.

[larry_vw_1955]

For transactions which fit all of your rules - especially not having a large number of inputs or outputs - then you are looking at somewhere in the region of 200 - 500 vbytes, meaning 1 sat/vbyte works out at around 10 to 20 cents at current prices. Is that really too much to pay for a transaction?

 I dont think anyone is going to complain about paying 10 or 20 cents. heck people on the eth network don't even complain about paying $50 to send $500. they think that's ok! for me personally, if I paid 2 cents transaction fee, I feel good about it. that's how it used to be on ethereum, not anymore!

It's probably less than the electricity cost would be for the proof of work you want people to do to earn a free transaction. If that is still too much for you, then open a Lightning channel for 10 cents and make as many transactions as you like essentially for free.

i doubt most casual bitcoin users or people that "accept" bitcoin know how to use the lightning network or even what it is. me included. but thanks for the suggestion, i'll think about it.

[o_e_l_e_o]

If you assigned a value to each utxo which represented how good or bad it was

Sure, but there is no way to, calculate, assign or verify such a value based on your rules without requiring each node to look back and analyze multiple transaction chains for every new unconfirmed transaction it receives.

Then you could incentivize miners to include this type of transactions by adding extra amounts to their coinbase reward to make up for the missing transaction fee. Well I know that would require some type of hard fork.

So instead of the person making a transaction paying a fee, every bitcoin user has to pay the fee with the cost of the slight devaluation of their coins since you are introducing excess new coins in to circulation.

i doubt most casual bitcoin users or people that "accept" bitcoin know how to use the lightning network or even what it is.

And how many casual bitcoin users would understand your multiple rules and how they function? It's far easier to download and use a Lightning wallet which will deal with all the channel open and closing for you.

[larry_vw_1955]

If you assigned a value to each utxo which represented how good or bad it was

Sure, but there is no way to, calculate, assign or verify such a value based on your rules without requiring each node to look back and analyze multiple transaction chains for every new unconfirmed transaction it receives.

Well I did some thinking about this issue and I think I came up with something. I'll have to gather my thoughts and post it soon!
 

So instead of the person making a transaction paying a fee, every bitcoin user has to pay the fee with the cost of the slight devaluation of their coins since you are introducing excess new coins in to circulation.

 if even 0.5% of bitcoins are lost forever each year, then in 100 years, what's that? 50% of all bitcoins are gone what are you going to do then? once the block subsidy ends, that becomes a real issue because it's kind of cheating to redenominate and start calling a millibtc a btc. they should never be allowed to redenominate like that.

And how many casual bitcoin users would understand your multiple rules and how they function? It's far easier to download and use a Lightning wallet which will deal with all the channel open and closing for you.

You'd be surprised how normal everyday people can become experts on things dealing with money when there's something in it for them. But I doubt the lightning network is the solution. For one thing, both parties have to be able to use it. Not just one of them. If someone had a transaction they wanted to submit without a fee, they could do that and if it worked it worked, if not then it gets rejected simple as that.

[larry_vw_1955]

ok guys, I think I might have solved the problem about a metric to use for seeing if a transaction qualifiy for no fee. it just uses a formula that gets computed when the transaction is submitted. the node will do the following computation.

Some background: Each utxo will be assigned a Score at the time it is created.

When a transaction is submitted: The node will sum up a satoshi-based weighting of the Scores of the individual inputs to give a value we will call Total_score. The formula is Total_score=sum(satoshis*score)

If Total_score >= free_transaction_threshhold then accept transaction.

If Total_score < free_transaction_threshhold then reject transaction.

For an accepted transaction, the node will assign Scores to all of the transactions outputs in such a way as to prevent spamming of the network and abuse of free transactions. And also to encourage utxo consolidation as it helps the utxo set to stay small.

For example, let P be a reduction percentage. A typical value for P might be 50% for example. Then let Output_total_score=Total_Score*P/100. The node would then compute the satoshi-based weighting for the outputs that solves the equation Output_total_score=sum(satoshis*score).


This is freaking amazing guys! I thnk I solved it thanks to all your helps!

[larry_vw_1955]

I realized there was a few issues with my idea so I plugged those holes let me show you what I changed:

ok guys, I think I might have solved the problem about a metric to use for seeing if a transaction qualifiy for no fee. it just uses a formula that gets computed when the transaction is submitted. the node will do the following computation.

Some background: Each utxo will be assigned a Score at the time it is created.

When a transaction is submitted: The node will sum up a satoshi-based weighting of the Scores of the individual inputs to give a value we will call Total_score. The formula is Total_score=sum(satoshis*score)

We also need to compute Ave_score=Total_score/(# of inputs).

If Total_score >= free_transaction_threshhold then accept transaction.

If Total_score < free_transaction_threshhold then reject transaction.

The correct comparison would be :

If Ave_score >= free_transaction_threshhold then accept transaction.

If Ave_score < free_transaction_threshhold then reject transaction.

For an accepted transaction, the node will assign Scores to all of the transactions outputs in such a way as to prevent spamming of the network and abuse of free transactions. And also to encourage utxo consolidation as it helps the utxo set to stay small.

For example, let P be a reduction percentage. A typical value for P might be 50% for example. Then let Output_total_score=Total_Score*P/100. The node would then compute the satoshi-based weighting for the outputs that solves the equation Output_total_score=sum(satoshis*score).

That would be nice but that's not well defined. There is no "unique" weighting. But we can fix that. For example, let all the individual scores of the outputs be equal such that the above equation is satisfied. The affect that will have is larger outputs will have a greater weight. Smaller outputs will have a smaller weight.

it's good to think about how this metric would stop someone from just sending the same bitcoin over and over to another address they own.

[BlackHatCoiner]

if even 0.5% of bitcoins are lost forever each year

But, this isn't a fixed value. I personally think that, overtime, people will protect their funds more than they did when they weren't that valuable. Think of it this way: In 2010 someone lost a hard drive with 9,000 BTC. At the moment, only huge exchange businesses own so many coins. Are the odds the same for them to lose them?

Not to mention that before the introduction of HD wallets, it was much easier to lose coins. You'd have to write down private keys which is dangerous for human mistakes. It also discouraged you to write them all down, if you had more than, let's say, five addresses. Thus, you kept them on your hard drive which can also lead to a loss.

Sure, there'll always be lost coins, especially the burned ones, but I don't believe that it'll remain 0.5% forever.

But I doubt the lightning network is the solution. For one thing, both parties have to be able to use it. Not just one of them.

When a payment is meant to be made, both of the parties have to be there. The sender must know that the receiver knows he got his money. The way block chains work confuse you with this payment's characteristic. Essentially, you lock your funds on some boxes and wait until the receivers open them and spend them. If they announce they lost their seed phrase / private keys, they haven't received them. (while they gave you an invoice saying that if you fund it, they will)

With the lightning network, both of the users have to be online to transact, but I don't understand why is that a drawback. In every non-IOU payment system we had so far, both of the users had to remain online except Bitcoin's blockchain. (To avoid misunderstandings:  LN isn't an IOU payment system)

If someone had a transaction they wanted to submit without a fee, they could do that and if it worked it worked, if not then it gets rejected simple as that.

It's not simple as that, but anyway.


Could you please not double/triple post, but just edit your last post instead?

[o_e_l_e_o]

if even 0.5% of bitcoins are lost forever each year, then in 100 years, what's that? 50% of all bitcoins are gone what are you going to do then?

Continue to use bitcoin as I always have done (except I won't be alive ). Bitcoin was built on a fixed supply, and Satoshi himself acknowledged the issue of lost coins, calling them a "donation to everyone". Any plan which will mint additional bitcoin will almost certainly be rejected by a supermajority of nodes, miners, and users.

once the block subsidy ends, that becomes a real issue because it's kind of cheating to redenominate and start calling a millibtc a btc. they should never be allowed to redenominate like that.

You don't need to redominate, just add additional zeros after the decimal point. Lightning already works in millisats, or 0.00000000001 BTC, which is an additional three decimal places over the base layer.

For one thing, both parties have to be able to use it. Not just one of them.

Many payment processors, services, and merchants, all set a minimum fee rate which is required for payments. What makes you think they would all happily accept zero fee transactions?

[larry_vw_1955]

What's the formula to assign score to each UTXO?

if you read all the way through you would see how outgoing newly created utxos get assigned a score. So I must assume you're asking me "how do utxos that have never been used before under this new system get assigned a score?" If that's your question, then that's a good one. Probably they would just get some nominal value probably not large enough to allow them a free transaction right away, but if it got combined with some other utxos they might help one another get a free transaction.

How is P value determined?

P could be hardcoded in but I don't think anyone could really know what value of P would be most reasonable without alot of data and experimentation. I'm using P=45% in my spreadsheet right now.

P.S. can you give example where the transaction has >1 input & >1 output?

I can do even more than that. Here's 10 inputs going to 5 outputs going to 1 output. The 10 inputs transaction qualified for a free transaction as it met the free transaction threshhold value which is 10^8 (hi satoshi). The 5 inputs going to 1 output did not qualify for a free transaction. And as we can see, the single output transaction does qualify for a free transaction. Consolidating utxos has benefits! Maybe not immediately but eventually you get rewarded. Sorry about the god awful typesetting.


   sat   100000000         
   p   45   percent      
   free_transaction_threshhold   100000000         
10   INPUTS            
   BTC   Satoshis   Pre-existing score   Calculated weight   
   0.001   100000   0   0   
   0.05   5000000   20   100000000   
   0.1   10000000   14   140000000   
   0.5   50000000   4   200000000   
   0.0001   10000   1   10000   
   0.025   2500000   3   7500000   
   1   100000000   4   400000000   
   0.0076   760000   3   2280000   
   0.55   55000000   3   165000000   
   0.34   34000000   1   34000000   
TOTALS   2.5737   257370000      1048790000   
Reduction by P            471955500   
               
               
Average            104879000   qualifies for free transcation
New score            1.833762676   
5   OUTPUTS            
   BTC   Satoshis   Computed scores   Calculated weight   
   0.0723   7230000   1.833762676   13258104.15   
   0.0014   140000   1.833762676   256726.7747   
   0.6   60000000   1.833762676   110025760.6   
   0.5   50000000   1.833762676   91688133.82   
   1.4   140000000   1.833762676   256726774.7   
TOTALS   2.5737   257370000   1.833762676   471955500   
Reduction by P            212379975   
               
               
Average            94391100   does not qualify for free transaction
New score            0.8251932043   
1   OUTPUTS            
   BTC   Satoshis   Computed scores   Calculated weight   
   2.5737   257370000   0.8251932043   212379975   
   0   0   0.8251932043   0   
   0   0   0.8251932043   0   
   0   0   0.8251932043   0   
   0   0   0.8251932043   0   
TOTALS   2.5737   257370000   1.833762676   212379975   
Reduction by P            95570988.75   
               
               
Average            212379975   qualifies for free transcation
               
               

[larry_vw_1955]

Hey guys, just an update. I don't think this idea works after running a few basic simulations on a spreadsheet. I think it actually punishes people for consolidating their utxos and eventually things would get to a point where no one would qualify to get a free transaction. So it doesn't even do any good.

So I got rid of P the reduction percentage parameter and put something else in its place. it works a little better maybe but i'm not ready to post any results on it yet because i don't wanna look like a fool again  but the idea I'm testing now is to look at (#inputs/#outputs)^(1/3) as a scaling factor for the total "weight". that way at least it rewards utxo consolidation but not too much but the problem is when inputs/outputs is less than 1, it doesn't punish it enough. and then there's the issue of if the ratio equals 1 theres a big problem there i noticed which is someone can just get free transactions repeatedly. not good.

[BlackHatCoiner]

The 5 inputs going to 1 output did not qualify for a free transaction. And as we can see, the single output transaction does qualify for a free transaction.

Hi, I've taken a look on the numbers you posted, but haven't understood much. In a nutshell, you want to make the block size non-standard, but to increase/decrease instead analogously with the total of the transactions it has. If the coinbase reward remains the same, please answer me the following question and I'll pay more attention to your post:

How will you incentivize the miners to include a transaction that provides zero benefit to them?

If the coinbase reward does not remain the same, but increases if it contains free transactions, how will you prevent them from creating their own transactions just to fulfill the requirement so that they can cheat the system?


It's nice to see new forum users dealing with the scaling problem.

[larry_vw_1955]

Hi, I've taken a look on the numbers you posted, but haven't understood much. In a nutshell, you want to make the block size non-standard, but to increase/decrease instead analogously with the total of the transactions it has. If the coinbase reward remains the same, please answer me the following question and I'll pay more attention to your post:

How will you incentivize the miners to include a transaction that provides zero benefit to them?

There has to be some type of motivation on their part to want to include no-fee transactions into a block. Incentives dont always have to be in the form of extra rewards. You could punish miners who did not put enough free transactions into a block for example by reducing their coinbase reward. Right now though I've been focused on coming up with a metric that decides whether a transaction qualifies to be free or not. I feel I've made some progress lately. Although the numbers I posted that you referenced were from an idea that didn't make the cut.

If the coinbase reward does not remain the same, but increases if it contains free transactions, how will you prevent them from creating their own transactions just to fulfill the requirement so that they can cheat the system?

The problem with the scenario of "comping" miners extra for putting no-fee transactions into blocks has to do with how does one place a value on no-fee transactions so that miners are not overly or underly incentivized to put no-fee transactions into blocks?

I'm hoping that if a strong enough metric can be put in place to decide if no fee is warranted then miners would not be able to do any cheating. Anymoreso than a normal bitcoin user.