Topic: Decentralized BTC Stock Market [Goodbye GLBSE] - page 2. (Read 16110 times)

It looks like one can centralise stock markets pretty easily starting by eliminating the central market and having the brokerages talk to each other directly.

The back end of Marketcetera is an order router to which all your clients (your night traders, your day traders, your evening traders, your financial offer, your compliance officer, basically all your staff that need access to trading) connect and to which you also connect strategy engines and, - here comes decentralisation - the order routers of other brokerages.

The client GUI looks quite nice, take a look at http://www.marketcetera.org/confluence/display/PN/Photon

It talks FIX protocol, which is pretty much standard trading protocol. FIX is also what the brokerages use to talk to each other.

Explore Marketcetera's site, fire up the router and client yourself and try it out, and you'll see that the default setup has you talking to their "stock market simulator". Dig down into the nitty gritty of your strategy engine capabilities (the Photon client includes strategy tools) and it should become clear to you that about the only service a centralised "stock market" would add would be co-ordinating everyone's views of how much of what is for sale at what price and who wants it.

Most of the that the brokerages can get directly from each other, and they can also co-ordinate their views too if they want by using tools such as http://zookeeper.apache.org/doc/trunk/zookeeperStarted.html

To scale up - that is, to become even more distributed, handling more than just the hundreds of brokerages that zookeeper might reasonably suffice to provide synchronised views to, message buses can be set up on which many many such clusters of brokerages can communicate, using things like http://incubator.apache.org/kafka/design.html and http://www.mulesoft.org/what-esb

It is important to notice that Marketcetera does not assume that brokerages just talk to stock exchanges and to end-users but to each other. That is key, as it is clear when you look closer that ultimately the stock is exchange is basically just the biggest broker on the block. If a few hundred brokers synchronised a view well that is what the stock exchange once was, wasn't it? Just hundreds of brokers all communicating with each other at once.

We can go farther with this though, because modern personal computers can run this stuff. So even small brokerages can run it, heck even a power user individual broker could run the whole system in his back room office at home.

-MarkM-

Now that you mention it, pruning may be another argument for ripplecoin (do this on an altchain) if all inputs are "tagged" with the issuing address. Tagging the inputs would be more efficient than tagging the outputs, right?

As said somewhere before, the "color conservation rules" would also be enforced by the chain protocol.

As far as I understand, he wants to use Bitcoin blockchain as a medium of transmission for signed, timestamped messages. On Bitcoin protocol level only signatures are checked, but not message contents.

These messages are interpreted with a special client software which will then maintain current state: i.e. who owns what.

I see a number of problems with this approach:

• To compute current state you need full Bitcoin blockchain. It isn't compatible with pruning. Thin clients are not possible.
• It makes rather inefficient of Bitcoin blockchain. It is, of course, possible to do implement signed, timestamped messaging with much lower overhead.
• Since protocol has to deal with concurrency, it will likely end up being rather complex, but still prone to all kinds of race conditions and stuff.

So, frankly, I don't see it as anything more than a curious mis-use of blockchain.

It is interesting to compare it with colored coins, though. Colored coin protocol is more integrated with Bitcoin protocol: colored coin transactions are Bitcoin transaction, and they have to follow Bitcoin conservation rules, but they impose additional rules (conservation of colors).

Thin colored coin client requires more information than thin Bitcoin client: besides basic information about transaction it also needs information to check correctness of coloring. But still, it doesn't need to download full blockchain: only path which goes from genesis to current transaction is required.

Why the use as currency should be prevented?
What's wrong with voluntary credit currencies?
What's wrong with high frequency trading when there's no insider information (today the privileged class knows prices in advance and abuses this through high frequency trading)?

That's a good reason to use a separate blockchain. It slows down the trades, which prevents two potentially harmful things from happening: high-frequency trades and using shares themselves as currency. (At least for the latter it might not prevent it outright but would make the shares less useful as a currency.)

This is true for OT's "untraceable cash" and two-phase Ripple, but not for ripplecoin or colored coins.
The credit/smart property can be moved even when the issuer is not connected.

