RFC -- Distributed Bitcoin Stock Exchange (DBSE)

[btc_artist]

This is a "Request for Comment" (RFC) Concerning a Distributed Bitcoin Stock Exchange. (DBSE)

This is an early RFC, subject to revision and may change entirely.  It's definitely in the pre-half-backed stage. Please try to poke it full of holes so it can be improved.  Also try to simplify some of the transactions if possible.  I am by no means an expert and I need you to vet this or point out why it's impossible.

Goal: Design a distributed, peer-to-peer, blockchain-based, Bitcoin stock exchange.

Summary: The basis for this stock exchange would be a blockchain and TradeTokens ("TT").  Mining would produce TT in declining block subsidies, as well as transaction fees and forfeited "good faith deposits".  TT produced by mining are used to pay the transaction fees for all transactions, including creating and managing TickerSymbols, creating initial shares, buying and selling shares, creating and voting on motions, etc.  If someone wants to participate in the stock exchange without mining, they would presumably purchase TT from a miner.  While TT is used for fees, Bitcoin ("BTC") is used for all share purchases.  There is a built-in escrow system to enforce trades and ensure that the purchaser receives their shares and the seller receives their payment in BTC after each trade.


1. TradeTokens (TT)

Mining will produce TradeTokens ("TT"), which will be used to pay the transaction fees for:

• Creating and managing a company listing (represented by a unique TickerSymbol) in the Distributed Bitcoin Stock Exchange ("DBSE").
• Creating IPO shares to sell.
• Submitting transactions to buy and sell shares (shares paid for in BTC)
• Creating and voting on motions
• Submitting transactions to pay dividends (dividends paid in BTC)

2. Block chain

• Mining in the DBSE blockchain will produce a declining per-block subsidy in TradeTokens (TT).  The miner will also receive TT transaction fees for transactions included in the block and any forfeited "good faith deposits" (in TT as well).
• Have relatively quick blocks, perhaps every 5 minutes? TBD.
• TradeToken block subsidy would start at 1000 TT per block for the first block, and drop by 0.00019 TT for each following block.  With 5 minute blocks, this would take ~50 years until the block subsidy reaches 0. This could be redesigned to not be linear and work more like Bitcoin block subsidies as well.

3. Public and private keys

Public and private key pairs would be used to identify who owns TickerSymbols ("TS"), Shares, and TradeTokens.  The public key (technically a shorter address derived from it) will be known as a "DBSE Address", and the corresponding private key will be the "DBSE PrivKey".  Any of the three items--TickerSymbols, Shares, or TradeTokens-- can be associated to a given DBSE PrivKey, and are thus owned by the owner of that private key.

If needed, three separate types of public/private key pairs could be created with distinct looking public addresses: One for ticker symbols, one for shares/assets, and one for TradeTokens. TBD.


4. Creating a company

To create a company listing, you choose a TickerSymbol that does not already exist in the block chain (or has been released, see below), and submit it, along with a TT transaction fee and a public key ("DBSE Address") for which you hold the private key ("DBSE PrivKey").  To get started, you would then send a transaction to create the initial shares, then send another transaction to offer some or all of those shares for sale for BTC.  After that, any shareholder can create and vote on Motions, the TickerSymbol owner can pay dividends, anyone can buy or sell shares for BTC, all by submitting the appropriate transactions.


5. Transaction Fees

Fees will be optional in the protocol. A yet-to-be determined algorithm will be used in the official client for generating a transaction fee in TradeTokens for all transactions.  Perhaps something like (0.000001 * TOTAL_NUM_TRADETOKENS_IN_EXISTENCE).

The fee for creating shares would be relatively high.  The buy and sell fees relatively low.  The fee for cancelling a buy or sell order might be slightly higher than the buy and sell fees.

Miners would dictate transaction fees based on their policies for including transactions in blocks based on fees.  The default mining software should enforce small fees.


6. Good faith deposit

