Jump to content


Bronze Contributor
  • Content count

  • Joined

  • Last visited

  • Days Won

  1. Higher Transaction Costs

    Exacly...the XRP I spent in fees were worth the learning
  2. Questions on fees

    None knows....who worked on that? PS: thanks for the detailed answers
  3. Higher Transaction Costs

    I'm always answered that there is a magic mechanism that drops the connection...but where is the code? Is IP spoofing proof? Do you mind if when I'll find the time I try this against Ripple's public nodes?
  4. Higher Transaction Costs

    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...
  5. Higher Transaction Costs

    Well, but my validator will relay it to all other peers (I know, it's equivalent to send it directly to all the peers), consuming bandwidth and CPU of all other nodes...isn't it?
  6. Higher Transaction Costs

    Have you ever thought about having a (much simpler) separate consensus on the network fees, such that the open_ledger fee for every node is the same in all nodes?
  7. Questions on fees

    Why? It was the most interesting... They share the information how and how do they react? Code pointer? Why would I want to specify a fixed fee instead of a maxFee? Isn't always better the second one? PS: thanks for the answers
  8. Higher Transaction Costs

    I'm not saying it is possible/easy/cheap but it's the only way I see it doable. Actually it is not that hard to test. You could setup some bots that spam lots of transactions that cannot claim any fee to your validator. You won't spend any XRP and you can check the status of the validator, if the network is saturated, if the CPU/memory have higher use and so on...
  9. Yeah...I imagine Ripple giving away 5M XRP to flashFX such that they can offer high liquidity AUD:XRP with tight spread (also losing some XRP), the volume increase because of the nice spread and other MM could kick in because the volume is higher...
  10. Higher Transaction Costs

    Well, not now, since the network is "centralized". It's enough to attack the 5 Ripple's validators to disrupt the network. And the attacks could involve (I'm not saying it is possible) only the 5 validators with transactions that are not relayed to other nodes nor included in the ledger...so other nodes wouldn't see anything.
  11. XRP Rings - Coming soon!

    Then we're gonna have the XRP illuminati holding that ring. With that ring we'll be able to open secret places around the world where the XRP's secrets are stored. In the next millennium people will look for the holy XRP instead of the holy grail. In Dizer's island party everybody will be initiated to the XRP's illuminati! Say hi to the holy XRP!
  12. Questions on fees

    It's really hard for me to understand the whole picture. If the queue is local it means that maybe in my server there is no queue, so I don't get a ter_QUEUED, but then the transaction is relayed to other peers (Ripple's validators for example) where there is a queue, so my transaction goes into the queue. How can I know now that my transaction is in the queue of some other servers while it is in the open ledger of others? Example: in my rippled there is no queue, so the transaction is relayed to the 5 validators. Now in three of them it enters the queue, in the other 2 it enters the open ledger. The consensus won't validate my transaction because it's only in 2 of the 5 validators open ledger?? getting complicated It says a different thing in another quote in the documentation. Look at my previous post. Also if I keep spamming this kind of transactions MAYBE it won't use (lots of) memory and CPU because they are discarded, but it could potentially use lots of the bandwidth. Isn't it? And I think (not sure at all) that the load factor is also based on the performance of the I/O. Yeah, but if my rippled has a local fee higher than the open ledger one, why would I pay more fee to relay that transaction which would need a much lower fee to go into the ledger? I really don't see the point of it. I see much more the point of having a "network" fee that is known to all peers based on which the transactions are discarded or not.
  13. Higher Transaction Costs

    Yeah it seems what it's happening now...there are many transactions from some users (I identified 3) that are going in the validated ledger paying 0.000011 XRP as fee, while other transactions to go in need 0.5, 1, 10 XRP...the point is that having consensus also on the fees is not an easy topic. I.e. finding a good DISTRIBUTED policy to escalate the fees in the network might be challenging. The point is that the current solution is not well documented, otherwise people could give some feedback. I did some works for consensus on dynamical systems (http://www.cds.caltech.edu/~murray/preprints/om03-acc.pdf) and I think some of those concept might be useful for this kind of work.
  14. Higher Transaction Costs

    Do you know what happens if I put a cap in the fees and then the cap is not enough for the open ledger? The transaction fails, but how many XRP are taken from the account? This is not clear from any documentation...
  15. Higher Transaction Costs

    In part I agree because now the product is 100% in the hands of Ripple, but what will happen when XRPLedger will be decentralized? I think we cannot blame Ripple of what happened. The code is there and public, sort of documentation is there, the API are very well documented. I'd read any freaking line of code and documentation before moving millions of USD worth of capital via XRPLedger as the user was doing.