Jump to content


  • Content count

  • Joined

  • Last visited

  1. So, hopefully in November 2018 there will be a recommended list of trusted nodes, that each validator can choose (?) to trust containing 13 validators run by Ripple and 14 by others? Do you already have a predefined plan to monitor stability?
  2. Questions on fees

    I think exactly this was the issue of the bug. Problems with placing the disputed tx back in queue, and tx also wasn't discarded so it stayed in the open ledger, until it would finally reach consensus until finally the other validators also had it in open ledger. Something like that.
  3. Questions on fees

    @JoelKatz or @EdH, if you have time, using the above example and not knowing the transactions in the open ledger and queue, can you help me understand the recent bug? I.e. why is expected_ledger_size 53 while only 7 transaction were included in the previous ledger (32939872); why are transactions included that have a fee lower than the open_ledger_fee; and how does the hotfix fix this? Seeing this example, the explanation and the text here I can only assume something like: 1. a lot of (low-fee) transactions in the open ledger do not get validated by other validators and therefore do not reach consensus. 2. disputed transactions cannot be placed back in queue because ??? and cause ??? 3. ??? inconsistent relaying ??? 4. same problem as before 1.
  4. Questions on fees

    I don't have my own rippled to try some on, so just on the public one: Executing the fee command (as described here) on the websocket gives me this instantaneous result: I verified that in the previous ledger 32939872, the median value of all fee's are indeed 13785. Now if I verify the open_ledger_fee with the known formula: open_ledger_fee = median_fee * current_ledger_size^2 / expected_ledger_size^2 It adds up: 50061 = 13785 * 101^2 / 53^2 Now that the hotfix is not deployed yet, only 14 transaction are included in the ledger with fees: {39, 113, 113, 113, 113, 113, 139, 1000, 1200, 1200, 2000, 29393, 32897, 323347} even though the current_ledger_size when I checked was 101. @donch, if you do the same and verify what fee levels come out of the server stream, what do you get?
  5. Questions on fees

    These numbers (except for 10) lie on the line: fee = 1.5945 x^2 with x = {59, 60, ..., 77, 78} It is likely that this is the amount of transactions in the open ledger at those moments. Any chance that could be true? This would mean that lastLedgerMedianFeeLevel / limit^2 = 1.5945 Any chance you can export lastLedgerMedianFeeLevel in the datadump, next to the the fields you already have in the link you sent?
  6. Questions on fees

    I saw JoelKatz replying in a different thread: In my understanding of what I read, I think your quadratic model seems correct if there are 51+ transactions in the open ledger. If there are 50 or less, the open ledger fee is equal to the base fee. This '10' in the end of your stream might also be that: ledger is just closed, the best estimation for the next open ledger fee is the base fee (until if fills up again over the limit)? Don't you have enough historical data of fees to compare to your model?
  7. This looks like a typical task for third parties to assess. If you also run a non-validating node and receive validator outputs, you could probably predict honest behavior fairly well. Pretty intensive task if you need to do that for all transactions/ledgers, but as attestor you probably will want to invest in analyzing potential dishonest behavior (just detected mismatches and analyze those). Still you probably can only see statistical information and no certainties about individual censored transactions.
  8. Wow, thanks for that. I guess it takes some time (or, n-th expert explanation) to connect all the dots in my head; most of the information was already out there. Next question is just to see if I can get some more clarity on future use of attestors and as close as you can get to 'proof of topology'. The easy-way-for-validators-to-publish-their-UNL-that-will-come-soon™ is going to be a proven UNL of the ledgers that the owner of the validator chooses to disclose? I.e. can validators proof that they used a specific UNL in specific ledgers? Or is it going to be a publication that the owner of the validator wants you to think it used until other people can proof otherwise? I assume these UNL publications will/can also be integral part of attestors assessment of validators?
  9. Can't wait to see what wonderful ideas and implementations come out of Ripple's offices and community-members' minds related to this. Whenever I think I have a valuable brainfart on this I'll definitely share it to discuss.
  10. This, decentralization, and actual proof of decentralization are for me the biggest points of concern related to XRPLedger's future. I have yet to find a piece of information, a comment, or an idea to ease my concern. @nikb, is there any news related to my questions or your statement: (Haven't been following Ripple and xrpchat the last 2 months, apologies if I missed something)
  11. Questions on fees

    Thats what I understand from it. In case it doesn't get consensus, the 2 validators will also put the transaction in their queue for the next ledger. Until enough validators consider the transaction in the same open ledger and it can be validated. I did but I don't find anything contradictory information in it. Can you point me to the specific quote or unanswered question? I haven't seen any contradictory information. I'd suggest you try it out and see what happens. Probably not that expensive to hire a botnet for a short time. I'd suggest you first try to DDOS your own validator and log performance in order to study what happens. You can either set the required higher fee (doesn't mean you will end up paying that fee though), or you can submit it to a less loaded validator (i.e. load balancing).
  12. Questions on fees

    I am not sure what happens is you spam a validator with lower than base+load fees. I.e. whether you can DDOS a validator for free, increasing the local load cost, therewith increasing the overall transaction costs.
  13. Questions on fees

    Quotes from https://ripple.com/build/transaction-cost/#transaction-cost as referenced by ripplerm. 4. "A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be queued for a following ledger instead." 5. queue is local, "the server adds the transaction to the transaction queue and relays the transaction to other members of the network [...] When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger [...] Transactions that pay the same transaction cost are queued in the order the server receives them." 6. Your relayed transaction will not meet the fee requirements of the other validators and will get discarded by those. It looks to me you are only spamming up your own validator tx queue: "Local Load Cost Each rippled server maintains a cost threshold based on its current load. If you submit a transaction with a Fee value that is lower than current load-based transaction cost of the rippled server, that server neither applies nor relays the transaction. (Note: If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive the consensus process unless its Fee value meets the requirements of a majority of servers." 8. local load fee is to run own validator smoothly. If you bypass the code you are really only making it harder for your own validator to work properly. 9-10. if your transaction is not included in the ledger, no XRP can be taken from your account as it cannot be registered in the ledger. 1,2,7. I have no clue. I don't run a rippled (yet). Looks like 3 is answered in https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md as referenced by ripplerm.
  14. @nikb, can you elaborate on this? Is this going to be a verifiable publication of UNL used in past ledgers? Or is this going to show intention for the coming ledgers? Do you know if there is going to be proof of topology? I personally don't doubt Ripple's intentions to work out decentralization in the coming period, and I don't doubt that Ripple has some very smart people on this topic. But in crypto-space it is always about proof. Do you envision a situation where there is some way or the other (with or without publishing individual UNL's) going to be proof of topology? Or can you convince that there is no need for such a proof, and that the proof of the pudding is in the eating?