The good faith deposit along with the transaction fee (both paid in TT) discourages people from submitting frivolous transactions for purposes of spaming, disrupting the DBSE, or manipulating the market.  The good faith deposit would be much larger (10 or 20 times larger) than the transaction fee.  The good faith deposit would be required by the protocol for all buy or sell offers submitted.  It will be refunded for "legitimate" orders, where "legitimate" means the order was concluded or it's time period expired, as opposed to being cancelled.


7. Motions and voting

Anyone who owns at least one share of a given stock (TickerSymbol) can create a Motion concerning it, and all other stockholders can vote on it.  When submitting the Motion, an expiry date from 1 to 90 days is given.  When the expiry date is reached, the Motion is defined by the protocol as having passed if (a) at least 50% of stockholders have voted and at least 2/3 of votes are for the motion, OR (b) at least 1/3 of stockholders have voted and at least 3/4 of votes are for the motion.  These percentages can be discussed, but should then be hard-coded into the protocol.


8. Dividend payments

The TickerSymbol owner can submit a transaction to make a dividend payment. The payment is made in BTC, and is divided among all shareholders and distributed automatically to the BTC addresses that the shareholders specified when purchasing the shares.  The details of how the would function need to be determined, but could work similarly to the Escrow functionality for share purchases as described below.


9. Internal escrow

Example: Buying shares.  Bob has some TT and would like to buy some shares in a given stock.  He submits a TRADE_BUY transaction. He pays the TT transaction fee and the TT "good faith deposit".  A miner matches up Bob's buy request with Alice's previously submitted sell request.  The miner does some EC math on the BTC public keys that both Bob and Alice submitted with their transactions, to produce a payment address that can only be redeemed by combining the private keys that Bob and Alice hold.  The miner includes a TRADE_MATCH transaction in the blockchain with the calculated payment address. The miner receives Bob and Alice's combined "Fulfillment fees" for this service.  Bob's client software pays 100% of the total sale price into the generated BTC address.  Alice's client software confirms that the BTC is there and sends a TRADE_FULFILL transaction transferring the shares to Bob (the shares are sent to Bob's TT address included in the TRADE_BUY transaction).  A miner includes that transfer in the block chain and the shares now belong to Bob.  When Bob's client software confirms that Bob now has the shares, it submits a TRADE_CONCLUDE transaction to the block chain which contains the Bob's private key for the BTC address.  Alice's client software withdraws the BTC by combining Bob's private key with Alice's private key to produce the private key that redeems the funds.  After sending TRADE_CONCLUDE, Bob's client software also submits a SHARE_CHANGEDIVIDENDADDRESS transaction to change the dividend address for the shares from Alice's to his.

A possible problem here is that Bob could maliciously withhold his private key from Alice after he has the shares.  So he would have his shares and Alice wouldn't get paid.  Of course, Bob couldn't redeem the BTC either.  This could possibly be mitigated by finding a way for Bob to pay exactly 110% of the final price, and when he releases the 100% to Alice, the 10% overpayment gets released back to him.

Another question here is at what point during this process can it still be cancelled by other parties?  It cannot be cancelled after the TRADE_FULFILL transaction is sent.  If it was cancelled before TRADE_FULFILL, but after the buyer had sent the BTC, then the seller would have to send their private key to the buyer, so they could retrieve the BTC they deposited.


10. Client Software

The client software will read the block chain and maintain indexes to quickly find appropriate data.  Based on analyzing the transactions in the block change, the client should list all relevant data for the user. For example:

• The client would show TickerSymbols owned by the user and how many shares exist for each. A Searchable list of all TickerSymbols. For any given ticker symbol, the client should list how many shares exist, how many shares are in buy or sell orders and their prices. List all shares owned, etc.
• The client would scan the blockchain for dividend payments and list all dividends received for each stock. Dividend payments will already have been send directly to the owner's BTC address.
• The client would show all Motions relevant to the shares you own.

11. High frequency trading

This would not support high frequency trading, however it would probably be possible to build a centralized exchange to support HFT that works on top of this distributed framework.


12. All Transaction Types

TICKERSYMBOL_CREATE

• Parameters:
• Fee
• New TickerSymbol to attempt to create
• Public key

