Jump to content
Professor Hantzen

The Fate of Fees

Recommended Posts

I was thinking about transaction fees, and had an idea - maybe it's come up before.  I'm tending on the side it's actually a bad idea, but I thought discussion around it might be useful.

At the moment, transaction fees are sent to black-hole address - ie, destroyed.  Given that the effect on the value of XRP is negligible in this regard as the amount destroyed has been very low, I wondered if something more useful could be done with them.

What would happen if fees were divided up and given to validators as a kind of "payment" for providing validation services?  Validating nodes cost money to run, but provide little to no reward.  It's arguable this has kept the network small.  It's in contrast to just about every other crypto currency or network, where nodes are rewarded for providing their services - assuring expansion and adoption, two things Ripple may have missed out on somewhat.

If fees were raised from their current - very cheap - levels, they could potentially offset the cost enough to have a meaningful effect.  This could further be tuned by making fees proportional rather than fixed.

Some problems:

1) It incentivises validators to increase the amount of transactions being placed on the network.  I'm not sure how this would play out.  Obviously they could only attempt to increase the number of transactions in an indirect manner, as paying for them themselves would provide no advantage.
2) An increase in validators would result in a decrease in fees received, incentivising validators to discourage other validators from providing services.
3) The above two together essentially open a new attack vector.

There are probably other considerations, and I'm not sure if the potential benefits would outweigh the negatives, or if those could be mitigated somehow?

Share this post


Link to post
Share on other sites

There are two main problems with this:

1) The whole point of the consensus design is that you don't need agreement on who the validators are. But this scheme couldn't work without agreement on who the validators are.

2) Security would be weakened by this scheme as now validators have an incentive to sabotage each other rather than an incentive to cooperate.

But also, it's not needed. Running a validator is no more expensive than running a Bitcoin full node. Those don't seem to need to be incentivized.

Share this post


Link to post
Share on other sites

Thanks!  Yes, I'm really not sure what could be done about the sabotage issue, though thinking about Bitcoin made me wonder if miners haven't survived given a similar situation.

Regarding point 1, could this be addressed say, by tracking participation in the consensus process (the "Agreement" value?), and then using consensus itself to decide where to award the fees collected during the previous closed ledger?

There are presently ~30 validators listed at http://validators.ripple.com (excluding testnet), vs Bitcoins ~5000.  Is that accurate/ideal?

Share this post


Link to post
Share on other sites
Thanks!  Yes, I'm really not sure what could be done about the sabotage issue, though thinking about Bitcoin made me wonder if miners haven't survived given a similar situation.

Regarding point 1, could this be addressed say, by tracking participation in the consensus process (the "Agreement" value?), and then using consensus itself to decide where to award the fees collected during the previous closed ledger?

There are presently ~30 validators listed at http://validators.ripple.com (excluding testnet), vs Bitcoins ~5000.  Is that accurate/ideal?

If Ripple could make it real simple: installation ready on iMac and for dummies, than there would at least be one more


Verzonden vanaf mijn iPhone met Tapatalk

Share this post


Link to post
Share on other sites

How about a combination of both validator and market maker, or pay the fees to market makers. If you validate and provide liquidity then you earn the fees... I know the market maker program is going allow market makers to earn XRP directly from ripple, but I guess just another way to bring in liquidity, maybe to gateways and smaller market makers, maybe something to support the community / developers?? I know ethereum classic had a new blockain coming out to incentivize development of ETH classic by paying developers, something like that. I'm sure somebody has already thought of most these ideas though, and there isn't much of a community anymore...

Or offer to pay the fees to ILP connectors who use RCL, I know that's basically what is being done with the MM program, but again offer it to connectors who are not yet with the program, or if they run out of XRP for the MM program...

Edited by rippleric

Share this post


Link to post
Share on other sites
5 hours ago, Professor Hantzen said:

At the moment, transaction fees are sent to black-hole address - ie, destroyed.

Transaction fees aren't sent to blackhole addresses: they are, actually, destroyed.

When processing a transaction, if you sum up the XRP moving, you'll see that more XRP went in than came out and the difference is an amount that is exactly equal to the fee that's paid.

Additionally, the ledger contains a counter that indicates how many XRP are in existence; that field is reduced exactly by the fee amount with every transaction.

