Quote from: FrictionlessCoin on June 02, 2014, 08:10:43 PM

Quote from: Vlad2Vlad on June 02, 2014, 08:04:05 PM

I've already talked to Jeffery and he said they have no issue updating to iXcoin's newest code. But we have to make it count; release the best update possible. Native escrow and whatever else will give us an edge against most other alts.

Anyone talking 'native escrow' is dreaming. How the hell is that going to be implemented? If you are talking multi-sig, then that's already in 0.8.6, otherwise, I have no idea what you folks are talking about.

We've already agreed that we prefer Counterparty to use IXC instead of a metacoin, but without being able to excrow IXC then trading will be slower (taking mulitple confirmations) and betting won't be possible. Plus, it would be very easy for one of the Counterparty assets to become the preferred metacoin over IXC, especially if a Counterparty asset can perform the functions faster. So it's best for the native IXC escrow to be there from the start.

As I see it an escrow transaction must be added to iXcoin, let's call it ESCROW-START. It would be similar to a regular transaction except instead of actually moving coins to a new owner it just locks the coins in place in the block chain. They are later unlocked and either left with the original owner or sent to a new owner depending on triggers from Counterparty. Of course, you would also need an expiration on escrows to prevent IXC from being permenantly locked, and you need a cancel escrow feature in case orders are cancelled. I assume most of the logic for escrow is already in Counterparty if you need a reference.

You may also need a second new escrow transaction, call it ESCROW-END, or you may just add some extra code in the normal IXC transaction logic. Either way, you need to finalize a transaction begun with ESCROW-START. Both ESCROW-START and ESCROW-END need to understand Counterparty triggers to integrate IXC correctly into Counterparty.

For example, for a Counterparty trade IXC logic would look for Counterparty orders where IXC was involved. Any time an order is placed an ESCROW-START transaction is also created, locking the IXC coins. Then Counterparty trade executions would trigger the ESCROW-END transaction to finalize, sending the coins to their new owner.

Similarly for bets, IXC logic would look for Counterparty bets. Any time a bet is placed an ESCROW-START transaction is created. Then a Counterparty bet winner would trigger an ESCROW-END to finalize the transaction.

All the triggers for escrowing and finalizing would be comming from Counterparty. In the furture, similar logic could be added to look for triggers from any other financial platform that we want to support natively.

It's more work to add this native IXC escrow, but IXC will benefit because it will be used much more intensively by these financial platforms, which means more IXC transactions, more fees and happier miners.