<p>This can be implemented in a similar way than <a href="https://en.bitcoin.it/wiki/Smart_Property" rel="nofollow">smart property</a>.</p>

<p>The issuer sells, for example, 1 satoshi to represent each share. He can sell a share for bitcoins <a href="https://bitcointalk.org/index.php?topic=46834.msg558558#msg558558" rel="nofollow">within one transaction</a>, atomically.</p>

<p>A decentralized market for those shares would be necessary. This can be implemented outside the chain in multiple ways, for example, using <a href="http://en.wikipedia.org/wiki/I2p" rel="nofollow">i2p</a> like <a href="https://bitcointalk.org/index.php?topic=27055.60" rel="nofollow">dark exchange</a>.</p>

<p>The problem that remains is forcing the orders in that market outside the chain to be executed. Without <a href="https://bitcointalk.org/index.php?topic=52494.msg628807#msg628807" rel="nofollow">extending the bitcoin protocol set of standard transactions</a> or starting a new chain.</p>

CC BY-SA 3.0
2011-11-22T11:05:08.840Z
Fixed the link for you an upvoted, hopefully you'll have enough rep soon to leave two links.
ripper234
CC BY-SA 3.0
2011-11-22T10:58:05.017Z
2011-11-24T23:17:50.747Z
2011-11-24T23:17:50.747Z
jtimon
<p>This can be done using Open-Transactions. There <em>are</em> 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.</p>

<p>Here's the project: <a href="https://github.com/FellowTraveler/Open-Transactions/wiki" rel="nofollow">https://github.com/FellowTraveler/Open-Transactions/wiki</a></p>

CC BY-SA 3.0
2011-11-24T10:05:31.327Z
How useable is OT (both in terms of use base, and ease of usage)?
ripper234
CC BY-SA 3.0
2011-11-24T12:16:02.550Z
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.)
Fellow Traveler
CC BY-SA 3.0
2012-11-12T18:41:26.157Z
This seems like a simpler solution than trying to manage it through bitcoin addresses.
John Zumbrum
CC BY-SA 3.0
2011-11-24T09:41:46.527Z
2011-11-24T09:41:46.527Z
Fellow Traveler
<p>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.</p>

CC BY-SA 3.0
2011-11-22T08:05:14.367Z
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
CC BY-SA 3.0
2011-11-22T09:50:50.140Z
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
CC BY-SA 3.0
2011-11-22T09:57:21.707Z
I guess it might be possible to accomplish under pure Bitcoin a la https://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
CC BY-SA 3.0
2011-11-22T08:02:06.253Z
2011-11-22T08:02:06.253Z
ThePiachu
<p><a href="http://cassandra.apache.org/" rel="nofollow">http://cassandra.apache.org/</a> this seems very well suited for a distributed p2p stock exchange.</p>

CC BY-SA 3.0
2012-10-14T15:33:12.467Z
Could you please add a few lines describing what Cassandra is? Thanks!
D.H.
CC BY-SA 3.0
2012-10-14T19:25:22.093Z
This doesn't seem related. AFAIK Cassandra is suitable for distributed networks owned by a single operator, not for truly p2p.
ripper234
CC BY-SA 3.0
2012-10-13T02:43:37.660Z
2012-10-13T02:43:37.660Z
anonymous
<p><strong>Step 1 - Representing shares in the company.</strong></p>

<p>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.</p>

<p><strong>Step 2 - Enabling OTC trades.</strong></p>

<p>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.</p>

<p><strong>Step 3 - Committing to offers.</strong></p>

<p>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.</p>

<p>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.</p>

<p>One way to do this is with a distributed trust model such as my own <a href="https://bitcointalk.org/index.php?topic=21164.0">NodeBank proposal</a>, where the bank nodes act as escrow for the trades.</p>

<p>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.</p>

<p><strong>Step 4 - Continuous trade services.</strong></p>

<p>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.</p>

CC BY-SA 3.0
2011-11-22T10:49:42.677Z
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
CC BY-SA 3.0
2011-11-22T23:34:45.097Z
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?
DeathAndTaxes
CC BY-SA 3.0
2011-11-23T05:57:05.010Z
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.)
Meni Rosenfeld
CC BY-SA 3.0
2011-11-23T07:44:23.430Z
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.
Meni Rosenfeld
CC BY-SA 3.0
2011-11-23T15:22:52.497Z
I think you are confusing "value" with "unique coins".  Bitcoin simply tracks value.  While there can never be more output (in terms of value) you can't track where an individual input goes.  Bitcoin only tracks value.  So if you have 1 "share satoshi" in an address and someone adds 1 million "regular satoshis" (and you can't block or reject transactions) then the two are forever co-mingled.  There is no way to seperate out the 1 "share satoshi".
DeathAndTaxes
CC BY-SA 3.0
2011-11-23T20:42:23.520Z
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.
Meni Rosenfeld
CC BY-SA 3.0
2012-10-10T21:00:17.343Z
One question regarding the merged mining approach: would this introduce another coin ("bitstock") along with the token coins? this part: "It will have a mechanism for making offers of Bitstock tokens vs. normal bitstocks" confused me a bit, hence the question. Could transactions in the slave chain be linked to transactions in the bitcoin chain in a way that would create a desired "combined share purchase" transaction (passing bitstock tokens one way and bitcoin the other)?
molecular
CC BY-SA 3.0
2012-10-11T05:44:07.967Z
@molecular: Yes, if we want a protocol with special features that are too big to be introduced in Bitcoin, it will have to be an alt with a separate blockchain. In the sentence you quote I spoke of exchanging Bitstock for other Bitstock, not Bitstock for Bitcoin. However, the latter may also be possible if Bitcoin supports it - see https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains.
Meni Rosenfeld
CC BY-SA 3.0
2012-10-15T12:59:01.053Z
Well... you could just do step 1 and 4, i.e. using Bitcoins to store shares, and using an external service to trade them.
o0'.
CC BY-SA 3.0
2011-11-22T10:33:51.320Z
2011-11-22T10:44:05.293Z
2011-11-22T10:44:05.293Z
Meni Rosenfeld
<p><a href="https://glbse.com/" rel="nofollow">GLBSE</a> is a privately owned bitcoin-based stock exchange website.</p>