Share this post


Link to post
Share on other sites
1 hour ago, nikb said:

Transaction fees aren't sent to blackhole addresses: they are, actually, destroyed.

When processing a transaction, if you sum up the XRP moving, you'll see that more XRP went in than came out and the difference is an amount that is exactly equal to the fee that's paid.

Additionally, the ledger contains a counter that indicates how many XRP are in existence; that field is reduced exactly by the fee amount with every transaction.

Huh, I wonder where I got that idea? I was sure that was the case! :D 

So, then - what are the known black hole addresses for?  I mean, of course they are for destroying XRP - but for what reason would this be done?

Share this post


Link to post
Share on other sites
6 minutes ago, Professor Hantzen said:

Huh, I wonder where I got that idea? I was sure that was the case! :D 

So, then - what are the known black hole addresses for?  I mean, of course they are for destroying XRP - but for what reason would this be done?

Black hole addresses are addresses that none has the secret key, so the'll actually result with XRP in it but noone will ever be able to use them...it is something that litterally annoys my mind. I'd prefer to see them destroyed that in the limbo, because they still are shown in the total XRP in circulation. 

Share this post


Link to post
Share on other sites
3 hours ago, rippledigital said:

I doubt there'd be enough XRP generated to properly incentivise market makers even if it could be done technically

If fees were proportional - and comparable to Bitcoin fees of yesteryear (prior to the current situation), I think there would be enough.  But even if flat, as they are - I think it would work.  For example:

In the past three years, there've been roughly 3 million XRP destroyed via fees.  So let's take it as 1 million per year.  The fee's average are something like 0.005 - 0.012 per transaction, transactions have also increased along with fees - but those numbers seem reasonable going by the readily available visual data on the chart (https://charts.ripple.com/#/metrics - scroll down to Network Fees, order by Day).  If we shift the decimal just once, we get 10 million per year, or 0.05 - 0.12XRP per transaction, still very cheap.  For a hundred validators, thats 100,000XRP each per year.  At current prices, that's around $680/year for each validator.

Who would consider running a validator for $680/year?  That was what got me thinking along these lines anyways, but it may well be too difficult to implement, and quite late in the game to introduce such a fundamental change. Though, I find the idea compelling somehow as it feels like Ripple may be missing something like this.  There's no "reward" built-in to the system, which could be one factor in the situation of other crypto's value racing ahead on little real-world application, while XRP remains somewhat stagnant despite significant real-world developments.

Share this post


Link to post
Share on other sites
24 minutes ago, Professor Hantzen said:

There's no "reward" built-in to the system, which could be one factor in the situation of other crypto's value racing ahead on little real-world application, while XRP remains somewhat stagnant despite significant real-world developments.

I think you got to see it somewhat more in the future and much bigger than the small possible fees to gain. The incentive of running a validator will be part of the business one can built around it. Compare it with the internet. What fee does one earn for running whatever service or server on the web? You can setup your own domain and email server, but what fee can you ask per user, per email??? Even more .... How much do you pay Google, Yahoo and likes for hosting, serving your personal data and mails? Right! It's all free but those whales have found other revenue streams. Same will happen with value moving/translating services. That yet to built crowd of validators will be some of their basic building blocks - just like those GMail and GDrive servers .....  

Share this post


Link to post
Share on other sites
6 hours ago, Professor Hantzen said:

Thanks!  Yes, I'm really not sure what could be done about the sabotage issue, though thinking about Bitcoin made me wonder if miners haven't survived given a similar situation.

This is one of the key differences between bitcoin's design and ripple's. Mining is fundamentally competitive, consensus is fundamentally cooperative. Validators have to be chosen (by long-term human consensus) for their willingness to cooperate with each other.

Share this post


Link to post
Share on other sites
1 hour ago, JoelKatz said:

This is one of the key differences between bitcoin's design and ripple's. Mining is fundamentally competitive, consensus is fundamentally cooperative. Validators have to be chosen (by long-term human consensus) for their willingness to cooperate with each other.

Right, now I understand your earlier comment better.

So then, how do you see the process of long-term human consensus taking place?

Share this post


Link to post
Share on other sites
7 hours ago, Professor Hantzen said:

So then, how do you see the process of long-term human consensus taking place?

