Jump to content
nexus5

Higher Transaction Costs

Recommended Posts

6 minutes ago, tulo said:

Why same open ledger means also same open ledger fees? Isn't the fee calculated on the local load and thus different? Unless the load is calculated on the open ledger...

A server will calculate the open ledger fee based on the number of transactions in the open ledger and metrics based on network performance from the consensus process. It will elevate that fee if it is locally overloaded, but it has no choice in that case. If you are handing it more transactions than it can handle, it has to limit you somehow.

That mechanism probably doesn't make much sense anymore. If it's overloaded with valid transactions, the open ledger fee will shoot up anyway. If it's overloaded with invalid transactions, raising the fee won't help since an invalid transaction never pays a fee anyway. In fact, I'm not sure this mechanism still exists in the code. It might have been removed with the fee queue changes.

Share this post


Link to post
Share on other sites
40 minutes ago, JoelKatz said:

Your server will only relay a transaction that is likely to claim a fee, unless you modify it to relay "junk". If a server sends too much junk, other servers will close their connections to it. You can still make outbound connections, of course, but servers will limit their inbound connection slots aggressively and drop inbound junk senders very quickly. A validator should not accept inbound connections from unknown sources, so the only way to send it junk is to wait for it to connect to you and send it junk -- but then it will just close the connection.

I was wondering, how does the rippled server decide to which other rippled to (outbound) connect to? Do these outbound connections always contain the validators from the local validator list? And are candidate transactions 'exchanged' between peers in both directions? Also related, does it hurt the network if I do not allow for inbound connections or can I expect better results if I allow for inbound connections? 

Share this post


Link to post
Share on other sites
12 minutes ago, JoelKatz said:

The rippled server makes outbound connections two ways. One way is based on its configuration. You can configure rippled to prefer to make connections to particular IP addresses and you can configure rippled to insist on making connections to particular IP addresses. The second way is dynamically -- rippled keeps track of servers that it has had stable connections to and will retry those. Since rippled will cut connections to server that send it junk or abuse it, a server that it has remained connected to for a long time is likely to be reliable and stable.

Ripple servers aren't that vulnerable to Sybil attacks because the server knows what it's looking for. What it's looking for can't be forged because it's timestamped and signed. And if a server isn't getting what it needs, it will know it.

Transactions are currently flooded on the network. That means that if a server sees a transaction it has not seen before that it thinks is likely to claim a fee, it will send that transaction to every server but the one(s) that sent that transaction to it.

If you don't allow inbound connections, you will be consuming other server's inbound connection slots while not adding any to the network yourself. This will reduce the network's supply of inbound connection slots. We're a very long way from that being an issue though as there are quite a few "hub" servers that are well-connected and offer enormous numbers of inbound slots.

An inbound connection might help you by giving you faster and better access to network information. But if you're poorly or marginally connected, you're probably not helping anyone. By adding traffic to your link, you're probably slowing yourself down and by sending someone else information slowly, you'll probably give it to them after they already have it. Worse, you'll wind up sending them the same information they're sending you and having the same messages cross in flight.

We have a proposed design for selective relaying suppression to improve this. The idea is that if you have a peer who always sends you information after you already have it, you squelch them, and they stop sending you stuff. If you ever don't get the information you need, you unsquelch them. This helps to preserve everyone's bandwidth, allowing servers to have many more connections. There are a few technical snags with getting this working well though and we haven't done much work on it in several months.

Thanks @JoelKatz for the elobarate answer. As matter of fact, this whole issue turns out to become quite educational. Thanks also @EdH, @wilsonianb and @nikb for chiming in

Share this post


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

You can configure rippled to prefer to make connections to particular IP addresses and you can configure rippled to insist on making connections to particular IP addresses.

Will you provide us with advanced notice before removing one of the Ripple validating nodes & replacing it with two new nodes, so that we can update our cfg files?

Will the IP addresses of the new validators be available, for those of us who configure our validators to only connect to other, trusted validators?

Will will we have access to an overview of some of the security practices used by the replacement validators, to aid in our decision making process, perhaps through an audit conducted by a third party?

In other words - will ability to contribute to the overall good & further decentralization of the network be a consideration when the new validators are selected?

 

Thanks so much to the Ripple team for all that you have done. Your forethought regarding security and attack vectors is nothing short of impressive! I look forward to a fix to this fee issue.

