Cointrace: Colored coins & Mastercoin mutant - please criticize

[elendir]

Hello everyone,
I'm a big fan of Colored coins and Mastercoin projects, there are some issues with both of them though. So I created another, super-simple smart property protocol and you can see it in action here: http://cointrace.net. I'd be grateful if you could look at it and provide some critique. Thank you!

[1713548502]

1713548502

[kjj]

A relative newcomer popping up and asking people to visit his website isn't likely to get much traffic...

[elendir]

A relative newcomer popping up and asking people to visit his website isn't likely to get much traffic...

Thank you for your comment. Is there anything I can do about it or am I doomed to be ignored? Maybe I should summarize what this is all about. Here's why I'm trying to propose a new smart property protocol:

Colored coins match the digital property ownership with individual inputs/outputs of bitcoin transactions so one can't spend these coins without losing the digital property ownership. Cointrace matches the ownership with a bitcoin address and it even allows the balance of the address to be zero and still retain the property ownership. Colored coins require dedicated client application to carefully handle the ins/outs while Cointrace can be used with existing clients.

Mastercoin is a protocol too complex for a simple digital property control and also requires a dedicated client application. Its exodus address is picked and controlled by its creators (and so is the Mastercoin itself), introducing a possible point of failure. Cointrace is much simpler and allows anyone to create and control their own "exodus address" (called the project address).

[spartacusrex]

Simple. Clean. Works.

That's a good start.

You may want to have a special-client that shows what's going on in a more pleasing 'visual' way.

Specify a PROTOCOL, with no loose ends, and they will come..

Like it.

[halvoraarud]

 This looks really good.  Nice design!  Like it too.

[GhostInTheBlockchain]

[from Cointrace website]
>Funding is ended by the first issuance transaction.

I think I am missing something.  How is this enforced if you are using standard clients?  What if someone sends a funding transaction to the project address after the issuance transaction?  Is it up to funders to make sure the issuance transaction has not yet occurred before they send a funding transaction?  If so, then there is a race condition here. Funder could be sending a funding transaction at same time as the issuer sends the first issuance transaction.

Maybe it's not an issue.  If additional funds are sent to the project address after the issuance transaction has occurred that's just more 'shares' that can be issued.

[elendir]

What if someone sends a funding transaction to the project address after the issuance transaction?

Such transaction is ignored by the protocol.

Maybe it's not an issue.  If additional funds are sent to the project address after the issuance transaction has occurred that's just more 'shares' that can be issued.

Correct. The funding part is only used for pre-calculating share distribution for the issuance part. Let's say there are two funding transactions: 2 BTC from A and 3 BTC from B. Issuer will than be presented with an option to issue 5 BTC worth of shares (2 to A, 3 to B), but it's not binding or enforced. Issuer can simply decide to issue only 2 BTC worth of shares, say 1 to A and 1 to B, keeping the remaining 3 BTC off the protocol.

[FrictionlessCoin]

Very nice and simple.

But maybe I'm a bit confused as to the simplicity.

Don't you just have some kind of actor responding to events related to an address?

So in general,  if we have an actor that has channels,  and we treat each channel as a bitcoin address, is this effectively what you are doing?

Is this the same thing what Electreum proposal is saying?

The only real technology that is needed is a colored coin capability.  Beyond that, all advanced protocols can be handled by actors/agents.

[elendir]

Don't you just have some kind of actor responding to events related to an address?

Yes, inspired by Mastercoin.

Is this the same thing what Electreum proposal is saying?

I'm afraid I'm not familiar with the proposal, could you please link me to it?

Anyhow, based on number of reviews I received, I plan to make some minor improvements to the cointrace protocol and finalize it. I'll also create a tutorial on how anyone can use it just today with no need for a dedicated client application (unlike CC or Mastercoin).

[grau]

Thanks, interesting proposal