I'm not exactly sure what the best way will turn out to be. Here's my best guess:

1) A few groups will emerge who are willing to publish lists of validators. They'll likely confirm the identity of the validator operator, the jurisdiction they're in, the type of organization they are (individual, government, company). They can also report the validator's policy claims -- for example, if they claim they will accept all transactions on a non-discriminatory basis, run unmodified versions of rippled, provide 30 days notice if they will cease operations if possible, and so on.

2) Server operators will configure a list of publishers and a policy. The policy will combine the publishers and also enforce whatever the operator wants. For example, they may not want too many validators in the same jurisdiction. They may not want any validators that won't promise to treat transactions in a non-discriminatory way. And so on. You can also rate limit how fast a publisher can change its entries, to protect against a publisher who goes rogue.

3) If the system is in danger of breaking in some way, humans should detect this long before it happens. That may mean changing publishers, blacklisting validators proven to misbehave, and so on.

4) If we ever have too many validators (more than 1,000 or so) we should probably prune the list. Possibly eliminating the slowest validators from the most crowded jurisdictions or something like that.

5) To start a new validator, you would configure your machine and apply to the most popular publishers. In the meantime, you could try to convince people to add you manually. If you perform well, people should add you.

The advantage of this over mining (beyond the energy savings) is that it's clear how you manage the system to make it very resistant to centralization and respond to any misbehaving participants. You aren't beholden to whoever spends the most money on hashing power. The disadvantage is that you do have to manage it and doing that in a decentralized way is non-trivial. While mining has proven itself reliable, it has not proven itself resistant to centralization. While proof of stake in a native token can work for networks where the primary purpose of the network is to preserve the value and utility of the native token, it doesn't properly align incentives for a network whose primary purpose is something other than that.

You can pretty much use any of these schemes for any system and it will work well enough, with just one exception: You can't use anything other than consensus for something with cross-currency payments and built in order books without really nasty consequences. Otherwise, while there are sub-optimal choices, you can get pretty much any of them to work for any use case.

Share this post


Link to post
Share on other sites
I'm not exactly sure what the best way will turn out to be. Here's my best guess:
1) A few groups will emerge who are willing to publish lists of validators. They'll likely confirm the identity of the validator operator, the jurisdiction they're in, the type of organization they are (individual, government, company). They can also report the validator's policy claims -- for example, if they claim they will accept all transactions on a non-discriminatory basis, run unmodified versions of rippled, provide 30 days notice if they will cease operations if possible, and so on.
2) Server operators will configure a list of publishers and a policy. The policy will combine the publishers and also enforce whatever the operator wants. For example, they may not want too many validators in the same jurisdiction. They may not want any validators that won't promise to treat transactions in a non-discriminatory way. And so on. You can also rate limit how fast a publisher can change its entries, to protect against a publisher who goes rogue.
3) If the system is in danger of breaking in some way, humans should detect this long before it happens. That may mean changing publishers, blacklisting validators proven to misbehave, and so on.
4) If we ever have too many validators (more than 1,000 or so) we should probably prune the list. Possibly eliminating the slowest validators from the most crowded jurisdictions or something like that.
5) To start a new validator, you would configure your machine and apply to the most popular publishers. In the meantime, you could try to convince people to add you manually. If you perform well, people should add you.
The advantage of this over mining (beyond the energy savings) is that it's clear how you manage the system to make it very resistant to centralization and respond to any misbehaving participants. You aren't beholden to whoever spends the most money on hashing power. The disadvantage is that you do have to manage it and doing that in a decentralized way is non-trivial. While mining has proven itself reliable, it has not proven itself resistant to centralization. While proof of stake in a native token can work for networks where the primary purpose of the network is to preserve the value and utility of the native token, it doesn't properly align incentives for a network whose primary purpose is something other than that.
You can pretty much use any of these schemes for any system and it will work well enough, with just one exception: You can't use anything other than consensus for something with cross-currency payments and built in order books without really nasty consequences. Otherwise, while there are sub-optimal choices, you can get pretty much any of them to work for any use case.

The best example of a well managed decentralized network is the internet itself. Managed where needed ( free to chose veriants on .com like .xxx for a long time were not allowed by the "managers") but overall free to use by all...


Verzonden vanaf mijn iPhone met Tapatalk

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×