Jump to content


  • Content Count

  • Joined

  • Last visited

About velmet

  • Rank

Recent Profile Visitors

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

  1. If you look at individual ledgers during roughly an hour this occurred it seems that ledgers closed every 3.5 seconds as usual but there were no transactions in at least the ledgers I have looked during this period. Perhaps simply this is due to Ripple public S1 cluster malfunctioning (since most services/people still use it instead of their own node or alternative public nodes)?
  2. My guess it is a leftover from the old days way back when XRP was not really listed as trading pair on Bitstamp but they did have option to buy XRP with USD so that the bought amount was deposited straight to your Ripple address (they no longer have this feature). They had quite large markup on the price though when buying with this feature (as compare with buying on Ripple ledger).
  3. That could explain why XRP was more expensive than elsewhere on Polo in recent days...
  4. They are BS'ing you. If you sent those XRP to correct address, they did recieve it and are in possession of it. They should credit you your XRP! Edit: They should credit you after finding out which tag you should have specified
  5. Another Google Translated announcement from their site:
  6. One can use Japan proxy to access their site (like http://proxyjapan.nu/ ). Google Translate version of the announcement text on their site:
  7. Option contract says: IANAL, but clearly this statement links this option with their agreement on this Xenon project. Would seem logical that they can not use this option because they did not deliver the goods associated with this Xenon project.
  8. While I do think that they should not publish scripts without maxFee set as best practice and that they could do a better job at expounding on the possible risks associated with fees and possible consequences in failing to understand that fees are there to prevent spam and can spike for legitimate reasons as well as bugs, this does not in any way translate to them being responsible in a legal sense since it is an opensource software (github scripts and rippled and etc.) - you use it at your own risk. They did not sell it to you and you did not give them any money to use it. It's software, bugs
  9. It does not matter how he crafted it - by some client or by bot code or by hand or some garden gnomes wrote it for him. Him signing this TX and submitting to the network is the agreement with the network to perform actions specified. If one cannot accept this, one should not use the network, because it is main principle allowing network to work. Yes, probably it was provoked by this fee inflation issue, but open ledger fees can excessively inflate for other valid reasons as well (e.g. some big network issues between validator or some huge rush in transactions with high fees). It is just plain
  10. While obviously no one here is denying that how fees are calculated could be more transparent and that what is now happenin with fees is a problem, no one robbed anyone in this situation. The one that paid 75K crafted a TX (in code or in some client) and explicitly stated that he wants to pay 75K and then signed it with their own secret key and submitted this TX to the network. Robbing involves some force from a second party, while there where non in this case, hence no robbery. Also whatever fee you pay, TX succeeds only when it finally gets to the ledger (even if initial server response was
  11. Probably not a security issue even if it is exploited by some malevolent actor to inflate fees. Also if someone failed to set max fee in their code or client then they basically saying "I am willing to pay anything". Paying 75K XRP is getting exactly what you requested.
  12. XRP is getting hammered against BTC in recent days, so doubt that this theory hold water.
  13. Try manually specifying fee size (if your client application allows it) to say 0.001000XRP. It should go to queue but make it to the ledger.
  14. I think you are missing few steps in how the address is created. After SHA256+RIPEMD160 hashing, result is hashed with SHA256 twice (at least in bitcoin, I would presume it is the same for Ripple) and first several bytes (not sure how many, perhaps 8) from this result is taken and is concatenated to SHA256+RIPEMD160 initial result. Those additional concatanated bytes act as checksum when verifying addresses. Then this concatinated result is encoded with base58 using ripple base58 dictionary (i.e. rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz). BTW, correct me if wrong, but I
  15. If it is UTC, why would one need it? Makes it less human readable also (someone could confuse with seconds or milliseconds or whatever)
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.