Counterpart (XCP) Explorer

[BitThink]

Hi, I've created a website to facilitate people to check their counterpart (XCP) balance.
http://www.counterparty-explorer.com/

Note:
1) Valid burn:
   a) all input addresses should be identical
   b) the FIRST output HAS TO BE the burn address.
   c) only BTC burnt up to 1 BTC limit is considered valid.
This complies with the official couterpartd.

2) Not polished yet, so it's only plain text for now. Please use Ctrl-F to search your address. Per-address detail will be added later.

Disclaimer: this is not an official site, so the balance may be different with the couterpartd.

Any feedback is welcome.

[1714546636]

1714546636

[1714546636]

1714546636

[1714546636]

1714546636

[1714546636]

1714546636

[BitThink]

reserved

[nocoin]

if there're two outputs, the first output should be the burn address and the second should be the same as the input address. Please correct me if this does not comply with the standard

Don't know how counterpartyd works, but standard bitcoin client doesn't guarantee outputs order.
https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1333

[BitThink]

if there're two outputs, the first output should be the burn address and the second should be the same as the input address. Please correct me if this does not comply with the standard

Don't know how counterpartyd works, but standard bitcoin client doesn't guarantee outputs order.
https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1333

Ok, then I will relax to

if there're two outputs, one has to be the burn address and one has to be the send address.

Any Counterpart developer can help to confirm these rules? Thanks a lot.

[led_lcd]

[
Ok, then I will relax to

if there're two outputs, one has to be the burn address and one has to be the send address.

Any Counterpart developer can help to confirm these rules? Thanks a lot.

Great work.

Valid transactions:

1) Where there is change left over from the burn - the first output address must be the burn address, the second output must be the sending address.

2) Where there is NO change left over from the burn - the only output is the burn address.

Source (scroll down to Verification):

http://counterpartyd-build.readthedocs.org/en/latest/HowToBurn.html

[BitThink]

[
Ok, then I will relax to

if there're two outputs, one has to be the burn address and one has to be the send address.

Any Counterpart developer can help to confirm these rules? Thanks a lot.

Great work.

Valid transactions:

1) Where there is change left over from the burn - the first output address must be the burn address, the second output must be the sending address.

2) Where there is NO change left over from the burn - the only output is the burn address.

Source (scroll down to Verification):

http://counterpartyd-build.readthedocs.org/en/latest/HowToBurn.html

Yes, that's the reason I checked the order,  but bitcoind seems does not ensure the first output address is always in the first position of the transaction. I am not sure about it, but fortunately it seems up till now, all the transactions with two outputs have the burn address in the first position.

[led_lcd]

Yes, that's the reason I checked the order,  but bitcoind seems does not ensure the first output address is always in the first position of the transaction. I am not sure about it, but fortunately it seems up till now, all the transactions with two outputs have the burn address in the first position.

Ah ok.

How are the results being aggregated and then the error thrown where there are multiple transactions on that address?

For example:

https://blockchain.info/address/1BPwZ758qNBAKygmq74s16nDZwNjsP6gu8

1BPwZ758qNBAKygmq74s16nDZwNjsP6gu8   --->   BTC spent: 0.01000000   XCP balance: 0.0000   error: no output address is the burn address

It appears to be a good burn of 0.01 BTC.

[led_lcd]

In the case where:

1) There was a burn which returned change and
2) The remainder of the balance was burned

The aggregation says error: no output address is the burn address" and has a XCP value of 0.0000. The burn looks ok by manual inspection:

https://blockchain.info/address/1KCJvwUqFPupAFg5VkatL4RqnzkbJ7MiCe

[BitThink]

Yes, that's the reason I checked the order,  but bitcoind seems does not ensure the first output address is always in the first position of the transaction. I am not sure about it, but fortunately it seems up till now, all the transactions with two outputs have the burn address in the first position.

Ah ok.

