Decentralized BTC Stock Market [Goodbye GLBSE]

[killerstorm]

Suppose I announced, "hey everybody, my name is Mike Caldwell, and I have X ounces of gold here in Sandy, Utah, USA.  All Satoshis numbered <insert list here> are hereby colored and represent legally binding claims on my gold... PGP signed, me.  Happy trading."  Then I'd have a functioning system exactly as you suggest.  And then someone from the government would be kicking down my door and taking the gold and wiring me with a smart ankle bracelet for the same reasons they did the same to E-Gold.

http://en.wikipedia.org/wiki/E-gold

The difference is that e-gold was actually providing a money-transfer service and was even profiting from it.

If you just issue some securities you won't be directly providing a service. So It would be much harder for authorities to claim that you're facilitating money laundering or something. After all, you can identify people who buy tokens from and who sell you tokens. These tokens can be traded somewhere, but in that sense they are not different from bearer certificates, cash, gold coins etc.

But if you want to do it on a large scale, it would be much better to do it through offshore shell company or something like that.

Also I've outlined a way which would allow to produce personalized final contract only at the last step, and last time I checked IOUs are not illegal.

Maybe authorities would claim that your intent was to create negotiable securities even though contracts do not look like that.

But then again, intent of using an offshore trust is paying less taxes, but it is not illegal. Even US presidential candidate does that, you know.

[1714884410]

1714884410

[jtimon]

By the way, I still see "not having to modify the current chain protocol" as the only advantage that colored coins have over ripplecoin.
Having to represent the assets with underlaying satoshis is just an artificial limitation for the system.

Well, another advantage is that it is easier to implement atomic coin swaps in one blockchain than implement cross-blockchain trade.

Atomic coin swapping can be implemented with today-enabled features and it is inherently 100% secure.

Cross-blockchain trade requires support for 'contracts' and non-traditional scripts, and it has different security considerations:

If the bitcoin protocol were modified, we would use atomic coin swapping too.
If you make it in another chain, you can make atomic coin swapping with the new hostcoin, which you need anyway to incentive miners and pay them tx fees.
Ideally I would prefer to change the bitcoin protocol, but I doubt a consensus on this can be achieved fast. Changing the protocol seems more possible now though. When I first proposed is it was more like "go on and make your fork" for any hard fork proposed. Now people seem more open to extend bitcoin functionality.

To be clear, the difference is that outputs with no inputs would be allowed (issuing) and the "credit assets" would be accounted separately from the bitcoins. Maybe adding the issuing address to outputs (what I think you mean when you say "tagging") would be a necessary optimization...

[killerstorm]

If the bitcoin protocol were modified, we would use atomic coin swapping too.

Sure. But there is a lot of advantages of using the Bitcoin for payments: it is already established, it has a lot of ecosystem around it, exchange rate is not so volatile etc.

If you start a new currency exchange rate can easily change 10000x. It would be rather hard to convince people to use it when it's so volatile. So it will create additional problems for adoption.

Ideally I would prefer to change the bitcoin protocol, but I doubt a consensus on this can be achieved fast.

I'm fairly sure people will tell you to make alt-chain with changed protocol and use cross-chain trade.

To be clear, the difference is that outputs with no inputs would be allowed (issuing) and the "credit assets" would be accounted separately from the bitcoins. Maybe adding the issuing address to outputs (what I think you mean when you say "tagging") would be a necessary optimization...

It is actually possible to have zero-valued inputs/outputs. And it's possible to attach arbitrary messages to it.

But it would be a shitty solution since all duty of validation will be passed onto clients. So you CAN have a situation where erroneous information is on blockchain, you can't have pruning and you can't have thin clients. And you have to pay fees with bitcoin.

So, again, how is that better than simply using colored satoshis?

It only makes sense in alt-chain with alternative rules, but I doubt we can collect all requirements now.

So it's better to start with colored satoshis and then maybe try something else.

[casascius]

What happens when two chains offer "atomic swapping" and then someone attacks one of the chains with a double spend or other attack, invalidating blocks on the other chain?  Nothing good to say the least. This can be mitigated, at the expense of all the benefits of having the other chain separate.

[killerstorm]

What happens when two chains offer "atomic swapping" and then someone attacks one of the chains with a double spend or other attack, invalidating blocks on the other chain?  Nothing good to say the least. This can be mitigated, at the expense of all the benefits of having the other chain separate.

Atomic swapping works only within one chain, not between two chains. To trade between chains one needs to use contracts.