In your traded Example (http://cointrace.net/1DpnYaMW1qPGd6bspzcz7vdi7NR782XWn7)

Funding phase:
investor 1Kug5MazR3c8VsBn61JZdvzdix49K7CCES sends 0.03 to project address, therefore should have 0.03/(0.03+0.034078)= 46.8% instead of 75%, isn't it?

In transfer phase:
What if https://blockchain.info/tx/48d7a411fe6fa67d562d8af8bd26e2b3c7fa6a5343fac60af71c2560b2a810ae would have spent more than 0.03 to 1LSmNv4kjh34AnnPHJ9s9NHQTymJ82HqnN ?

or if in https://blockchain.info/tx/ece810e8166f984787961febcc9b90fc01d644f9d8826097349296f573e47d31 the sum of outputs to 13XUuo2ieBBrjyRySst7pMyLtyovsH6Msc and 1P4bJN7u88dPee7hKN4mQh46RsR7J9exd9 would have exceeded 0.02 ?

[grau]

I found in the meanwhile on the other example, that transactions could be rejected because of:
"Insufficient funds at sending address" - this answers my 2nd and 3rd question.
The rule should however be on http://cointrace.net/about

[grau]

I suggest to add a fourth type of transaction, the swap. This makes trading assets identified by traces atomic and observable.

Rule 4. Swap
A valid swap has two inputs and one or two marker payments to project address(es). The swap has two regular outputs with addresses matching the inputs but swapping the input quantities reduced by payments to project address(es).

A is an address having ALPHA (project address) trace, B has (optional) BETA trace. a is the quantity of ALPHA swapped for b amount of BETA.

Inputs  Outputs
A a      B a - marker
B b      A b - marker
          ALPHA marker
          BETA   marker

Interpretation:
Swap a(-marker) of ALPHA for b(-marker) of BETA

[grau]

A problem with the current proposal, that in case of a transfer the transaction fee for mining and marking would be paid from the trace, that is eventually expensive if trace has value above its intrinsic satoshis.

[FrictionlessCoin]

I suggest to add a fourth type of transaction, the swap. This makes trading assets identified by traces atomic and observable.

Rule 4. Swap
A valid swap has two inputs and one or two marker payments to project address(es). The swap has two regular outputs with addresses matching the inputs but swapping the input quantities reduced by payments to project address(es).

A is an address having ALPHA (project address) trace, B has (optional) BETA trace. a is the quantity of ALPHA swapped for b amount of BETA.

Inputs  Outputs
A a      B a - marker
B b      A b - marker
          ALPHA marker
          BETA   marker

Interpretation:
Swap a(-marker) of ALPHA for b(-marker) of BETA

interesting

[grau]

I attempted a more formal description also adding new types Trade and Swap.

Abstract
Definition of the Coin Trace (CT) rule set to map lifecycle events of digital assets to Bitcoin transactions. The rules aim for simplicity and backward compatibility with Bitcoin wallets that can only deal with transfers between addresses.

Definitions
We trace nominal holding of a digital asset through CT compliant Bitcoin transactions, CTTs.

The trace of an address is the net of nominal trace credited and debited to it by CTTs.

A marker address is a Bitcoin address associated with the trace, it acts as the unique reference to the trace.

CTTs are a subset of valid Bitcoin transactions that match a definition in this document. Non-CTTs are ignored for the purposes of this protocol.

Digital asset lifecycle
CT supports following lifecycle events of the digital asset

• Funding the marker address
• Issue trace
• Transfer trace
• Trade a trace
• Swap traces
• Destroy trace

Funding
Any address can be a marker address. Transactions that credit the marker address are Funding CTTs until there is no Issue CTT observed on the marker address.

Issue
The Issue CTT is the first transaction with input only from the marker address. Outputs of the issue transaction that are not sending to the marker address credit nominal amounts of the trace to their target addresses. Subsequent spends of the marker address holding are not CTTs.

Transfer
A trace can be transferred to another addresses with Transfer CTTs.  A Transfer CTT has an output to the marker address and only input addresses having trace of the same marker address. A transaction is not a Transfer CTT if any of its inputs consumes more of an address than the trace of that address.

Trade
A Trade CTT exchanges a trace on an address for traceless Bitcoins. The Trade CTT has an output to the marker address and a matching pair of input and output addresses. Only one of the input addresses has the trace of the marker output in at least the amount of that input. Trade CTT output to a non marker address is not more than the amount of input on the other address.

Swap
A Swap CTT exchanges traces of a pair of addresses. The Swap CTT has two outputs to two marker addresses and a matching pair of input and output addresses. Input addresses have the trace of one of the marker addresses in at least the amount of that input. Swap CTT output to a non marker address is not more than the amount of input on the other address.

Destroy
A trace is destroyed if transferred to the marker address.