[
{
"addr" : "198.154.60.183:8337",
"services" : "00000001",
"lastsend" : 1419790508,
"lastrecv" : 1419790604,
"bytessent" : 541965,
"bytesrecv" : 16467122,
"conntime" : 1419790303,
"pingtime" : 0.00000000,
"version" : 32430,
"subver" : "",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "167.160.36.73:8337",
"services" : "00000001",
"lastsend" : 1419790603,
"lastrecv" : 1419790603,
"bytessent" : 129220,
"bytesrecv" : 2061513,
"conntime" : 1419790320,
"pingtime" : 0.00000000,
"version" : 70001,
"subver" : "/Satoshi:0.8.6/",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.226.177.232:8337",
"services" : "00000001",
"lastsend" : 1419790511,
"lastrecv" : 1419790608,
"bytessent" : 128902,
"bytesrecv" : 2067448,
"conntime" : 1419790348,
"pingtime" : 0.00000000,
"version" : 70001,
"subver" : "/Satoshi:0.8.6/",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "213.184.8.22:8337",
"services" : "00000001",
"lastsend" : 1419790511,
"lastrecv" : 1419790606,
"bytessent" : 137253,
"bytesrecv" : 2090872,
"conntime" : 1419790409,
"pingtime" : 0.00000000,
"version" : 70001,
"subver" : "/Satoshi:0.8.6/",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "68.168.104.10:8337",
"services" : "00000001",
"lastsend" : 1419790511,
"lastrecv" : 1419790607,
"bytessent" : 122587,
"bytesrecv" : 1059,
"conntime" : 1419790421,
"pingtime" : 0.00000000,
"version" : 32430,
"subver" : "",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "85.159.107.224:8337",
"services" : "00000001",
"lastsend" : 1419790511,
"lastrecv" : 1419790615,
"bytessent" : 122515,
"bytesrecv" : 1029,
"conntime" : 1419790455,
"pingtime" : 0.00000000,
"version" : 32430,
"subver" : "",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "76.174.192.84:8337",
"services" : "00000001",
"lastsend" : 1419790561,
"lastrecv" : 1419790606,
"bytessent" : 172,
"bytesrecv" : 759,
"conntime" : 1419790561,
"pingtime" : 0.00000000,
"version" : 32430,
"subver" : "",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "192.155.88.115:8337",
"services" : "00000001",
"lastsend" : 1419790590,
"lastrecv" : 1419790604,
"bytessent" : 227,
"bytesrecv" : 75290,
"conntime" : 1419790589,
"pingtime" : 0.00000000,
"version" : 70001,
"subver" : "/Satoshi:0.8.6/",
"inbound" : false,
"startingheight" : 239195,
"banscore" : 0,
"syncnode" : false
}
]

C'mon ... when I got interested in this coin in February/March I sent to the donation address 5000 IXC as I thought they were going to the development, and soon after I sent you another 5000 IXC for CP. It was before I realized that there were nothing that could expected from you to deliver, and I thereby lost my interest in the coin.

Now that there seems to be actually a competent coder, I suggest that you take your cut out of that 10000 IXC for the work done since March, and send the rest (if any) to Ahmed. Please announce here how much (if any) you sent to Ahmed.

Block #2937 missing for some reason.

You can access the wallet once it's synchorinized. It can actually already open and create new wallets. Excellent work in such a short time!

If you mean the data directory by "roaming", it indeed is automaticly saving the blockchain there (at least for me). As I don't like that, I noticed that you can change the default directory the same way you do it for the deamon and so I created a small .bat file to start my GUI wallet:

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

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.

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

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/

Is this something that has been agreed upon? I don't think these additional fees encourage the use of IXC CP ... why to use it if it costs more than bitcoin CP (ot NXT asset exchange)? How are fees decided?  

Yes, exactly. And now think about average-Joe who wants to make some bets. First he buys IXC. So far so good. Then he starts looking betting markets. He finds three games with nice odds. Game A is definied in terms of user-definied-currency-A (UDCA). So he tries to buy UDCA with decent price. Game B is definied in UDCB, So he buys some UDCB. Game C is definied in UDCC, ... you get the picture. So maybe it might be better just to have metacoin he could buy with IXC and make his bets in all games?