Trade between blockchains is indeed vulnerable to double spends. Just like with accepting Bitcoin transactions, one needs to wait for a certain number of transactions before he ships goods -- in this case, finalizes the trade.

But it opens no vulnerabilities for blockchain itself: contracts are just transactions.

[jtimon]

To be clear, the difference is that outputs with no inputs would be allowed (issuing) and the "credit assets" would be accounted separately from the bitcoins. Maybe adding the issuing address to outputs (what I think you mean when you say "tagging") would be a necessary optimization...

It is actually possible to have zero-valued inputs/outputs. And it's possible to attach arbitrary messages to it.

But it would be a shitty solution since all duty of validation will be passed onto clients. So you CAN have a situation where erroneous information is on blockchain, you can't have pruning and you can't have thin clients. And you have to pay fees with bitcoin.

So, again, how is that better than simply using colored satoshis?

I meant with with valued inputs/outputs (those outputs just don't represent bitcoins) and the protocol validating the movements.

It only makes sense in alt-chain with alternative rules, but I doubt we can collect all requirements now.

So it's better to start with colored satoshis and then maybe try something else.

Yes, this is probably the best way to start, I'm not denying that. I'm only saying that not needing satoshis would be preferable later, and a more elegant solution. Jeff, for example, disagrees here.

I'm biased anyway. First because I proposed ripplecoin and also because the colored coins solution is unpractical for freicoin, in which satoshis disappear with time.

[markm]

If satoshis are in short supply you could use DeVCoin, lots of satoshis there and no ever-decreasing minting of them.

-MarkM-

[jl2012]

If satoshis are in short supply you could use DeVCoin, lots of satoshis there and no ever-decreasing minting of them.

-MarkM-

There are about 1,000,000,000 shares for Apple Inc. With 1 satoshi representing 1 share, it takes only 10BTC. I don't think this would become a real problem in the near future

[Energizer]

I am currently experimenting/designing a new asset exchange protocol that will take place on top of the block chain for assets issuing/buying/selling/...

My design is radically different from any current colored coins design. In colored coins the asset starts being tracked from a root transaction where all coins in such transaction is considered to be colored. In my design there is no such a thing called colored coins.

The protocol will treat btc addresses as nodes in a network. Where transactions are gonna be used as network events being sent from one node to another "BTC address to BTC address".

I was assuming colored coins did exactly that all along.

There will be no worries about assets being mixed "multiple colored coins transfered in one transaction". Cause the design by its nature will hook all the asset activities to one BTC address "the issuer's".

I don't think it is really important. You only mix colors if you want, and that's just stupid.

In fact there will be no colored coins at all. A BTC address can hold 1000 shares of an asset where its btc balance is = to zero.

Mhhmm. Without modifying the protocol?
Can you elaborate on this?
That sounds basically like ripplecoin.

There is no decentralized mechanism for exchange in all current colored coins protocol designs. That is the main issue that motivated me to work on a new design. If shares ownership relies on the issuer/share holder to transferring their shares to another shareholder, there would be no roam for any sort of a decentralized exchange mechanism within such protocol. It is that particular point that forced me to redesign the protocol in a manager that shares ownership wouldn't be related to any sort of colored coins. In order to create a mechanism for a decentralized exchange, share holding should come as reflection/output to such exchange. So shares movement from one node to another should take place on multiple stages:

1- Node ["A"] broadcasts a sell "ASK" order and a BTC address to receive payment on
2- Node ["B"] broadcasts buying the shares broadcasted by ["A"] "or portion of it"
3- Node ["B"] sends the requested BTC amount to node ["A"]'s BTC address
4- The application automatically parses steps (1,2,3) and moves ownership for the shares bought on (3) from node ["A"] to node ["B"]

The broadcast mechanism will take place as transactions sent to the issuer's BTC address, while all nodes are monitoring all transactions send/received by the issuer's BTC address. That would result in a real time messaging protocol on top of the block chain. Transactions sent to the issuer's address will be parsed as binary protocol events. Where the last "one or two number" will be parsed as an event id: {"0.00000001:issue","0.00000002:buy","0.00000003:sell","0.00000004:ask",...}. The most challenging part now is optimizing the operations/transactions to its minimum.

Your feedback is more than welcome.

[killerstorm]

There is no decentralized mechanism for exchange in all current colored coins protocol designs.

This isn't true. There are at least two exchange mechanism proposals.

You might not like that, but that doesn't mean that you can say that they don't exist.

[Energizer]

There is no decentralized mechanism for exchange in all current colored coins protocol designs.

This isn't true. There are at least two exchange mechanism proposals.

You might not like that, but that doesn't mean that you can say that they don't exist.

Could you please post the links?

[jgarzik]

Atomic coin swapping can be implemented with today-enabled features and it is inherently 100% secure.

Cross-blockchain trade requires support for 'contracts' and non-traditional scripts, and it has different security considerations:

If the bitcoin protocol were modified, we would use atomic coin swapping too.
If you make it in another chain, you can make atomic coin swapping with the new hostcoin, which you need anyway to incentive miners and pay them tx fees.

I definitely think that a "smart property chain" separate from the main bitcoin chain should be pursued.  It helps separate purposes (currency vs. property registry) and keep property registry data out of the mainnet chain.

The main practical obstacle is getting the smart property chain into the common merged-mining merkle root that pools obtain from the merged-mining daemon.

If people are interested in working on a smart property chain The Right Way, let me know and we can coordinate.

My smartcoin (formerly pybond) project will include some cross-chain trading support for precisely this purpose.  In fact, I am seriously thinking that cross-chain trading should be prioritized over making a solution that works in the main bitcoin chain.

[jl2012]

Atomic coin swapping can be implemented with today-enabled features and it is inherently 100% secure.

Cross-blockchain trade requires support for 'contracts' and non-traditional scripts, and it has different security considerations:

If the bitcoin protocol were modified, we would use atomic coin swapping too.
If you make it in another chain, you can make atomic coin swapping with the new hostcoin, which you need anyway to incentive miners and pay them tx fees.

I definitely think that a "smart property chain" separate from the main bitcoin chain should be pursued.  It helps separate purposes (currency vs. property registry) and keep property registry data out of the mainnet chain.

The main practical obstacle is getting the smart property chain into the common merged-mining merkle root that pools obtain from the merged-mining daemon.

If people are interested in working on a smart property chain The Right Way, let me know and we can coordinate.

My smartcoin (formerly pybond) project will include some cross-chain trading support for precisely this purpose.  In fact, I am seriously thinking that cross-chain trading should be prioritized over making a solution that works in the main bitcoin chain.

How could you prevent double spend attack with cross-chain trading?

[killerstorm]

Could you please post the links?

https://github.com/jgarzik/smartcoin: node.py: financial P2P network and DHT client

Description of how it's going to be used: https://bitcointalk.org/index.php?topic=92421.0


My plan is to use HTTP to post/retrieve orders and to exchange pieces of transactions. It can work in centralized way (one HTTP server) and in decentralized way (many HTTP servers).

I can publish a more detailed description if somebody's interested...

[jgarzik]

How could you prevent double spend attack with cross-chain trading?

In general, see Contracts: cross-chain trading

Double spending is always possible even on a single chain.  Adding multiple chains implies you would want to post to the weaker chain first.

The largest risk tends to be "holdup risk", where one sender simply refuses to proceed with the transaction.  In that case, Party A would be forced to double-spend, to secure the coins it wanted to trade with Party B.

[killerstorm]

Double spend can be prevented by waiting until 'the payment' gets enough confirmations.

When Party B refuses to proceed and 'the payment' already got some confirmations Party A has to wait until Tx2 ('the contract') is locked so Party A will get its coins back.

So this is inherently slower than 'atomic coin swap' because in the best case one needs to wait several confirmations, in the worse case one needs to wait for Tx2 lock.

[sron]

I too recently started a thread regarding this matter - How to clone Bitcoin to create your own crypto currency or crypto shares system: https://bitcointalk.org/index.php?topic=114336

I really believe that a decentralized crypto currency based stock exchange is very important and could have great benefits for humankind.

I support the idea of separate block chains. I would like to make it as easy as possible for anyone to create their own crypto currency clone and use it as an asset if they like. I think the open transactions system could work for the exchange part of it.

Now, this discussion quickly gets very technical but I'm glad to see that so many people are working on a solution to this problem.

I personally believe that the crypto stock exchange is as important as the crypto currency software itself and I can't wait too see more solutions go live. It could be a VHS vs betamax sort of thing. I support the idea of separate block chains, not the colored coins one at least for the time being.

[jl2012]

So this is inherently slower than 'atomic coin swap' because in the best case one needs to wait several confirmations, in the worse case one needs to wait for Tx2 lock.

That's why I think doing it on the same blockchain is more efficient

[jtimon]

If shares ownership relies on the issuer/share holder to transferring their shares to another shareholder,...

This is true for OT's "untraceable cash" and two-phase Ripple, but not for ripplecoin or colored coins.
The credit/smart property can be moved even when the issuer is not connected.

And I'm not sure your proposal will work or I've even understand it.
Why do you want to put the orders in the chain if the chain protocol is not going to enforce it?
Are you talking about a fork too?
In any case, putting the orders in the chain sounds already non-optimal to me.

If you make it in another chain, you can make atomic coin swapping with the new hostcoin, which you need anyway to incentive miners and pay them tx fees.

I definitely think that a "smart property chain" separate from the main bitcoin chain should be pursued.  It helps separate purposes (currency vs. property registry) and keep property registry data out of the mainnet chain.

The main practical obstacle is getting the smart property chain into the common merged-mining merkle root that pools obtain from the merged-mining daemon.

In the ripplecoin thread (not sure if here or in the ripple mailing list), we came to the conclusion that a hostcoin cash was probably the only way to incentive miners effectively. We considered paying fees with the credit/propery claims itself, but probably miners would not be interested in such an uncertain reward or a lot of transaction would be excluded for not offering "the right currency".

This other solution doesn't convince me:
https://en.bitcoin.it/wiki/Alternative_chain#Incentivising_non-resource_based_chains
and I don't think it's compatible with cross-chain trade.

But this may be feasible by paying the fees with an extern chain cash (bitcoin) as described here:

https://en.bitcoin.it/wiki/Alternative_chain#Paying_for_resources_on_alternative_chains_with_Bitcoins

A first problem is that you're making the altcoin protocol dependend on the bitcoin chain.
"Why is that a problem?" you would say. Well, not really a problem per se, but it would be "unfair" for freicoin.
Not only because you make bitcoin more valuable with this new fee use...
Once your protocol is dependend on another chain, you no longer need the cross-chain contract to atomically trade with it. You can make the part on the other chain the commit itself.
That's what I proposed for "trading across chains" before the contract solution existed. Sorry for introducing another made up term but once I called this middlecoin.

Middlecoins (in this case the issued assets) would be considered transferred conditionally, if a given quantity of bitcoins was sent to a given address (both explicitly espcified in the middlecoin tx). You also need the "bitcoin collateral" (or "public pre-pay") to prevent DoS attacks, so I'm not sure this have any real advantage over the cross-chain contract. An expiry block would also be needed or..."I have some bitcoins, let's pree-accept some orders and block some middlecoins until I get bored or I want to spend my btc elsewere".

Be it with contracts or making the new chain dependent, what scares me most are DoS attacks for cashless chains. If you're going to pay the fees later...why not broadcast 10 million tx with a generous 1 btc fee?

And if we accept that a hostcoin is needed for the mining incentive and fees, won't that new cash become more valuable than bitcoin even if its chain gets "dirty with non cash transactions"?

If people are interested in working on a smart property chain The Right Way, let me know and we can coordinate.

I'm definitely interested in participate in such a project. And I'm sure I can learn much working with experienced bitcoin developers like you.
Since I will be done with the univeristy this friday (yeah!), I will have time to write other free software different from my lonely (and worse than pybrain) preann.
But I need to train some basic skills first, like making my first git commit and pull request.
I will do it with freicoin: I feel really bad about not having coded a single line even when there's people working on it. Maybe freicoin can be the ideal incentive hostcoin with its constant supply but everlasting miners reward I would also like to learn python and help with villages.cc and two-phase Ripple (better privacy and/or latency). Maybe too many things...

We first need to discuss if the hostcoin is necessary. Maybe there's another solution I haven't thought about.

My smartcoin (formerly pybond) project will include some cross-chain trading support for precisely this purpose.  In fact, I am seriously thinking that cross-chain trading should be prioritized over making a solution that works in the main bitcoin chain.

Cross-chain trading is cool and will be good to have at some point anyway, but the current bitcoin protocol needs to be modified too, doesn't it?

[ShireSilver]

So this is inherently slower than 'atomic coin swap' because in the best case one needs to wait several confirmations, in the worse case one needs to wait for Tx2 lock.

That's why I think doing it on the same blockchain is more efficient

That's a good reason to use a separate blockchain. It slows down the trades, which prevents two potentially harmful things from happening: high-frequency trades and using shares themselves as currency. (At least for the latter it might not prevent it outright but would make the shares less useful as a currency.)