Transaction fees: bug or feature?

AFAIK, transaction fees are not mandatory in Bitcoin. So nodes of the network can already be spammed.

Also, nodes are free to include the transactions they want. They can just ignore spammers if needed.

Finally, uCoin does allow fees, but I recognize it is kinda unefficient: you can issue a transaction and put the public key of the node which will include it, with an amount for him. And to be ensure several nodes try to include it, you can issue multiple times the same transaction but with a different beneficiary’s pubkey. Only one will be written.

Maybe a “Fee” field on transactions could be helpful.

edit: ok, answering 10 month later without reading again the initial arguments was a bad idea. We do not need a Fee field.

in the beginning the spam problem in bitocoin was solved by using the coin age destroyed in the transaction as priority of the transaction.

whats is the reason to implement it like that? looks little bit strange to me. what is the benefit of that compared to just using the normal fee / coin age priority like in bitcoin?

my suggestion would be just to let the fee optional and use the destruction of coin age by default as priority, just like bitcoin did it. like in bitcoin the protocol should not define if fees are needed or not, but miners could define it (soft fork)

if the UD is incentive enough in the longer run to have enough validating nodes only time will show,

what was nice with mining in bitcoin was, that you could just start the computer mining in the beginning and see the coins coming in. what still is nice in mining is, that it helps to give liquidity to the market, because miners have an incentive to sell some part of their mined coins to cover the power costs.

by the way, we should think also about how many transactions per time we want to allow. I for my part dont want to end up in an situation where the hole community splits, because of an set spam protection limit of 1MB like in Bitcoin.
For example Ethereum uses an algorithm that allows an single block to be at max 20% bigger as an average block.

summary:

  • as long as we can only process a limited amount of transactions per time, we need some kind of spam protection
  • using the coin age as transaction priority and allowing optional transaction fees could solve the spam problem
  • if UD is enough incentive to run verifying nodes only time will show, still it would be nice at least to have some small incentive for running an verifying node.
  • We should think about using an dynamic algorithm like Ethereum has that limits the size of an single block to protect against spam

I agree it is very strange and not very efficient. And this is not about spam, but about rewarding nodes of the network for processing transactions.[quote=“Arcurus, post:12, topic:40”]
like in bitcoin the protocol should not define if fees are needed or not, but miners could define it (soft fork)
[/quote]

We have now another view of the fees: we consider this is not a core feature, it should not be included in the core protocol. Actually we should rather talk about “rewards” than “fees” in uCoin case, because this is what we used to be cared about. Rewards should be another system, something external.

This external reward system (that I have no idea yet what it could look like) might be an incentive, coupled with classic UD incentive.

That’s a very good idea :smile: added to GItHub issue #62.

Yes, why not. After all, the nodes may do what they want as long as they respect the protocol they were meant to follow.

2 « J'aime »

and what is the benefit to using normal transaction fees?
or is this feature so or so outdated and is / will be removed :smile:

lol sometimes its really ¨hard¨ here :smiley: at least, you havent linked to some kind of french manual :wink:

but back to the topic, what means exactly you have removed transaction fees? does it mean you even have no chance to give a fee even if you would want?

Lets say we would use the destroyed coin age as transaction priority. if i happen to make an low priority transaction, with no chance to give an optional fee my transaction would have to wait at worst very long time to come above the spam limit.

As said one main use-case of transactions fees is to overcome the spam level.
incentives / rewards for nodes is an fully different story thats good to discuss separately :smile:

I don’t agree at all with that point of view. You join different topics :

  • Technological solution to solve a technological problem
  • Economical solution to solve an economical problem
  • Money solution to solve a money problem

There is no economical cost relatively to a transaction. The solution cannot be an economical one.

There is a technological problem for a community if some of the members do anything to stop the other members to exchange through a technological way.

The solution is a software/protocol one.

uCoin prevents a node to write many blocks through a calculation power increase. uCoin can also prevent accounts to write many transactions through a technological cost too.

how is this solved currently? or if not how you suggest to solve it?

UPDATE
theoretically we could try to use some kind of member based priority.

technically as long as we use something like a blockchain, space per time in the blockchain is limited.
Everything that is limited has an value.
even if we use member based priority, still space in the blockchain would have some value, so members could trade it.
which would lead also to an fee market if we reach the current transaction limit.
so why to restrict what is possible on the protocol level?
or just wait and hope that this would be solved until we have significant transactions?

Technological solutions always have an economic impact.
economical solutions always stimulate or hinder technological solutions
money solutions always have an economic effect, which again has an technological effect
economical solutions and technological solutions have an influence what kind of money is good or even possible to use.

Further, we could see it also that way, that maybe someone want to give some voluntary donation in his transaction to support the network. why hinder him?

cgeek will answer that more precisely but it is simple to understand : once you have written a block, the calculation needed is more important for you (and you are known through your key, you cannot write without it). So the more you write with your key, the more difficult it will be to write again, so you will let the others write too.

