Do you have a working version of counterpart yet?
Yes.
Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 653. (Read 1276774 times)
January 04, 2014, 01:29:29 PM
Yes.
January 04, 2014, 01:28:32 PM
Followed all the instructions but am getting an error when I run setup.py for the first time.
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
What version of Windows? Also, can you please post the full traceback on pastebin.com and give me the link (or, you can file a bug report at https://github.com/xnova/counterpartyd_build/issues)
Actually, putting all of the output from the run of setup.py on pastebin.com would be most helpful.
Here is the pastebin with my full command prompt. I followed the instructions to the letter from http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html
Windows 7 64 bit
http://pastebin.com/iSTJ1uNk
Thank you for that bug submission!
The problem was virtualenv version 1.5 was just released on Jan 2 that had a number of backwards-incompatible changes. This broke the setup (as the script was just fetching the newest version of virtualenv). I've tied the version the setup uses to the previous versions of virtualenv and pip, and it appears to work fine.
Here's what you need to do:
* Update your counterpartyd_build code from git (e.g. "cd C:\counterpartyd_build && git pull origin master")
* Remove Python3.3.3 from your system (via Add/Remove Programs), along with all Python3.3.3 child dependencies listed in the add/remove programs list with it (pywin32, cg_freeze ..remove them before removing Python itself)
* Manually delete the C:\Python3.3 directory (make sure it doesn't exist anymore)
* Reinstall Python3.3.3 and related packages (just follow the instructions again)
* Try to rerun the setup.py script as normal
I just rebuilt using these instructions under Win7 64-bit and it worked fine. Let me know if you have any more issues.
Build works fine now..
Cheers
January 04, 2014, 01:18:12 PM
Announcement: We made some changes to the protocol and the client: now burns don’t require the use of OP_RETURN, and we’re no longer pushing transactions through Eligius, which seems to now be rejecting anything with such an output. This means that 1) a bunch of bugs have been fixed, 2) the only Counterparty transaction that will work on mainnet until Bitcoind 0.9 comes out is a burn, 3) burns are much faster, and 4) it is theoretically possible for burns to be made with a regular Bitcoin client.
We’re not currently recommending that anyone use anything other than counterpartyd to burn. The format of a Counterparty transaction
is very specific, and we can’t guarantee that a transaction constructed by any other software will work (and if it doesn’t, you’ll lose your BTC).
For those interested, the protocol will recognise as a valid burn any transaction with the following characteristics:
Instructions on how to use a Blockchain.info wallet to construct a burn should be forthcoming. The burn functionality of counterpartyd will continue to work as it has been doing.
We’re not currently recommending that anyone use anything other than counterpartyd to burn. The format of a Counterparty transaction
is very specific, and we can’t guarantee that a transaction constructed by any other software will work (and if it doesn’t, you’ll lose your BTC).
For those interested, the protocol will recognise as a valid burn any transaction with the following characteristics:
- All of the input addresses are identical.
- The address of the first output is the unspendable address '1CounterpartyXXXXXXXXXXXXXXXUWLpVr' (mainnet) or 'mvCounterpartyXXXXXXXXXXXXXXW24Hef' (testnet).
- The total number of BTC burned by the source address is less than or equal to 1.
Instructions on how to use a Blockchain.info wallet to construct a burn should be forthcoming. The burn functionality of counterpartyd will continue to work as it has been doing.
Awesome! Great work.
January 04, 2014, 01:16:29 PM
Announcement: We made some changes to the protocol and the client: now burns don’t require the use of OP_RETURN, and we’re no longer pushing transactions through Eligius, which seems to now be rejecting anything with such an output. This means that 1) a bunch of bugs have been fixed, 2) the only Counterparty transaction that will work on mainnet until Bitcoind 0.9 comes out is a burn, 3) burns are much faster, and 4) it is theoretically possible for burns to be made with a regular Bitcoin client.
We’re not currently recommending that anyone use anything other than counterpartyd to burn. The format of a Counterparty transaction
is very specific, and we can’t guarantee that a transaction constructed by any other software will work (and if it doesn’t, you’ll lose your BTC).
For those interested, the protocol will recognise as a valid burn any transaction with the following characteristics:
Instructions on how to use a Blockchain.info wallet to construct a burn should be forthcoming. The burn functionality of counterpartyd will continue to work as it has been doing, and of course previous burns remain valid.
We’re not currently recommending that anyone use anything other than counterpartyd to burn. The format of a Counterparty transaction
is very specific, and we can’t guarantee that a transaction constructed by any other software will work (and if it doesn’t, you’ll lose your BTC).
For those interested, the protocol will recognise as a valid burn any transaction with the following characteristics:
- All of the input addresses are identical.
- The address of the first output is the unspendable address '1CounterpartyXXXXXXXXXXXXXXXUWLpVr' (mainnet) or 'mvCounterpartyXXXXXXXXXXXXXXW24Hef' (testnet).
- The total number of BTC burned by the source address is less than or equal to 1.
Instructions on how to use a Blockchain.info wallet to construct a burn should be forthcoming. The burn functionality of counterpartyd will continue to work as it has been doing, and of course previous burns remain valid.
January 04, 2014, 01:12:53 PM
Do you have a working version of counterpart yet?
January 04, 2014, 01:10:08 PM
Very interesting concept. I have some questions:
1. If the bitcoin blockchain is used as transport layer then how many confirmations are needed for a counterparty protocol message to be "visible" to other peers in the counterparty network? Do I understant correctly that if the default value of 6 confirmations is used then completing an order would take 2 hours on average (6 confirmations to issue an order and 6 confirmations for completed order to be seen in the network)? It's a quite long time, I think that it may be a limiting factor in your project.
2. Would it be possible to carry out auctions via counterparty protocol? If not, I suggest extending the order message to allow that (selling for the best price available at given time), in my opinion it would be a great functionality.
Good luck with your project.
1. If the bitcoin blockchain is used as transport layer then how many confirmations are needed for a counterparty protocol message to be "visible" to other peers in the counterparty network? Do I understant correctly that if the default value of 6 confirmations is used then completing an order would take 2 hours on average (6 confirmations to issue an order and 6 confirmations for completed order to be seen in the network)? It's a quite long time, I think that it may be a limiting factor in your project.
2. Would it be possible to carry out auctions via counterparty protocol? If not, I suggest extending the order message to allow that (selling for the best price available at given time), in my opinion it would be a great functionality.
Good luck with your project.
1. Only one confirmation is required for a transaction to be visible.
2. The current order mechanism is actually very similar to a Dutch auction. We are considering adding a new message type for something like an English auction. It would have to be a new message type, I think.
Thank you.
January 04, 2014, 12:38:59 PM
Followed all the instructions but am getting an error when I run setup.py for the first time.
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
What version of Windows? Also, can you please post the full traceback on pastebin.com and give me the link (or, you can file a bug report at https://github.com/xnova/counterpartyd_build/issues)
Actually, putting all of the output from the run of setup.py on pastebin.com would be most helpful.
Here is the pastebin with my full command prompt. I followed the instructions to the letter from http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html
Windows 7 64 bit
http://pastebin.com/iSTJ1uNk
Thank you for that bug submission!
The problem was virtualenv version 1.5 was just released on Jan 2 that had a number of backwards-incompatible changes. This broke the setup (as the script was just fetching the newest version of virtualenv). I've tied the version the setup uses to the previous versions of virtualenv and pip, and it appears to work fine.
Here's what you need to do:
* Update your counterpartyd_build code from git (e.g. "cd C:\counterpartyd_build && git pull origin master")
* Remove Python3.3.3 from your system (via Add/Remove Programs), along with all Python3.3.3 child dependencies listed in the add/remove programs list with it (pywin32, cg_freeze ..remove them before removing Python itself)
* Manually delete the C:\Python3.3 directory (make sure it doesn't exist anymore)
* Reinstall Python3.3.3 and related packages (just follow the instructions again)
* Try to rerun the setup.py script as normal
I just rebuilt using these instructions under Win7 64-bit and it worked fine. Let me know if you have any more issues.
January 04, 2014, 12:31:48 PM
Very interesting concept. I have some questions:
1. If the bitcoin blockchain is used as transport layer then how many confirmations are needed for a counterparty protocol message to be "visible" to other peers in the counterparty network? Do I understant correctly that if the default value of 6 confirmations is used then completing an order would take 2 hours on average (6 confirmations to issue an order and 6 confirmations for completed order to be seen in the network)? It's a quite long time, I think that it may be a limiting factor in your project.
2. Would it be possible to carry out auctions via counterparty protocol? If not, I suggest extending the order message to allow that (selling for the best price available at given time), in my opinion it would be a great functionality.
Good luck with your project.
1. If the bitcoin blockchain is used as transport layer then how many confirmations are needed for a counterparty protocol message to be "visible" to other peers in the counterparty network? Do I understant correctly that if the default value of 6 confirmations is used then completing an order would take 2 hours on average (6 confirmations to issue an order and 6 confirmations for completed order to be seen in the network)? It's a quite long time, I think that it may be a limiting factor in your project.
2. Would it be possible to carry out auctions via counterparty protocol? If not, I suggest extending the order message to allow that (selling for the best price available at given time), in my opinion it would be a great functionality.
Good luck with your project.
January 04, 2014, 11:42:08 AM
Quote
How is the price determined?
Quote
Right now, XCP are being rewarded to those that burn BTC at a price between 1500 XCP/BTC and 1000 XCP/BTC. The exact formula is:
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
Thank you PhantomPhreak. I would need both bitcoind and counterpartyd running? It sounds like there are plans to have intermediaries do the burning for people soon so they don't have to set this up?
That's right.
What is the end block number? Approximately.
The end block number is listed in the spec, in this section: https://github.com/PhantomPhreak/Counterparty#burn
January 04, 2014, 11:34:51 AM
Followed all the instructions but am getting an error when I run setup.py for the first time.
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
line 956, in install_wheel
'PIP_NO_INDEX': '1'
File "c:\python33\lib\site-packages\virtualenv-1.11-py3.3.egg\virtualenv.py",
line 898, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command c:\counterpartyd_build\env\Scripts\python.exe -c "import sys, p
ip; pip...ll\"] + sys.argv[1:])" setuptools pip failed with error code 1
2014-01-03 16:35:35,134|ERROR: Command failed: 'c:\python33\Scripts\virtualenv.e
xe --system-site-packages c:\counterpartyd_build\env'
What version of Windows? Also, can you please post the full traceback on pastebin.com and give me the link (or, you can file a bug report at https://github.com/xnova/counterpartyd_build/issues)
Actually, putting all of the output from the run of setup.py on pastebin.com would be most helpful.
Here is the pastebin with my full command prompt. I followed the instructions to the letter from http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html
Windows 7 64 bit
http://pastebin.com/iSTJ1uNk
Also why its checked version of my linux, why only Ubuntu ?
January 04, 2014, 11:32:12 AM
Quote
How is the price determined?
Quote
Right now, XCP are being rewarded to those that burn BTC at a price between 1500 XCP/BTC and 1000 XCP/BTC. The exact formula is:
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
Thank you PhantomPhreak. I would need both bitcoind and counterpartyd running? It sounds like there are plans to have intermediaries do the burning for people soon so they don't have to set this up?
That's right.
What is the end block number? Approximately.
January 04, 2014, 11:11:48 AM
Some help anyone?
We are implementing a change that will address this issue of burns currently not working, and make them a lot easier to do. The change will be complete and we will have an announcement within 2 hours from this point with the full details. Thanks everyone for your patience.
January 04, 2014, 11:07:15 AM
Quote
How is the price determined?
Quote
Right now, XCP are being rewarded to those that burn BTC at a price between 1500 XCP/BTC and 1000 XCP/BTC. The exact formula is:
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
Thank you PhantomPhreak. I would need both bitcoind and counterpartyd running? It sounds like there are plans to have intermediaries do the burning for people soon so they don't have to set this up?
That's right.
January 04, 2014, 11:05:31 AM
Some help anyone?
January 04, 2014, 10:27:03 AM
Running ./counterpartyd.py server
I get.
Traceback (most recent call last):
File "./counterpartyd.py", line 405, in
util.bitcoind_check(db)
File "/home/X/counterpartyd/lib/util.py", line 18, in bitcoind_check
block_count = bitcoin.rpc('getblockcount', [])
File "/home/X/counterpartyd/lib/bitcoin.py", line 36, in rpc
response = requests.post(config.RPC, data=json.dumps(payload), headers=headers)
File "/usr/lib/python3/dist-packages/requests/api.py", line 85, in post
return request('post', url, data=data, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 40, in request
return s.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 229, in request
r.send(prefetch=prefetch)
File "/usr/lib/python3/dist-packages/requests/models.py", line 468, in send
url = self.full_url
File "/usr/lib/python3/dist-packages/requests/models.py", line 382, in full_url
netloc = netloc.encode('idna').decode('utf-8')
File "/usr/lib/python3.2/encodings/idna.py", line 167, in encode
result.extend(ToASCII(label))
File "/usr/lib/python3.2/encodings/idna.py", line 73, in ToASCII
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long
Any ideas?
I get.
Traceback (most recent call last):
File "./counterpartyd.py", line 405, in
util.bitcoind_check(db)
File "/home/X/counterpartyd/lib/util.py", line 18, in bitcoind_check
block_count = bitcoin.rpc('getblockcount', [])
File "/home/X/counterpartyd/lib/bitcoin.py", line 36, in rpc
response = requests.post(config.RPC, data=json.dumps(payload), headers=headers)
File "/usr/lib/python3/dist-packages/requests/api.py", line 85, in post
return request('post', url, data=data, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 40, in request
return s.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 229, in request
r.send(prefetch=prefetch)
File "/usr/lib/python3/dist-packages/requests/models.py", line 468, in send
url = self.full_url
File "/usr/lib/python3/dist-packages/requests/models.py", line 382, in full_url
netloc = netloc.encode('idna').decode('utf-8')
File "/usr/lib/python3.2/encodings/idna.py", line 167, in encode
result.extend(ToASCII(label))
File "/usr/lib/python3.2/encodings/idna.py", line 73, in ToASCII
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long
Any ideas?
January 04, 2014, 10:24:31 AM
Umm... I can get counterpartyd running myself, no problem.
However, your posts have confused me.
I have bitcoind running, as you previously specified.
Can you please summarise what is the current procedure for burring BTC to get XCP on the main net?
Thanks!
Oh, I misunderstood. The instructions are in the second post in this thread. Are they not clear enough?
They are OK. I thought you had changed things in subsequent posts (e.g., with new destruction address 1CounterpartyXXXXXXXXXXXXXXXUWLpVr).
If you could, a repost or update consolidating everything would be very helpful.
Thanks!
January 04, 2014, 10:18:58 AM
Important update: Now you can use any Bitcoin client to burn BTC for XCP. Just send BTC to the unspendable addresses '1CounterpartyXXXXXXXXXXXXXXXUWLpVr' (mainnet) and 'mvCounterpartyXXXXXXXXXXXXXXW24Hef' (testnet). Be careful not to try to burn more than 1 BTC per address. If you do, your last attempted burn will be completely invalid.
Hi PhantonPhreak
Can you clarify on the above? Do you mean that "counterpartyd.py" will now work with any Bitcoin client or are you saying that we can just send coins to the exodus address '1CounterpartyXXXXXXXXXXXXXXXUWLpVr' from a client that we have control for?
Cheers
The latter.
So,
Do we need to make sure the coins are sent from a single address still?
Also, do we need
txindex=1
server=1
Anymore?
Can I burn from the MultiBit bitcoin client?
Thanks.
I've disabled that feature for now, as it opens up a whole can of worms. (How can Bitcoind still not have coin control?!)
EDIT: Seriously, though, sorry for the mixed messages. I was being overeager.
Neat. I only saw one transaction that was directly sent to the exodus address from a non CounterParty client
Wondering if there were any updates on the build issues on windows? Has anyone successfully build the counterparty client on windows?
Cheers
January 04, 2014, 10:17:56 AM
Just woke up...wanted to test if the burn is going through now...After rebuilding counterpartyd, the burn still fails with this message,
I assume this is still being worked on?
Didnt mean to hurry u guys...just want to make sure I can get going as soon as the update is working. Thx for being so responsive...I'm already beginning to like this team
Quote
Burn did *not* appear to be successful. Full output from Eligius:
Eligius - Push Transaction
false
Trying to send...
array(3) {
["result"]=>
NULL
["error"]=>
array(2) {
["code"]=>
int(-22)
["message"]=>
string(11) "TX rejected"
}
["id"]=>
string(1) "1"
}
Response = 0
false
I assume this is still being worked on?
Didnt mean to hurry u guys...just want to make sure I can get going as soon as the update is working. Thx for being so responsive...I'm already beginning to like this team
Yes, we're aware of this issue and working on it.
January 04, 2014, 10:17:35 AM
So only qt in windows, right?
Too bad cause i dont have space for the whole blockchain.
Would be greatly appreciated if you provided us another option, before minimizing the reward.
Thanks
Too bad cause i dont have space for the whole blockchain.
Would be greatly appreciated if you provided us another option, before minimizing the reward.
Thanks
You shouldn't actually need to download a complete copy of the blockchain in order to burn. You should be able to pass counterpartyd the flag --force and, as long as Bitcoind is running with the correct options, it will ignore the fact that it hasn't caught up with the network yet.
That's great news!
January 04, 2014, 10:15:54 AM
Quote
How is the price determined?
Quote
Right now, XCP are being rewarded to those that burn BTC at a price between 1500 XCP/BTC and 1000 XCP/BTC. The exact formula is:
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
XCP_EARNED = BTC_BURNED * (1000 * (1 + .5 * ((END_BLOCK - CURRENT_BLOCK) / (END_BLOCK - START_BLOCK))
Thank you PhantomPhreak. I would need both bitcoind and counterpartyd running? It sounds like there are plans to have intermediaries do the burning for people soon so they don't have to set this up?
Jump to: