Jump to content


  • Content Count

  • Joined

  • Last visited

About Eik

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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. 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. @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. 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. 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. 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. Assuming btc2ripple service was running smoothly (and not charging fee from BTC amount), I see three candidate transactions: received by bitcoin nodes at 2014-08-06 14:57:24 (1 minute after Ripple transaction) https://blockchain.info/tx/31e7a1f6d8a32c64cd66e61c6c5ef38cd96b726cac0bd5ff9960c71692246f88 received by bitcoin nodes at 2014-08-06 15:32:15 (36 minutes after Ripple transaction) https://blockchain.info/tx/ba77f35a97555a2d3cbd2baedbb54a75751af24a648766923a5279457d4af71b received by bitcoin nodes at 2014-08-06 15:42:24 (46 minutes after Ripple transaction) https://blockchain.info/tx/7b9144a15e10ee7677fcccb1f9982c26f16f1f57e86a8de032fbe24ca1f8450c All of these have already been spent again. So if it wasn't that you sent the BTC to yourself, you will never see the funds again. If you are still interested in finding out who did this, then you'll have to search some further, starting with btc2ripple service (snapswap exchange) asking for destination tag 1403334172.
  10. The 26900 XRP were converted to 0.23 BTC and sent to a bitcoin address using the btc2ripple service (=SnapSwap exchange). I don't think the exchange is still operational? Otherwise contact them and ask to which bitcoin address it was sent. EDIT: destination tag for the btc2ripple service was 1403334172
  11. 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.
  12. 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)
  13. 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).
  14. 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.
  • Create New...