Since you hold the corresponding private key, ("DBSE PrivKey") only you can manage this new TickerSymbol.

Known issue: How do we deal with the conflict if there are two transactions trying to create the same TickerSymbol at the same time (they are trying to be included in the same block). Using a timestamp of when the transaction was first seen on the network would be subject to manipulation.  The solution would probably be to reject both (all) conflicting transactions, invalidating* them. The end user can resend them until one is included in a block before the other.

*Not sure how the invalidation would work.

TickerSymbol squatting would be mitigating by automatically releasing unused TickerSymbols after X blocks have been created. With 5 minute blocks, X might be 8064, which would be approximately four weeks.  "Unused" TickerSymbols would be defined as TickerSymbols that have been created, but shares have never been created for them, and X blocks have passed since the TickerSymbol was created.

SHARE_CREATE

• Parameters:
• Fee
• TickerSymbol Private Key
• Number of shares to create

Shares can only be created by the owner of the TickerSymbol DBSE PrivKey, and only if the current number of shares is zero (0) or if there is a successful Motion to create more shares.

The owner of the created shares will be the owner of the TickerSymbol DBSE PrivKey. After creation, some or all of the shares can be put on the market with TRADE_SELL.

TRADE_BUY

• Parameters:
• Fee
• Fulfillment Fee (used to pay the miners for the additional transactions needed to complete the trade)
• TickerSymbol of the shares to buy
• Number of shares to buy
• Maximum price to pay per share in BTC
• TT "good faith deposit" calculated on the number of shares and share price
• timeout after which this offer expires
• TT Address for refunding the "good faith deposit"
• BTC address to refund the unused part of the payment, if any
• BTC address for receiving dividend payments from these shares
• public BTC address to use for creating (along with a BTC address provided by the seller) the BTC address for payment to be sent to
• TT address for the shares to be sent to

This is an *offer* to buy at this price. If the offer is cancelled before expiring, the "good faith deposit" is forfeited to the block subsidy payout address for the block the cancel transaction is in.  If the offer is successfully completed or if the expiry date is reached, the "good faith deposit" is refunded (via a refund request initiated by the owner). If no shares are available to buy at the price you specified (eg. someone buys them right before you do), the offer stands until expiring or being cancelled.

TRADE_SELL

• Parameters:
• Fee
• Fulfillment Fee (used to pay the miners for the additional transactions needed to complete the trade)
• TickerSymbol of the shares to sell
• Number of shares to sell
• Minimum price per share in BTC
• TT "good faith deposit" calculated based on the number of shares and share price
• timeout after which this offer expires
• BTC address for payment.

This is an *offer* to sell at this price. If the offer is cancelled before expiring, the "good faith deposit" is forfeited to the block subsidy payout address for the block the cancel transaction is in.  If the offer is successfully completed or if the expiry date is reached, the "good faith deposit" is refunded (via a refund request initiated by the owner). If there are no standing offers buy at the price you specified (eg. someone sold the same shares as you, right before you), the offer stands until expiring or being cancelled.

TRADE_MATCH

• Parameters:
• Transaction Hash(es) for the buy or sell offer(s) being matched.

This is not a transaction sent by the client software.  This is a transaction generated by the mining software, when it finds two or more compatible sell/buy orders. Sell and buy orders do not have to executed all at once. An order can be exectuted in pieces.  A partically executed sell/buy order can still expire or be cancelled. If it expires, the full good faith deposit is refunded. If it is cancelled, a pro-rated part of the good faith deposit is refunded, based on the ratio of the number of shares bought/sold and the original number offered.  If one or more of the buy/sell orders are being completed fully, the TT refund (TRADE_GOODFAITHREFUND) for the good faith deposit is also initiated by the mining software.

TRADE_FULFILL

• Parameters:
• Fee
• TickerSymbol for shares being sent
• Number of shares to send
• Recipient's TT address to send shares to
• Original Buy order hash that this fulfills

TRADE_CONCLUDE

• Parameters:
• Fee
• Original Buy order hash that this fulfills
• Private key for seller to use to calculate the private key where the BTC funds are held

