Topic: RFC -- Distributed Bitcoin Stock Exchange (DBSE) (Read 11011 times)

any update on this?

Did this die?

Yes, I agree. Furthermore, OT can implement the Ripple distributed protocol.
But I mean specifically for the trades. Then the dividends for bonds, and a lot of other things can be managed well through OT.
Does Ripple lacks something for trades of crypto-assets that make OT preferable (for that particular task)?
As said, at the moment OT is the solution that needs less trust IMO.

If glbse supports importing your assets to open transactions that would be a nice feature.

Ripple credit card ftw.

If you could have a normal chip and pin or swipe card that ties into the ripple system it could be a killer feature.

When will people understand...

It's not OT or Ripple. It's OT and Ripple.

It's not Bitcoin or gold. It's Bitcoin and gold.

It's not either/or -- the future that is coming, is a combination of all of these things.

Are you saying that someone has implemented a chain with assets that can be issued by any keypair (instead of only for miners) and the chain has been destroyed by a pool that doesn't know what it's mining for?
Do you have a link for that?
They have implemented the base of ripplecoin. Anyway, the current design of the Ripple distributed protocol is better than ripplecoin because it has instant payments.
I think OT is currently the more "trust-less" (well you always trust the minter of the substitute/IOU ("untraceable cash" in OT terms): mtggoxUSSSD, mtgoxBTC...) solution for decentralized exchange of digital assets/promises. But Ripple will be better. What will it miss that OT has (for decentralized trading of crypto-assets)?

The Open Transactions server thread fellowtraveler mentioned is at https://bitcointalksearch.org/topic/open-transactions-server-assetbondcommoditycryptocoindeedsharestock-exch-53329

I know this current thread I am posting to is old, but I deliberately went searching for threads about distributed stock exchanges to make sure that what seems to have turned out to be a major problem for various steps in such directions has been mentioned.

I see that it did receive one small mention toward the end of the thread, but hopefully it can bear more thought.

The problem is that even with the implementation of merged mining to make adding more blockchains to one's mix when mining relatively cheap, the reactions encountered by various chains have taught us that even with merged mining the miners demand an impractical percentage of the entire market cap of the issued securities / coins / tokens. In short, they want to own them all, one hundred percent of all issued assets! That is totally prohibitive and makes the entire concept of using blockchains for issues belonging to anyone other than miners pretty much ruled out from the get-go.

Then too, even beyond demanding 100% of the total worth of any blockchains they touch, miners also have shown a willingness, even a desire, to conspire to attack blockchains or, failing directly contributing themselves to the attack, at least a desire to have others perform such attacks so they can gleefully sit back and laugh. And let us be clear here, this is not how they treat chains that fail to hand over to them 100% of the chain's assets, oh no, this is how they treat even chains that do hand over 100% of their assets to the miners!

At least two corps (General Mining Corp and General Retirement Corp) issued what amounted to "preferred shares" in blockchain form, but, along with several other assets that once upon a time were implemented using blockchains, they have been forced to scrap the blockchain approach for now in favour of using Open Transactions.

Coins on a blockchain amount in practice pretty much to some form of share of the total economy of that asset. So far DeVCoin is the only blockchain predicated upon not giving 100% of its assets to miners that is still running in blockchain form instead of having switched over to using Open Transactions.

Really think about this. It is comically imbecilic, it would sound like fiction, so ridiculous as not to be believable, to anyone not familiar with the history of blockchain based assets that even when 100% of the assets were to be seized by the miners at the very moment and by the very method of their issuance, miners prefer to destroy all possible value of such assets. I am not sure if that is more worthy of Kafka or Monty Python or some Dadaist or what.

SInce the initial move of several assets that had been implemented as blockchains over to Open Transactions format and to trading on the Digitalis Open Transactions server, new assets have basically given up on the blockchain concept for now and have been starting out from inception on the Open Transactions server.

-MarkM-

FYI Markm is already running a test server, though it's down today until I get a certain bug fixed. Should be back up tomorrow or the next day.
Search this forum for markm, open transactions alpha server, and you will find all the relevant info.

