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

[konfet]

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'

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

got the same error.
Also why its checked version of my linux, why only Ubuntu  ?

[1713956882]

1713956882

[1713956882]

1713956882

[xnova]

How is the price determined?

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

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

[phm]

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.

[xnova]

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'

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.

[PhantomPhreak]

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

[xibeijan]

Do you have a working version of counterpart yet?

[PhantomPhreak]

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:

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

[xibeijan]

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:

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

[mtbitcoin]

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'

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

[PhantomPhreak]

Do you have a working version of counterpart yet?

Yes.

[panonym]

Okay
A little of turbulence.

I'm not convince I like this last change announcement.
When things are say to be done like that-way from tx to ty, I like it to stay that way.

Main problem I see is that before: a fully working counterpartyd was available for testing.
Now only the burning...
Meaning I have to trust you for the working of the descentralized exchange.
Also might mean that I cannot transfer my XCP, does send still work?
Very bad if ONLY burn work...

How comes that Eligius was the only pool to treat OP_RETURN?
Do you have any influence there? contact?
This suddent change make me uncomfortable with your project.
Also, is it 100% sure OP_RETURN will be in the v0.9?
For my research it appear to be likely, but 100% sure?

Please try to solve the situation with Eligius.
Need the ability to test.


edit: WORST: if this problem with Eligius happen globally after v0.9 is out, your project is dead, burned coin lost... Knowing what went/is going wrong with Eligius is very important.

[PhantomPhreak]

Okay
A little of turbulence.

I'm not convince I like this last change announcement.
When things are say to be done like that-way from tx to ty, I like it to stay that way.

Main problem I see is that before: a fully working counterpartyd was available for testing.
Now only the burning...
Meaning I have to trust you for the working of the descentralized exchange.
Also might mean that I cannot transfer my XCP, does send still work?
Very bad if ONLY burn work...

How comes that Eligius was the only pool to treat OP_RETURN?
Do you have any influence there? contact?
This suddent change make me uncomfortable with your project.
Also, is it 100% sure OP_RETURN will be in the v0.9?
For my research it appear to be likely, but 100% sure?

Please try to solve the situation with Eligius.
Need the ability to test.

You can still use all of Counterparty's functions on testnet. It's just that right now no one is mining transactions with OP_RETURN on mainnet.

We are trying to talk to the operator of Eligius and find out what changed. It's possible that he just updated the version of Bitcoind that he was running and hasn't yet patched it again. His PHP form, which was working for me for a whole month, just suddenly started rejecting our transactions. Eligius does a few things that other pools don't do, for example rate-limiting address reuse.

We are as sure as we could possibly be that OP_RETURN will be in 0.9. See Gavin's announcement. Furthermore, I recently contacted Gavin myself, mentioned that we were going to be using OP_RETURN and asked when he thought that 0.9 would be released: there should be a release candidate out in only a couple of weeks (TM).

[panonym]

'losing money today, and having problem with my laptop *laugh
Yesterday was better.

Joke appart, how is it that it works on testnet?
Everyone testing with pre-v0.9?
(I never used a testnet, is there a whole blockchain-to-DL-again only for it?)

[PhantomPhreak]

Any ideas as to what would this imply?


----
C:\counterpartyd_build\dist\counterpartyd>counterpartyd.py --rpc-user=rpc --rpc-password=XXXXXX  -
v market
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 407, in <module>
    util.database_check(db)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 36, in database_check
    raise exceptions.DatabaseError('Countparty database is behind Bitcoind.')
lib.exceptions.DatabaseError: Countparty database is behind Bitcoind.

Are you running counterpartyd server in the background? (I just changed the error message to ask that question itself.)  What block is it on?

[PhantomPhreak]

'losing money today, and having problem with my laptop *laugh
Yesterday was better.

Joke appart, how is it that it works on testnet?
Everyone testing with pre-v0.9?
(I never used a testnet, is there a whole blockchain-to-DL-again only for it?)

testnet just accepts non-standard transactions. (Any transaction with an OP_RETURN output is, before 0.9, non-standard.) There's a separate blockchain, but it's only about 500 MB.

[mtbitcoin]

Any ideas as to what would this imply?


----
C:\counterpartyd_build\dist\counterpartyd>counterpartyd.py --rpc-user=rpc --rpc-password=XXXXXX  -
v market
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 407, in <module>
    util.database_check(db)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 36, in database_check
    raise exceptions.DatabaseError('Countparty database is behind Bitcoind.')
lib.exceptions.DatabaseError: Countparty database is behind Bitcoind.

Are you running counterpartyd server in the background? (I just changed the error message to ask that question itself.)  What block is it on?

Yup. Fixed this. Thanks. I can confirm that the windows installation is indeed working


Regarding the burn process. Can we burn on behalf of another address not within our control (which we don't own the private keys). Lets say I want to burn BTC for XCP on behalf of a friend, can I just use his BTC address as the source in the "from" command line?

[panonym]

Luckily not.
Otherwise you could burn the coin of everyone you wish 

[mtbitcoin]

Luckily not.
Otherwise you could burn the coin of everyone you wish  

Yeah. Makes sense now.. Wasn't thinking straight just now  

So to a burn for a 3rd party one would need to burn the coins for Xcp and transfer the Xcp over to the btc address?

[reader31]

I was able to burn btc sucessfully...The transactions are on the blockchain.

1)
How many confirmations should I wait for before the xcp shows up in my balance?

2)
whats the command to check the total number of xcp I have?


I'm invested. So very excited to support this project

[PhantomPhreak]

I was able to burn btc sucessfully...The transactions are on the blockchain.

1)
How many confirmations should I wait for before the xcp shows up in my balance?

2)
whats the command to check the total number of xcp I have?


I'm invested. So very excited to support this project

Congratulations!

1) One confirmation. (That is, it just has to be in the blockchain.)

2) counterpartyd address ADDRESS