BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 04:15:03 AM Last edit: January 09, 2014, 08:46:22 AM by 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.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 04:15:24 AM |
|
reserved
|
|
|
|
nocoin
|
|
January 08, 2014, 04:29:14 AM |
|
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 (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 04:42:26 AM |
|
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#L1333Ok, 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
|
|
January 08, 2014, 05:34:58 AM |
|
[ 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 (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 05:45:22 AM |
|
[ 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.htmlYes, 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
|
|
January 08, 2014, 05:52:04 AM |
|
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/1BPwZ758qNBAKygmq74s16nDZwNjsP6gu81BPwZ758qNBAKygmq74s16nDZwNjsP6gu8 ---> 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.
|
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 06:16:57 AM |
|
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/1BPwZ758qNBAKygmq74s16nDZwNjsP6gu81BPwZ758qNBAKygmq74s16nDZwNjsP6gu8 ---> 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
|
|
January 08, 2014, 06:19:44 AM |
|
It's due to a bug. Fixed already.
Love your work! Btw, which address was the first that did a successful burn?
|
|
|
|
|
PhantomPhreak
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 08, 2014, 12:39:04 PM |
|
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#L1333Ok, 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
|
|
January 08, 2014, 01:04:35 PM |
|
Excellent job, thank you! I exceeded the 1 BTC limit, does this matter?
|
|
|
|
PhantomPhreak
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 08, 2014, 01:12:17 PM |
|
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
|
|
January 08, 2014, 01:46:01 PM |
|
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
Legendary
Online
Activity: 2142
Merit: 1121
|
|
January 08, 2014, 01:56:08 PM |
|
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 (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 08, 2014, 02:35:01 PM |
|
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#L1333Ok, 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
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 08, 2014, 03:17:53 PM |
|
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
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
January 08, 2014, 03:32:26 PM |
|
Thanks BitThink for your work on this. This is the first community project out of what will hopefully be many.
|
|
|
|
PhantomPhreak
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 08, 2014, 03:39:00 PM |
|
Thanks BitThink for your work on this. This is the first community project out of what will hopefully be many. Yes, seconded.
|
|
|
|
NxtChoice
|
|
January 08, 2014, 04:19:31 PM |
|
Great!
|
|
|
|
jimhsu
|
|
January 08, 2014, 08:23:06 PM |
|
I think it wouldn't be hard to programmatically check every address you get from that table with counterpartyd, and get the burn amount. In fact, an even easier way is to check the counterpartyd logfile, which has a pretty structured log syntax that you can turn into data with a few string commands. Of course this will require running bitcoind and counterpartyd on your remote server. Example from log file: ... 2014-01-06-T10:30:27Central Standard Time Block: 278930 2014-01-06-T10:30:27Central Standard Time Burn: 1GSJoRMuFEqtx3e4UjmfZiNonoGrHnt5Wv burned 1.0 BTC for 1443.63636364 XCP (b8a27744…79d741e4) 2014-01-06-T10:30:27Central Standard Time Burn: 146FcHjXUSiJMcYWE7WKPBKSvvCedi2YuA burned 1.0 BTC for 1443.63636364 XCP (e62cd3f0…88fc3542) 2014-01-06-T10:30:27Central Standard Time Burn: 18tJnidmGRi4QxAFmUQgwdQMJm9tRVZotp burned 0.9999 BTC for 1443.492 XCP (cd68e0a1…13c4f575) 2014-01-06-T10:30:27Central Standard Time Burn: 1NULPePYzi8oz6r8D2pgKjfAcJjXQGKasc burned 0.30370714 BTC for 438.4426712 XCP (d29b8039…972e4573) 2014-01-06-T10:30:28Central Standard Time Block: 278931 2014-01-06-T10:30:31Central Standard Time Block: 278932 2014-01-06-T10:30:39Central Standard Time Block: 278933 2014-01-06-T10:30:40Central Standard Time Block: 278934 2014-01-06-T10:30:41Central Standard Time Block: 278935 2014-01-06-T10:30:44Central Standard Time Block: 278936 2014-01-06-T10:30:44Central Standard Time Burn: 1NFga6ZVsrx9wP4uRg6rNzD9drbdz5hbsA burned 0.99909597 BTC for 1441.78631162 XCP (460f00fc…c4605fbc) 2014-01-06-T10:30:44Central Standard Time Burn: 1NDBXUBa1DPbPbxLEA8r8FJufzNdrT9Pb7 burned 0.9941 BTC for 1434.57667273 XCP (93a7209d…b2c95f7f) 2014-01-06-T10:30:46Central Standard Time Block: 278937 2014-01-06-T10:30:47Central Standard Time Block: 278938 ...
|
Dans les champs de l'observation le hasard ne favorise que les esprits préparé
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 09, 2014, 01:05:54 AM |
|
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. Ok it make sense. I will change my validation.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 09, 2014, 01:08:26 AM |
|
I think it wouldn't be hard to programmatically check every address you get from that table with counterpartyd, and get the burn amount. In fact, an even easier way is to check the counterpartyd logfile, which has a pretty structured log syntax that you can turn into data with a few string commands. Of course this will require running bitcoind and counterpartyd on your remote server. Example from log file: ... 2014-01-06-T10:30:27Central Standard Time Block: 278930 2014-01-06-T10:30:27Central Standard Time Burn: 1GSJoRMuFEqtx3e4UjmfZiNonoGrHnt5Wv burned 1.0 BTC for 1443.63636364 XCP (b8a27744…79d741e4) 2014-01-06-T10:30:27Central Standard Time Burn: 146FcHjXUSiJMcYWE7WKPBKSvvCedi2YuA burned 1.0 BTC for 1443.63636364 XCP (e62cd3f0…88fc3542) 2014-01-06-T10:30:27Central Standard Time Burn: 18tJnidmGRi4QxAFmUQgwdQMJm9tRVZotp burned 0.9999 BTC for 1443.492 XCP (cd68e0a1…13c4f575) 2014-01-06-T10:30:27Central Standard Time Burn: 1NULPePYzi8oz6r8D2pgKjfAcJjXQGKasc burned 0.30370714 BTC for 438.4426712 XCP (d29b8039…972e4573) 2014-01-06-T10:30:28Central Standard Time Block: 278931 2014-01-06-T10:30:31Central Standard Time Block: 278932 2014-01-06-T10:30:39Central Standard Time Block: 278933 2014-01-06-T10:30:40Central Standard Time Block: 278934 2014-01-06-T10:30:41Central Standard Time Block: 278935 2014-01-06-T10:30:44Central Standard Time Block: 278936 2014-01-06-T10:30:44Central Standard Time Burn: 1NFga6ZVsrx9wP4uRg6rNzD9drbdz5hbsA burned 0.99909597 BTC for 1441.78631162 XCP (460f00fc…c4605fbc) 2014-01-06-T10:30:44Central Standard Time Burn: 1NDBXUBa1DPbPbxLEA8r8FJufzNdrT9Pb7 burned 0.9941 BTC for 1434.57667273 XCP (93a7209d…b2c95f7f) 2014-01-06-T10:30:46Central Standard Time Block: 278937 2014-01-06-T10:30:47Central Standard Time Block: 278938 ... Good idea, I will at least install it on my local computer and compare the results periodically.
|
|
|
|
PhantomPhreak
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 09, 2014, 01:20:09 AM |
|
I think it wouldn't be hard to programmatically check every address you get from that table with counterpartyd, and get the burn amount. In fact, an even easier way is to check the counterpartyd logfile, which has a pretty structured log syntax that you can turn into data with a few string commands. Of course this will require running bitcoind and counterpartyd on your remote server. Example from log file: ... 2014-01-06-T10:30:27Central Standard Time Block: 278930 2014-01-06-T10:30:27Central Standard Time Burn: 1GSJoRMuFEqtx3e4UjmfZiNonoGrHnt5Wv burned 1.0 BTC for 1443.63636364 XCP (b8a27744…79d741e4) 2014-01-06-T10:30:27Central Standard Time Burn: 146FcHjXUSiJMcYWE7WKPBKSvvCedi2YuA burned 1.0 BTC for 1443.63636364 XCP (e62cd3f0…88fc3542) 2014-01-06-T10:30:27Central Standard Time Burn: 18tJnidmGRi4QxAFmUQgwdQMJm9tRVZotp burned 0.9999 BTC for 1443.492 XCP (cd68e0a1…13c4f575) 2014-01-06-T10:30:27Central Standard Time Burn: 1NULPePYzi8oz6r8D2pgKjfAcJjXQGKasc burned 0.30370714 BTC for 438.4426712 XCP (d29b8039…972e4573) 2014-01-06-T10:30:28Central Standard Time Block: 278931 2014-01-06-T10:30:31Central Standard Time Block: 278932 2014-01-06-T10:30:39Central Standard Time Block: 278933 2014-01-06-T10:30:40Central Standard Time Block: 278934 2014-01-06-T10:30:41Central Standard Time Block: 278935 2014-01-06-T10:30:44Central Standard Time Block: 278936 2014-01-06-T10:30:44Central Standard Time Burn: 1NFga6ZVsrx9wP4uRg6rNzD9drbdz5hbsA burned 0.99909597 BTC for 1441.78631162 XCP (460f00fc…c4605fbc) 2014-01-06-T10:30:44Central Standard Time Burn: 1NDBXUBa1DPbPbxLEA8r8FJufzNdrT9Pb7 burned 0.9941 BTC for 1434.57667273 XCP (93a7209d…b2c95f7f) 2014-01-06-T10:30:46Central Standard Time Block: 278937 2014-01-06-T10:30:47Central Standard Time Block: 278938 ... Good idea, I will at least install it on my local computer and compare the results periodically. If I may ask, why aren't you using counterpartyd, and its JSON-RPC API, to get all of the values? It is the reference implementation of the protocol, so its results are guaranteed to be correct.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 09, 2014, 02:13:36 AM |
|
Hi, PhantomPhreak. It's too heavy to install bitcoind. Currently I am using the blockchain.info API and this explorer is just a very lightweight Go program running on Heroku without any dependency. Moreover, I think a separate parsing program may help standardize the protocol specification. That said, I will follow the changes in the python source since now the source is the specification.
|
|
|
|
PhantomPhreak
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
January 09, 2014, 02:25:50 AM |
|
Hi, PhantomPhreak. It's too heavy to install bitcoind. Currently I am using the blockchain.info API and this explorer is just a very lightweight Go program running on Heroku without any dependency. Moreover, I think a separate parsing program may help standardize the protocol specification. That said, I will follow the changes in the python source since now the source is the specification. Hi. That sounds fine. Re-implementations, which should indeed help test the protocol, are great. We should come up with a standard way of comparing different implementations, of course, when it's time.
|
|
|
|
BitThink (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
January 09, 2014, 02:31:22 AM |
|
Hi, PhantomPhreak. It's too heavy to install bitcoind. Currently I am using the blockchain.info API and this explorer is just a very lightweight Go program running on Heroku without any dependency. Moreover, I think a separate parsing program may help standardize the protocol specification. That said, I will follow the changes in the python source since now the source is the specification. Hi. That sounds fine. Re-implementations, which should indeed help test the protocol, are great. We should come up with a standard way of comparing different implementations, of course, when it's time. Yes, a complete set of tests can help a lot. For example, btcd (a Go implementation of bitcoind) passed all the tests of bitcoind. Moreover, the tests can help the reference implementation itself too for regression testing. This is certainly not a priority for now. In current stage, when I get time I will setup a couterpartd in my own laptop and create a script to compare the results periodically.
|
|
|
|
Alexd32
Newbie
Offline
Activity: 42
Merit: 0
|
|
October 17, 2017, 12:27:01 PM |
|
Hi, PhantomPhreak. It's too heavy to install bitcoind. Currently I am using the blockchain.info API and this explorer is just a very lightweight Go program running on Heroku without any dependency. Moreover, I think a separate parsing program may help standardize the protocol specification. That said, I will follow the changes in the python source since now the source is the specification. Hi. That sounds fine. Re-implementations, which should indeed help test the protocol, are great. We should come up with a standard way of comparing different implementations, of course, when it's time. Yes, a complete set of tests can help a lot. For example, btcd (a Go implementation of bitcoind) passed all the tests of bitcoind. Moreover, the tests can help the reference implementation itself too for regression testing. This is certainly not a priority for now. In current stage, when I get time I will setup a couterpartd in my own laptop and create a script to compare the results periodically. Thanks, it very much will help.
|
|
|
|
|