And I'm not sure your proposal will work or I've even understand it.
Why do you want to put the orders in the chain if the chain protocol is not going to enforce it?
Are you talking about a fork too?
In any case, putting the orders in the chain sounds already non-optimal to me.


In the ripplecoin thread (not sure if here or in the ripple mailing list), we came to the conclusion that a hostcoin cash was probably the only way to incentive miners effectively. We considered paying fees with the credit/propery claims itself, but probably miners would not be interested in such an uncertain reward or a lot of transaction would be excluded for not offering "the right currency".

This other solution doesn't convince me:
https://en.bitcoin.it/wiki/Alternative_chain#Incentivising_non-resource_based_chains
and I don't think it's compatible with cross-chain trade.

But this may be feasible by paying the fees with an extern chain cash (bitcoin) as described here:

https://en.bitcoin.it/wiki/Alternative_chain#Paying_for_resources_on_alternative_chains_with_Bitcoins

A first problem is that you're making the altcoin protocol dependend on the bitcoin chain.
"Why is that a problem?" you would say. Well, not really a problem per se, but it would be "unfair" for freicoin.
Not only because you make bitcoin more valuable with this new fee use...
Once your protocol is dependend on another chain, you no longer need the cross-chain contract to atomically trade with it. You can make the part on the other chain the commit itself.
That's what I proposed for "trading across chains" before the contract solution existed. Sorry for introducing another made up term but once I called this middlecoin.

Middlecoins (in this case the issued assets) would be considered transferred conditionally, if a given quantity of bitcoins was sent to a given address (both explicitly espcified in the middlecoin tx). You also need the "bitcoin collateral" (or "public pre-pay") to prevent DoS attacks, so I'm not sure this have any real advantage over the cross-chain contract. An expiry block would also be needed or..."I have some bitcoins, let's pree-accept some orders and block some middlecoins until I get bored or I want to spend my btc elsewere".

Be it with contracts or making the new chain dependent, what scares me most are DoS attacks for cashless chains. If you're going to pay the fees later...why not broadcast 10 million tx with a generous 1 btc fee?

And if we accept that a hostcoin is needed for the mining incentive and fees, won't that new cash become more valuable than bitcoin even if its chain gets "dirty with non cash transactions"?


I'm definitely interested in participate in such a project. And I'm sure I can learn much working with experienced bitcoin developers like you.
Since I will be done with the univeristy this friday (yeah!), I will have time to write other free software different from my lonely (and worse than pybrain) preann.
But I need to train some basic skills first, like making my first git commit and pull request.
I will do it with freicoin: I feel really bad about not having coded a single line even when there's people working on it. Maybe freicoin can be the ideal incentive hostcoin with its constant supply but everlasting miners reward I would also like to learn python and help with villages.cc and two-phase Ripple (better privacy and/or latency). Maybe too many things...

We first need to discuss if the hostcoin is necessary. Maybe there's another solution I haven't thought about.


Cross-chain trading is cool and will be good to have at some point anyway, but the current bitcoin protocol needs to be modified too, doesn't it?

That's why I think doing it on the same blockchain is more efficient

I too recently started a thread regarding this matter - How to clone Bitcoin to create your own crypto currency or crypto shares system: https://bitcointalksearch.org/topic/how-to-clone-bitcoin-to-create-your-own-crypto-currency-crypto-shares-system-114336

I really believe that a decentralized crypto currency based stock exchange is very important and could have great benefits for humankind.

I support the idea of separate block chains. I would like to make it as easy as possible for anyone to create their own crypto currency clone and use it as an asset if they like. I think the open transactions system could work for the exchange part of it.

Now, this discussion quickly gets very technical but I'm glad to see that so many people are working on a solution to this problem.

I personally believe that the crypto stock exchange is as important as the crypto currency software itself and I can't wait too see more solutions go live. It could be a VHS vs betamax sort of thing. I support the idea of separate block chains, not the colored coins one at least for the time being.

