Jump to content


Platinum Member
  • Content Count

  • Joined

About Sukrim

  • Rank

Recent Profile Visitors

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

  1. That depends a lot on the hashing/encryption method. Which they didn't disclose. Maybe it is in a report/postmortem of that forensic investigation? Doesn't look like it will be published though, so probably this case is closed now. Good luck with getting money via a lawyer in the US from a UK based LLC that actually is run from Slovenia... but hey, closed source web wallets, what could possibly go wrong, amirite?
  2. By the way: Since the Coil platform doesn't do this, maybe you could add (also retroactively) a "posted" date to these articles? Not all information and news in crypto space age well and it would be unfortunate to have things taken/quoted out of context later.
  3. A hash is unique per transaction, but a transaction doesn't have to be unique. Most are, because a transaction signature contains a random number (derived from the private key as seed, if done correctly) and a sequence number, so it will always have slightly different content as input for the hash. SetFee transactions are not signed and don't have sequence numbers, so setting the same fee twice results in the same transaction - which then has the same hash. @xrpscan seems to think that transaction IDs are unique, so they don't display the data 100% correctly.
  4. Yeah, but "enough" also means that at least part of Ripple's validators will have to vote for lower fees, since the magic threshold for being able to veto things on XRPL is not 50%, it is 20%.
  5. Quotas, GPU support, Healthcheck and liveness probes, logging config, storage... In general https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pod-v1-core seems quite a bit more flexible than https://github.com/codius/manifest/blob/master/schemas/GeneratedManifestSpec.json Yes, I'd send a host a description of what I want to run, get a quote back and as long as I stream at least the amount that is quoted, the pod is being scheduled and run. Once I stop paying (ideally in a more graceful way after notifying the operator, since there might be some more seconds of CPU time when shutting down), the pod gets descheduled and killed. Knative is also nice, but one layer higher. On the plus side, it might be easier to reason about and to price. Besides Katacontainers, you could also look at Kubevirt or GiantSwarm's KVM-operator, but in the end you're advocating for people to pay for runing unvetted customer/attacker supplied containers or VMs (depending on the isolation model). I personally have a hard time in seeing the "smart contract platform" part of this, but it seems like a neat concept.
  6. Because the ledger state hash and/or transaction hash would change. Exactly as you describe for Bitcoin. Proof of Work is a mechanism to decide automatically between several possible chains. On XRPL you'd instead ask validators you trust to be operated by unique entities (a UNL) for the one true chain and if a supermajority of them agrees, then this is the latest tip of the chain. All predecessors follow from that, so you can come up with a different chain but you'd still need to convince a lot of other entities to use that as well.
  7. In that case the signature would be invalid and/or the transaction data would be invalid, so it is practically impossible to happen.
  8. What do you mean by "corrupted"? Transactions are only valid with a valid signature, signatures also are over the part about how many fees are acceptable for a transaction. It is not possible to just take any signed valid transaction, change something in there and have it stay valid. What is the TPS capacity of MainNet (I'm not talking about synthetic benchmarks but about actual capabilities) and what's your source for that number?
  9. Disabling the node store might also help a lot, but might make it slightly harder to get back to sync in case of a more catastrophic failure.
  10. But tracking every single token instead of tracking balances is a huge difference in resources used... you can't have cheap AND non-fungible. After all you also buy your rice in the market by weight, not by individual grain.
  11. You have ~160 bits of address space available for currencies, I'd say that's plenty enough for whatever magic swords you need to encode. another issue you'll run into is divisibility (you can't sell half a sword... right?). I personally would not build a game upon this premise (you'd need a trust line for every single item you own in a game, this can get expensive!), but you can try it out on the TestNet I guess.
  12. Tokens in the same denomination (e.g. "USD") are fungible between the same issuer, but not between different ones (1 "USD/Bitstamp" is the same as another "USD/Bitstamp", but not as a "USD/Gatehub"). To make your tokens non-fungible, you'd need to issue a different currency for each token.
  13. The next question I'd have would be about the exact mechanism of hashing and encryption that was used. This can range from negligent up to "well, users chose bad passwords".
  14. This is a clear risk, your validator shouldn't connect to untrusted servers. If you have servers you totally trust outside the ones you operate yourself, then you're really lucky (or maybe naive... ;-) ). I guess peer connections are cheap enough (resource wise) to not care about "insane" peers, I'd just allow more connections and be done with it instead of micro-managing connections.
  15. They can give some good indications, but they are not proof.
  • Create New...