Topic: A cryptographic direct business to investor bitcoin stock certificate system (Read 2149 times)

Why don't you simply use the btc block chain as a delivery method directly (indirectly?)

Build a wallet software used only for the exchange.
Let it load a btc address directly (for payment processing).
Signed msgs in the btc blockchain for all transactions (buy, sell, buyback, whatever we need).

Then the client software is capable of displaying all activity simply by parsing the blockchain for correctly formatted stock exchange activity.

and BAM instant stock market using existing network.... and all we really have to design is a slick UI and define the layout of the msgs used by the client.

Of course it would only be as anonymous as the users wanted it to be.

No, it won't let you pay a dividend in the same asset type as the shares.

For example, you can't pay Pepsi dividends using Pepsi shares. Any other asset type should work though.


In Bitcoin it's possible to send a transaction to more than one Bitcoin address in a single spend, such that a vote of the recipients is necessary to transfer back out.

Then it's just a matter of setting up a protocol between any group (say, a group of OT servers) where they agree to vote in favor of any bailout requests that are properly signed by both parties (wallet and server in question.) Then if the signatures check out, they just take a 4-out-of-5 vote (or whatever), and transfer the Bitcoins back out. Even if the OT server you are using disappears entirely, you would still be able to submit a recovery request to the other servers and get your vote.

I've posted extensively about this, if you are curious to read more. Also check out the OT wiki.

So you could pay dividends using shares of the company (since any asset can be used to pay dividends)? Interesting.

Could you go into more detail about what this multi-sig based voting pool is?

Here's how you would do that on OT:

1. Have a Bitcoin issuer, who holds actual Bitcoins, and who issues Bitcoin UNITS onto the OT server, where OT users can open BTC Unit accounts, and trade around these units (exchanging them back out with the Bitcoin issuer, whenever they want to get back off the server.) The long-term vision is to store the backing Bitcoins in a voting pool on the blockchain (rather than directly with an issuer) in order to protect the users from being ripped off by the issuer. Voting pools aren't coded yet though, so for now, you would have to trust a Bitcoin issuer, the same as a gold issuer or any other kind of issuer.

2. Have a stock issuer for each type of shares. For example, if you issued "Pepsi shares" onto the server, then you must be the Pepsi issuer. You could issue some Pepsi shares, in that example, and then sell them on the OT market in return for BTC units, or any other currency issued there.

3. Whenever the Pepsi issuer is ready to pay a dividend, he chooses the currency it's paid in (let's say, BTC units, or centicoins or millicoins) and he also chooses the payout per share. OT will then loop through all the Pepsi accounts and send a cheque to each account holder, based on the number of shares in his account.

4. Each payee receives a dividend cheque in his inbox, denominated in BTC units. He can cash the cheque, or deposit it into any BTC-unit denominated account. (This is all working already.)

5. To get actual Bitcoins back off of the OT server, the payee would take his BTC units to the BTC units issuer, and get a blockchain transfer of actual coins.

6. It would be possible to code the OT server itself to act as the BTC issuer, which would automate things without involving any third parties. But then you would have to trust the OT server with your Bitcoins during the time it is holding them, which means you are vulnerable to a malicious server, or a hacked server. I have therefore avoided this in order to protect the OT brand, preferring instead to aim for the eventual "voting pool on the blockchain" solution, which is more secure than having to trust an issuer.

It wouldn't be hard to write some scripts that receive Bitcoins (using whatever tools you would use for those already) and then use an OT-Script to issue units onto the OT server, or to remove said units, using whatever rules you devise based on what you are trying to do on the blockchain. The entire OT API is available in script form now, so there's no reason you can't automate behaviors using cron and existing Bitcoin command-line tools.

In other words, while OT does enable you to issue shares, and to pay dividends, it doesn't pay those dividends directly in BTC to a blockchain address. Instead, it pays the dividends in OT-BTC-units, internal to OT, by sending a cashier's cheque to each shareholder, just as it might pay dividends in gold, or silver, or other currencies. (Any OT units will work.) Payees would have to then bail their BTC-units back off the OT server (and back onto the blockchain), through their BTC issuer. (And eventually, through a multisig-based voting pool on the blockchain, which would act as the "issuer.")

I have been playing around with developing something similar to this, since the events at GLBSE. I am actually on my way out the door, but I hope to be able to discuss this with you guys further.

Sounds interesting, keep us posted.

Yeah, that clears up alot, and makes it sound much more workable than having a never-ending pile of receipts.

