Quote from: Sukrim on August 03, 2013, 07:28:54 AM

Quote from: d4n13 on August 03, 2013, 12:29:03 AM

Cool... I've posted an API stub if you want to gather some more precise data. Look forward to your paper...

https://github.com/d4n13

Nice, I personally work simply with the web socket client in Python and rippled, but it might help others.

Currently the most limits concern the rate rippled can actually serve ledger data vs. new ledgers being created.
Maybe I'll try to put some stuff in a local redis or other nosql database so I don't kill or choke the public servers that much...

Anyways, that's details and bitcoind would also have problems if I requested the utxo set + balances for all nonzero addresses at any height...

Back to topic I guess one of the main issues would be to find someone to write a reasonably extendable client to be used by gateways and making rippled more secure and stable. There is a lot going on however, so I'm sure they use the summer not just to chill on the Bahamas with their vc funding. Wink

Edit:
About xrp and market making:
I'm not too sure if xrp have to be market makers by design. They have the very useful property of being 100% accepted, on the other hand though they are volatile. They might be useful as intermediates in paths but I'm not too sure if there is a lot of money in this as to market make, Jed would also need to trust at least one (to gain high arbitrage: a little trusted which in return is more dangerous!) IOU gateway to exchange his xrp at a profit to these IOUs.
If the gateway is already very liquid like bitstamp there will be a lot of people and lines trying to underbid you, if it is badly connected to other gateways like trade fortress, there might be a reason for that...

You are forward engineering a tiny, struggling Network to Nowhere.

Instead, you have to reverse engineer Jed's simulations of a future multi-billion $$$ network.