Bitcoin Forum
December 09, 2016, 09:55:57 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: A generic protocol for cryptographic assets  (Read 4086 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 25, 2012, 12:08:44 PM
 #21

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).
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
January 25, 2012, 12:43:01 PM
 #22

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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 25, 2012, 03:04:36 PM
 #23

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
February 11, 2012, 12:56:31 PM
 #24

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?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!