Maybe they prefer to stay the way they are. Remember that the trades will be slower if they're executed within a chain.
But they can always do both.

Which is why I think a hybrid solution may be the best bet.

Have the stock ownership and transfers handled by a decentralized blockchain and then allow multiple exchanges to support higher level tools like placing trades/orders against that blockchain.

True but I hope they would see the advantage (maybe not personal advantage) of having the actual "shares" exist outside of GLBSE.  Imagine if for whatever reason GLBSE goes down forever tomorrow.  The chaos and yet more negative PR that brings to Bitcoin.

Just wanted to point everyone watching this thread to this new thread by btc_artist about DBSE

If merged mining can work with arbitrary numbers of blockchains, maybe shares could be issued simply by starting a new chain that issues that many units in its genesis block? The issuing ocmpany would own those, and ownership can spread from there by normal operations of changing ownership on blockchains.

There are already supposedly methods one can use to lock in change of ownership on one chain so a change of ownership of something on another chain has to happen too.

Basically each type of share would be another alt currency, like the GMC (General Mining Corp) and GRF (General Retirement Funds) chains.

-MarkM-

Open Transactions uses cryptography to sign everything, maybe just publishing transactions can suffice?

Anyone interested could keep histories, even though Open Transactions uses triple-signed receipts to avoid actually needing to keep transaction histories. (The receipt, signed by the two parties to the transaction and the server that executed it, serves as "proof" both parties and the notary server all agreed as to the balance, making the history of how that balance was arrived at moot/irrelevant.)

Since we depend on the issuer anyway - the company of which shares are issued - they could simply run a server themselves. They need not though, as any other server can allow them to do an issue. Either way there is their signed contract describing the issue, and triple-signed transactions whenever any units of the issue change ownership.

Ultimately we probably don't really care much how many people or entities who can do nothing in the way of actually grabbing for us some portion of the real assets of a company we have shares in think we have such shares. It is those who can actually give us something real when the company dies that need to know how much of the assets should be shipped to us or sold for something that is shipped/transferred to us.

But if all the transactions get published, so that the issuer and anyone else can see a server never issued any more than the actual issuer of the contract ordered them to, does it really matter what kind of storage or database various observers choose to use to store that info?

If a company's only assets are to be p2p assets though, such as holdings of various alt coins for example, then possibly it might make sense to try to run the whole company as a p2p application. As soon as you want it to hold non p2p assets though, there is centralisation, in that the value of each such asset is probably centralised at the location of that asset and/or the legal/de-facto ownership/control of that asset.

("Smart assets" can help with that though so maybe we should work on developing those while at it.)

-MarkM-

Heh. Well, live and learn.

Re Meni's concerns about commited offers and cancelling offers:

Cannot people who want to offer some bitcoins for, say, some litecoins use the cross-chain atomic trades system?

Or, if offering some blue satoshis for some red satoshis, use the in-chain atomic colour-trade system?

Both systems take a few steps, don't they? Until all the steps are complete the transaction the two (or potentially more?) parties are constructing cannot be mined into a block, right?

So one could have countless numbers of partially constructed atomic trades in progress at any particular moment, constantly optimising/prioritising how many steps toward completion/finalisation against how good a deal any particular atomic trade currently being constructed would be compared to others if it does end up being the one that gets finalised.

Cancelling is, surely, simply a matter of spending out from under it the outputs it is secifying as its inputs, so if someone does not finalise an atomic trade sooner than you spend out from under it the coins it planned to use as its input tough, it is invalidated thus in effect cancelled?

-MarkM-

That should be enough IMO.


We mean this, not currently possible (nLockTime and tx replacements are disabled).


For the all assets in one chain case (possible right now, that's what pybond tries to do), the transaction must be constructed carefully to take the colours into account, but nothing special is required for the signatures, just the default SIGHASH_ALL and all parties involved signing. If anyone moves its coins before the transaction gets into the block it is canceled no matter if all the signatures have been added or not.