<p><a href="https://bitcointalk.org/index.php?topic=52494.0" rel="nofollow">Recently there has been talk</a> about creating a distributed, open source version of it, without any single point of failure, possibly utilizing blockchain/Namecoin technology.</p>

<p>Would such a project work, technically? How would you design it?</p>

<glbse>
Is a distributed version of GLBSE possible? How would you design it?
ripper234
# Is a distributed version of GLBSE possible? How would you design it?

(Asked by: username_0 on 2011-11-22)

[GLBSE](https://glbse.com/) is a privately owned bitcoin-based stock exchange website.

[Recently there has been talk](https://bitcointalk.org/index.php?topic=52494.0) 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?

**Tags:** glbse


---

## 5 answers

### Answer by username_7 on 2011-11-22. Score: 7 | Accepted answer

**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](https://bitcointalk.org/index.php?topic=21164.0), 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.

> **Comments:**
> **username_0**: 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.  
> **username_8**: 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?  
> **username_7**: 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.)  
> **username_7**: 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.  
> **username_8**: I think you are confusing "value" with "unique coins".  Bitcoin simply tracks value.  While there can never be more output (in terms of value) you can't track where an individual input goes.  Bitcoin only tracks value.  So if you have 1 "share satoshi" in an address and someone adds 1 million "regular satoshis" (and you can't block or reject transactions) then the two are forever co-mingled.  There is no way to seperate out the 1 "share satoshi".  
> **username_7**: 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.  
> **username_9**: One question regarding the merged mining approach: would this introduce another coin ("bitstock") along with the token coins? this part: "It will have a mechanism for making offers of Bitstock tokens vs. normal bitstocks" confused me a bit, hence the question. Could transactions in the slave chain be linked to transactions in the bitcoin chain in a way that would create a desired "combined share purchase" transaction (passing bitstock tokens one way and bitcoin the other)?  
> **username_7**: @username_9: Yes, if we want a protocol with special features that are too big to be introduced in Bitcoin, it will have to be an alt with a separate blockchain. In the sentence you quote I spoke of exchanging Bitstock for other Bitstock, not Bitstock for Bitcoin. However, the latter may also be possible if Bitcoin supports it - see https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains.  
> **username_10**: Well... you could just do step 1 and 4, i.e. using Bitcoins to store shares, and using an external service to trade them.  

---

### Answer by username_1 on 2011-11-22. Score: 3

This can be implemented in a similar way than [smart property](https://en.bitcoin.it/wiki/Smart_Property).

The issuer sells, for example, 1 satoshi to represent each share. He can sell a share for bitcoins [within one transaction](https://bitcointalk.org/index.php?topic=46834.msg558558#msg558558), atomically.

A decentralized market for those shares would be necessary. This can be implemented outside the chain in multiple ways, for example, using [i2p](http://en.wikipedia.org/wiki/I2p) like [dark exchange](https://bitcointalk.org/index.php?topic=27055.60).

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](https://bitcointalk.org/index.php?topic=52494.msg628807#msg628807) or starting a new chain.

> **Comments:**
> **username_0**: Fixed the link for you an upvoted, hopefully you'll have enough rep soon to leave two links.  

---

### Answer by username_2 on 2011-11-24. Score: 2

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/username_2/Open-Transactions/wiki>

> **Comments:**
> **username_0**: How useable is OT (both in terms of use base, and ease of usage)?  
> **username_2**: 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.)  
> **username_3**: This seems like a simpler solution than trying to manage it through bitcoin addresses.  

---

### Answer by username_4 on 2011-11-22. Score: 0

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.

> **Comments:**
> **username_0**: 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.  
> **username_4**: 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?  
> **username_0**: I guess it might be possible to accomplish under pure Bitcoin a la https://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).  

---

### Answer by username_5 on 2012-10-13. Score: -1

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

> **Comments:**
> **username_6**: Could you please add a few lines describing what Cassandra is? Thanks!  
> **username_0**: This doesn't seem related. AFAIK Cassandra is suitable for distributed networks owned by a single operator, not for truly p2p.  

---

