Topic: RFC -- Distributed Bitcoin Stock Exchange (DBSE) - page 4. (Read 10976 times)

+1

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

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 hadn't really gotten that far yet, but that might be something to explore (with Nefario's consent, of course).

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.

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.

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-

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
-----