TRADE_CANCEL

• Parameters:
• Fee
• Transaction Hash for the buy/sell offer to be cancelled
• Private key used to create the original transaction. (to sign this transaction and prove this is the owner of the original transaction)

TRADE_GOODFAITHREFUND

• Parameters:
• Transaction Hash for the completed buy/sell offer that contains the good faith deposit to refund.

This is initiated by the miner when an order is completed.

TICKERSYMBOL_SYNONYMIZE

• Parameters:
• Fee
• an array of TickerSymbols
• sign with the Private Key for all TickerSymbols to prove you're the owner
• set the preferred TickerSymbol.

This transaction would be a way to rename TickerSymbols.  First create a new ticker symbol, then submit a transaction with the old and new TickerSymbols and set which of them is the preferred TickerSymbol to use as its display name.

TICKERSYMBOL_CLOSE

 Have a transaction to "close" a TickerSymbol?

MOTION_CREATE

• Parameters:
• Fee
• TickerSymbol
• Title [50 chars]
• Text [10000 chars]
• Expiry [1 - 90 days]

This would generate a MotionHash which would be a unique hash representing this motion.  If the motion is for creating more shares, it would need an additional parameter specifying this and how many shares would be authorized to be created, to tie into the subsequent SHARE_CREATE transaction to actually create the shares.

MOTION_VOTE

• Parameters:
• Fee
• MotionHash
• Vote [yes/no]
• Comment [200 chars]

DIVIDEND_NOTIFY

• Parameters:
• Fee
• TickerSymbol that this payment is for
• Total amount in BTC
• Comment [200 chars]

This dividend transaction will notify the client that dividends have been paid.  As part of sending this transaction, the client would divvy up the dividends and send (using sendmany) the appropriate amount to the BTC address specified for each shareholder (specified when purchasing shares).  End users could also consolidate their dividend addresses by sending a SHARE_CHANGEDIVIDENDADDRESS transaction

SHARE_CHANGEDIVIDENDADDRESS

• Parameters:
• Fee
• Public TT key for the shares to be changed
• New BTC payout address
• Signed with the private key corresponding to the shares to prove ownership

-----
END OF RFC
-----

[1714881567]

1714881567

[1714881567]

1714881567

[1714881567]

1714881567

[markm]

I am not sure a p2p stock exchange makes a lot of sense unless there first exist p2p entities whose stocks would be traded.

Otherwise you basically just have a smokescreen p2p system potentially causing customers to forget that ultimately the stocks they are buying are centralised entities they still ultimately have to trust.

Since ultimately it is the specific entites issuing shares that you have to resort to to get your share of whatever it is the shares are of, and whom you have to depend on to issue any dividends that might get paid, this whole p2p overlay on top of it seems like potentially jsut another clever scam/smokescreen allowing issuers to pretty much do like bitcoin itself did: issue tokens they have no intention of actually backing but that might nonetheless get seen as having some value due to there being plenty of suckers out there who will in-effect "back it" by buying it.

It will be like hey, mining costs more than issuing a bunch of shares does, so instead of mining a bunch of whatever kind of coins (bitcoins, scamcoins, whatever) lets just issue a bunch of shares. In either case we have no intention of backing them, perish forbid. Any value they end up having will be from other people buying them. All we do is mine them (or in this case, issue them, even less work than mining maybe) and put them out there for suckers to buy.

So maybe a distributed p2p corporation system would be a good foundation, so that we have actual p2p entities whose shares we could then worry about issuing.

Maybe that would be quite a similar system but start with the assumption that the whole system itself is one p2p corporation, and the shares offered are shares of itself. Then instead of arbitrary non-p2p entities issuing shares just because they decide to, there could be a whole voting process on whether the system as a whole even wants to risk sullying its repution by entertaining the notion of handling company X's proposed shares. Do a majority of the token-holders think the company applying to do an IPO with us is legit? Is it a business of a kind we wish to be associated with? Are our armed forces or police or whatever in a position to seize their assets if they default on something? Whatever the criteria, at least a basic vote by the shareholders (token holders?) of the exchange system itself might be appropriate before willy-nilly becoming an accomplice to the latest new Enron scam by agreeing to do the new Enron's IPO on our network?

