Simply transferring XCP, for example, does not incur an XCP fee.
How is this possible, if the XCP transactions need to be written into the bitcoin block chain? Still wondering how this is possible. Thx. Why would you need an XCP fee to put data in a Bitcoin transaction? order --from=mtQheFaSfWELRB2MyMBaiWjdDm6ux9Ezns --get-quantity=10 --get-asset=BTC --give-quantity=20 --give-asset=XCP --expiration=10 --fee_provided=.001 Buy BBBC for BTC
order --from=mtQheFaSfWELRB2MyMBaiWjdDm6ux9Ezns --get-quantity=10 --get-asset=BBBC --give-quantity=20 --give-asset=BTC --expiration=10 --fee_required.001 Buy XCP for BBBC
order --from=mtQheFaSfWELRB2MyMBaiWjdDm6ux9Ezns --get-quantity=10 --get-asset=XCP --give-quantity=20 --give-asset=BBBC --expiration=10
Why does first have --fee_provided, second have --fee_required and third have no fee?
Again, all fees are in XCP?
How does this actually get recorded into BTC blockchain without BTC fee?
For now I'll refer you to the documentation for the answer to that question. I am running into issues too .. Could the documentation be incorrect? The github docs state
•Buy BTC for XCP order --from=mtQheFaSfWELRB2MyMBaiWjdDm6ux9Ezns --get-quantity=10 --get-asset=BTC --give-quantity=20 --give-asset=XCP --expiration=10 --fee_provided=.001
However when attempting to do a buy using the format above the following exception is thrown : File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 426, in <module> raise exceptions.FeeError('When buying BTC, do not specify a fee provided.') lib.exceptions.FeeError: When buying BTC, do not specify a fee provided.
|
|
|
Did a test transaction (but not confirmed yet). Can anyone confirm that this works?
e73ef35f4ddda1ae30c5a7dbdec120f98008c92586880b8a32339682c3c78689
Meanwhile downloading the bitcoin blockchain will take a while...
You look good to go ------------------------- Balances +-------+---------+ | Asset | Amount | +-------+---------+ | XCP | 14.3325 | +-------+---------+
|
|
|
How many XCP will exist? how are they mined/released after the first month?
Number of XCP that will exists depends on the number of BTC burned for XCP during the burned period. No additional XCP will be "mined" after the burn-in period. The maximum circulation of XCP after the burn in period = number of XCP created during the burn-in period Cheers
|
|
|
Looking through the posts .. it looks like quite a number of viewers here are only interested in speculating on XCP with little to no inclination as to how the protocol/client actually works. Well I guess seeing that this is the "Alternate currencies" subforum it is to be expected At the moment in order to burn XCP you will effectively need to have full control of the address (private key). Yet, many are willing to place this trust with a 3rd party to burn BTC for XCP on behalf of them ..... And without the ability to send the coins to another address this would mean someone else would have control of your coins for an unforeseeable time (seeing that the latest statment from eligius is that they are not going to process the txns) -imho-
|
|
|
Actual problem is that you will not be able to send those XCP anywhere. Because for this to work on the mainnet, Eligius need to process your transaction. Which it stopped.
counterpartyd address ADDRESS So that at least is still working, with burn. (I have to test by myself instead of asking the question... But I'm curious and soft/hardware troube prevent me to test right now.) Can I check the amount of XCP in any address with this command? Including not mine.
Yes, you can Since everything is on the blockchain Example output: Balances +-------+---------------+ | Asset | Amount | +-------+---------------+ | XCP | 1479.70063636 | +-------+---------------+
|
|
|
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?
|
|
|
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?
|
|
|
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.htmlWindows 7 64 bit http://pastebin.com/iSTJ1uNkThank 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
|
|
|
Well. I admit this went horribly. And I can guarantee that I am not the one getting all the blocks. Not that it matters. I'll have to restart the coin, because I don't want one or two people owning such a big chunk. As far as I am concerned, the current blockchain is not official anymore. microCoin will be relaunched with a higher difficulty and possibly changed block rewards and POS. We deeply apologize for wasting your time. Hopefully you will still be interested when the coin is relaunched.
Thanks for clearing that up. Don't hurry, do it right Was that you Magnet ... mining up all the coins with your super rigs ? Lol, I have 4.5Mhash Lol.. Looking back the QQCoin launch was actually quite a smooth launch (relatively speaking) ...
|
|
|
Well. I admit this went horribly. And I can guarantee that I am not the one getting all the blocks. Not that it matters. I'll have to restart the coin, because I don't want one or two people owning such a big chunk. As far as I am concerned, the current blockchain is not official anymore. microCoin will be relaunched with a higher difficulty and possibly changed block rewards and POS. We deeply apologize for wasting your time. Hopefully you will still be interested when the coin is relaunched.
Thanks for clearing that up. Don't hurry, do it right Was that you Magnet ... mining up all the coins with your super rigs ?
|
|
|
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
|
|
|
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? If this applies to the bitcoin QT client, isn't it possible that the coins can come from multiple addresses and as the client lack "coin control"? Cheers
|
|
|
Selling 100 GIFT for 1 LTC (equivalent to 0.03x btc). Cheap, cheap ... While stocks last
|
|
|
I am running into the similiar issues on Windows (64bit)
"...Installing setuptools, pip...done. Traceback (most recent call last): File "C:\Python33\Scripts\virtualenv-script.py", line 9, in <module> load_entry_point('virtualenv==1.11', 'console_scripts', 'virtualenv')()"
Has anyone actually got this to run correctly on a windows box?
Cheers
If this helps... Would this have anything to do with an incorrect install of configParser. This was the only module that I was unable to correctly install on windoze box '---- Traceback (most recent call last): File "C:\Install\configparser-3.3.0r2\setup.py", line 12, in <module> from setuptools import setup, find_packages File "<frozen importlib._bootstrap>", line 1565, in _find_and_load File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked File "C:\Python33\lib\site-packages\setuptools-1.4.1-py3.3.egg\setuptools\__init__.py", line 5, i <module> File "C:\Python33\lib\distutils\core.py", line 19, in <module> from distutils.config import PyPIRCCommand File "C:\Python33\lib\distutils\config.py", line 7, in <module> from configparser import ConfigParser File "C:\Install\configparser-3.3.0r2\configparser.py", line 397 _KEYCRE = re.compile(ur"%\(([^)]+)\)s") ^ SyntaxError: invalid syntax
|
|
|
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.htmlhttp://pastebin.com/iSTJ1uNkI am running into the similiar issues on Windows (64bit) "...Installing setuptools, pip...done. Traceback (most recent call last): File "C:\Python33\Scripts\virtualenv-script.py", line 9, in <module> load_entry_point('virtualenv==1.11', 'console_scripts', 'virtualenv')()" Has anyone actually got this to run correctly on a windows box? Cheers
|
|
|
Agreed. Nice community. Reminds me of JKC (back in the ole days)
|
|
|
Edit, he just gained access to my miner again. Cell phone screen shot of the hacker's pool Do you have entire box firewalled? Or are there still specific ports open to the public. I've blocked of all incoming ports and so far so good
|
|
|
Just as a heads up .. I've had one these boxes compromised. I've now firewalled the entire box.
However, I suspect there is might a scheduled script to restart the miner in preconfigured intervals to point to a specific pool. Any ideas as to where I should be looking to see if there were any backdoors or schedule scripts/jobs?
Cheers
|
|
|
The difficulty has rocketed up since the listing on coinedup ...
|
|
|
i think solo is still possible if you have enough gpu power, i also have my cpu's running on it same time.
Solo is still doable for now.. but for mass market you will need a pool. Perhaps we can start a bounty for a p2pool with pledges
|
|
|
|