I gues what I am envisioning would be a front-end client for Open Transactions, which associates a bitcoin address with the shares, allowing the issuer to for example, send dividends or coupon payments to share holders.

To be clear: Open-Transactions does not need to store any historical data, other than the last signed receipt.

Most transaction systems break down without their historical data, which is necessary for them to prove the current state of the system. But Open-Transactions is able to prove your balance, as well as which instruments are still valid, and which transactions have closed, without storing the entire history, but instead by merely storing the last signed receipt.

Therefore when OT places receipts in a DHT (which it doesn't do yet) it will only be for a temporary period of time, in order to facilitate receipt exchange, and to give auditors access to the receipts. It will not be because of some need to keep them around as "necessary data" and it will not result in some "ever-growing pile."

I hope that clears it up.

Hey, if you don't want the volume of a full p2p network fine.

Each server can run its own user-inbox-storage server and not care about your p2p hopes until you pony up the storage your idea would require.

How much p2p data do you actually want?

-MarkM-

The problem I forsee, and it is one shared by bitcoins, is that the distributed hash table just keeps on growing, like the blockchain. The more popular the system becomes, the faster the database grows, and the more memory needed to save it. Is there a way to keep all the nessecary  data without the evergrowing pile of everybodies data?

The proposed audit system for Open Transactions is for all receipts to be published to a Disitributed Hash Table.

Is there anything preventing such a distributed table from being "p2p" ?

If anyone is free to participate in the table, then maybe such a table could amount to a p2p network whereby anyone who cares can observe all changes of ownership of assets, as witnessed by the signed receipts.

The plan is that even the normal client software would no longer pick up the inboxes of its accounts directly from the server; the server does not put one copy into the account's inbox and send another to the DHT for auditors to see, the DHT is where they all go and clients and auditors alike pick them up from there.

If people were willing to co-operate / collaborate in forming the DHT, anyone who wished to who is using an Open Transactions server and using a DHT to send receipts could all use the same DHT, making a huge global distributed database of receipts from all such servers who choose to and are permitted to participate in that network.

-MarkM-

I am looking into Open Transactions, this might be able to be a system built on top of it.

With the recent turmoil surrounding the closing of the Global Bitcoin Stock Exchange, I have put some thought into a way to have a bitcoin stock market without a single point of failure. Since there must be trust in the asset issuer for assets to have any value, a completely decentralized system is unnecessary.

The most basic way to have a stock (or bond) system would be for the company to record identities using cryptographic signatures, and correlate ownership of a number of shares and a bitcoin address with each identity.

Transactions would be kept in a database, similar to the bitcoin system, where any transaction must be signed by the current owner.
For example, a Company sells stock. An investor A provides their public key, and the company signs messages transferring shares to A. If A sells shares to B, then they send a gpg signed message to the company with the public key of B and the number of shares.  Each investor sends a gpg signed message with a bitcoin address to the company to receive any dividends. To change the address for receiving dividends they would just send a new signed message with the new bitcoin address.

Each company would run their own database, thus they would always have current information of who owns what.

Each investor would connect to the different companies. They would have cryptographic receipts showing any changes to their own account(s).
What I have described would handle transfers of assets. The bidding could be spread among many exchanges, OTC, etc. Brokers could have accounts for investors.

There could be an option, set by the issuer, on whether or not shares could be transferred to a unregistered account. By this I mean: to register with a company, you send a gpg signed message of a bitcoin address. That way, whoever own the shares there is a bitcoin address associated with those shares to receive dividends. You could also register an email address with the company to receive shareholder notices. If the option is selected to allow unregistered owners, then shares can be transferred to a public key which the company has no record of. This key could be later claimed by its owner to receive dividends or just to transfer the shares elsewhere. There is a danger here that the key was an error, and nobody owns it, thus the company might want to require registration so no invalid keys are used. Also, a company might not want to deal with having dividends owed to shares with no associated bitcoin address.

I suggest using an escrow system for transferring the assets/bitcoins when a sale is made. Without escrow, scamming might be too easy going both ways (I offer to buy your shares but don’t send bitcoin, or I offer to sell you shares take the bitcoin but never had any shares). But doing the escrow would not have to be centralized. And this is actually a common concern in bitcoin businesses (trying to decide who sends fist, and whether to trust a third party). One way to lower the total number of people needing trust would be to have the asset issuer do the escrowing. They can even do a check to see if the person selling the shares is the owner.

Voting would be available too. The company publishes a motion, each shareholder sends their gpg signed vote, and at the end of voting the company correlates the votes with the number of shares held by that key to tally the votes.