Quote from: kraizi on June 04, 2014, 03:06:10 AM

Quote from: jamaer on June 03, 2014, 11:56:34 AM

Quote from: kraizi on June 03, 2014, 04:50:10 AM

They are later unlocked and either left with the original owner or sent to a new owner depending on triggers from Counterparty.

And that's the problem. In oder the network to decide where the coins should go, the network has to understand the Counterparty protocol. That is, the implementation has to be native. Or can you explain a method for an escrow without the network understanding/parsing the protocol?

Yes, I'm starting to agree that going fully native using IXC as the metacoin, in effect, is probably a bit too ambitious and risky at this time. But just so everyone understands, I'm not saying Counterparty needs to be fully translated into the IXC client code. The exchange logic, betting logic, issuing logic still stays in CP. Probably 99% of the code stays in CP. But yes, IXC must be able to read the CP protocol (orders, bets, cancels, etc.) to know when an IXC escrow or transaction must occur. IXC would be parsing the CP protocol in OP_RETURN. I don't know how else you would do it. I guess that's best for a later time.

Yes, that is correct, for CP to go native, the OP_RETURN needs to parsed and validated in the ixcoind logic.

This is a possibility for IXC, but not very likely to happen with BTC. However, this is further away in the future.