T8493

XRPCharts uses Data API v2 which uses HBase (a key-value database that runs on top HDFS). Data API v2 get 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).

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).

@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.

Cookie?

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?

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".

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).

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).

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.

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.

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

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.

The problem with two columns is that you lose timezone information.

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.

Why not instead just check what you typed in the browser?