Topic: How to give btc users no transaction fees. - page 3. (Read 1167 times)

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.

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.

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:
Edit: also see https://en.bitcoin.it/wiki/Miner_fees#Historic_rules_for_free_transactions

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




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.

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.

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.

Simple! You charge a fee.

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.

The median fee is usually less than 10 sats/vbyte. Even large transactions don't pay more than $3 if they use SegWit native and 1 sat/vbyte. Most of the entities that create these large transactions are exchanges. They'll prefer to wait until they can get their transactions confirmed cheaper rather than pay too much money; the fact that they don't is another story.

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?

Not necessarily a "few cents" I think it might cost like $5 to send bitcoin sometimes on average. If it was always just a few cents to send then that would be different.


One thing I didn't consider is what if someone sends to 500 different addresses in one big batch just to try and game my system. Then from each individual address they try and use it to get free transactions all the time. Wow that would be a big disaster. I would have to figure out a way to stop a cheater like that dead in their tracks! That cuold be a problem.


That would be ok as long as they didn't abuse it. The thing is though, they might find their customers not too happy with how long it took to get their money. As we know, exchanges usually inflate the fee to make sure things get confirmed fast, very fast. too fast.
 One  address per one person is fine but they would find out pretty fast that this isn't for power users.

If a user is only sending bitcoin once a month, then what is the issue with paying a few cents equivalent in a fee?

Further, how do you plan to differentiate a casual user from a power user without KYC, given that any user can generate as many different addresses as they want? An exchange could just keep user deposits on individual addresses and not consolidate them since they know they can then process withdrawals for free.

not if the consensus rules are good enough and sophistocated enough then someone won't be able to get away with avoiding batching and paying a fee vs sending out a huge number of separate transactions. it's not meant for that. free transactions are meant for the casual bitcoin user who from time to time would like to send some bitcoin somewhere. but not everyday and maybe not ever week. maybe once a month or something like that. power users and businesses don't need free transactions to the extent that I would care how my rules affected them. thanks for your post.

And in doing so, you incentivize users and exchanges not to batch their transactions. It is preferable then, from a fee point of view, to create 100 separate transactions each with 2 outputs each (obviously each transaction would include a change output), than it is to create 1 transaction with 100 outputs. The total size difference, even considering the best case segwit use, is something around 14,000 vbytes compared to 3,000 vbytes. That's an awful lot of unnecessary blockchain bloat and an awful lot of excess unconfirmed vbytes in the mempool. This would make things worse for everybody.

Like a post toll? If you have more than 10, will you pay more? These transactions already pay more than those that have less vouts. They pay similar amounts percentage-ly, but if you change that, then the transactions' objectivity is lost. The miners will, then, prefer including the transactions that pay more percentage-ly, which means those that have lots of vouts.

As I said, miners will want from those people to continue spamming. By changing this consensus rule, you aren't defending spamming; you're incentivising miners to include spamming transactions into their blocks.

There is no unnecessary "attributes" that lets the spammers spam, they are using the same attributes that everyone else is using and creating the same normal looking transactions to attack the network. You are also focusing too much on only a single type of spam attack but there are many types. For example the simplest form is to fill the mempool with regular transactions with 1 input and 2 outputs.

Small transactions aren't necessarily the problem. The problem is when a single transaction has alot of "vouts". You could change consensus rule so that if transaction had more than a certain number of vout then it has to pay a fee. That could be one of the rules. There would have to be others most likely. That would not be enough but it would be a start point.

For people that wanting to spam the network with large vout count transactions they can feel free to just continue doing the same thing because it's not a problem for the network. They will continue to pay the required fee and things will be just fine.

Sure, but how? What's to stop some big exchange, service, or other business, who has tens or even hundreds of thousands of UTXOs they want to consolidate or move around but with no urgency whatsoever just flooding the mempool with zero fee transactions, or at the very least taking up all the permitted "slots" with their zero fee transactions, leaving no slots available for anybody else?

Based on what criteria? Who gets to decide which transactions are allowed to have no fee and which aren't?

And as I said earlier in the thread, you can then end up with the situation where zero fee transactions are prioritized over fee paying transactions when there are not enough fee paying transactions to overcome the additional incentive you proposed for zero fee blocks. Users are then stuck with fee paying transactions in the mempool which they cannot replace and aren't being mined.

This is an incentive based system. Just think that the security of the network is maintained due to the importance of the incentive; due to the exploitation of the human's greed. It turns out that this is the greatest and possible way to secure a network if it's ran by humans.

And you received some answers with co-arguments. Simply put, you can't do what you've thought and retain both the same security, transaction objectivity and fee zeroing.

Well, I personally would not be the one to choose who gets to use a free transaction. I suppose that would be left up to the system. It would need to be able to look at a transaction and determine whether to accept it or reject it with no transaction fee attached.


Well I don't think you understand the whole idea was that free transactions would be mined in a block of their own, not mixed with other transactions that had a fee. You can read back through the thread though and you'll see where I discussed that idea.


That was already explained in detail. You can find that explanation earlier in this thread. Once you read over that explanation then I'm sure it will make more sense to you!

And how do you choose who gets to use the free transactions? There is no way to set up a system where "everybody gets one" or something similar without some ridiculous KYC requirements. If you allow something like "10 per block", then you guarantee that the mempool would be permanently filled with a huge backlog of free transactions, and you can also guarantee some people would set up bots to auto-rebroadcast their own free transactions, and so the average user would be no better off. And what would be the incentive for miners to pick up a few free transactions over paying ones?

Exactly. but I think there would have to be some type of a trade off. The question is, is it acceptable to people. I wouldn't mind limiting certain types of transactions such as large # of outputs with small transaction amounts per output. Those are clearly undesirable. But other people might disagree but when you're sending dust to 500 btc addresses, you're spamming. If you want to pay for it fine but if not then that shouldn't be free.

But even that might not be enough in a free transactions utopia. You have to be more sophistocated than that. I'm gonna cook up some ideas though and see if they fly. but it might take me a while!

So if there was free transactions with no fees spam wuold still be a matter of perspective? If that's the case then I'm all for having free transactions! maybe not unlimited in number but at least a few every week. as a side question why wuold bitcoin developers build attributes into the prototocol that they dislike and frown upon them being used when they themself designed it to be used that way. certainly they had to realize that if they allow for example transactions with large numbers of outputs and small send sizes per output then people will do that, right? why should anyone frown upon something that the consensus rules allow unless it is unintended behavior which in that case means things need fixing.

Currently, if someone tries to spam the network, he will be punished financially, due to the fees he'll have to pay.

Staking isn't the same with transacting. It's the mechanism used to secure the network; in Ethereum, they aren't punished if they spam with lots transactions unless if you include the fact that I wrote above.

The biggest challenge was to figure out a way to decentralize consensus. We didn't need Vitalik for that, so possibly nor for this situation.