Smart property and stock shares (contracts use case)

[jtimon]

I haven't thought the details, but I'm sure it is possible.
The proposal is simple: decentralized a stock exchange with contracts.
Probably you should read this:
https://en.bitcoin.it/wiki/Smart_Property
https://en.bitcoin.it/wiki/Contracts

I'll explain it with an example:

1) The founder of the company sells 100 shares of his company by splitting a btc (or less) into 100 transactions with 0.01 btc to the buyers.

2) The holders of those ownership keys will receive the dividends.

3) Owners can place an ask order (not necessarily in the chain, but distribute it in a parallel p2p network) through a transaction that says sumarizing "I send this 0.1 btc to whatever address sends 30 btc (the selling price) to S2". In fact, the founder could have done this from the beginning.

I think the last part is actually the hardest part. Please, correct me if what I propose is not feasible the way I want to do it.

0) The seller just broadcasts a hash of his secret along with his public key (the receiving key for the trade, S2), the current ownership key (S) and the selling price (all signed with the ownership key). Then the chain trade is executed with the seller of the share acting like B and the buyer like A. Almost nothing changes:

1) Both parties generates a new key and some random data (the secret).
2) Party S sends a hash of his secret to A along with his public key. (already done in 0)
3) Party A generates Tx1 (the payment for the share, from A to S2) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key A and key S) or with (secret A, secret S, key S). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
4) Party A generates Tx2 (the contract) which spends Tx1 and has an output going back to key A. It has a lock time of some point in the future and the input has a sequence number of zero, so it can be replaced. A signs Tx2 and sends it to S, who also signs it and sends it back.
5) A broadcasts Tx1 and Tx2. Party S can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
6) S performs the same scheme in reverse on the alternative chain to transfer the share. Both sides of the trade are now pending but incomplete.
7) A sends his secret (random data) to S, who then uses it to re-issue the now finalized contract using (secret A, secret S, key S) and an output of his choice (S2). S now owns the coins but in the process of claiming them, revealed his secret, allowing A to claim the other side of the trade (to claim the share).

If someone thinks "hey, you have to trust that the founder/managers of the company will pay you the dividends", he is right. Yes you have to trust the managers when you want to buy shares of their company.

What do you think? Another use case for contracts?
Is there anything wrong in the trade part?

[Mike Hearn]

It's a neat idea. I'm not sure chain trades are the simplest way to achieve it. The technique used in the smart property article might work better:

1) Buyer of the share creates a transaction that takes 30 BTC of his own money and spends it to the seller key (S2 in your text). He also adds an input connected to the share and an output to his new ownership key. This tx is not valid because the second input is not signed and the buyer cannot sign it himself.

2) He sends the transaction to the seller who verifies that it follows the expected form, and signs the remaining unsigned input. The seller then broadcasts it to confirm the trade. Control of the coins and the ownership key are transferred atomically.

You can transfer anything controlled by a key in this way. Smart property assumes the thing you are controlling is a physical item, but it could also be a conceptual marker, like a share, or something in between, like SSH access to a remote computer.

It's probably safer to create a protocol in which only the variable parts of the transaction are sent between buyer and seller, rather than an actual serialized transaction. That makes it less likely you'll accidentally sign something unexpected (a funny script or something with a lock time set, etc). There might be use cases for weird transactions but it's better to add support for them explicitly.

It'd be quite easy to implement such a share trading scheme, if you wanted to go ahead and do it.

[jtimon]

Thank you, definitely your approach is much simpler. I should have read the smart property page again before writing the post.

I don't want to develop this share trading scheme, I was just hearing Gavin's concerns about private stock exchanges and the idea just came.
Maybe the GBLSE people is interested in the idea.

Will you put it in the wiki or expand the smart property article to non-physical property?

[Mike Hearn]

I've updated the first paragraph on smart property to mention non-physical assets.

[Mike Hearn]

By the way, if you're interested in these topics, you could try your hand at designing some further protocols:

