GLBSE is a privately owned bitcoin-based stock exchange website.

Recently there has been talk about creating a distributed, open source version of it, without any single point of failure, possibly utilizing blockchain/Namecoin technology.

Would such a project work, technically? How would you design it?

  • I don't think we need another alt-coin for this... The only issue I'm seeing with it, how does a user gather information about what stocks/bonds are available - tracking the transactions via network is the back end of this --- how can it be presented to users in a way that isn't a massive headache?
    – user2041
    Oct 11, 2012 at 15:17

5 Answers 5


Step 1 - Representing shares in the company.

This is easy enough and has been discussed. The company sends a small amount of bitcoins to one of its addresses. It releases a digitally signed announcement that any bitcoins which can be traced back to this particular output are tokens representing shares in the company. When dividends are to be paid, they are sent (in normal bitcoins) to addresses which contain tokens in proportion to the amount. Initially the company is in ownership of its shares and can sell them to raise funds.

Step 2 - Enabling OTC trades.

Also easy. People who want to trade can broadcast their offers, perhaps on a dedicated Bitstock p2p network. People who want to execute standing orders can contact their issuers and together construct a Bitcoin transaction that sends X normal bitcoins from A to B and Y tokens from B to A, and both sign it. No trust is needed because the exchange happens simultaneously. There can be a Bitstock client that is a modified Bitcoin client, which is careful to distinguish tokens from normal BTC and can communicate with the Bitstock network.

Step 3 - Committing to offers.

Here's the hard part. With a normal OTC trade, there's nothing stopping a trader from backing out of an issued order if it becomes unprofitable by the time he is taken up on it. A market where orders needn't be honored will be inefficient and subject to manipulation. There needs to be some way to make committing orders.

One could conceive concocting some special Bitcoin transaction where the output can be claimed by reciprocating by sending tokens to a specified address, up to a given time. But I think this has too many moving parts to work. The Bitcoin script will need to verify that the tokens indeed originate in the company's address, and the completed transaction will expire if not included by some time - which is said to be impossible since it will be messed up in chain reorgs.

One way to do this is with a distributed trust model such as my own NodeBank proposal, where the bank nodes act as escrow for the trades.

If you want to do this completely trustless, I think you may have to create a separate Bitstock blockchain with its own rules (shared between all companies, but distinct from Bitcoin). I'm not sure it's possible to make a commitment mechanism for offering bitcoins for token bitstocks, so Bitstock will have to be its own currency which can also be used to create company tokens (just like Namecoin is a currency which can be used to create a DNS record). The Bitstock blockchain will have rapid blocks and a relatively strict timestamp requirement, and will be merge mined with Bitcoin. It will have a mechanism for making offers of Bitstock tokens vs. normal bitstocks, which is enforced by protocol if an execution request is made with its hash included in an early enough block. There should be a way to make special rules to make this survive reorgs - for example, orphan blocks will also be considered when evaluating whether an execution was given early enough, but a confirmation of this validity will also be included in the main branch, and require enough confirmations to make sure a validation can't be added retrospectively.

Step 4 - Continuous trade services.

No matter how clever we make the decentralized stock exchange, some things can still only be offered by a centralized service, in particular in regards to the speed with which orders can be placed, retracted and executed. A centralized service can be built on top of the p2p system to offer such features. It should enable depositing and withdrawing normal coins and token coins, and offer advanced features for trading deposited coins.

  • Nice work. Now we just need a critical mass of developers to kickstart the project. A functioning, distributed GLBSE clone is a killer Bitcoin feature.
    – ripper234
    Nov 22, 2011 at 10:49
  • 3
    How can you trace Bitcoins? The block chain only tracks value not individual "coins". For example if you send 1 satoshi representing a share in xyz to an address which contains 1 BTC do you now have 1 million shares of xyz. Likewise if someone transfers BTC to addresses containing shares and then satoshis are transfered out which ones are shares and which ones are BTC? Nov 22, 2011 at 23:34
  • 1
    The block chain does in fact track individual coins. Every input to a transaction is a clearly specified output of another transaction. If you go to block explorer, pick a transaction and repeatedly click on "previous output", you can trace the coin all the way back to its generation. Or to a specified output, and there can never be more coins tracing back to an output than the value of that output. (Though since every transaction can have several inputs, to avoid brute force search you may want to keep a separate record of the correct path.) Nov 23, 2011 at 5:57
  • 1
    Actually this wasn't completely right, you do need to be more sophisticated. For the outputs to be legitimate tokens, you need all inputs to be tokens, except for inputs which are unambiguously designated as tx fee inputs, and you'll need a change output for tokens and a change output for tx fee. And when validating a certain output you'll need to validate all of its inputs, which may branch. This may be challenging but should be solvable, I'll look more closely if the smart property proposal already solves it. Nov 23, 2011 at 7:44
  • 2
    No, sending coins means specifying a particular output to be redeemed. An output traceable to the original token will remain distinct even if the address receives more coins in a different output. The only point where coins are intermingled is inside a transaction, if you don't have a convention to recognize the distinguished inputs. Nov 23, 2011 at 20:42

