Jump to content

Sukrim

Platinum Member
  • Content Count

    1,761
  • Joined

Everything posted by Sukrim

  1. If you are querying a server that has to dig into its database for ancient transactions you're not really into performance anyways I guess, also I'd expect a proxy to run on the same machine and localhost is quite fast usually... ;-)
  2. Still useless if they expect to be able to retrieve random transactions from somewhere. All it takes is an afternoon to add a proxy in front of rippled and filter out memos when serving unauthenticated users if this becomes a problem. There are less than a dozen full history server operators probably on this planet, so I wouldn't rely on this data being available.
  3. It has been enabled on TestNet so far. There is no central public place where validator operators are committing to enable/disable amendments, so we can only hope that eventually the ones on the default UNL will also vote to enable this amendment.
  4. There are tons of other transaction types that can interfere with your account balance (which one actually? XRP? Then EVERY valid transaction signed and submitted by you will change the balance since fees are deducted). The data API is NOT reliable at all, if you implement some service on top of XRPL, I'd recommend implementing it against rippled (so the s1.ripple.com or s2.ripple.com cluster) and operating a server yourself as primary node to connect to (with some public ones as fallback). https://xrpl.org/data-api.html
  5. You could just post your address and be done with it, but probably you want something a bit more sophisticated (e.g. display one destination tag per customer or transaction/order). Accepting XRP doesn't need any extra software, it is permissionless after all - but you might want to be a bit more specific what you expect from such a "payment gateway". Lastly it might be a better idea to be paid in USD than XRP if you are calculating in USD - both are possible on XRPL...
  6. Personally I'd prefer a more standard based approach, e.g. a Prometheus exporter or something that emits metrics in the OpenMetrics format instead of custom JSON.
  7. Derive the private key from the secret and calculate the matching public key, then encode it in base58 in Ripple's alphabet and see if it matches. If you sign a transaction but never submit it, nothing gets burned by the way.
  8. Well, currently it doesn't use any other digital asset. It certainly could though, the concept is not exclusive to XRP in any way. ... source?
  9. So everything should be scaled down accordingly? Also: Bitcoin is still inflating its monetary supply, XRP supply is shrinking. Anyways, code it up and let's have a discussion in the pull request on GitHub about it. Personally I think it won't bring much benefit, but I could be wrong of course.
  10. Too much spam and insults ("fudder") here, not going to answer this one.
  11. 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?
  12. 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.
  13. 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.
  14. 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%.
  15. 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.
  16. 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.
  17. In that case the signature would be invalid and/or the transaction data would be invalid, so it is practically impossible to happen.
  18. 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?
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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".
  24. 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.
  25. They can give some good indications, but they are not proof.
×
×
  • Create New...