-MarkM-

[btc_artist]

Since ultimately it is the specific entites issuing shares that you have to resort to to get your share of whatever it is the shares are of, and whom you have to depend on to issue any dividends that might get paid, this whole p2p overlay on top of it seems like potentially jsut another clever scam/smokescreen allowing issuers to pretty much do like bitcoin itself did: issue tokens they have no intention of actually backing but that might nonetheless get seen as having some value due to there being plenty of suckers out there who will in-effect "back it" by buying it.

It will be like hey, mining costs more than issuing a bunch of shares does, so instead of mining a bunch of whatever kind of coins (bitcoins, scamcoins, whatever) lets just iddue a bunch of shares. In either case we have no intention of backing them, perish forbid. Any value they end up having will be from other people buying them. All we do is mine them (or in this case, issue them, even less work than mining maybe) and put them out there for suckers to buy.

This proposal isn't supposed to address the issue of an untrustworthy person starting a company and issuing shares.  The issue it addresses is the problem of having a centralized stock exchange controlled by one person, where all stock issuers and stock holders must put their trust in the centralized exchange and the person who controls it.

[Fireball]

I see it playing the role of a "distributed depository". All trading happens on a certain exchange, but when clearing is performed, the corresponding stock is moved to/away from the depository. This makes it possible to transfer stocks to different exchange, like it's possible in the real world.

[Red Emerald]

I am not sure a p2p stock exchange makes a lot of sense unless there first exist p2p entities whose stocks would be traded.

Otherwise you basically just have a smokescreen p2p system potentially causing customers to forget that ultimately the stocks they are buying are centralised entities they still ultimately have to trust.

Since ultimately it is the specific entites issuing shares that you have to resort to to get your share of whatever it is the shares are of, and whom you have to depend on to issue any dividends that might get paid, this whole p2p overlay on top of it seems like potentially jsut another clever scam/smokescreen allowing issuers to pretty much do like bitcoin itself did: issue tokens they have no intention of actually backing but that might nonetheless get seen as having some value due to there being plenty of suckers out there who will in-effect "back it" by buying it.

It will be like hey, mining costs more than issuing a bunch of shares does, so instead of mining a bunch of whatever kind of coins (bitcoins, scamcoins, whatever) lets just iddue a bunch of shares. In either case we have no intention of backing them, perish forbid. Any value they end up having will be from other people buying them. All we do is mine them (or in this case, issue them, even less work than mining maybe) and put them out there for suckers to buy.

So maybe a distributed p2p corporation system would be a good foundation, so that we have actual p2p entities whose shares we could then worry about issuing.

Maybe that would be quite a similar system but start with the assumption that the whole system itself is one p2p corporation, and the shares offered are shares of itself. Then instead of arbitrary non-p2p entities issuing shares just because they decide to, there could be a whole voting process o nwhether the system as a whole even wants to risk sullying its repution by entertaining the notion of handling company X's proposed shares. DO a majority of the token-holders think the company applying to do an IPO with us is legit? Is it a business of a kind we wish to be associated with? Are out armed forces or police or whatever in a position to seize their assets if they default on something? Whatever the criteria, at least a basic vote by the shareholders (token holders?) of the exchange system itself might be appropriate before willy-nilly becoming an accomplice to the latest new Enron scam by agreeing to do the new Enron's IPO on our network?

-MarkM-

I don't think the P2P part has anything to do with fake companies posting shares and hoping for stupid/scammed people to buy them.  That can happen on centralized exchanges too.  GLBSE had someone make a fake entity for GLBSE and some people didn't do research and so bought shares.

Why would anyone invest in a company that they aren't sure is legit where through a centralized exchange or a p2p exchange?

I'm glad to see you are getting this together btc_artist.

I think it would be really neat if we could have the current GLBSE assets form the genesis block, but I'm not sure how we could migrate the GLBSE accounts.

[btc_artist]

I'm glad to see you are getting this together btc_artist.