• Smart property can be used as collateral in a loan. However, 1:1 loaning between individuals normally only works for small amounts. For larger loans, like to a business, multiple people need to be able to contribute funds. Can you design a system that uses an assurance contract to let people contribute funds until the required size of the loan is satisfied, and which is combined with ownership re-assignment for the collateral?
• In real life, loans are often partially or entirely unsecured. Instead, sound judgement is required to decide whether to make the loan or not. Today banks are the primary source of this judgement, but as has been repeatedly demonstrated over the past few years, banks do not always make good investment decisions. Consider how to decentralize this task so people with spare Bitcoins to invest can automatically do so with as little mental overhead as possible. For example, fund managers could cryptographically prove what their previous ROI has been. Your app could then show ads for different investment funds ranked by different stats, like their alpha. In an international, highly liquid market for debt you should be able to automatically invest some fraction of your coins with minimal risk.
• Combine all the ideas discussed here to allow people to create, trade and redeem bonds that are only issued once a threshold is met. Think of a small business that wants to buy some new equipment. A loan of less than X is useless and would have to be returned (but it's better if that's not required). More than X is too much. Once the bond threshold is met, contributors should be able to trade the slices they contributed so the repayments go to the new owners. For bonus points, think about how to make a companies domain name or VPN keys into collateral so "control" of the firm can be automatically transferred to a liquidator if the company defaults.

I think you get the general idea - take something that we currently rely on trust or centralized institutions for, and see if you can implement it cryptographically instead.

[jtimon]

I've updated the first paragraph on smart property to mention non-physical assets.

Thank you. I hope someone gets interested in implementing the idea.
I thought it would not be possible without nLockTime, but is actually posible right now.
Am I right or at least multiple signatures must be allowed?
Each participant signs an input or both of them sign the whole transaction?

[Mike Hearn]

You can do it today with no software changes. Each participant signs one input.

[jtimon]

Thank you for the confirmation. I will suggest it to the GBLSE people.
I'm interested in these topics, but not particularly in loans collateral for now.

What amazes me is that bitcoin not only takes back power and freedom from the money monopolizers, but empowers people to enable a freedom that we never had. A decentralized property registry! I didn't see the usefulness the first time I hear it. It was long before the smart property thread.
A problem that interest me more is the feasibility of instant payments in a ripple block chain combining these two concepts:

https://bitcointalk.org/index.php?topic=37505.0

https://bitcointalk.org/index.php?topic=25786

But that's kind of outside bitcoin.

[EhVedadoOAnonimato]

This thread is really interesting. I'm posting here just to be kept up to date on the discussion.

[Mike Hearn]

Merging Ripple and Bitcoin concepts makes sense, but the right place to start is probably a distributed currency exchange.

Consider how to decentralize MtGox/TradeHill. You need a Hawala-esque network of agents who buy/sell coins for other currencies, relying on their pre-existing trust relationships. New users without a link into the trust network would have to meet an agent in person and give them cash, or use some irreversible form of electronic payment. Ripple acts as a way for these agents to keep track of who owes what. If I have euros and want to buy Bitcoins, and the only seller I can find is in another country, he'd send me the coins and simultaneously mark me as oweing some third person the euros. That third person would then discover they have transitively gained a debt to the seller of that many euros, and he is responsible for collecting that debt from me and passing it on to the seller.

I'm not sure it makes sense to hew too closely to Bitcoins design for this. You're establishing and destroying edges in a graph. A block chain may make sense for ordering the transactions again. To perform the trade your local software would do a graph search (probably A* with geophysical locality as the cost function) until it finds a workable path to the seller. Once you find a path that satisfies the rules you'd use it as part of a chain trade. The trade of Bitcoins for newly created debt relationships would be atomic.

[Bitcoin Oz]

It's a neat idea. I'm not sure chain trades are the simplest way to achieve it. The technique used in the smart property article might work better:

1) Buyer of the share creates a transaction that takes 30 BTC of his own money and spends it to the seller key (S2 in your text). He also adds an input connected to the share and an output to his new ownership key. This tx is not valid because the second input is not signed and the buyer cannot sign it himself.

2) He sends the transaction to the seller who verifies that it follows the expected form, and signs the remaining unsigned input. The seller then broadcasts it to confirm the trade. Control of the coins and the ownership key are transferred atomically.

You can transfer anything controlled by a key in this way. Smart property assumes the thing you are controlling is a physical item, but it could also be a conceptual marker, like a share, or something in between, like SSH access to a remote computer.