This is an axiom, I refute :

You cannot decide what is value or not for me. Value is relative. Even more : if two men decide a same thing is a value, the price they decide for that value is relative too. Study RTM in english or french to know more about this point.

No. (idem) Your choice about what is value or not is only your choice, not other’s ones.

No (idem).

Incoherent axioms reveal incoherent questions about incoherent problems.

You can also study “La preuve de la valeur ?” you can translate into English through right English flag.

Axiom I refute too (idem).

You seem to have definitive answer about what are things and what they aren’t.

I refute this point of view.

i did not mean writing a block i meant writing / creating transactions / if someone tries to spam the network.
how writing a block is functioing in ucoin i know. how spam protection is handled currently in ucoin i dont know yet :smile:

that is what i do not understand. its my choice if something has value for me or not and if so how much.
so why to restrict my freedom how i can interact with someone if i want to exchange limited space for someucoins?

but I will read the RTM, maybe i have already read it, but i will read it again and again :smiley:

Your freedom is not restricted. You can propose to exchange what you define as “limited space” for some free money units.

Like TCP/IP allow computer to interact in a P2P way, it allows you also to develop something like a server using TCP/IP, that allows you to exchange what you want with money to connect to your server. This is just not part of TCP/IP protocol, it’s something TCP/IP allows but it’s a separated thing all the people don’t share.

A free money allows you to develop the values you want to develop, including money services or what you want. It’s a separated and relative thing all the people don’t share.

1 « J'aime »

For example, you could totally develop a service which has ucoin nodes and accepts to mine a block only if it was paid for it, and you’d ask people to pay for you to mine blocks. But this is not a protocol issue ! :slight_smile:

yea I could, as I outlined above. the only difference is if it is artificially hindered at the protocol level, then i need to do some extra work / communication to fix that problem, which would be needed if the protocol would allow it.
Just imagine TCP/IP would not allow to transmit encrypted packets.
in this case I would have to create other communications channels / reinvent the internet, or try to hide my encrypted stuff in the packets. So I had to do a lot of effort which would be needed to do if it would not be artificially limited.

so the question is here now if we want to artificially limit something and if so why?

and the second question is if we want to solve the transaction spam problem at this time, and if so how?

Well TCP/IP is agnostic of the kind of packet transmitted. uCoin is agnostic of the services built with the money.

It’s not artificially limitting, it’s just that it’s not the role of the protocol to define this. The protocol is about issuing and transfering money.

For the transaction spam problem, I guess we have to find ideas which do not involve the protocol, but the node implementations.

1 « J'aime »

lol yea, in fact it is very difficult to hinder someone to give some writing nodes some coins for prioritizing their transaction, you just have to give it to an address that is spendable by all :smile:

but of course the original bitcoin fee concept would make it lot more efficient :smile:
not allowing fees is the same as not allowing outputs that everybody could spent, why we artificially try to make it harder at protocol level then it must be?
its like designing tcp ip and saying that the number 3 must be decoded as 33,because we dont like 3 so it would still function to transmit 3, but it needs more space and is more complicated then needed.

what nodes do is an separate topic, but if the protocol makes certain thinks less efficient, then implementations of nodes are more restricted then needed.

I’d say the transactions fees are more like implementing file transfers on the TCP/IP level :wink:

There could be thousands way to have individuals be paid to mine blocks. I can think of a tip to mine system, mutual association of miners with donations, or many other things. It’s not the role of the protocol to define it. It’s not a problem if it’s more complex after all.
Internet is really complex, this web site is built on ARPTCPIPHTTPSSLVirtualizationLinuxNodeJsContainers… But each one of these blocks are just resolving one specific goal, and are agnostic of what they will be used for.

3 « J'aime »

maybe i am misunderstood. at protocol level it is not about transactions fees yes or no, its about if spendable outputs are allowed that can be spent by the block writer. not more not less:

if these transactions would be made not valid at protocol level. it would restrict certain usages of the protocol.
as said, you can build always on the top on an not so efficient protocol, but its much more harder and less efficient (needs more space in an transaction which would increase the orignial problem of using an limited available space per time)

as said, the question is not if fees yes no, the question is if we want to make the implementation of certain use cases of the protocol by purpose more complicated and less efficient.

What do you think about Peano Axioms defining Integer Numbers !? Is it complicated, less efficient than another set of Axioms !?

“Complicated” or “efficient” suppose a definition of a space where you can measure those things, what space do you refer to !? Will other people share your choice of measures concerning those concepts ?!

Which ones will you choose !? This is your freedom. You can choose them, fork them, develop the ones you find the more efficient for any relative reason you think could be good.

So you stay totally free to choose and develop, adopt or not.