It's not together yet.   It needs some inquisitive minds to give it a thorough beating to see if the idea will hold up and to point out what I'm missing.

I think it would be really neat if we could have the current GLBSE assets form the genesis block, but I'm not sure how we could migrate the GLBSE accounts.

I hadn't really gotten that far yet, but that might be something to explore (with Nefario's consent, of course).

[Andrew Bitcoiner]

anything it will take to get this RFC spec completed, server space, ideas, funding, let me know and I will help.

[ovidiusoft]

anything it will take to get this RFC spec completed, server space, ideas, funding, let me know and I will help.

+1

[boonies4u]

3. Public and private keys

Public and private key pairs would be used to identify who owns TickerSymbols ("TS"), Shares, and TradeTokens.  The public key (technically a shorter address derived from it) will be known as a "DBSE Address", and the corresponding private key will be the "DBSE PrivKey".  Any of the three items--TickerSymbols, Shares, or TradeTokens-- can be associated to a given DBSE PrivKey, and are thus owned by the owner of that private key.

If needed, three separate types of public/private key pairs could be created with distinct looking public addresses: One for ticker symbols, one for shares/assets, and one for TradeTokens. TBD.

I really like the sound of this, one of the things that currently bother me about GLBSE is actually proving that I own particular shares. Having a public address would make this a lot easier.

7. Motions and voting

Anyone who owns at least one share of a given stock (TickerSymbol) can create a Motion concerning it, and all other stockholders can vote on it.  When submitting the Motion, an expiry date from 1 to 90 days is given.  When the expiry date is reached, the Motion is defined by the protocol as having passed if (a) at least 50% of stockholders have voted and at least 2/3 of votes are for the motion, OR (b) at least 1/3 of stockholders have voted and at least 3/4 of votes are for the motion.  These percentages can be discussed, but should then be hard-coded into the protocol.

Would there be good faith deposits for issuing motions? I wouldn't like seeing a bunch of spam motions from someone who owns one share in an asset.

Perhaps instead of a deposit, only allow a non-issuer (someone who issues an asset may need to have multiple up for the asset they put out) to have one motion up per asset at a time.

[btc_artist]

anything it will take to get this RFC spec completed, server space, ideas, funding, let me know and I will help.

Thank you.

3. Public and private keys

Public and private key pairs would be used to identify who owns TickerSymbols ("TS"), Shares, and TradeTokens.  The public key (technically a shorter address derived from it) will be known as a "DBSE Address", and the corresponding private key will be the "DBSE PrivKey".  Any of the three items--TickerSymbols, Shares, or TradeTokens-- can be associated to a given DBSE PrivKey, and are thus owned by the owner of that private key.

If needed, three separate types of public/private key pairs could be created with distinct looking public addresses: One for ticker symbols, one for shares/assets, and one for TradeTokens. TBD.

I really like the sound of this, one of the things that currently bother me about GLBSE is actually proving that I own particular shares. Having a public address would make this a lot easier.

Yes.  Even if there were centralized exchanges built on top of DBSE, the shares you own would still forever be immortalized in the public blockchain that all the peers have.

7. Motions and voting

Anyone who owns at least one share of a given stock (TickerSymbol) can create a Motion concerning it, and all other stockholders can vote on it.  When submitting the Motion, an expiry date from 1 to 90 days is given.  When the expiry date is reached, the Motion is defined by the protocol as having passed if (a) at least 50% of stockholders have voted and at least 2/3 of votes are for the motion, OR (b) at least 1/3 of stockholders have voted and at least 3/4 of votes are for the motion.  These percentages can be discussed, but should then be hard-coded into the protocol.

Would there be good faith deposits for issuing motions? I wouldn't like seeing a bunch of spam motions from someone who owns one share in an asset.

Perhaps instead of a deposit, only allow a non-issuer (someone who issues an asset may need to have multiple up for the asset they put out) to have one motion up per asset at a time.

Good ideas.  The idea of only allowing a non-issuer to have one motion up at a time might be good, but I can't see any way to enforce it.  I could own 10 shares of a given stock under 10 different TT addresses, and there would be no way for the blockchain or client to know that those 10 shares are owned by the same person.

