btc_artist



Offline



Activity: 154

Merit: 100



Bitcoin!







Full MemberActivity: 154Merit: 100Bitcoin! RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 08, 2011, 08:42:19 PM #1 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").

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

----- Design a distributed, peer-to-peer, blockchain-based, Bitcoin stock exchange.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.Mining will produce("TT"), which will be used to pay the transaction fees for: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.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.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.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.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.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.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.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: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.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.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.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.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.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.This is initiated by the miner when an order is completed.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.Have a transaction to "close" a TickerSymbol?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.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-----END OF RFC----- BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf

LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE

CATCH THE WINNING SPIRIT CATCH THE WINNING SPIRIT rtised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites arenot endorsed by the Bitcoin Forum. They may beunsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

markm



Offline



Activity: 2618

Merit: 1038









LegendaryActivity: 2618Merit: 1038 Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 08, 2011, 09:20:53 PM

Last edit: July 10, 2012, 08:54:30 PM by markm #2 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-



Free website hosting with PHP, MySQL etc: Browser-launched Crossfire client now online (select CrossCiv server for Galactic Milieu) Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/

btc_artist



Offline



Activity: 154

Merit: 100



Bitcoin!







Full MemberActivity: 154Merit: 100Bitcoin! Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 08, 2011, 09:30:46 PM #3 Quote from: markm on December 08, 2011, 09:20:53 PM 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. 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. BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf

LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE

Red Emerald



Offline



Activity: 742

Merit: 500









Hero MemberActivity: 742Merit: 500 Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 08, 2011, 11:40:29 PM #5 Quote from: markm on December 08, 2011, 09:20:53 PM 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. 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. Firstbits 11235813 | Bitcoin Homebrew Tap | P2Pool | OTC | Tumblr | STV | Bitcoin PR | VanityPool

boonies4u



Offline



Activity: 826

Merit: 1000









Hero MemberActivity: 826Merit: 1000 Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 09:54:17 AM #9 Quote from: btc_artist on December 08, 2011, 08:42:19 PM 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.



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



Offline



Activity: 154

Merit: 100



Bitcoin!







Full MemberActivity: 154Merit: 100Bitcoin! Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 02:23:12 PM #10 Quote from: Andrew Bitcoiner on December 09, 2011, 06:10:11 AM anything it will take to get this RFC spec completed, server space, ideas, funding, let me know and I will help.

Thank you.





Quote from: boonies4u on December 09, 2011, 09:54:17 AM Quote from: btc_artist on December 08, 2011, 08:42:19 PM 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.

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.



Quote from: boonies4u on December 09, 2011, 09:54:17 AM Quote 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.

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.



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. Thank you.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.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. BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf

LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE

weex



Offline



Activity: 1104

Merit: 1000









LegendaryActivity: 1104Merit: 1000 Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 05:42:09 PM #11 Quote 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. 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



Offline



Activity: 154

Merit: 100



Bitcoin!







Full MemberActivity: 154Merit: 100Bitcoin! Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 06:18:12 PM #12 Quote from: weex on December 09, 2011, 05:42:09 PM 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. 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 shares3. Owning shares4. 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 motions6. Voting on motionsThe 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. BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf

LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE

weex



Offline



Activity: 1104

Merit: 1000









LegendaryActivity: 1104Merit: 1000 Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 07:06:14 PM #13 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.

ripper234



Offline



Activity: 1358

Merit: 1002





Ron Gross







LegendaryActivity: 1358Merit: 1002Ron Gross Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 07:46:23 PM #15 +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?

Executive Director

Co-founder of the Israeli Bitcoin Association Please do not pm me, use ron@bitcoin.org.il instead Mastercoin Executive DirectorCo-founder of the Israeli Bitcoin Association

Nefario



Offline



Activity: 602

Merit: 502





GLBSE Support support@glbse.com







Hero MemberActivity: 602Merit: 502GLBSE Support support@glbse.com Re: RFC -- Distributed Bitcoin Stock Exchange (DBSE) December 09, 2011, 08:58:05 PM #16 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.



To get help and support for GLBSE please email PGP key id at pgp.mit.edu 0xA68F4B7CTo get help and support for GLBSE please email support@glbse.com