The easiest way to play with OT is to just download it, since the default configuration includes sample data for a "localhost" server.
You just run the server yourself on your local machine, then run the GUI on the same machine, in order to play with the functionality.
(That's what you see me doing on the OT videos.)

I wouldn't characterize OT (the library itself) as needing marketing, since it is already well-known and short on demos.
More likely, once more user-friendly applications are available, then those will need the marketing.
(The first real users of OT will encounter it not directly, but through software built with it. That's where I think marketing will come in.)

-FT

Thanks fellowtraveler for the reply.

I think I understand where you're coming from. If OT does what it's billed to then it really needs lots more users which mean some sort of marketing.

I guess I should thank you for chiming in on this thread since OT does seem to fit well with the goal stated here.

So, who wants to setup an OT server so readers of this thread can play with it?

FYI, "the OT community" can only be a reference to me, since I have slaved away on it, alone, for the past year-and-a-half. (Seeking volunteer coders.)

We're in the process now of testing our way through the first alpha server.  Discussion is at irc.freenode.net #opentransactions

My own focus has been on developing the library itself, and supporting anyone who uses it (not so much on building sites that use it or creating demos, which is your job, not mine.) In the end there will only be two types of people: those using OT, and those re-inventing the wheel, coding new systems that do the same things. There is no escaping this. (And either end is fine with me  :-)

-FT

Ok, I've watched a couple of videos on OT and visited the github wiki page. I can see now that Open Transactions has a lot going for it. If it works, it has the fundamentals of what we need.

It also solves a problem of incentives for mining a new general asset blockchain. If you have a ton of assets and nothing to give miners besides initially sparse transaction fees, a general asset blockchain might fail.

The most glaring issue with OT that I can see is the lack of a javascript client. GLBSE is as easy to use as it is because of the javascript client and seeing one for OT might enable users/issuers etc to get up and running with a minimum of fuss.

Also, I think this thread should culminate in some sort of action. Perhaps a bounty for an OT javascript client?

I'm personally a little bit annoyed at the mention again of Open Transactions. We know Bitcoin works and I've still not seen a working system using Open Transactions. I'm watching a video on it now so hopefully I'll learn that OT is ready to go but I think the OT community could do a better job of providing demo servers or examples of sites that are using it.

I'm definitely "still interested", but I still think Open Transactions+bitcoin is probably the way to go. It is as distributed as we need, and the technology is already there.
I don't think we need to create new chains for everything. The issuance of backed tokens is pretty much what OT is about.

Just something to think about:

Bitcoin enables many other P2P projects, most of which we can't imagine yet.
I think there should be some sort of P2P Bitcoin-backed database, that could serve as infrastructure to such projects.

I wrote a paragraph about it on Reddit:


I'm not saying that it makes sense to develop this database while also developing BDSE, but it's just something to keep in mind. If you could kill two birds with one stone ...

Bitcoin's beauty is the fact that the underlying database is distributed, and enforced by the 51% rule.  A global asset exchange/registry based on the same principles would be revolutionary. 

Hard ?  Yes, but that's what we do.

Is anyone still interested in this idea? I think a distributed asset exchange built on a blockchain with written linkage to traditional legal entities has merit.

Don't know, maybe. I see it complicated.

Not to the chain of course but perhaps sending requests to the p2p network of miners instead... the answers could be in the blocks. The message structure doesn't need to be precisely identical, only "compatible" so that centralized tokens could be exchanged by tokens issued on this chain, and also that issuers could migrate their tokens from a server to the chain and vice-verse.

Now I understand what you mean. I would say it is not feasible, but don't take my word for it. I don't understand OT well enough to be able to firmly tell you that it is not possible. It's just that you can't talk to a block chain like you do with a server. Request, answer, request, answer, etc. If possible, it would be definitely harder to implement than the chain proposed here.

I don't even know if it's feasible, but I was imagining a blockchain implementation that would do pretty much the same task an OT server does. This way, such chain could be seen as another OT server by OT clients. This would make everything more flexible, adding competition and interoperability. Do you see what I mean? Actually, do you understand the OT protocol well enough to say if what I'm imagining is even feasible?

I mean cheaper for the issuer than running its own server.

Sure, the OT solution could be "tomorrow". And this thing "the day after tomorrow" or later. We're just playing with a design draft.
I'm interested in this solution because it offers some advantages and enables new possibilities. For example, (and this is what's most interesting to me) a blockchain based ripple.

That sounds great.

I'm not sure I get this part. What's an OT-blockchain?

Are you sure of that? Miners would want their fees. There's also the harder to measure costs of waiting for confirmations, as well as the probability of double-spends.

Anyway, we can't really know for sure what would be better, I guess both have its uses. I'm just saying that I think it would be more productive if we would focus on improving what's already there for OT, instead of working on this new chain right now. The OT protocol seems promising. I myself should read more about it and eventually contribute, I believe I saw there's a Java client for it or something...

But of course, an OT-blockchain, compatible with the OT protocol, would only bring extra choices and thus improvements.

As far as I can tell, each OT transaction server would have its own market. I meant global in the sense of unique.

Of course.

This solution as well as the OT one, would allow the issuer to manage the double-spendings cheaply. It's just a technical advantage for the issuer and a convenience for the buyers. You also remove the needed trust from the operators of the market.
For example, with GLBSE you have to trust both the issuer and the market managers.

That's the ideal, of course, but there's no way we can do that with technology only. That doesn't mean strong reputation systems can't arise. If everything you've got are "gentlemen agreements", we can at least try to better identify who are the gentlemen and who are not. That's not as good as enforceable contracts, but still, I believe such a thing could bring some competition into an over regulated and consequently too concentrated market.

Legal contracts? Of course.
If the contract is based on certain technology (say the parts of a vehicle) the courts may have to call expert witnesses. That's how it works in Spain, at least.


I'm not planning on enforcing nothing legally. That was YOUR requirement. I was just telling you how you could do it.
Of course, you need a lawyer to write such a contract and make it well defined and legal, maybe even a notary.
By the way, a service offering those kind of contracts is an entrepreneurial opportunity if any lawyer's interested...

The OT protocol is pretty much global too. And I must insist: this chain solution would not manage to decentralize the most important aspect of this problem, which is the trust on the issuer. This problem is inherently centralized. The chain would only decentralize double-spend checks, which IMHO are a minor issue in this context (if your issuer is serious, he won't allow double-spending, if he's not, that's the least of your worries).

Anyway, if you are really wanting to go by this chain solution, I'd suggest researching the viability of making this chain fully compatible with OT, in the sense that the chain itself, in what concerns the OT protocol, could be seen as just an extra server. This would bring more flexibility, interaction and competition.


I definitely agree with that as well.

A series of chained blocks. Obviously.

Do you really believe that existing government courts are going to enforce these things?

Good luck explaining to the judge what a "blockchain" is

You can't enforce law with a technology. But you could sign a legal contract (maybe with a digital signature technology provided by your state) in which you express the legal meaning of the tokens. This way you could sell shares in the legal sense.
What we want is secure the tokens by decentralizing its management first and let people use them with the laws of their jurisdiction or in an informal way if it serves them.

Until recently Open Transactions was not ready to test.

Now it is working, and I am running a test, see https://bitcointalksearch.org/topic/open-transactions-server-assetbondcommoditycryptocoindeedsharestock-exch-53329

It does not have voting yet, nor dividend distribution. So it is not ready to handle voting shares yet.

-MarkM-

This has the same problem as GLBSE: it's called a stock exchange, but what's exchanged isn't actually stock.

Stock in a company represents an enforceable claim on the assets and future earnings of the company.  If those assets are physical, then ultimately that claim must be backed up by an entity (i.e. a government) that is able to use force (i.e. police with guns) to transfer of those physical assets if the company's management flagrantly and repeatedly disobeys the instructions (or at least the best interests) of the shareholders.  This sort of liquidation does not happen very often in real life, but the threat of it happening is essential for the proper functioning of a securities system.

So this can't possibly be useful except for companies whose assets are 100% intangible and for which transfer of those assets can be enforced cryptographically.  There aren't many companies that fit that description.  In fact, there aren't many other assets other than bitcoins that fit that description.  Namecoin is revolutionary because it moves domain names into this category.

I think using OT servers would be an improvement over the existing model for both currency and share exchanges. This could spring more specialization and provide more security. The current exchanges and eWallets would be issuers and the proper exchanges would reside in OT servers with less critical security. If there's enough of them, you only really need to trust the issuers.

But is worth to consider the idea for a longer run.
The advantage of the chain solution is that it would enable a global and completely decentralized market, but it has disadvantages too.
For example, the trades in OT are instant, but the trades within the chain may take longer.

The simplest design I can think of would be a chain like bitcoin but in which each key pair can issue its own currency.
Each output would need to additionally contain the address of the issuer.
The units can represent anything: an mtgoxUSD, a property tittle, an Islamic Bank of Bitcoin share, a right to vote in your neighbor assembly, an IOU for an hour of work...
The parties involved are responsible to make good for the property represented outside of the protocol.
For example, you can pay back your tradehillUSD to tradehill to receive the funds in your bank account.
To receive the profits of a share, you can sign with the key that holds the shares the bitcoin address you want to receive them on.
Basically it would work like smart property but without the need of the "tainted satoshi".
This has an advantage. Some transactions are "instant".
For example, If I give you 10 fresh issued timonCoins, you don't really need to wait for confirmations once you have the transaction.
There's no way I can double spend something that I can just create at will. When you give them to a third person, he has to wait because you can cheat him by doublespend.
When I issue and give them to you I can cheat you, but I don't need to double spend. I can just not honor my word as you're directly trusting me when you accept my shareCoins in exchange of something else.
The fees can be payed in bitcoins or the tokens within the chain (but some miners may not want them).
With contracts the tokens can be securely traded for bitcoins.
Trade tokens between them is trivial (like trading a tainted satoshi for regular bitcoins in the smart property wiki page).

Maybe an additional communication protocol to send messages directly to a given address would be useful.
For example, when the manager of a company wants to pay the dividends, he can look the public keys of the shareholders and send them a ciphered message asking for the bitcoin address.

I have no clue how this could work for options though.

EDIT:
+1

OT is an interesting development and looks to have had a lot of work done on it. Why isn't there a stock exchange built on it already? What has it been lacking? If it's possible to retain an export of all the data necessary to get up and running on another exchange or even better to run on multiple exchanges simultaneously that would seem to accomplish many of the goals of this DBSE.

As an aside, maybe it should be called more generally a Distributed Asset Exchange since Bitcoin is just the currency of choice and Stocks are just one instrument that might be handled within it.

I do still like the idea that in-person or off-exchange transfers could be made if a blockchain existed for these assets.

An OT server can publish all its receipts, so everyone knows the balances.

If a server goes away, the issuer of a token can re-issue on another server.

-MarkM-

Correct.  But we want the ability to move to a different centralized place.

Say GLBSE goes bad (I don't think he will, but this is hypothetical).  We would all be stuck because there is no access to their database.  We have our private keys encrypted, but that doesn't get us our accounts back.

However, if GLBSE had their accounts in a blockchain that any other exchange could also use, we could all move around freely.

But this problem is inherently centralized. You'll only decentralize the double-spending checks with such blockchain, but the main trust problem - if the issuer of the token will keep up to his "words" - remains centralized on the issuer.

But OT is centralized.  I think we want OT that uses a blockchain.

Shouldn't we be looking toward something like Open Transactions instead? The protocol is already there, and as far as I understood, it suits precisely these kind of "token issuing" use cases.

Sure... people can then operate web based or other exchanges that do matchmaking and gather orders for a small fee.  It would be nice if individual nodes could optionally hold a queryable order book.

I think you might be confusing this stock exchange idea with the idea of a distributed currency exchange which is discussed more often. I believe the goal here is to develop a distributed generalization of the blockchain that can be used for pretty much any asset. A distributed currency exchange may be a special case of a distributed stock exchange but I still think one should keep the trading logic out of this first version and focus on the problem of allowing users to issue assets like shares of stock, bonds, options and to be able to transfer ownership to other users of the system.

I love this.  Don't understand it all but it seems like a good addition to a coin.

I don't remember well. If you can't drop them you can at least not renew them.
But it can be implemented inside bitcoin too. Isn't not interfering with the host chain the reason for starting the new one?
Is it really better to implement it inside namecoin instead of inside bitcoin or in its own chain?

I suppose. I was thinking of simply re-issuing them later possibly.

I kind of like the idea of buying them back at higher price than I issued them at instead of dividends, because if you have to actually part with shares to realise income/profit the percentage of total shares you own would change if, and as, you cash out. So someone with 51% would have good reason to stay invested instead of cashing out if they want to retain a "controlling interest".

Truthfully though I am not really enamoured of the idea of issuing "common stock", that is, voting shares. I actually thought most share issues nowadays are "preferred shares", used just to raise capital not to dilute control of the company by handing out votes.

Doesn't namecoin have any way of dropping names? Surely one could simply not pay to renew them when they expire if one no longer needs them?

-MarkM-

I see. Yes, that could work. Don't sure why but I don't like it.
I guess I would want the shares to be destroyed if they return to the original issuer.

I was thinking pretty simplistic, something like d/knotwork to register my knotwork.bit domain then use subdomain-like strings maybe like d/share001.knotwork, d/share002.knotwork etc.

I expect that is not ideal, but since domains can be transferred to new owners presumably shares structured like domains would also be transferable.

Using the actual domain namespace would allow each share to have its own website as a side-effect I guess.

But maybe other namespaces in the chain can also be transferred from owner to owner?

-MarkM-

I've heard this before but I don't get how it would work.
Let's say I want to issue 10 shares (or units or whatever) with address A and give them to address B. Then B gives the shares to address C.
How is it done in namecoin?

I originally liked the idea of using namecoin, but I think some of the asset handling would be better suited for another chain.

So you think we should share addresses across BTC and TT? Interesting. People are still going to have a bunch of addresses though.

How far are we going to take anonymity.  Will it be possible to tell who owns what shares?  Or could someone have a bunch of accounts.  Should we have something like namecoin's personal namespace that allows people to list all of their addresses?

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-

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.

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

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


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.

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.

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.

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

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?

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.

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.

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.

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.

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.

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