But motion spam might still be a problem. How about just having a transaction fee for it?  If a motion is important to you, pay the fee and submit it.

[weex]

12. All Transaction Types

I think you can greatly simplify this system and increase the chance of it working by leaving the trading logic(buy,sell,etc,) out of it. Instead, you would be better off focusing on the problem of having arbitrary numbers of issuers creating shares and motions that can be owned and voted upon by arbitrary numbers of investors. Even ticker symbols can be an overlay though it's not too disruptive to include it.

By simplifying the system to create the bare minimum required to function, you allow exchanges to pop up that can all be working on the same data. You also offload the escrow to those exchanges or other trusted third parties. Successful transfer can be defined by having your transaction in the longest blockchain(so you defend against a double-sale of shares).

This does bring up a problem similar to running the same wallet on multiple machines. Exchanges will need to check orders against available shares for the associated private key and monitor for transfers that would force that order to be inactive/cancelled.

I'm thinking you may want to go distributed to a fault but the above is how I see the goal of distributed ownership being achieved. Good luck. Subbed.

[btc_artist]

I think you can greatly simplify this system and increase the chance of it working by leaving the trading logic(buy,sell,etc,) out of it. Instead, you would be better off focusing on the problem of having arbitrary numbers of issuers creating shares and motions that can be owned and voted upon by arbitrary numbers of investors. Even ticker symbols can be an overlay though it's not too disruptive to include it.

By simplifying the system to create the bare minimum required to function, you allow exchanges to pop up that can all be working on the same data. You also offload the escrow to those exchanges or other trusted third parties. Successful transfer can be defined by having your transaction in the longest blockchain(so you defend against a double-sale of shares).

This does bring up a problem similar to running the same wallet on multiple machines. Exchanges will need to check orders against available shares for the associated private key and monitor for transfers that would force that order to be inactive/cancelled.

I'm thinking you may want to go distributed to a fault but the above is how I see the goal of distributed ownership being achieved. Good luck. Subbed.

That hadn't even occurred to me, but it sounds very appealing.  

So the blockchain and protocol would only concern itself with:

1. Creating ticker symbols / companies / stocks (I'm using these interchangeably, it's just a unique identifier for an entity that issues shares)
2. Creating shares
3. Owning shares
4. Sending shares from one address to another (this would be like sending bitcoin from one address to another, it would not be all the trade transactions above)
5. Creating motions
6. Voting on motions

The blockchain would serve as the back end.  It would show all shares in existence and who owns them, and allow changing the ownership.  But the actual trading of shares would be left to trusted centralized parties that would serve as clearing houses for buy/sell orders and serve as a trusted escrow service.

I like this a lot.

Note: I think the ticker symbol needs to be in the block chain as the identifier for any associated shares that are issued for that company.

Edit: For paying dividends, we could include a BTC dividend payment address along with the ownership of each share, and it would be paid there.

[weex]

Upon further thought, and I'm not trying to minimize the feature set more than necessary, you might want to remove the motions as well. There are probably tons of rights ownership of a share may grant and this could vary widely from one issuance to another.

Does anyone else have an idea of the rights granted to those owning shares of a publicly traded company on the NYSE/Nasdaq for example? Voting is one, introducing motions, but perhaps shares could even be issued that can't be transferred until after some date in the future. The private key enables all kinds of actions granted by the issuing company to be signed and honored only during the duration of ownership.

[btc_artist]

I think it's useful to minimize the feature set as much as possible to make the underlying protocol as robust as possible.  Would you make dividend payment as part of the protocol?

[ripper234]

+1 I'd really like to see this implemented. I was thinking of using either Bitcoin or Namecoin as underlying backend (since they both have a huge hash power behind them), but a separate chain offers a lot more flexibility.

A few comments:

1. I wouldn't limit assets to stocks only - I suggest creating other types of assets, like bonds, options and futures as 1st class citizens in the protocol. That would allow stuff like creating a bond that is backed by stocks ... the protocol can guarantee that dividends on a bond are paid on a set date (or block ID) ... or else certain stocks are transferred to the bond issuer.