How are the results being aggregated and then the error thrown where there are multiple transactions on that address?

For example:

https://blockchain.info/address/1BPwZ758qNBAKygmq74s16nDZwNjsP6gu8

1BPwZ758qNBAKygmq74s16nDZwNjsP6gu8   --->   BTC spent: 0.01000000   XCP balance: 0.0000   error: no output address is the burn address

It appears to be a good burn of 0.01 BTC.

It's due to a bug. Fixed already.

[led_lcd]

It's due to a bug. Fixed already.

Love your work!

Btw, which address was the first that did a successful burn?

[BitThink]

It's due to a bug. Fixed already.

Love your work!

Btw, which address was the first that did a successful burn?

I guess this one
https://blockchain.info/tx/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098


Currently, the order in my website is random the order is from the most XCP to least.

[PhantomPhreak]

if there're two outputs, the first output should be the burn address and the second should be the same as the input address. Please correct me if this does not comply with the standard

Don't know how counterpartyd works, but standard bitcoin client doesn't guarantee outputs order.
https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1333

Ok, then I will relax to

if there're two outputs, one has to be the burn address and one has to be the send address.

Any Counterpart developer can help to confirm these rules? Thanks a lot.

As others have noted, the change address is unimportant; what matters is the order of the outputs, which counterpartyd picks carefully. I'm going to change the HowToBurn instructions now.

[NWO]

Excellent job, thank you! I exceeded the 1 BTC limit, does this matter?

[PhantomPhreak]

Excellent job, thank you! I exceeded the 1 BTC limit, does this matter?

If you exceeded the 1 BTC limit, you'll get 1 BTC worth of XCP.

[NWO]

Excellent job, thank you! I exceeded the 1 BTC limit, does this matter?

If you exceeded the 1 BTC limit, you'll get 1 BTC worth of XCP.

Thanks for clearing that up 

[superresistant]

Excellent job, thank you! I exceeded the 1 BTC limit, does this matter?

If you exceeded the 1 BTC limit, you'll get 1 BTC worth of XCP.

Thanks for clearing that up 

Here you are NWO, not missing any opportunity... 

[BitThink]

if there're two outputs, the first output should be the burn address and the second should be the same as the input address. Please correct me if this does not comply with the standard

Don't know how counterpartyd works, but standard bitcoin client doesn't guarantee outputs order.
https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L1333

Ok, then I will relax to

if there're two outputs, one has to be the burn address and one has to be the send address.

Any Counterpart developer can help to confirm these rules? Thanks a lot.

As others have noted, the change address is unimportant; what matters is the order of the outputs, which counterpartyd picks carefully. I'm going to change the HowToBurn instructions now.

Ok. Thanks for your clarification. So I will remove the requirement that change address has to be the sent address. Just wonder why you restrict the order. 1) order is not guaranteed in many clients. 2) order is not needed in determining the burnt amount. Thanks.

Btw some clients randomize the output order to increase the anonimosity, so people don't know which address is change address and tracking becomes more difficult.

[PhantomPhreak]

Ok. Thanks for your clarification. So I will remove the requirement that change address has to be the sent address. Just wonder why you restrict the order. 1) order is not guaranteed in many clients. 2) order is not needed in determining the burnt amount. Thanks.

Btw some clients randomize the output order to increase the anonimosity, so people don't know which address is change address and tracking becomes more difficult.

It's only burn transactions that can even theoretically be constructed with a client that isn't specifically designed to handle Counterparty transactions (which, in every other case, include an OP_RETURN output). This way, the algorithm for parsing a burn is the same as that for parsing any Counterparty transaction with regard to identifying the 'destination': a burn is any valid Counterparty transaction whose destination is the unspendable address.

[xnova]

Thanks BitThink for your work on this. This is the first community project out of what will hopefully be many.

[PhantomPhreak]

Thanks BitThink for your work on this. This is the first community project out of what will hopefully be many.

Yes, seconded.