Sukrim

Member
  • Content count

    365
  • Joined

  • Last visited

2 Followers

About Sukrim

  • Rank
    Advanced Member
  1. I thought of offering a gateway to in-game currencies a few years back, but in the end you're most likely violating TOSes left and right by offering derivatives on in-game currencies and making them transferrable outside of the game itself, so I decided to scratch that idea and not play the whack-a-mole game with publishers. I don't think this belongs to the technical section by the way.
  2. From the wiki: "ACCOUNT_ONE has the address rrrrrrrrrrrrrrrrrrrrBZbvji, also known as ADDRESS_ONE, and is used as a neutral account, most significantly in Ripple state entries. In decimal, this account has an address of 1."
  3. There are multiple implementations for bitcoind, there is only a single public attempt for an alternative rippled implementation and afaik it cannot validate. Also the code is under a free license for both projects, so the argument "There is only a limited set of people working on the code == centralized system" is really a bad one. Is Linux centralized, because Linus approves commits ultimately? Is BitTorrent centralized, because there is only one swarm per torrent? Is voting in your country centralized, because only people allowed to vote are allowed to vote? There are lots of better arguments that could be made, "only one repo" is both wrong and not valid.
  4. Extortion/legal pressure/unenforced on the network side (if you claim that your UNL is X and it secretly is Y, the servers won't find out)/can only be verified for the past while you could switch UNLs for the current round/gives attackers an advantage on seeing which validators are disproportionately trusted to be unique and thus influential/...
  5. Then it's not "published" anyways - how would you communicate this to only a select group and enforce that the info doesn't get out by the way? And what would you get out of it? RCL, as any blockchain, thrives because of public data and external verifiability.
  6. Will there also a "simulation mode" to see how a server with a certain UNL should have voted vs. how it actually has voted on Consensus rounds to detect potential frauds? While UNLs can be published if so desired, it is very hard to prove that the published UNL is actually the one in use.
  7. Stellar's modified Consensus algorithm makes UNLs public (but I haven't seen any proof why validators can't lie there or would be punished for it). Enforcing topology is the main reason why RCL is still running centralized I guess. The hope seems to be that most/all validators will use the same or a very similar list of criteria for their UNLs. There are several reasons not to publish your UNL (e.g. you don't want to disclose that you have a validator from Iran on there as a US bank for example) and even if you publish it, you might disagree with the network from time to time for random reasons (packet loss, a slow responding node...) which is indistinguishable from you not respecting the vote of your UNL and thus having published a fake UNL and not the one you're actually using.
  8. I trust in math instead of trusting in trust, but that's just me.
  9. I don't really follow what you are saying... are you suggesting that validators should publish/sign which other validators they have on their UNL? This is private information and a mismatch there would not automatically indicate malicious intent.
  10. Interestingly, ripple.com does not have an EV cert.
  11. Which of the 50 ones are their validator keys? Why don't they publicly advertise them? https://microsoft.com/ripple.txt I don't believe any of this marketing stuff, especially since most of the validators are not publicly and verifiably disclosing their affiliation. Also, the list of "criteria" is quite bad: "Server topology Server uptime, including 24-hour incident response capabilities Speed of server updates following new releases Network agreement rate Verification with Extended Validation Certificate Public Attestation via ripple.txt file or DNS TXT record" Very few measurables, something that can be lied about with 0 consequences (if "server topology" means the server's UNL) and also forcing people to buy a useless EV cert (which Ripple themselves do NOT own - will they remove themselves now from their UNL?). How can I know if I fulfill these criteria? How fast must I upgrade to new rippled versions or how do I measure my "24-hour incident response capabilities" for example?
  12. I wonder if there is a good account explorer site that also decodes account flags that can be used for linking to these accounts. The flag decoding is important, since the DisableMaster flag matters a lot.
  13. This is a trust line for the "GCB" currency between the 2 accounts rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n and rhRFGCy2RJTA8oxkjjtYTvofPVGqcgvXWj (high and low just mean one account has a higher address than the other, to be able to differentiate them) If the limit is non-zero, this means that the account in the "issuer" field trusts the other one. In your example, rhRFGCy2RJTA8oxkjjtYTvofPVGqcgvXWj trusts rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n for 2000000 units of "GCB". The balance is still 0 by the way. If both sides have some value, they trust each other, if both are 0, then probably the flags are still nonstandard. Trust lines with standard flags are removed from the ledgerState "tree". When trying to construct a graph out of this, I recommend to create helper nodes per currency+issuer, otherwise it is a bit hard to analyze...
  14. https://ripple.com/build/transactions/#accountset
  15. It is visible in the ledger and it is possible since the private key for that account is publicly known by design. Someone used that key to set their own key as the only owner key, which doesn't look very low entropy to me: (RegularKey : "rBmVUQNF6tJy4cLvoKdPXb4BNqKBk5JY1Y"). To me the probability of this being a "lost" account is close to 0, not 100% as you claim in OP. I have several issues with your list and definitions by the way, "ownership" has nothing to do with something being a blackhole account. To make something a blackhole, the (private) key(s) that is/are allowed to sign transactions for this account must not exist. This is the case if the public keys for these private keys are extremely not random, since there is no known method to generate enough private keys to stumble across such a key by chance. Every account that fulfills such criteria (e.g. because their address is already unlikely [the Stellar giveaway] OR because they later disabled the original key and set a non-random RegularKey [the PRX issuing account]) is a blackhole account, no matter which person or company claims to "own" it. It is not enough to just set a non-random RegularKey by the way, one also needs to ensure that the asf/lsfDisableMaster flag is set (https://ripple.com/build/transactions/#accountset-flags) I'd like to see the following columns: Description / Address / Key(s) allowed to sign transactions for this account / amount of XRP locked up This would also make it easier for people like @T8493 to see why the PRX issuing account is a blackhole account (not because it starts with PRX, but because it has "RegularKey" set to "rrrrrrrrrrrrrrrrrrrrBZbvji" and probably set the lsfDisableMaster flag [haven't checked]).