Jump to content


Platinum Member
  • Content Count

  • Joined

  • Last visited

Everything posted by Sukrim

  1. https://github.com/ripple/rippled/issues/2601 would be a better solution than rolling out the same key on multiple servers (PLEASE DON'T DO THAT!). The agreement score is mostly cosmetic and can vary slightly depending on the place that's measuring it. I wouldn't really give much thought to it.
  2. About the server version, yes. About the amendments contained in that version... well, that's a bit more complicated. In theory you can also choose which features are enabled in your web browser, in practice you probably will go with whatever your browser vendor sets as default initially and only deviate if you absolutely have to (e.g. to enable beta features or to allow a connection that the browser sees as insecure because it doesn't know the CA). If you're already updating consciously anyways, I don't see any harm in also asking the server operator for things (like votes) that the server software simply can not know or assume to know about the owner's intent. One operator might update because she heard that the new version has better performance, another one might feel passionate about a different feature and someone else just wants to run the latest and greatest. Choosing a server software version shouldn't mean that this implies any type of vote for/against any amendment. A similar topic by the way are fee and reserve votes which are also set to default "recommended" values in https://github.com/ripple/rippled/blob/develop/src/ripple/app/misc/FeeVote.h with no explanation how these recommendations were chosen or when/how/if they might change. I was arguing for higher reserves already a while back when the price of XRP was even higher, what would be necessary to review and merge a change to these recommended default values for 1.3.0?
  3. If you couldn't then it would be too late, because you'd only find out after the fact. Using a hosted and trusted solution like BitGo or Polysign might be a viable solution after initially trying out how your system could work on the TestNet.
  4. Yes, but in the case of switching to versions that contain new amendments, these should be reviewed manually anyways before the update to know if they (currently) should be "vetoed" (voted "no") or not. IMHO it is part of the responsibility of operating a validator to vote on these things (including fees and reserves by the way), so making people choose instead of silently assuming consent might be a good compromise to offering "abstain" votes and more complicated schemes around that.
  5. Validators should never automatically pull updates! That's a recipe for disaster, because whoever controls the place that offers these updates would control the whole system. A compromised repository at https://mirrors.ripple.com/ could mean major efforts including coordinated ledger rollbacks would be necessary if validator operators blindly update from it. https://developers.ripple.com/update-rippled-automatically-on-centos-rhel.html already mentions the possiblity of outages as well, I don't agree with the recommendation for automatic upgrades there, especially for validators. Yes, starting with e.g. 1.3.0. Since updates should happen manually anyways, it would be easy to display something already when updating/installing the package and/or write an error message to the log if amendment votes are missing. Validator operators on Ripple's UNL are in a shared Slack channel anyways, so you could also inform them, other ones would just need to read the patch notes I guess. I imagine to simulate the existing behavior it could also be possible to offer "agree to everything except..." (and maybe "disagree with everything except..."?) options that allow for more automation. I would not like to see them implemented, but it could be argued that the first one is already the current behavior and it should be possible to keep it, in case someone wants to experiment or really wants everything enabled asap without even knowing what it is, as long as it is supported by rippled.
  6. You could require an explicit yes/no vote on all votable amendments before a server can validate ledgers instead of defaulting to anything (yes/no/abstain). That way "updating without thinking" cannot happen, as the server simply won't start until it knows explicitly the votes on fees, reserves and amendments that its operator wants to cast. Explicit is better than implicit! What's also really bad by the way is the bleeding of JIRA ticket number into amendment names, especially considering that these tickets are private and their contents are not published. "fix1368" might be a useful name if I can look it up on https://ripplelabs.atlassian.net/, but for anyone outside Ripple that name is just random. It got a bit better lately, but even the quite recent version 1.2.0 contains the "fix1578" amendment. (I guess you wanted to link to something else? Probably https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/Feature.cpp)
  7. It should. Instead of writing code yourself, maybe you can try the ldb tool? https://github.com/facebook/rocksdb/wiki/Administration-and-Data-Access-Tool
  8. So did you learn how to drive by reading a website and tweeting about what to do now that you got on the highway? I'm just saying that in my opinion you'd benefit more from a few driving lessons with a driving instructor than asking a veteran car designer about how a handbrake works. Good luck with your venture and good luck with keeping those keys safe.
  9. Not in the node database. How should that even work, there are sometimes thousands of different versions of the same addresses' AccountRoot object in there (just think what the XRP balance of an account should be that you look up from the database). He needs the 0x4D4C4E00 prefix, the full encoded specific AccountRoot object and the (Index) hash you mention to actually get an instance of an AccountRoot object from the node store. (and I know that this is a bit weird that you need the full object to even get the hash to look up the full object... that's why you have the SHAmap trie to break this circle - but to descend a SHAmap via the index hash you mentioned, you need its root node and the hash of that one is in a ledger header)
  10. There seem to be too many fundamentals missing to effectively help in an async written format like this forum and if I really go into the consulting business and do hand-holding for someone who's reaction to a JSON-RPC call is "LOL, squiggles.", I expect to be paid for it above market rates up-front.
  11. I re-wrote parts of NuDB I needed in Python, though I still need to fix that stuff up to actually publish it. There's also no real demand for that stuff anyways. "nudb.fetch(query_hash.to_bytes(32, byteorder="big")" is probably not really helpful if you don't have the implementation behind that... ;-) Maybe you have issues with the correct byte order in your hash (it has to be big endian)? Yes, keys/values should be the same no matter the backend, though values can be compressed in several different formats (https://github.com/ripple/rippled/blob/develop/src/ripple/nodestore/impl/codec.h) so don't expect raw values to be the same across servers/databases. According to the following query (https://developers.ripple.com/websocket-api-tool.html#ledger): { "command": "ledger", "ledger_hash": "26706B14D370E69DE1F3A7ED6972CABC8FD249D3EB55510178A4F6765F58E69D", "binary": true } You should get the following value for the key "26706B14D370E69DE1F3A7ED6972CABC8FD249D3EB55510178A4F6765F58E69D" (maybe after decompression): 02C612E501633DDECCEF1A6BD5AB292ED5C988A58F71909262FE055F30830832F3C4305D5AC44A2AD5251667FB0C7D64D4735958B34400D15C599D073E007B4F7D06F309F1559C91C73284D054AC346E5A094B24311CD2BBF9AEB72C5F819D0A99AE9F8BC8B1ACCA61CC6B7024462AC124462AC20A00 Full answer: { "id": 1, "status": "success", "type": "response", "result": { "ledger": { "closed": true, "ledger_data": "02C612E501633DDECCEF1A6BD5AB292ED5C988A58F71909262FE055F30830832F3C4305D5AC44A2AD5251667FB0C7D64D4735958B34400D15C599D073E007B4F7D06F309F1559C91C73284D054AC346E5A094B24311CD2BBF9AEB72C5F819D0A99AE9F8BC8B1ACCA61CC6B7024462AC124462AC20A00" }, "ledger_hash": "26706B14D370E69DE1F3A7ED6972CABC8FD249D3EB55510178A4F6765F58E69D", "ledger_index": 46535397, "validated": true } }
  12. Are you sure that this ledger is in your database and that this is the correct way to get data from a RocksDB database? I personally use NuDB and generally write Python, so I can't help much with your code snippet without context up there, but in general you should be able to get a blob of data if querying for the ledger hash as key. Code for rippled should be probably in https://github.com/ripple/rippled/tree/develop/src/ripple/nodestore
  13. This was a trade, not a transfer. Handing me e.g. 1 US cent is not enough to get 1000 EUR from me and this transaction is trying to make an even more ridiculous trade than that, value wise. The higher fees are because the sender signed a transaction with 7000 drops as fee, they could/should have spent less on fees probably.
  14. The clearest explanation I've found for the different formats is https://github.com/rubblelabs/ripple/blob/master/data/doc.go No, you can not just hash an address and pull out an account from the node database.
  15. Ich muss den Verkauf von XRP versteuern und auch beweisen können, welche XRP ich verkauft habe. Deklarieren muss ich es nur, wenn ich Steuern zahlen muss (also die XRP jünger als 1 Jahr sind), allerdings muss ich bei einer Stuerprüfung nachweisen können, dass ich eben eine ältere Tranche verkauft habe. Beweispflicht ist natürlich bei mir. Wer XRP in EUR tauscht zahlt auch Steuern, das ist in dem Fall aber rel. irrelevant. Ich rede nicht von KeSt sondern Einkommenssteuer auf Einkommen aus Spekulationsgeschäften. In Österreich: Sondersteuersatz von 25% (oder waren's 27,5%?) auf Kursgewinne aus dem verliehenen Grundstock, KeST auf die erzielten Zinsen zum Tageswert des Erhalts.
  16. Spannendes Finanzamt, in Österreich würde da einfach der aktuelle Marktwert bei Tauschhandel (XRP gegen Dienstleistung) hergenommen um die Steuer zu berechnen (das kann dann je nach Tranche der XRP die ich verwende natürlich steuerfrei sein). Ansonsten würde ich ja einfach alles statt mit Euro nur mehr mit Kartoffeln oder wasweißich zahlen.
  17. It would be really illuminating to see the latest vote on each amendment per validator on https://xrpcharts.ripple.com/#/validators
  18. Looking at the UNLs in use out in the network using the /crawl endpoint, in practice they currently do.
  19. Amendments are usually introduced if transaction processing is impacted, so a replay of all transactions in a certain ledger might come to a different result with or without the amendment. I don't think that there was a lot of care taken that pre-amendment ledgers are processed with pre-amendment code if replaying them once a certain amendment has passed, so you might already get different results now. Putting "opt-in-to-Amendments" behind an Amendment by the way would be slightly weird, since that only concerns an implementation detail of rippled, not the protocol itself (I assume that validators actually send votes/vetos, not imply that a missing vote means "yes"?).
  20. Imagine for example Checks being enabled for a while and then removed again. In that case, there would still be ledgers out there that contain Check objects which rippled should be able to (de-)serialize and display ideally instead of crashing or showing just some random-looking hex numbers instead of nicely formatted JSON when you ask for the contents of these objects. The transaction processing part probably could be ripped out, the object descriptions etc. not so much (at least not without causing some pain later).
  21. I just think there's a difference between opt-in and opt-out (amendment voting is "opt-out" currently). Currently every amendment in the code would become enabled if enough people just update their node software, there needs to be explicit action taken by enough validators at each update that introduces a new amendment to the code base to keep it from being enabled. Making amendments "opt-in" (instead of maintaining a "[veto_amendments]" section, validators would maintain an "[amendments]" section until the threshold is reached) might make it easier to have more experimental/controversial amendments out there - and changing the default voting behavior wouldn't even require an amendment itself. Isn't it simply crazy that probably most validators out there (that just aren't in the Ripple recommended UNL) vote in favor of SHAmapv2?! About your features: 1) is possible by doing an Escrow instead. There could also be a field added to Checks that doesn't allow the sender to cancel before expiry. This could be added on top of the current implementation later with little impact (consider all current Checks to not have this field). 2) is possible by doing a single transaction paying myself in a different currency instead which also wouldn't hinder any further extensions of a CheckCash transaction to make this transaction atomic and save a transaction fee of a few drops. If your fear is that these features won't be used anyways, I'm not sure if adding even more features on top before knowing if they are even popular is worth it. About TickSize for example my issue with it is that I want to set this per currency, not per issuing account. I assume this might be similar for others. Also as yxxyun said, gateways are rare these days. Checks would be a feature that they need. This features is in purgatory for over a year now, even though it would have real benefits for gateway operators (would ease the huge pain of bootstrapping customers - "first get 25+ XRP, then create a trust line, THEN I can give you the money you sent me!"). It is great to hear that you have ideas to improve it further (I have some ideas too for Checks) - is there some place or process to discuss this further or is that only documented in JIRA? Taking this amendment as example: https://github.com/ripple/rippled/pull/2245 implemented the ticket RIPD-1487 which is not public (https://ripplelabs.atlassian.net/secure/BrowseProjects.jspa is empty), so it kinda came out of the blue (from a non-Ripple perspective) with a full implementation of an undisclosed spec/design, was discussed/reviewed by Ripple employees and then merged. Yet Ripple (amongst others) vetoes it for over a year now for undisclosed reasons (prior to your explanation that you want more features in Checks first).
  22. You can't influence what Ripple writes in their manifest, so there's nothing to do on your end in that regard and you could already start serving a file at https://syracloud.net/.well-known/xrp-ledger.toml right now, that spec isn't going to change soon and independent of rippled versions.
  23. You mean Ripple is explicitly vetoing them, since by default a validator would vote in favor anyways, as long as it knows the proposed amendment, right? https://developers.ripple.com/amendments.html#amendment-voting
  24. This can be put into place already right now by the way, so no need to wait for 1.3.0 for that one. :-) (https://ripple.com/.well-known/xrp-ledger.toml ) The first part can also be done already (afaik all non-specified fields in a manifest are just ignored by rippled), there's just no good way (other than running the latest beta) to actually display the domains that a UNL registry claims that validator pubkeys belong to.
  25. Especially considering that Checks are available on the TestNet for a very long time already.
  • Create New...