Share this post


Link to post
Share on other sites
JFA    4
15 hours ago, JoelKatz said:

We now think we understand to root cause of the problem and are finalizing a fix. It's actually kind of an amusing unforeseen chain of things that cause other things to happen and ultimately form a closed loop that can lock the network in a state where very few transactions confirm because very few transactions are confirming.

The root cause of the problem appears to be the way the network recovers disputed transactions (ones that were candidates during consensus but didn't garner a majority in the round). The disastrous consequence appears to be servers with large numbers of low-fee transactions in their open ledgers and not in the open ledgers of other servers. This causes inconsistent transaction relaying and artificially high fees.

I'm glad you have identified the root cause of the  problem. However I do not understand how it explains the stange and repeatable behavior where, at the same time:

  • A cannot send payment to B : telINSUF_FEE_P
  • B can send payment to A : terQUEUED
  • maxFee is set to 0.002
  • getFee is > Maxfee

The only difference between A and B is that A has a long history of payments sent (> 10000) while B has not.

image.thumb.png.d408ec7b5b4488c193b68c99a66cee0d.png

Ripple addresses

r9CtyXkbenXX3j2bxpDNX5sy9vfDZxfjn

rhz5yGX9oY16W8jtbjWr1N4zm4ak6J3cBM

Share this post


Link to post
Share on other sites
8 hours ago, Rabbit_Kick_Club said:

Will the IP addresses of the new validators be available, for those of us who configure our validators to only connect to other, trusted validators?

Validators should not directly connect to any server not under your direct control, ideally physical control. This includes other validators. If your validator is directly reachable on the internet I wouldn't want it in my UNL.

Edited by Sukrim

Share this post


Link to post
Share on other sites
23 hours ago, EdH said:

That's basically the algorithm we used to have before fee escalation was enabled. Without going into details, it was cheaply exploitable.

Why it was exploitable?

Having a common open ledger fees increase the chance of having same open ledgers on all the nodes...isn't it? With all the advantages Joel mentioned...

Share this post


Link to post
Share on other sites
23 hours ago, JoelKatz said:

Given these benefits, it's worth putting more effort into getting the open ledgers consistent. We expected the fee queue to do that, and it did until this event happened.

So the paradigm is that if the open ledger is the same, then the fees will be the same. But if something happens (a "disturbance"), and the fees disagree, then the consequence is that the open ledgers will disagree too, making it collapse because of the loop...it's like a positive feedback. There is clearly a feedback action in this system, a sort of interconnection. 

While on the other side, if there is a consensus on the fees not depending on the open ledgers (the old mechanism), then the open ledger should be consistent on all node, isn't it? I don't see why this method was changed...

Share this post


Link to post
Share on other sites
9 hours ago, Sukrim said:

Validators should not directly connect to any server not under your direct control, ideally physical control. This includes other validators. If your validator is directly reachable on the internet I wouldn't want it in my UNL.

All nodes (validating or otherwise) have to make outgoing connections to some other node(s) through the peer protocol. Otherwise they would not be able to get copies of the ledger. It is possible to manually specify IP addresses (using the [ips] feature) where your node can find a copy of the peer protocol. The default list is currently available at ripple.com/ripple.txt or r.ripple.com:51235. As Ripple works to decentralize, I hope that they will work with others to ensure that there are a consistent set of nodes that provide access to complete ledger history. It seems ideal that a validating node only connect to a non-validating node, which forwards ledger entries to the validator, but not everyone can afford to run two nodes.

I think what you are referring to is blocking all incoming connections (except on known ports that you personally use to communicate with your own validator), and binding the validator to a non-validating node that is responsible for fetching the ledger from other nodes that publicly serve it. I am talking about restricting outgoing connections to a set of known peers (i.e., the nodes in ripple.com/ripple.txt), instead of letting the validator select from anyone who has the peer protocol/port_peer enabled.

Our validator is not directly reachable via the internet. In fact, it doesn't have a public IP address, and it sits behind multiple firewalls, which block all incoming connections (other than inbound responses that are related to tightly controlled outgoing connections & connections on the websocket port we use to communicate w/ the validator). All connections in/out of the validator are restricted to a VPN tunnel through iptables rules. We also have [peer_private] enabled, and we have disabled port_peer.

Edited by Rabbit_Kick_Club

Share this post


Link to post
Share on other sites

×