[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[reader31]

https://blockchain.info/tx/9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9

Another invalid transaction with 0.5 BTC !

Attention:

Please stop burning from a wallet with multiple addresses !!!!!!

PhantomPhreak:

I really think it's better to credit the XCP to the first input address. This will not cause any serious issue (at most adding 2 to 3 lines of code) in my opinion.

Does this happen only sometimes? Beacause i did burn from multiple addresses from the same wallet and the burn seem to go through fine and I was able to verify the xcp balance on those addresses as well.

[1713568530]

1713568530

[1713568530]

1713568530

[1713568530]

1713568530

[BitThink]

https://blockchain.info/tx/9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9

Another invalid transaction with 0.5 BTC !

Attention:

Please stop burning from a wallet with multiple addresses !!!!!!

PhantomPhreak:

I really think it's better to credit the XCP to the first input address. This will not cause any serious issue (at most adding 2 to 3 lines of code) in my opinion.

Does this happen only sometimes? Beacause i did burn from multiple addresses from the same wallet and the burn seem to go through fine and I was able to verify the xcp balance on those addresses as well.

Yes, it only happens when the client combine two previous outputs of two different addresses. It usually happens when there's no enough BTC in any single addresses.

Take the above transaction as an example. Because both addresses have less than 0.5 BTC, but the user wanted to burn 0.5 BTC, so the client has to combine previous outputs in two addresses.

Normally, the client only shows the sum of all its addresses, so it's not so easy to know when the client will combine inputs from the different addresses. Therefore, the safest solution is to only burn from a wallet with only one address.

[mtbitcoin]

https://blockchain.info/tx/9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9

Another invalid transaction with 0.5 BTC !

Attention:

Please stop burning from a wallet with multiple addresses !!!!!!

PhantomPhreak:

I really think it's better to credit the XCP to the first input address. This will not cause any serious issue (at most adding 2 to 3 lines of code) in my opinion.

Does this happen only sometimes? Beacause i did burn from multiple addresses from the same wallet and the burn seem to go through fine and I was able to verify the xcp balance on those addresses as well.

Yes, it only happens when the client combine two previous outputs of two different addresses. It usually happens when there's no enough BTC in any single addresses.

Take the above transaction as an example. Because both addresses have less than 0.5 BTC, but the user wanted to burn 0.5 BTC, so the client has to combine previous outputs in two addresses.

Normally, the client only shows the sum of all its addresses, so it's not so easy to know when the client will combine inputs from the different addresses. Therefore, the safest solution is to only burn from a wallet with only one address.

Yes, it does look like that is what is happening. Therefore the safest solution as far as the QT client is concerned, is to do a "full"  burn from a "NEW" wallet which you have newly funded to a single address. However, after the first burn any remaining balance could get allocated to a different change address. The QT client lacks coin control at the moment.

[BitThink]

https://blockchain.info/tx/9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9

Another invalid transaction with 0.5 BTC !

Attention:

Please stop burning from a wallet with multiple addresses !!!!!!

PhantomPhreak:

I really think it's better to credit the XCP to the first input address. This will not cause any serious issue (at most adding 2 to 3 lines of code) in my opinion.

Does this happen only sometimes? Beacause i did burn from multiple addresses from the same wallet and the burn seem to go through fine and I was able to verify the xcp balance on those addresses as well.

Yes, it only happens when the client combine two previous outputs of two different addresses. It usually happens when there's no enough BTC in any single addresses.

Take the above transaction as an example. Because both addresses have less than 0.5 BTC, but the user wanted to burn 0.5 BTC, so the client has to combine previous outputs in two addresses.

Normally, the client only shows the sum of all its addresses, so it's not so easy to know when the client will combine inputs from the different addresses. Therefore, the safest solution is to only burn from a wallet with only one address.

Yes, it does look like that is what is happening. Therefore the safest solution as far as the QT client is concerned, is to do a "full"  burn from a "NEW" wallet which you have newly funded to a single address. However, after the first burn any remaining balance could get allocated to a different change address. The QT client lacks coin control at the moment.

Yes, Qt client will create a new address for the change.  After burn once, all the coins left, if any, will go to a new address. Therefore, you will be safe if you never send bitcoin to the same address more than once.

Nonetheless, I still think the developers can do just a little bit more work to avoid this tricky part. if all burning are credited to the first input address, these invalid burnings will be valid.

[BitThink]

Sadly, the same guy just wasted 0.5 BTC made another invalid burning and threw another 0.001 BTC.

https://blockchain.info/tx/e8bc59126544d18f7f2d5e00f70188496350aec44c82ed26306e20f7868b5d7d


This time, the error was that the burning address was in the second output, which is not allowed by the XCP protocol.

[panonym]

Note that you will need BTC on this same address to be able to move your XCP. So keep some.

I've emptied a (several) blockchain wallets to burn, is this an issue? do I need to add some bitcoin to them?

When bitcoind v0.9 is out, XCP transaction will be possible thanks to the implementation of OP_RETURN.
But XCP living on top of BTC, 0.0001 BTC is needed for every transaction.
So keep a millibit or something. (You can add it later, no problem. It will just link ownership between your addresses in the blockchain history.)


And now~
Maybe a few more people start to grasp well why I said bitcoind is crappy software (especially knowing it's 5 years old).
You cannot always explicitly control what it does.
You cannot even specify from which key in your wallet you wish your btc to be sent.
Also no warning nor confirmation-ask before it mixes all necessary address to reach x amount if 'not enough in 1key.
(No choice either? about what is done with your bitcoin surplus when you send only a tiny part.)

Code:

9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9
1M7YzE6hfm79MwvuQiubXCf4vi9sFK423x 		1CounterpartyXXXXXXXXXXXXXXXUWLpVr 0.50 BTC
18ioiq22htQBBq9ogX4UfNpjKNZr8TNhtL              1KwwWC6vXEF8KhR8nX7cNHYK2nc4Bsdqdz 0.48979995 BTC

0ffcfaca47b5e962913e5e12ef914cb665bbaecec7132de476bd132c8edce732
1bPb7NZ1mdH9sQPEWp2j3shPmHS1BMVos		1CounterpartyXXXXXXXXXXXXXXXUWLpVr 0.70 BTC
1NMwvn6DWFr5LPrHX2M1KAJzxfy6heRSTH 		1LW9agyYcAJEdAdfGdbnfAbUd8Pxo1Tzr 0.00022036 BTC

So now we officially have 1.2 BTC which has been burned for nothing. It's lost. No XCP in exchange.
A bit mean, but I honestly don't care too much about these two because they have been made negligently using blockchain.info
The counterpartyd software does allow to chose from which address the coin are destroyed.
And so this is theoretically not possible to happen using the software.

What concern me much more is this one:

Code:

e8bc59126544d18f7f2d5e00f70188496350aec44c82ed26306e20f7868b5d7d
1KwwWC6vXEF8KhR8nX7cNHYK2nc4Bsdqdz		14JP4xbN6XtihBBnfLv73sNQGABQ5zYv2a 0.48869995 BTC
                                                1CounterpartyXXXXXXXXXXXXXXXUWLpVr 0.001 BTC

What did happen here?
Bitcoind seem to have fucked up for no reason (therefore crappy/unreliable),
because it sent the bitcoin surplus to another address instead of the same output one (where in the first place, it shouldn't have moved these 0.448BTC at all - if we don't want it to (but it's bitcoind... no full control)).
I do not understand why this happened. Why was it sent to 1CounterpartyXXX only in 2nd? If anyone can explain, I'm interested.
Very lucky it happened only once.
These 0.001BTC were also burn for nothing, lost.

Obvious advice to everyone: start by burning a very tiny amount, and verify it worked before burning more.

PS: I advise using the counterpartyd software even if it makes you lose 3-4 days, as it did for me.
That way there is almost no risk.
You're free to follow someone else advice.

577'950.8549 XCP are created as of now.
But peculiar fact: we can reach 3 different value for the equivalent total BTC burned.

Code:

405.22870838 BTC  https://blockchain.info/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr?offset=0&filter=0&currency=BTC
403.99070000 BTC  http://www.blockscan.com/default.aspx
404.02770838 BTC = my calculus 405.22870838 - 0.5 - 0.7 - 0.001

(which mean that if blockscan.com is correct, additional unspotted ~0.037 BTC burn failed)

[allwelder]

Really need help how to quickly find or search my burning transaction from http://www.counterparty-explorer.com/
Anyone can help?
Thanks

[mtbitcoin]

Code:

405.22870838 BTC  https://blockchain.info/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr?offset=0&filter=0&currency=BTC
403.99070000 BTC  http://www.blockscan.com/default.aspx
404.02770838 BTC = my calculus 405.22870838 - 0.5 - 0.7 - 0.001

(which mean that if blockscan.com is correct, additional unspotted ~0.037 BTC burn failed)

Just for clarification ... The data from BlockScan only includes all confirmed transactions as per the Counterparty client. So unless the Counterparty client burn transactions database is incorrect this is what is recorded by the official client

[mtbitcoin]

Really need help how to quickly find or search my burning transaction from http://www.counterparty-explorer.com/
Anyone can help?
Thanks

You can check for confirmed XCP balances at http://blockscan.com. Just enter your BTC address in the search box.

[panonym]

So unless the Counterparty client burn transactions database is incorrect this is what is recorded by the official client

I sure hope the official reference is correct then ^^
(which does mean we have a mysterious 0.037BTC lost?! whatever, it's the 0.001 fail that concern me)

I didn't check how you created your block explorer.
It's directly made from counterpartyd log, is that it? Good job.

[BitThink]

Really need help how to quickly find or search my burning transaction from http://www.counterparty-explorer.com/
Anyone can help?
Thanks

ctrl-f and enter your address

[BitThink]

Some clients put change address in a random position to enhance anonymity. That could be the reason burn address goes to the second.

[allwelder]

Really need help how to quickly find or search my burning transaction from http://www.counterparty-explorer.com/
Anyone can help?
Thanks

You can check for confirmed XCP balances at http://blockscan.com. Just enter your BTC address in the search box.

from: allwelder on Today at 09:03:13 AM
Really need help how to quickly find or search my burning transaction from http://www.counterparty-explorer.com/
Anyone can help?
Thanks
ctrl-f and enter your address

Both are worked well,thank you

[plasm]

@PhantomPhreak

Hello,when I saw your XCP,I was surprised to find that it's characterized is very similar to my previous thoughts.
This is my  postings at December 26.
https://bitcointalk.org/index.php?topic=385739.msg4154105#msg4154105
Maybe a coincidence?

[reader31]

https://blockchain.info/tx/9615ea60603430587f67a82f4bf62eaa1a4cae4a156807cb62b7ccaaab3ba4f9

Another invalid transaction with 0.5 BTC !

Attention:

Please stop burning from a wallet with multiple addresses !!!!!!

PhantomPhreak:

I really think it's better to credit the XCP to the first input address. This will not cause any serious issue (at most adding 2 to 3 lines of code) in my opinion.

Does this happen only sometimes? Beacause i did burn from multiple addresses from the same wallet and the burn seem to go through fine and I was able to verify the xcp balance on those addresses as well.

Yes, it only happens when the client combine two previous outputs of two different addresses. It usually happens when there's no enough BTC in any single addresses.

Take the above transaction as an example. Because both addresses have less than 0.5 BTC, but the user wanted to burn 0.5 BTC, so the client has to combine previous outputs in two addresses.

Normally, the client only shows the sum of all its addresses, so it's not so easy to know when the client will combine inputs from the different addresses. Therefore, the safest solution is to only burn from a wallet with only one address.

got it

[prophetx]

Still couldnt getting run.py to work properly so I am now trying the beta installer, but once again I get an error:


C:\Users\Leo>"C:\Program Files\counterpartyd\counterpartyd.exe"


Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)

Bitcoin.conf
rpcuser=rpc
rpcpassword=XXXX
server=1
daemon=1
txindex=1

Counterpartyd.conf
[Default]
rpc-connect=localhost
rpc-port=18832
rpc-user=rpc
rpc-password=XXXX

Tried port 18832 and 8332, same error. I'm getting really close to just giving up

With that bitcoin.conf configuration, your bitcoin server listens on port 8332. Worse case, edit bitcoind.conf, and add the following lines:

Code:

rpcport=8332
port=8333

So given that, that you are not running on testnet, your counterpartyd.conf is configured to listen on the wrong port. With your specified bitcoin.conf file, "rpc-port" in counterpartyd.conf should be "rpc-port=8332", NOT "rpc-port=18832".

Please make those changes, restart both bitcoind/bitcoin-qt and counterpartyd, and let us know if that fixes it.

konfet: Your issue is probably pretty similar to this. Please verify these port numbers, as well as verifying that your bitcoind/bitcoin-qt is actually running, and listening (you can open up a DOS window and run "netstat -an" then search through the list of ports...see if you see those bitcoind ports.

I tried this and it is still not connecting.  when i run netstat -an i get 8333 showing up but not 8332.  any ideas what I might be doing wrong??

[xnova]

Still couldnt getting run.py to work properly so I am now trying the beta installer, but once again I get an error:


C:\Users\Leo>"C:\Program Files\counterpartyd\counterpartyd.exe"


Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)

Bitcoin.conf
rpcuser=rpc
rpcpassword=XXXX
server=1
daemon=1
txindex=1

Counterpartyd.conf
[Default]
rpc-connect=localhost
rpc-port=18832
rpc-user=rpc
rpc-password=XXXX

Tried port 18832 and 8332, same error. I'm getting really close to just giving up

With that bitcoin.conf configuration, your bitcoin server listens on port 8332. Worse case, edit bitcoind.conf, and add the following lines:

Code:

rpcport=8332
port=8333

So given that, that you are not running on testnet, your counterpartyd.conf is configured to listen on the wrong port. With your specified bitcoin.conf file, "rpc-port" in counterpartyd.conf should be "rpc-port=8332", NOT "rpc-port=18832".

Please make those changes, restart both bitcoind/bitcoin-qt and counterpartyd, and let us know if that fixes it.

konfet: Your issue is probably pretty similar to this. Please verify these port numbers, as well as verifying that your bitcoind/bitcoin-qt is actually running, and listening (you can open up a DOS window and run "netstat -an" then search through the list of ports...see if you see those bitcoind ports.

I tried this and it is still not connecting.  when i run netstat -an i get 8333 showing up but not 8332.  any ideas what I might be doing wrong??

Can you post up your bitcoin.conf? Also, if all else fails, try messing with the values of rpcport and port in bitcoin.conf and see how it's reflected in netstat -an.


Important note: In the latest versions of counterpartyd (on git), the rpc-host, rpc-port, etc parameters have changed. Please view the most up to date documentation on this at http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

[prophetx]

Still couldnt getting run.py to work properly so I am now trying the beta installer, but once again I get an error:


C:\Users\Leo>"C:\Program Files\counterpartyd\counterpartyd.exe"


Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)

Bitcoin.conf
rpcuser=rpc
rpcpassword=XXXX
server=1
daemon=1
txindex=1

Counterpartyd.conf
[Default]
rpc-connect=localhost
rpc-port=18832
rpc-user=rpc
rpc-password=XXXX

Tried port 18832 and 8332, same error. I'm getting really close to just giving up

With that bitcoin.conf configuration, your bitcoin server listens on port 8332. Worse case, edit bitcoind.conf, and add the following lines:

Code:

rpcport=8332
port=8333

So given that, that you are not running on testnet, your counterpartyd.conf is configured to listen on the wrong port. With your specified bitcoin.conf file, "rpc-port" in counterpartyd.conf should be "rpc-port=8332", NOT "rpc-port=18832".

Please make those changes, restart both bitcoind/bitcoin-qt and counterpartyd, and let us know if that fixes it.

konfet: Your issue is probably pretty similar to this. Please verify these port numbers, as well as verifying that your bitcoind/bitcoin-qt is actually running, and listening (you can open up a DOS window and run "netstat -an" then search through the list of ports...see if you see those bitcoind ports.

I tried this and it is still not connecting.  when i run netstat -an i get 8333 showing up but not 8332.  any ideas what I might be doing wrong??

Can you post up your bitcoin.conf? Also, if all else fails, try messing with the values of rpcport and port in bitcoin.conf and see how it's reflected in netstat -an.


Important note: In the latest versions of counterpartyd, the rpc-host, rpc-port, etc parameters have changed. Please view the most up to date documentation on this at http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

bitcoin.conf

Code:

rpcport=8332
rpcconnect=localhost
rpcuser=rpc
rpcpassword=XXX
server=1
daemon=1
txindex=1
testnet=0

counterpartyd.conf

Code:

[Default]
rpc-connect=localhost
rpc-port=8332
rpc-user=rpc
rpc-password=XXX

i am just running bitcoin-qt without any special commands on win8.  i know i can get this to work on linux but each time i have tried this on windows machines i just can never get rpc to work.  so i probably am doing something really stupid.

[prophetx]

ok i figured it out... on this new laptop i had file extensions hidden so bitcoin.conf was actually bitcoin.conf.conf

i knew i did something dumb ... thanks for the help

[btc4ever]

so how many XCP total issued so far?