Double spend can be prevented by waiting until 'the payment' gets enough confirmations.

When Party B refuses to proceed and 'the payment' already got some confirmations Party A has to wait until Tx2 ('the contract') is locked so Party A will get its coins back.

So this is inherently slower than 'atomic coin swap' because in the best case one needs to wait several confirmations, in the worse case one needs to wait for Tx2 lock.

In general, see Contracts: cross-chain trading

Double spending is always possible even on a single chain.  Adding multiple chains implies you would want to post to the weaker chain first.

The largest risk tends to be "holdup risk", where one sender simply refuses to proceed with the transaction.  In that case, Party A would be forced to double-spend, to secure the coins it wanted to trade with Party B.

https://github.com/jgarzik/smartcoin: node.py: financial P2P network and DHT client

Description of how it's going to be used: https://bitcointalksearch.org/topic/distributed-bond-markets-and-pay-to-policy-outputs-92421

---

My plan is to use HTTP to post/retrieve orders and to exchange pieces of transactions. It can work in centralized way (one HTTP server) and in decentralized way (many HTTP servers).

I can publish a more detailed description if somebody's interested...

How could you prevent double spend attack with cross-chain trading?

I definitely think that a "smart property chain" separate from the main bitcoin chain should be pursued.  It helps separate purposes (currency vs. property registry) and keep property registry data out of the mainnet chain.

The main practical obstacle is getting the smart property chain into the common merged-mining merkle root that pools obtain from the merged-mining daemon.

If people are interested in working on a smart property chain The Right Way, let me know and we can coordinate.

My smartcoin (formerly pybond) project will include some cross-chain trading support for precisely this purpose.  In fact, I am seriously thinking that cross-chain trading should be prioritized over making a solution that works in the main bitcoin chain.

Could you please post the links?

This isn't true. There are at least two exchange mechanism proposals.

You might not like that, but that doesn't mean that you can say that they don't exist.

There is no decentralized mechanism for exchange in all current colored coins protocol designs. That is the main issue that motivated me to work on a new design. If shares ownership relies on the issuer/share holder to transferring their shares to another shareholder, there would be no roam for any sort of a decentralized exchange mechanism within such protocol. It is that particular point that forced me to redesign the protocol in a manager that shares ownership wouldn't be related to any sort of colored coins. In order to create a mechanism for a decentralized exchange, share holding should come as reflection/output to such exchange. So shares movement from one node to another should take place on multiple stages:

1- Node ["A"] broadcasts a sell "ASK" order and a BTC address to receive payment on
2- Node ["B"] broadcasts buying the shares broadcasted by ["A"] "or portion of it"
3- Node ["B"] sends the requested BTC amount to node ["A"]'s BTC address
4- The application automatically parses steps (1,2,3) and moves ownership for the shares bought on (3) from node ["A"] to node ["B"]

The broadcast mechanism will take place as transactions sent to the issuer's BTC address, while all nodes are monitoring all transactions send/received by the issuer's BTC address. That would result in a real time messaging protocol on top of the block chain. Transactions sent to the issuer's address will be parsed as binary protocol events. Where the last "one or two number" will be parsed as an event id: {"0.00000001:issue","0.00000002:buy","0.00000003:sell","0.00000004:ask",...}. The most challenging part now is optimizing the operations/transactions to its minimum.

Your feedback is more than welcome.

There are about 1,000,000,000 shares for Apple Inc. With 1 satoshi representing 1 share, it takes only 10BTC. I don't think this would become a real problem in the near future

If satoshis are in short supply you could use DeVCoin, lots of satoshis there and no ever-decreasing minting of them.

-MarkM-

I meant with with valued inputs/outputs (those outputs just don't represent bitcoins) and the protocol validating the movements.


Yes, this is probably the best way to start, I'm not denying that. I'm only saying that not needing satoshis would be preferable later, and a more elegant solution. Jeff, for example, disagrees here.

I'm biased anyway. First because I proposed ripplecoin and also because the colored coins solution is unpractical for freicoin, in which satoshis disappear with time.