Topic: Ixcoin TODO - page 153. (Read 631736 times)

It depends how you view it. Mastercoin certainly was first. Counterparty created the metacoin (XCP) by burning, Mastercoin by collecting the money to the foundation. Despite raising 5000 BTC in August, Mastercoin still doesn't have anythin else but BTC/MSC exchange working. Also I personally prefer some choices made in the CP protocol specification compared to the Mastecoin specification.  For instance, Mastercoin specification in the feed requires some unnecessary specification terms (category, sub-category etc) where as in CP the description is pretty much left to the users to decide. The first mentioned approach gives me bad echoes of "central planning"...


I think Brock is pissed, but 80 -> 40 thing was not definitely pleasing to him. See for instance the feed example in the Mastercoin spec: 57 bytes!

Other suggestions for the development of IXCoin:

1) I think there should be centralized (the official) place for all IXCoin related source codes in the GitHub where the developemnt would take place.
2) When the IXC client is now updated (this is urgent to get the OP_RETURN (and thereby CP) working), I think we should also make the miners fee mandatory as in the bitcoin client.

When you are using CP, you have the bitcoin daemon (client) running in the background. So CP client just creates the bitcoin transaction to be sent by the bitcoin client, so everything is working through the bitcoin client. But there is no manual "fee sending process" for the user if that's what you are wondering.

Notice first that by clicking "Block" you can view how the transaction actually looks in the bitcoin network. Here's an example of one of those "0 fees" (Asset Issuance of "1020 JODI"):
https://blockchain.info/tx/8e382205e147d42f3092ab885c35f049b84edaeb9ee9921315395eb0780fac1e
So indeed the right column in your table is the normal bitcoin transaction fee (miners fee). Now every bitcoin transaction needs to have an output. Since those CP operations in your table do not have any recipient, you need still to put something in that field. It seems that most people are using here (like in my example) a clever trick to send just small amount of BTC to back to oneself: they are put into "escrow" (one out of oneself). I believe .0001086 BTC is the smallest amount above the dust level. "BTCAmount" in your table is just the actual amount sent to another address. For some reason not all CP transactions are using the escrow trick but instead they are sending the .0001086 BTC to another address (CP protocol is indifferent in what you do in the destination field in the operations like the ones in your table), but it is not any type of fee.

This is also the place (I think) Friction has planned the new fee I talked earlier. Instead of having these "self escrows" or whatever, it would be required that an amout of IXCs needs to be transfered to a certain address (this is the "Mastercoin way"), i.e. "the Foundation fee". IMO, that's a good idea, but I wish he would discuss the fee amounts etc here instead of just putting whatever pleases him. IMO, the fees should be rather small (to encourage the use of IXC CP) and also rather simple (to prevent complications in the long term). My preferered way would be to have the amount send to Foundation to be exactly the same amount as paid to miners regardless of the CP action. This would be very easy to check from the implementation point of view (so easy that it could be easily implemented as native if needed) needing no adjustments in the future, and IMO it is also fair ("half to miners, half to the Foundation"). Also from the users's perspective, it would not be too expensive (double of making a normal IXC transfer).

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?

User doesn't pay any BTC fees (apart from the miners' fee). No need to open the bitcoin client unless user is involved in an operation explicitly involving BTC.

Quick question.

Is Counterparty a rip off of MasterCoin?

That's my understanding.  If so, then Brock must be pissed which is why maybe the 80-bytes was cut down to 40 bytes.

And if we're now giving Counterparty a second chance at life....well, things might get interesting.

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.  

It depends what you exactly mean by "transaction fee". From the bitcoin network point of view, placing a bet (or any other action in CP) is just a normal bitcoin transaction (with some 80 (40) additional symbols the network does not care about). So the bitcoin miners get their fee from there just like from any other normal bitcoin transaction.

In addition to that the CP protocol requires a fee (in XCP) to the feed-provider. The amount (fee-fraction) is specified by the provider (when he describes the event), and it is reduced (I think) from the bets when they are finalized. I don't know how Friction has planned to handle this fee if we go by his preferred plan 2c: is it allowed the feed provider to dictate the user currency that bets are made (when using his feed), or is it allowed to use any asset for any feed (in which case the feed operator may end up with small amounts of many different assets he doesn't really care)?

Furthermore, there is an additional possibility for a fee that, if I have understood correctly, Friction is planning. Namely any ixcoin (bitcoin) transaction has also a destination address. The original CP does not care (I think) what is the destination address and how much money is transfered in operations like bets, broadcast, issue etc which do not have a clear target (i.e., no assets are moved directly from one party to another). But you could require that, for instance, a certain amount of IXCs (in addition to the miners' fee) needs to be sent to a specific address in order the protocol to accept the transaction as a valid bet. If I have understood correctly, Friction is planning something like that (for the benefit of the Foundation).

Interesting perspective, brother.

Thanks for your input and support!

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.

No, betting and callbacks are allowed in XCP (the metacoin) only. See the FAQ entry:
https://www.counterparty.co/resources/faqs/why-must-dividends-bets-and-betting-fees-be-paid-in-xcp/

Doesn't anyone see what's happening?  People are getting nervous about the rise of iXcoin!!!  For three years the strategy was to ignore iXcoin and hope it went away.  Now it has a chance to make some real progress and challenge the bigger coins.  Now some serious technical discussions are happening so people think they need to scare others away.  That's why the comments lately are coming out of left field and not making sense.

iXcoin is almost as secure as Bitcoin itself!  So someone has to threaten to attack the block chain to imply vulnerability.  CEX.io has joined the board, so that was called a lie.  The end of the block reward is coming... run people run.  iXcoin has no inflation planned after October, so someone tries to push the board to inflate.  Anything to weaken iXcoin.

I have to hand it to Vlad for sticking to his guns.  Be careful everyone when someone get's so worked up trying to "help".  Question their motives.  iXcoin is on a good track.  Damn the torpedoes and stay the course.  Let's get Counterparty out and really see people sweat.

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, 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.   

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.

Thank you cinnamon.

Great points.  I was pushing for the biggest update possible but what you say makes sense.

Let's add as much functionality as possible without a hard fork and with as little bloat as possible. 


Thanks!