2. I'm concerned with 51% attacks. Until merged mining, this network will be easy to attack. So, I can sell you shares for 5000 BTC, and 51% attack the new blockchain for a cost of up anywhere up to 4999BTC (just rent a few machines in an Amazon GPU cluster), producing me a net gain.

3. Why not use the Namecoin algorithm where the block reward never changes?

4. How about putting this up on a wiki page? Or is it too soon?

[Nefario]

This is of interest to me.

Good luck with it, this is not going to be an easy task.

If you can get this rolling I'd be happy to have existing shares on GLBSE enter the genesis block if the share issuers want, although I'm not too sure how that could be done.

Nefario.

[cbeast]

I love this idea. It's a much more developed version of the idea I had regarding a decentralized exchange for purposes of creating a ticker type service.

It's not like we need a full exchange that reports the volume of transactions. All we need is a general idea of the price bitcoin is being traded at.

• An Exchange Coin is created. The coins generated from it include pricing of all included crypto-currencies. More can be added if everyone agrees.
  
• Each coin client (including bitcoin) allows a price value in various fiat currencies to be reported to Exchange Coin.
  
• The Exchange Coin factors in the reported prices and runs a statistics algorithm that finds the current mean values.
  
• HST and bot trades could be filtered out statistically.

This would be organic and require trust of not a central reporting authority, but of all bitcoin users to volunteer honest reporting.

[jtimon]

The blockchain would serve as the back end.  It would show all shares in existence and who owns them, and allow changing the ownership.  But the actual trading of shares would be left to trusted centralized parties that would serve as clearing houses for buy/sell orders and serve as a trusted escrow service.

You don't need centralized exchanges, you just need contracts for the trades.

Edit: For paying dividends, we could include a BTC dividend payment address along with the ownership of each share, and it would be paid there.

If the dividends and the shares are going to be paid in bitcoins, why do you need the TT at all?
The fees can be paid with bitcoins too.

I mean, I see it cleaner and more logic if everything is paid for either in bitcoins or in TT, but not this hybrid. Or you could allow both currencies in all cases.

This same chain could be used for other interesting things beside the stock exchange without adding anything. Examples:
1) Decentralized currency exchange: An exchange could issue usdCoins to have its btc/usd exchange decentralized.
2) Distributed ripple: the shares can be viewed as IOUs. An example of ripple transaction:

A trusts B who trusts C. C wants to pay 10 to A.
within the same transaction, they sign:
A gives 10 aShares to B
B gives 10 bShares to C

with this A can prove that he has paid to C.

And I'm sure we can think of many other fancy things.

The big problem I fear are DoS attacks. What prevents me from issuing a thousand types of shares and a million of each share and trade between one another like crazy?
Only fees? I'm not sure that's enough.

[Red Emerald]

If the dividends and the shares are going to be paid in bitcoins, why do you need the TT at all?
The fees can be paid with bitcoins too.

I mean, I see it cleaner and more logic if everything is paid for either in bitcoins or in TT, but not this hybrid. Or you could allow both currencies in all cases.

I didn't think about having even the fees be bitcoin.  I think I like that idea.  So would there be no block reward in that system since we wouldn't need TT?  That seems kinds of strange and might make it hard to get the chain going.

The big problem I fear are DoS attacks. What prevents me from issuing a thousand types of shares and a million of each share and trade between one another like crazy?
Only fees? I'm not sure that's enough.

Aren't fees the only things that keep you from doing the same thing on any of the other chains?

[markm]

Namecoin might be able to handle ownership of shares pretty easily without modification.

It is a pity that namecoin addresses are forced to look different from bitcoin address though, as that means you cannot simply use the same address as a bitcoin address to send dividends or whatever to. You'd have to eat up space in the namecoin chain to specify a bitcoin address if you wanted to use bitcoin along with it. On the other hand though, you could simply pay all dividends and such in namecoin and let people trade them on exchanges for any other kind of coin they would prefer to have.

-MarkM-