Jump to content

velmet

Member
  • Content Count

    109
  • Joined

  • Last visited

About velmet

  • Rank
    Regular

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 and issues happen, ultimately only you yourself sign-off on how much to pay in fees , rippled can only suggest how much to pay to get to current ledger (you can spend less than suggested if you are OK with going to the queue), it does not perform any actions you have not signed-off on. It sort of reminds me of those issues when people blindly trust GPS and drive into the ditches, except that in this case there is no client-provider relationship since no one bought anything here and are participating in it volatility. Again you yourself sign-off on fees you pay with you secret key and you are in control of it. If your balances started changing without you signing anything, then it would be a very different kind of animal. Not comparable. Again you are conflating open-source voluntary relationship with client-provider business relationship. You do not pay to participate on RCL. Just like creators of Linux are not responsible for possible damages resulting from bugs and issues in their software or misconceptions on how to handle safely their software for their users.
  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 irresponsible to not take that into account. Yes life is hard, especially when you yourself agree to make it harder...
  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 "success"). In other words you can not be 100% sure that TX will get to ledger in 100% of cases. If one feels like counting pennies, one always can pay very little fee and go to the queue and get to the ledger this way, either way you have to monitor if TX finally got to the ledger.
  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 think Ethereum addresses do not have this checksum, and thus if you type one character wrong, your ETH you have sent to this address is gone for good.
  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...