Jump to content

T8493

Bronze Member
  • Content Count

    2,304
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by T8493

  1. If you need to sporadically update a ledger and you have limited connectivity, you can store "commands" that update the ledger locally and transfer them to the location of your server when connection is alive. However, these commands need to include some kind of instructions what happens if command fails (for example, you can retry it). Command would be something like: "transfer X XRPs from account A to account B" (these are not ripple transactions because they can't handle "failure" - e.g. if you transaction fails and if you choose to skip it, you would need to modify sequence number on all other transactions).
  2. For rippled websockets connection there are probably several reasons (browser & library support, compression is per message and it doesn't compress entire stream, etc.). Compression is always a trade-off (between latency, bandwidth, CPU usage).
  3. I'm not sure banks aren't allowed to use public clouds. They use them all the time. Cloud services are becoming more and more PCI DSS, HIPAA, SOC, ISO etc. compliant. Well, if you talk about rippled API (and not rippled peer-to-peer connection), then the answer is a lot (maybe >90% compression). Some of these measures have already been implemented (gzip compression of websockets Rippled API connections), although savings could be much larger if you can develop encoding scheme that is specialized for your use case.
  4. There is always an option to run rippled on a public cloud with "unlimited" bandwidth. One could also develop a proxy that would run between rippled and your location and this proxy could make things more bearable (e.g. it could use binary serialization format, compression, even UDP for streaming changes, etc.).
  5. XRPCharts uses Data API v2 which uses HBase (a key-value database that runs on top of HDFS). Data API v2 gets information about e.g. transactions from rippled servers using standard APIs in (sort of) real-time (because sometimes it takes a lot of time before transactions are visible via Data API v2).
  6. XRP Ledger Escrow for "Traditional Whole Life Policy" can't work because mathematical reserves can be much lower than the insured sum (insurer can't "lock" the entire insured sum in a smart contract (escrow) when the policy is written).
  7. No, at least not until Ripple protocol changes.
  8. @Professor Hantzen, some sites that allow access to court documents don't allow public distribution of the downloaded documents. This is maybe one of the reasons.
  9. If you don't trust certificates, then you can never be sure that you're really connected to GateHub.....
  10. ILP is probably an interesting choice. But you can also look at the Microsoft's CoCo framework and how it implements smart contracts (compared with e.g. Ethereum). EDIT: if you want something more practical, you can take a look at different storage platforms (e.g. HBase, Cassandra, DynamoDB, SQL databases, warehouse solutions: e.g. Amazon Redshift, etc.) and how are they appropriate for storing and querying blockchain transactions. What types of queries can you run efficiently on HBase? What type of queries can you run efficiently on e.g. DynamoDB or warehousing solutions (Amazon Redshift)? Can you insert transactions in these databases in real-time or do you need some kind of batch processing? Can you use Hadoop/MapReduce/Spark/Spark Streaming? This problem is very realistic and it has very practical implications. EDIT 2: Ripple supports > 1500 transactions/sec. Which software solution can be used to store 1500 transactions/sec in real time? What hardware do you need and how much would it cost?
  11. For Master's degree you probably don't need "unsolved issue" (in the sense of "unsolved research/scientific problem"). You need such "unsolved issue" for e.g PhD. If you already have software that solves your problem, then your problem is not "unsolved".
  12. I don't exactly understand all this fuss regarding public IP addresses. Most users are typically behind NAT, which by default doesn't do any port forwarding or anything like that (unless you use e.g. UPnP).
  13. Do you maybe know which vulnerabilities (or classes of vulnerabilities) Satoshi had in mind? I somehow understand rationale for this in Bitcoin. Bitcoin doesn't have accounts (it has UTXOs) and when transaction is broadcasted with the public key, then UTXO becomes (sort of) "unusable". However, on the other side this reduces the size of address and it may be easier to find collision. Private keys in bitcoin are 32 bytes long, compressed public keys in bitcoin are 33 bytes long, but digests (account addresses without "parity bytes") are only 20 bytes long. Basically that means that a lot of different private & public keys can be mapped to the same public address. Bitcoin has therefore intentionally "reduced" "security strength" (FIPS meaning) from 256 bits (32 bytes) to 160 bits (20 bytes). Same probably applies to Ripple. (I'm not deeply familiar with details of Bitcoin transaction, but the general idea should still hold even if some number are slightly off).
  14. You can base58 or hex encode public keys, too. And you can add additional error detecting bytes or use some other error correcting/detecting scheme. These error detecting/correcting codes are a completely different problem.
  15. Ok, this is obvious, but is this the only advantage? Discrete logarithm problem is already hard (you can't calculate private key from public key) and this "obfuscation" only works for accounts which have never submitted any transaction (how many accounts have this property?). But on the other side, each verification has to calculate SHA256 and RIPEMD160 digest.
  16. Is there any special rationale for account ids being digests (SHA256+RIPEMD160) of public keys? Why not just use public keys for account ids? Public keys are already publicly visible when you broadcast the transaction. Account id = string that starts with r
  17. IF it is UTC.... But this is probably not documented or part of any public "service contract". EDIT: when you export this CSV file, exported times could be easily converted to your local time zone. Or they may even use some non-UTC timezone settings on their servers (they operate from Slovenia). EDIT 2: even if it was UTC, spreadsheets could treat it as being in local timezone.
  18. The problem with two columns is that you lose timezone information.
  19. There is an option that treats text between two quotation marks as one column (in this case comma won't "split" the column in two columns). @gregor, maybe you could output dates and times in ISO 8601 format with timezone. Your date/time format is non-standard and cannot be easily parsed, sorted, etc.
  20. Yes, although technically secp256k1 and ed25519 private keys are just integers (and you can use the same private key (modulo some large number if it is too large) in both cases). I was trying to explain to him that if the signature scheme is broken, then you need to replace entire signature scheme and not just generate new private keys for the broken signature scheme.
  21. What do you mean by "collision"? Generating a random number (private key) equal to some other fixed number (other private key)? Or generating such random number (private key) so that the associated public addresses are the same (Ripple uses RIPEMD160 hash function which outputs 160 bits)? I think the answer to the question is actually a birthday paradox problem and not binomial distribution.
  22. You need to change algorithm (signature scheme) and not private keys.
  23. Every now and then mathematicians come up with new classes of weak elliptic curves (e.g. "anomalous" elliptic curves or some curves that don't satisfy the so called "MOV condition") Maybe secp256k1 will be in one of such classes. And cryptographers weren't able to come up with completely satisfying proofs that DSA/ECDSA schemes are "secure" either. It also looks like EU is a little bit sceptical regarding DSA/ECDSA use (and some nations have their own implementations of EC signatures). But I concur that nothing will happen overnight.
  24. @klasurekar, how do these phishing sites work and why doesn't GateHub "new device" email prevent such attacks? It looks like attackers submit username/password from other IP address and not from the user's IP address.
×
×
  • Create New...