I like it.  The fees you propose aren't excessive so they shouldn't be a turn off to users.  We really need some regular income coming into the foundation so we can make steady progress rather than waiting for donations.  This is only a modest amount but as CP is used more and IXC prices increase the revenue stream will increase.

So CP talks to bitcoin through RPC calls?

On the CP block explorer link I gave it looks like EVERY CP transaction has a bitcoin transaction fee (most of them are .0002 BTC at the moment).  So do you need to send this fee with the bitcoin client? Or is there some other method inside CP?

http://www.blockscan.com/tx.aspx

This link shows the Counterparty transactions.  Take a look at the two right columns.  I believe the far right column is the normal Bitcoin transaction fee.  I haven't quite figured out the BTCAmount column.  Some types of transaction types have 0 and some don't.  Are these fees within Counterparty?  The betting fees should be in XCP, so I'm not sure why it shows BTC?  I know fees can vary, but that .0001086 BTC fee seems to be very consistent.

               
                          BTCAmount                      (BTC Tx) Fee
Asset Issuance     .0001086 BTC                    .0002 BTC      
Asset Received     .0001086 BTC                    .0002 BTC
Bet                     .0001086 BTC                    .0002 BTC
Broadcast              0 BTC                             .0002 BTC
Open Order            0 BTC                             .00022672 BTC
Cancel Order          0 BTC                             .0002 BTC

I was really asking about the process the user goes through to pay the BTC fee.  I haven't used Counterparty, so I was wondering about how you place a bet in XCP in the CP client.  After completing the XCP transfer, do you then need to open the bitcoin client to pay a .0001 BTC fee.  It seems a bit cumbersome.  

Can someone explain how the transaction fees get paid, even with bitcoin CP?  When someone places a bet in XCP, how and when do they send BTC for the transaction fee?  Do they actually need two currencies for betting or any other operation in CP?

In my mind we're down to 2b or 2c.

jamaer has a point.  Why have many disjointed assets doing the job of the original metacoin?  We would be forcing the user community to recreate functions already available in the stock CP.  Why disable betting using the original metacoin, then expect or hope someone will add an asset to fill the void.  

I do like ALSO allowing user defined assets/currencies for betting.  Is this not allowed in the original CP?

It's inevitable that new assets will crop up to duplicate the functionality of the metacoin, but it may be best to leave the metacoin in to get users off to a quick start.

My original concern about the metacoin devaluing IXC is lessening.  CP doesn't work without assets, which can act just like the metacoin.  So why not just leave the metacoin in place to provide full functionality of CP?  Aren't we just delaying the inevitable?

Regarding the 80 byte OP_RETURN, Counterparty is working now on the Bitcoin chain with 40 bytes.  Right?  What is not working in the 40 byte version?  Is it actually a different version of CP?  How will we know we are implementing the version of CP designed for the 80 byte OP_RETURN?

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.

Before answering, does anyone know if each Counterparty order, trade or bet is contained in its own separate IXC transaction.  Or are multiple Counterparty events crammed into a single IXC transaction?  I assume only one event per IXC transaction since we only have 80 bytes in the OP_RETURN. 

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.

I assume the update will be based on version 0.8.6, not 0.9.0, which is ok.

What about native IXC escrow?  I still think that would be best for the reasons already stated, even if it takes more time.  Maybe we should vote on IXC escrow.

Since we need to upgrade to version 0.9.0 anyway to get OP_RETURN, we should go ahead and add IXC escrow!!!  Kill two birds with one coin.  It's hard enough getting CEX.io to upgrade.  Imagine trying to do it twice!

The best option:

My recomendation is to add escrow natively to iXcoin before or with the Counterparty update.  If we have the capability to escrow IXC then we can add any financial platform to use IXC as its core currency. 

My fear is if we add IXC escrow later the market will have already chosen a Counterparty asset as a standard and it will be hard to change.  Basically, it will be almost the same as using the metacoin from the start.

IXC escrow should also allow the complete Counterparty function set to be implemented.  Again, if we eliminate betting, someone else may setup a betting proxy asset and beat us to the punch before IXC is installed in this role.

jamaer,

I don't recall anyone mentioning this about XCP from the CP wiki.

"5 XCP are destroyed every time a new asset is issued; there must be at least 5 XCP at [address] in order to issue an asset."

So the stock CP implementation destroys (burns) the native coin to get XCP.  Then it destroys XCP to get assets.  

Is your version of IXCP also going to be destroyed every time a new asset is launched? 

jamear,

With your use of a metacoin, I'm not clear on how IXCP would be tradeable within the IXC blockchain.  Are you saying it would be traded on the CP exchange which rides on the IXC blockchain? 

Well that pretty much eliminates our need to rush a Counterparty solution out the door.  CEX.io isn't going to stop mining iXcoin.  Plus we're still seeing about 60% of all blocks now with mining fees.

My concern with a one time distribution of IXCP is much of it may go unused, but I guess IXCP will be exchangeable within our CP environment?  Right?  So five years from now if someone wants to start a new asset or vending service they should still be able to get IXCP?  Right?

I'm also still concerned about IXCP diluting IXC value, or diverting users to IXCP instead of IXC.

Yes, I see the problem with bets if IXC is not escrowed since the looser doesn't have much incentive to pay up because they don't send any funds until they know they've lost.  With orders both sides generally want the order to go through at the time they submit, so it's more doable with IXC.  The issues would probably be with orders which aren't filled immediately.  Someone my move their IXC, but that only results in no order occurring, not someone loosing their funds.

So for bets we would need a betting proxy asset, because all assets come with escrow.

It may be true that a stripped down CP feature set could be done with ColoredCoins, but we also need to look at future growth.  Even if CP is only partially implemented, it still has more potential for feature growth than ColoredCoins, so why not stick with CP.