Ok, you are right, and now I understand your previous comment about distribution. Sorry about my previous answer (and its tone). My bad.

So you can set the protocol rules so that a user definied coin can be made techinically the same as the metacoin after the coin has been set up. So the problems are more practical: how the coins will be distributed (requires the trust to the issuer), and more importantly, it will take (too) long time for the markets to sort out the defacto asset to be used in bets.

But like I said earlier, I'm happy with 2c) (which I prefer over burning the specific metacoin) althoug I still think the (specific) metacoin (2b) would be better. Since I think there seems to a general agreement that we should get something soon (in order not to miss the opportunity), I really think you should proceed with your plan. What do you think should be done with the OP_RETURN issue?

WTF? Why are you playing silly word games? This has nothing to do with "the difference between issuance and distribution". It is simply than no one can issue more CP metacoins or cancel the metacoin as nobody can cancel bitcoin or make 50 million more bitcoins. Any CP user definied currency can be canceled at any time or more of the currency can be created at the will of the issuer. I guess you understood that already, but instead of being man enough to admit your (repeated) false statement, you chose to play childish "muddying the waters" games. I have no time for those, so have fun with yourself.

No, it is not. How many times we need to go through this?

A metacoin is not issued by anyone, it is created within the implementation. Therefore it is not controlled by anyone, and it will exists as long as the protocol exists. Any user definied asset is issued by someone, and requires trust to the issuer (additionally with some legal implications). I could issue a coin mimicin my proposed metacoin 2b), but I can also cancel the coin at any time. I'm sure you can imagine reasons (mob/feds, my family) for doing that.

Nope. In 2c) there is no coin/asset (apart from IXC) with a special status, i.e., there are more things in 2b (and 2a) than in 2c. If you really want to see this as a "subset" thing, you can argue that 2c) is a subset of 2b) (or 2a) (with an additional freedom that any asset can be used for bets).

2b (and 2a) is not a subset. There is a crucial difference between a metacoin and a user definied currency (as explained earlier): a metacoin is not issued (by any entity) and it is trusted by everyone accepting/trusting the protocol itself.

Ok, let me try to recap tens of pages of discussion about IXCoin & Counterparty etc  for the benefit of all the casual readers. And this is only my understanding of the situation, so please correct me if I'm wrong.

As far as I understand, there are only two basic options for the "counterparty features" to be added to IXCoin:

1) Native implementation
2) OP_RETURN based (or similar) implementation (using IXCoin as a transport layer), i.e., Counterparty/Metacoin/ColoredCoins type implementation

I think 1) is out of question simply due to resources available (it would be a huge project with a lot of coding and testing). So we are left with 2), which only needs a small change to the current IXCoin client, and we can utilize existing code for the "features" (feature clients/apps etc). AFAIK there has been four porposed working variations of 2):

2a) Counterparty with a metacoin ("native" coin in the bitcoin Counterparty (XCP)/Mastercoin (MSC)) created by burning (i.e. destroying) IXCs
2b) Counterparty with a metecoin "distributed" to all IXCoin owners according to their IXCoin ownership at a certain block heigth (launch)
2c) Counterparty with no metacoin. Betting etc. implemented by allowing bets to be offered in any user definied asset/currency (instead of using a metacoin).
2d) Counterparty with no metacoin. All features requiring escrow (betting etc.) stripped off. This is pretty much equivalent to ColoredCoins.

Did I miss something?

I don't know any other reason than that some people do not like things like Counterparty to be used in Bitcoin network. And that's exactly (as Friction has been saying several times) is the chance for IXCoin. We can offer almost the same crucial feature (security), and instead of obfuscating the use of of protocols like Counterparty, we welcome them!

For the second question, I think update is needed only for the OP_RETURN feature to be enabled. So I think originally the idea was to get the pools to update to the current version, but if I recall right, Friction said that OP_RETURN is not enabled in the current version (as it was supposed to be). So we need a new version of the client. When doing that, we could also increase the 80-byte limit (especially if it makes sense from the counterparty implementation point of view) as opposed to bitcoin decreasing(?) it!