This can be implemented in a similar way than smart property.

The issuer sells, for example, 1 satoshi to represent each share. He can sell a share for bitcoins within one transaction, atomically.

A decentralized market for those shares would be necessary. This can be implemented outside the chain in multiple ways, for example, using i2p like dark exchange.

The problem that remains is forcing the orders in that market outside the chain to be executed. Without extending the bitcoin protocol set of standard transactions or starting a new chain.

  • Fixed the link for you an upvoted, hopefully you'll have enough rep soon to leave two links.
    – ripper234
    Nov 22, 2011 at 11:05

This can be done using Open-Transactions. There are servers, but the overall architecture is larger than that -- issuers can issue funds onto multiple servers, and balances are still provable/recoverable even in cases where a server disappears. Servers cannot forge balances or transactions, and untraceable cash is available.

Here's the project: https://github.com/FellowTraveler/Open-Transactions/wiki

  • How useable is OT (both in terms of use base, and ease of usage)?
    – ripper234
    Nov 24, 2011 at 10:05
  • OT is primarily a library and an API. I believe the API is easy to work with, from a programmer's perspective. (There is some degree of irreducible complexity in providing untraceable cash, destruction of account history, markets, etc, but it's pretty well hidden behind the API.) If you check out the Wiki, there's a video of the test GUI in action, so you can see what the software does. I should caution that the test GUI is primarily for testing the whole API, and is not representative of how a commercial UI might appear. (Many UIs are possible, since OT has many potential applications.) Nov 24, 2011 at 12:16
  • This seems like a simpler solution than trying to manage it through bitcoin addresses. Nov 12, 2012 at 18:41

It probably could work. You'd probably need to implement a mechanism of creating special addresses that would be associated with a company (like Namecoins), enable them to create coins associated with themselves, and for example support something akin to merged mining for buying and selling of shares. For example, one would encode in the tx sent to the Bitcoin network a Tx equivalent in the share-coin. So it would be like saying: "A sends B 50 Bitcoins. Note: B sells A 10 shares of B". This could work pretty good once Bitcoin allows for messages to be encoded in the Txs more readily.

  • I was thinking something along those line. I need to get some free time and create a preliminary design doc. I think this should ride completely on Bitcoin & Namecoin (no need for a separate chain), and use the various "encode messages in the Bitcoin blockchain" techniques/services, to encode actual contracts.
    – ripper234
    Nov 22, 2011 at 8:05
  • Well, I guess it might be possible purely under Bitcoin if you use a proper message system. What do you want to use Namecoins for?
    – ThePiachu
    Nov 22, 2011 at 9:50
  • I guess it might be possible to accomplish under pure Bitcoin a la en.bitcoin.it/wiki/Smart_Property I haven't worked out the details yet, just musing. Namecoin seems to be really suited to for the purpose of registering assets (names in the basic protocol).
    – ripper234
    Nov 22, 2011 at 9:57

http://cassandra.apache.org/ this seems very well suited for a distributed p2p stock exchange.

  • 1
    Could you please add a few lines describing what Cassandra is? Thanks!
    – D.H.
    Oct 14, 2012 at 15:33
  • This doesn't seem related. AFAIK Cassandra is suitable for distributed networks owned by a single operator, not for truly p2p.
    – ripper234
    Oct 14, 2012 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.