Bitcoin Forum
November 01, 2024, 12:30:57 PM *
News: Bitcoin Pumpkin Carving Contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: stock exchange based on colored coins  (Read 2920 times)
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
October 15, 2012, 11:26:57 PM
 #1

Stock market needs some unique features, so I'm going to describe how they map unto 'colored coin' concept.

(Please check general intro into colored coins first if you aren't familiar with it: https://bitcointalk.org/index.php?topic=106373.0)

I. Issuing shares.

So you have a company and you want to issue shares. To do that, you create a color definition (with help of client software, which will likely have "issue shares" button). Color definition should include:

1. Genesis transaction information (transaction hash, output number). Genesis transaction will be created by client software out of coins you already own.
2. Information about units, e.g. 1 satoshi in genesis transaction = 1 share.
3. Display name, e.g. "XYZ corporation"
4. Identifier of a contract, e.g. its hash
5. Identifier of a color, e.g. hash of address used to issue shares.

Once you've made this color definition you can upload it to your site or maybe into some color definition directory. Anybody who is interested in XYZ corporation will be able to get this definition and import it into their client software.

After that you can sell your shares in an IPO. People who have imported color definition will be able to distinguish shares from normal bitcoins. (How exactly shares can be traded is discussed below.)

But we have an open question: how would we handle additional share issues? Quite often company needs to issue more shares.

There is a couple of possible approaches:

1. Do not allow additional issues at all. All authorized shares should be included into original color definition. If necessary, company can sell them in blocks, keeping some unissued/treasury shares for itself. So one should authorize more shares than he plans to sell, just in case...

2. Client software should recognize ALL outputs which come from issuing address as issues of shares. So, basically, issuer can make any amount of shares at any time.

3. Client software will identify all outputs which come from issuing address, but it will ask confirmation from user before it will start recognizing coins coming from those new outputs. I.e. client software will show a message: "XYZ corporation issued 1000 more shares. Do you approve that?"

4. Additional issue is done through updated color definition. Users will have to import updated definition manually. (Or perhaps client software will pull it from some directory and will ask whether they approve changes.)

Approaches 1 and 2 are problematic because issuer can suddenly release a large quantity of shares, thus diluting existing shareholders/bondholders. It can make shareholder identification rather problematic.

So I'm more for approaches where user needs to consent to new issue. It is more democratic, i.e. people kind of vote for whether they authorize new issue (it is different from a normal shareholder vote because it is implicit). Also they have control: if something weird will happen, people will have a warning before they accept diluted shares. E.g. consider a scenario with a hacked server: attacker obtains private key used to sign color definition, issues more shares and tries to dump them on market to get money. If there is a confirmation, he won't be able to do that.

Chromia: a better dapp platform
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
October 15, 2012, 11:29:30 PM
 #2

In next releases we'll discuss these topics:

II. Trading, i.e. exchange proper functionality.
III. Shareholder voting, shareholder identification.
IV. Dividends.
V. Buybacks.

Stay tuned!

I'm going to sleep now, though...

Chromia: a better dapp platform
yoniassia
Newbie
*
Offline Offline

Activity: 42
Merit: 0



View Profile WWW
October 16, 2012, 12:07:06 AM
 #3

Maybe it can be kept flexible to the company to decide, and enable all different scenario's to be implemented by issuers.
For example, Company A can decide they can issue additional shares without any limitation, Company B can decide they will issue only if all users say ok, company C decide on voting mechanism, and Company D decides that they print it once and that's it.
When you issue a color you should simply explain how you are going to color more coins, and your users need to accept it.

Getting the all user consent for each additional shares is not practical, it will reach a deadlock very fast, and any kind of voting will require mapping of share to voting rights and min voting rights for decisions, that will become corporate governance which is must stay flexible (like it is today flexible to change the articles of association of a company).

So Company X can say :
I am selling BTX (colored bitcoin of company X) for 2 BTC, so Company X takes 1000 BTC and colors them in BTX, and now sells 500 BTX for 1000 BTC. With option #2 , if more people want to buy shares, and they bought all shares that were available, than CompanyX can now issue another 1000 at another price, etc' .

That's the most trivial case, same as it works in 100% owned company.

If you consider real companies, than in most cases its shareholders get voting rights for each share, and shares have an initial value (usually low like 1 USD) and then define in their articles that there needs to be a majority to issue more shares (off course also requires more code, since there might be conflicts etc' and then the coloring code needs to also deal with "governance" code), maybe corporate governance should be 3rd party to colored bitcoins and not a requirement.
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1100


View Profile
October 16, 2012, 05:41:14 AM
 #4

Approaches 1 and 2 are problematic because issuer can suddenly release a large quantity of shares, thus diluting existing shareholders/bondholders. It can make shareholder identification rather problematic.

So I'm more for approaches where user needs to consent to new issue. It is more democratic, i.e. people kind of vote for whether they authorize new issue (it is different from a normal shareholder vote because it is implicit). Also they have control: if something weird will happen, people will have a warning before they accept diluted shares.

Everybody hits this conceptual problem eventually: new, dilutive issues.

The thing is, they are unavoidable.  It is a variant of the Sybil attack.  An issuer may create new shares at any time, simply by representing themselves under a new identity.  An issuer may also issue more shares/bonds than there are assets to back their bond (i.e. a mining company selling 1TH worth of bonds, when they only have 500GH).

Without rating and third party auditing and real-world identity checking (of the issuer), voting to authorize a new issue might simply provide an illusion of safety behind which dishonest folks hide.

The question to ask oneself is:  what would a rational (if amoral) economic actor do?  What are the economic incentives that drive the issuer, and the holders?  And what can software do to change or enhance those incentives?

For example, software could make it easy to track payments as well as smart property.  This makes issuer -> holder payments transparent, and audit-able by any third party reading the block chain.  Third parties could verify that an issuer pays everyone on the publicly known (somehow) terms.

This software change creates a familiar, positive economic incentives -- good ratings, transparent, provable operations -- for issuers.

Satoshi spent a long time designing the economic incentives surrounding bitcoin.  For example, he worked hard to make block header hashing a static affair, not directly related to transaction or block byte count.  Increasing the "work" as block size increased would encourage miners to make their blocks as small as possible, he realized.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
October 16, 2012, 05:59:15 AM
 #5

I think that share dilution should not be made possible - instead the "company" should simply issue a new contract for a new "color" and if they desire offer cheaper purchasing price for owners of the original contract (the link between the two contracts and the issuer could be stored somewhere externally).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
October 16, 2012, 08:17:01 AM
 #6

Quote
Everybody hits this conceptual problem eventually: new, dilutive issues.

I don't think it's a conceptual problem. Dilution of an existing color is more like a convenience function, it isn't fundamental.

Association between color and issuing address is also merely a convenience. It isn't fundamental. On blockchain level, we trace transaction outputs. Addresses are nearly irrelevant.

So it's more like my question was: do you REALLY need that convenience? Or maybe we can simply use most simple and restrictive approach?
"One color = one transaction output" kinda makes sense.

Quote
The thing is, they are unavoidable.  It is a variant of the Sybil attack.  An issuer may create new shares at any time, simply by representing themselves under a new identity.  An issuer may also issue more shares/bonds than there are assets to back their bond (i.e. a mining company selling 1TH worth of bonds, when they only have 500GH).

These are different things. On stock/bond markets shares represent ownership of securities. I.e. contact which is associated with color will say that shareholders which can be identified through blockchain tracing have certain rights. Once you own shares you can demand contract to be enforced via legal mechanism, at least in theory.
I.e. bond holders can sue issuer if he didn't back his bonds with assets as promised, and perhaps he will be personally liable if contract says that.

Electronic signatures are recognized by law enforcement, and I'm sure there is a way to tie identity to contract. So as long as holder identification mechanism works correctly, colored coin mechanism is about as good as having a signed paper.

However if you allow dilution of existing colors, it might break identification mechanism. E.g. contract says there are 1000 bonds, but 1,000,000 are issued. Obviously this is wrong, but how do we find which of these 1,000,000 bonds are valid? If there is no good way to do it, I'd say it is a failure of colored coins as of an identification mechanism.

Don't forget that issuer can always claim that his private key was stolen and that he's not responsible for over-issuance. Again, I don't want theft, or theft-used-as-an-excuse, to be able to break holder identification via colored coins.

If we use the most restricted model, it provides a certain guarantee: if you currently hold 1 bond out of 1000 issued, you can always prove that you own 1 bond of 1000 issued, no matter what.

Quote
Without rating and third party auditing and real-world identity checking (of the issuer), voting to authorize a new issue might simply provide an illusion of safety behind which dishonest folks hide.

Rating, third party audit and real-world identity check are orthogonal to this: they are necessary to for safety of investment, but even if issuer is honest there is always a room for software failure or theft which can wrack a havoc through dilution.

The question to ask oneself is:  what would a rational (if amoral) economic actor do?  What are the economic incentives that drive the issuer, and the holders?  And what can software do to change or enhance those incentives?

Quote
Satoshi spent a long time designing the economic incentives surrounding bitcoin.  For example, he worked hard to make block header hashing a static affair, not directly related to transaction or block byte count.  Increasing the "work" as block size increased would encourage miners to make their blocks as small as possible, he realized.

Satoshi also made it so that only 21 million of coins will be issued, and it isn't a matter of incentive but a matter of consensus.

Even if all miners will refuse to cut block awards client software simply won't accept their blocks. So expansion of Bitcoin emission is only possible with approval of considerable number of users, not miners. Does it remind you anything?

I believe that implicit-consensus-based approach is inherently bitcoinesque, for better or worse.

Chromia: a better dapp platform
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1100


View Profile
October 16, 2012, 03:33:32 PM
Last edit: October 16, 2012, 05:59:09 PM by jgarzik
 #7

Quote
Satoshi spent a long time designing the economic incentives surrounding bitcoin.  For example, he worked hard to make block header hashing a static affair, not directly related to transaction or block byte count.  Increasing the "work" as block size increased would encourage miners to make their blocks as small as possible, he realized.

Satoshi also made it so that only 21 million of coins will be issued, and it isn't a matter of incentive but a matter of consensus.

It is entirely a matter of incentives.  Satoshi designed the system so that users would have the economic incentive to maintain the 21M limit -- thereby maintaining the value of the bitcoins in their pockets.  They have incentives to maintain a distributed consensus.  Economic incentives drive consensus making.

Quote
Even if all miners will refuse to cut block awards client software simply won't accept their blocks. So expansion of Bitcoin emission is only possible with approval of considerable number of users, not miners. Does it remind you anything?

Yes -- economic incentives.  Smiley

Miners cannot mine without users using their bitcoins.  Users cannot use bitcoins without miners mining.

Otherwise there is a loss of value.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
chrisrico
Hero Member
*****
Offline Offline

Activity: 496
Merit: 500


View Profile
October 16, 2012, 04:31:32 PM
 #8

Miners cannot mine without users using their bitcoins.

Do you mean after the end of the block subsidy, and that they won't mine? Otherwise, I disagree. Blocks can be created without any transactions...

Users cannot use bitcoins without miners mining.

This is true, but as long as there are users that want to use bitcoins, then there will be miners, even if just the users themselves.
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1100


View Profile
October 16, 2012, 04:55:46 PM
 #9

Miners cannot mine without users using their bitcoins.

Do you mean after the end of the block subsidy, and that they won't mine? Otherwise, I disagree. Blocks can be created without any transactions...

You are micro-parsing.  The post was discussing economic incentives.

Without users, an empty block has zero value to a miner, regardless of initial block reward.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
chrisrico
Hero Member
*****
Offline Offline

Activity: 496
Merit: 500


View Profile
October 16, 2012, 05:16:54 PM
 #10

Ah, I see your point now.
matthewh3
Legendary
*
Offline Offline

Activity: 1372
Merit: 1003



View Profile WWW
October 26, 2012, 02:01:42 AM
 #11

In next releases we'll discuss these topics:

II. Trading, i.e. exchange proper functionality.
III. Shareholder voting, shareholder identification.
IV. Dividends.
V. Buybacks.

Stay tuned!

I'm going to sleep now, though...

Any ideas on those two subjects yet?

killerstorm (OP)
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
October 26, 2012, 02:23:44 PM
 #12

I have plenty of ideas, but writing them down takes considerable time, and I also need to work on Armory client.

I'll try to write more about it soon. This weekend, maybe.

Chromia: a better dapp platform
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!