It's probably safer to create a protocol in which only the variable parts of the transaction are sent between buyer and seller, rather than an actual serialized transaction. That makes it less likely you'll accidentally sign something unexpected (a funny script or something with a lock time set, etc). There might be use cases for weird transactions but it's better to add support for them explicitly.

It'd be quite easy to implement such a share trading scheme, if you wanted to go ahead and do it.

Thats quite interesting. How do you deal with conflicts in a smart property situation ?

[jtimon]

Merging Ripple and Bitcoin concepts makes sense, but the right place to start is probably a distributed currency exchange.

We're talking about this here:
https://bitcointalk.org/index.php?topic=46203.msg558607#msg558607

But actually, a ripple network between all the exchanges and e-wallets could be very useful for instant payments:

https://bitcointalk.org/index.php?topic=32818.msg422557#msg422557

But for that you need instant decentralized ripple, which doesn't exist yet.
That's why I like to explore the possibilities of a block chain based ripple. To the current distributed ripple protocol draft I would add bitcoin-like scripts instead of registries, like Ryan wants. This could allow I think exchanging ripple credits for bitcoins atomically.

Another possibility is implement decentralized ripple inside OT just by allowing a set of market trades to be executed atomically. Read below in the same thread. But I don't really understand the decentralized nature of Open Transactions. It seems that OT cash cannot be traded directly in OT markets but only deposits in accounts.

Decentralized ripple will be very useful for the bitcoin community and bitcoin can also empower ripple. The first thing that comes to mind is a ripple node with lots of connection that gives you as much ripple credit as the amount of bitcoins you deposit with them. Customers get additional liquidity and the service lives on withdrawal fees.

[Mike Hearn]

Thats quite interesting. How do you deal with conflicts in a smart property situation ?

I'm not sure what you mean. There are no conflicts at any point with this protocol. The property always has exactly one owner, who may choose to grant temporary access to others.

[Mike Hearn]

But for that you need instant decentralized ripple, which doesn't exist yet.
That's why I like to explore the possibilities of a block chain based ripple. To the current distributed ripple protocol draft I would add bitcoin-like scripts instead of registries, like Ryan wants. This could allow I think exchanging ripple credits for bitcoins atomically.

Design-wise I'd start by ignoring the p2p/decentralized aspect of it. Bitcoin the system is implementable entirely within one computer. The block chain and proof of work parts are only for synchronizing multiple independent systems.

Implementing a Ripple-style system entirely within a single program isn't too hard. It boils down to parallel graph search algorithms. If you assume participants are not entirely anonymous you can optimize by assuming trust relationships exist between people who live near to each other and using that as a heuristic. Seeking out and destroying circular debt is a harder problem to do at scale, but once you manage it within a single computer decentralizing it Bitcoin-style is an easy next step.

[jtimon]

Design-wise I'd start by ignoring the p2p/decentralized aspect of it. Bitcoin the system is implementable entirely within one computer. The block chain and proof of work parts are only for synchronizing multiple independent systems.

Implementing a Ripple-style system entirely within a single program isn't too hard. It boils down to parallel graph search algorithms. If you assume participants are not entirely anonymous you can optimize by assuming trust relationships exist between people who live near to each other and using that as a heuristic. Seeking out and destroying circular debt is a harder problem to do at scale, but once you manage it within a single computer decentralizing it Bitcoin-style is an easy next step.

The single-computer/non decentralized Ripple is already implemented. Maybe circular debt destruction could be enhanced but with the decentralized implementation the system can't do it on its own.
A node would have to start the "circular transaction".
So I think the project is ready to focus on the decentralized implementation.

The main problems I see with the block chain ripple implementation are:

1) Enable instant transactions. Otherwise the "ripple between e-wallets to achieve instant bitcoin transactions" use case is not valid.
Maybe this can be solved with a variation of the "instant bitcoin transactions through confirmed escrow" concept. But an escrow of IOUs seems very strange to me. Maybe I just need time to believe it.

2) Spam attacks. After all, anyone can create two nodes and pay from one to the other. Since there's no limit in the IOUs a node can create, there's no limit creating transactions.
I think this could be solved by miners always requiring transaction fees (which can be paid in bitcoins or other chain cash).

For the non block chain ripple protocol, the main problem is atomicity (and expiration of intermediaries promises), which is solved through registries. Although I advocate for a bitcoin scripts-like extension as it would be far more generic and would also enable registries.