A generic protocol for cryptographic assets

[Mike Hearn]

BGP is essentially a fully-trust based flood fill algorithm, these days with some manually-maintained filtering rules to make it not completely trust based. It's not really applicable to something like Ripple.

I think for Ripple it's best to give up on the idea of decentralized routing. Just do a Satoshi and scale it through brute force. Every node has full knowledge of the trust relationship graph. You can then use one of the well known graph routing algorithms on it (A* or whatever).

[1714915174]

1714915174

[1714915174]

1714915174

[1714915174]

1714915174

[1714915174]

1714915174

[1714915174]

1714915174

[jtimon]

I think for Ripple it's best to give up on the idea of decentralized routing. Just do a Satoshi and scale it through brute force. Every node has full knowledge of the trust relationship graph. You can then use one of the well known graph routing algorithms on it (A* or whatever).

That was my idea but not exactly.
Markets can apply the graph routing algorithms on the part of the trust relationship they know but they don't necessarily know the whole graph. Every client can run their own market if they want and different markets can have different policies for sharing offers and promises.
But, yes, I expect them to be mostly public. Specially the market dedicated servers (like BitTorrent trackers, they're there to assist).

I want to stress that ripple debts are treated just like any other asset and markets build the graphs directly from the offers (and promises or "binding offers").
Markets don't even know what kind of assets are being traded (with the exception of block-chain assets), only the public key of the minter.

[Steve]

BGP is essentially a fully-trust based flood fill algorithm, these days with some manually-maintained filtering rules to make it not completely trust based. It's not really applicable to something like Ripple.

I think for Ripple it's best to give up on the idea of decentralized routing. Just do a Satoshi and scale it through brute force. Every node has full knowledge of the trust relationship graph. You can then use one of the well known graph routing algorithms on it (A* or whatever).

Actually, maybe it's really simple.  You could pull a satoshi in the sense that you're broadcasting most things throughout the p2p network, but I don't think you necessarily need all nodes to maintain a global view of the trust network…maybe it's as simple as this:

- a node (A) in the p2p network announces an order (not to be confused with the trust network)
- everyone hears about it and adds it to their order books
- another node (B) sees that they have a matching order (or someone places a matching order)
- node B announces that they've got a matching order to their trust neighbors
- the trust neighbors forward to all of their trust neighbors (other than B), appending info about the route back and fees, as well as the maximum size of the order that can be filled (if it's less that the total amount of the order…credit limits could make it such that some paths are only able to do a partial fill)
- original node starts hearing back about the matching order and various paths…it selects the path that is most ideal (able to fill entire order, has lowest fees, fewest hops in the trust network, etc)…it might execute along multiple paths if no single path is able to fill the entire order

[jtimon]

BGP is essentially a fully-trust based flood fill algorithm, these days with some manually-maintained filtering rules to make it not completely trust based. It's not really applicable to something like Ripple.

I think for Ripple it's best to give up on the idea of decentralized routing. Just do a Satoshi and scale it through brute force. Every node has full knowledge of the trust relationship graph. You can then use one of the well known graph routing algorithms on it (A* or whatever).

Actually, maybe it's really simple.  You could pull a satoshi in the sense that you're broadcasting most things throughout the p2p network, but I don't think you necessarily need all nodes to maintain a global view of the trust network…maybe it's as simple as this:
...

What you want to implement is a p2p "Market" (as described on the proposal), but I prefer to leave that for later.

I'm reading about zeroMQ and it seems very interesting. Maybe it would be a good choice for implementing a simple prototype.
http://www.zeromq.org/

The more I think about this, the more changes I want to make to this draft. It still has lots of holes. I'm going back to specification and later to design.
I also want to support chains as timestamper and accounter without acting like Minters. A chain that allows users to issue their own tokens. We could call iouChain or somethign like that. But scalability and DoS attacks scare me there.

Anyway, there would be three types of tokens:
1) Tokens: Issued and accounted "centrally".
2) TokenCoins: Issued "centrally" (by anyone) and accounted by a chain.
3) Coins: Issued and accounted by a chain.

*Better ideas for the names are welcomed.

Any combination of them should be tradeable atomically. When a chain is involved, the protocol should be able to "compile" to a bitcoin transaction the part that needs to be solved in that chain.
When one of the "currencies" involved is not a basic token (but some of the two type of coins), its chain must be the timestamper (maybe a timestamper is needed if we consider "green addresses" transactions, but I'm not sure we should).
When more than a chain is involved, contracts are needed. I can imagine a trade with more than two chains by adding more secrets, but maybe there's problems I fail to see.
Would an atomic trade like this be possible and secure?

A gives btc and gets nmc
B gives nmc and gets usdCoin
C gives usdCoin and gets btc

SecretA enables B to gets the usdCoins by revealing secretB, which enables C to get the btc's if he reveals secret C, which enables A to get the nmc's using secretA (which is already public).
A must sends his secret to C for him to sign his payment, etc.
Mike, do you see any problems with a trade like this?