I am quite opposed to this feature being included in core…
First, why is it even discussed?

  • Is it to solve an hypothetical spam problem? If so, I am sure there are other purely technical solutions for this problem.

  • Is it to “reward” the node owners? If so, I am sure it is not needed. uCoin has some specific values attached to it that attract certain individuals only (basic income, freedom, etc…). These people are not in for the profit. Having a free money and basic income for all is incentive enough to run a node. Communities, cooperatives, families or even town halls can decide to fund extra nodes if needed. It is a public/community service. Without these nodes, there is no uCoin.

  • Is it to cover the server and power costs? It is hard to evaluate how much cost a transaction. People have different server rigs, different usage, etc… Also let me emphasize it again: I am quite sure people are not in uCoin for the profit. An perhaps more in for the values than for the money itself. It doesn’t matter to cover costs if you run a uCoin node on 20% CPU of your home server that is running anyway. Or in a server funded by a community cooperative to make uCoin and free money happen.

I really think it does not matter to most people interested in uCoin to be financially rewarded for making uCoin happen. If they wish to be rewarded nevertheless, there are alternative means: call for funds, kickstarting a giant node, get a patron, etc…
Also someone said that nodes can treat the blockchain transactions they wish, am I correct? If so, we could totally imagine a business centered around high availability node clusters that will treat only the blockchain transactions of their clients in a very quick and efficient way. It’s just one idea among others.

True not having transaction fees will be disappointing to someone who wants to make big money out of cryptocurrency and avoid taxes altogether with a multi-GPU power hungry cheap server farm. I don’t care. They can mine bitcoins/litecoins/dogecoin/whatever and earn free untracable money (as in free beer) between themselves. These people are very unlikely to be involved in a free money (as in freedom) with a basic income anyway. They won’t use uCoin if there is no profit for them to be found there. Or if there is no more profit for them than for the next guy. So let’s not give them “weapons” to do that. I can totally live with them not being part of my economic and social circles.

In my opinion, this feature should not be part of the core at all. If you give the core the ability to incorporate fees, you will make transaction fees. This is not unlike what Jacques Ellul blamed technology for. People will start wondering “well I can earn money with my node by just activating a parameter on my node because it is part of the core. Well why not… I was not in for the profit but if there can be profit LET IT SNOW B*TCH!” And bam now we have hundreds of nodes collecting fees just because they can. Not because they need or because they intrisically want, just because they can…

I think this is a really bad idea that has absolutely no reason to exist in uCoin and that can only make uCoin worse.

4 « J'aime »

Yes you are, uCoin protocol is agnostic of how transactions are processed for their inclusion in a block.

Very nice answer @scith :heart:

The majority of this post is related to fee-based priority. Please see the end of my post for the section regarding certification-based priority!

Some Quick Review:


Fees are optional, but they help you out!

If you decide to go for fees, I have a few suggestions for their use:

  • every member of the community contributes a small portion of their resources to writing blocks. [1]
  • have a very small fee that can be increased, but not decreased, by the sender. [2]
  • every transaction (other than a minimum ([6]) UD transaction) has a fee by default. It can be disabled on a per-transaction basis. [3]
  • fees are not dependent upon the size of a transaction. [4]
  • the fees contained in the transactions of a block are awarded to the miner. [2] [4] [5]
  • if a certain portion, P, of one’s transactions included fees, then they get a reward (perhaps one of the following): [6]
    • their certifications last longer, [7]
    • their transactions are prioritized slightly, [6] [8]
    • their membership will last longer. [6]

[1] (Similar to I2P; I2P is built such that every user participates in the network.)
[2] (By small I mean: a quantity of UD small enough that it does not become a burden to those sending transactions.)
[3] (This makes it a bit harder to accidentally send a transaction without helping the community maintain their resources.)
[4] (This prevents very large inputs from incurring a large fee, as can happen with Bitcoin-based currencies.)
[5] (If we use fees of a significantly small magnitude, then the fees won’t make anyone rich; they’d just be an extra reward to the miners be they big or small!)
[6] (An arbitrary constant. Discussion may be helpful in fine-tuning it.)
[7] (This may not be a good idea if large stakeholders decide only to certify other large stakeholders or friends; it will keep them from having to make an effort to keep their sub-community connected and might prevent the churn of certifications.)
[8] (Those whose transactions are prioritized might have the priority be based upon the amount of UD being sent along with the fee being included?)


The NEW Part!

I have a completely different concept for prioritization of transactions: certification-base priority!

  • if the member (m) has more outward certifications than inward, he gains priority.
  • if the member has many unique links within (s) steps, then he gains a proportional boost.
  • if the member is sending a large portion of their UD, he gains a boost proportional to the amount of his UD he is spending.

I have put together a TeX document that (roughly) lays out the calculations for priority. It is quite lengthy because it attempts to take every variable (other than fees) into account: http://www.texpaste.com/n/1bh6lzhc