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

[xnova]

Assuming windows

Right click computer -> properties -> advanced system settings -> environmental variables -> highlight path and click edit

Add this to the end of whatever is in variable value         ;C:\Program Files (x86)\Git\cmd




Now, could someone please help me with my issue? I can't get counterpartyd to work

http://pastebin.com/ZzAJbrSW

I see you are trying to run it like:

Code:

c:\counterpartyd_build>C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py

If you installed with the counterpartyd_build system, then you have to run it like the build system docs say:

Code:

cd C:\counterpartyd_build
C:\Python33\python.exe run.py --log-file=-

or, for no logging to screen (log to log file instead):

Code:

cd C:\counterpartyd_build
C:\Python33\python.exe run.py

Reason for this, is that run.py runs counterpartyd in a dedicated Python virtualenv, which has all the python libraries at versions that are tested with counterpartyd.

[PhantomPhreak]

I guess what I am saying is that it would be nice if there was a listaddresses command, so that one could easily see which of my bitcoin addresses have counterparty assets associated with them.

Right now, the only way I know of to do that is to iterate one-by-one through all addresses in a given bitcoin wallet calling 'counterpartyd address' with each.

Otherwise, one must keep an external list of wallet addresses that hold counterpartyd funds.   This feels klunky.

I just added a new command wallet, which will list all of the addresses in your wallet that have a non-zero balance in BTC or any Counterparty asset, along with those values.

[PhantomPhreak]

I think I read burning BTC to get XCP was possible even if bitcoind wasn't sync?! is it? (edit: nope)

You actually can, with the --force flag.

[BldSwtTrs]

Assuming windows

Right click computer -> properties -> advanced system settings -> environmental variables -> highlight path and click edit

Add this to the end of whatever is in variable value         ;C:\Program Files (x86)\Git\cmd

Thanks, that's solved my problem.


Now I have an another problem. I don't understand how to modify the counterperty .conf file. What should I do to do that?

[wizkid057]

Destroying Bitcoins by using outputs that are not provably prunable harms Bitcoin by bloating the transaction index.

You people are absolutely crazy for destroying bitcoins in this fashion.

Please modify your protocol to not harm Bitcoin and I will happily mine your txns with Eligius.

-wk

[PhantomPhreak]

Destroying Bitcoins by using outputs that are not provably prunable harms Bitcoin by bloating the transaction index.

You people are absolutely crazy for destroying bitcoins in this fashion.

Please modify your protocol to not harm Bitcoin and I will happily mine your txns with Eligius.

-wk

How? We wanted to burn to miners' fees, but that's not secure.

Only the burns, which will be created for only one month, create unspendable txouts; none of the other message types (by design!). That's not a lot of transactions, and not a lot of unprunable data.

[xnova]

Added instructions on how to burn (using either counterpartyd, or blockchain.info):  http://counterpartyd-build.readthedocs.org/en/latest/HowToBurn.html

Please remember, when burning with a non counterpartyd method, you are doing so at your own risk. Please try with small transactions, before moving to larger ones.

[wizkid057]

Destroying Bitcoins by using outputs that are not provably prunable harms Bitcoin by bloating the transaction index.

You people are absolutely crazy for destroying bitcoins in this fashion.

Please modify your protocol to not harm Bitcoin and I will happily mine your txns with Eligius.

-wk

How? We wanted to burn to miners' fees, but that's not secure.

Only the burns, which will be created for only one month, create unspendable txouts; none of the other message types (by design!). That's not a lot of transactions, and not a lot of unprunable data.

Any unspendable output is bad for Bitcoin. They all add up.  Just because in your opinion it is "not a lot of unprunable data" doesn't make it any less harmful.

Since as the Eligius pool op I definitely don't care to utilize or abuse your service, I'd much rather work out a situation where the "burns" go to the pool fees.  Eligius automatically distributes fees to its miners, so, no way I could abuse this anyway, provided you only used Eligius.

-wk

[xnova]

A BETA installer is also released for 64-bit Windows. Please see http://counterpartyd-build.readthedocs.org/en/latest/UsingTheInstaller.html for more information. Bug reports welcome!

[xibeijan]

have you thought of doing it over Peercoin blockchain as BTC is so precious that it would be much sad to see it burnt ? Ppc inflates 1% on POS minting (although it also destroys 0.01 transaction fee), so the burnt coins will hopefully be regenerated and we can keep our XCP.

We have been exploring taking the concept of Counterparty out to additional blockchains. From a technical standpoint, Counterparty uses the OP_RETURN feature of Bitcoin to store its data (full support for which will be included in Bitcoin v0.9, which will most likely be out and deployed across the major mining pools in about a month to two based on Gavin's estimates).

The advantage of this is that it's a very clean way of encoding the data: Counterparty transactions can be easily pruned from the blockchain. The disadvantage is that any altcoin looking to implement Counterparty support would need to have this feature (or, fork and extend the Counterparty protocol to use a slightly different encoding method, such as multisig or something similar to Mastercoin's Class A transactions).

Currently, Peercoin is moving to 0.8.4 code I believe. Once SunnyKing syncs up to 0.9, this may be possible (however, there may still need to be some adjustment made to deal with the stake blocks that Peercoin has).

This all being said, we are interested in speaking to altcoin developers (and especially ones that can work with the OP_RETURN featureset) as this develops. Counterparty becomes stronger as its standards are deployed across multiple blockchains.

So, are you saying that, in the future, Counterparty could possibly link directly into different block chains enabling atomic trade of currencies from both chains, nearly natively?

For example, I could have a PC with bitcoind and ppcoind fire up and counterparty running and I can sell BTC for PPC and actually see PPC appear in my peercoin wallet and BTC disappear from my bitcoin wallet, natively?

If so, then this is amazing stuff!

P.S. Does Mastercoin support this?  Does Mastercoin use OP_RETURN?

[aTriz]

A BETA installer is also released for 64-bit Windows. Please see http://counterpartyd-build.readthedocs.org/en/latest/UsingTheInstaller.html for more information. Bug reports welcome!

link doesn't seem to be working (the download link)( https://raw.github.com/xnova/counterpartyd_binaries/counterpartyd-v1-amd64_install.exe )


*EDIT* Now working installing now!

[PhantomPhreak]

Any unspendable output is bad for Bitcoin. They all add up.  Just because in your opinion it is "not a lot of unprunable data" doesn't make it any less harmful.

Since as the Eligius pool op I definitely don't care to utilize or abuse your service, I'd much rather work out a situation where the "burns" go to the pool fees.  Eligius automatically distributes fees to its miners, so, no way I could abuse this anyway, provided you only used Eligius.

-wk

I appreciate your offer, but it's a very important feature of this protocol that it involves trusting no one at all. Is it provable beyond all doubt that you would have no control whatsoever over where the fees would go?

I agree that it's bad for bitcoin, but the size of the problem is proportional to the amount of data that can't be pruned. The harm done to the blockchain, in this case, is not much worse than that caused by someone losing the only copy of a private key to a heavily used personal address. And the benefits that this protocol brings to Bitcoin must also be taken into account.

[xnova]

have you thought of doing it over Peercoin blockchain as BTC is so precious that it would be much sad to see it burnt ? Ppc inflates 1% on POS minting (although it also destroys 0.01 transaction fee), so the burnt coins will hopefully be regenerated and we can keep our XCP.

We have been exploring taking the concept of Counterparty out to additional blockchains. From a technical standpoint, Counterparty uses the OP_RETURN feature of Bitcoin to store its data (full support for which will be included in Bitcoin v0.9, which will most likely be out and deployed across the major mining pools in about a month to two based on Gavin's estimates).

The advantage of this is that it's a very clean way of encoding the data: Counterparty transactions can be easily pruned from the blockchain. The disadvantage is that any altcoin looking to implement Counterparty support would need to have this feature (or, fork and extend the Counterparty protocol to use a slightly different encoding method, such as multisig or something similar to Mastercoin's Class A transactions).

Currently, Peercoin is moving to 0.8.4 code I believe. Once SunnyKing syncs up to 0.9, this may be possible (however, there may still need to be some adjustment made to deal with the stake blocks that Peercoin has).

This all being said, we are interested in speaking to altcoin developers (and especially ones that can work with the OP_RETURN featureset) as this develops. Counterparty becomes stronger as its standards are deployed across multiple blockchains.

So, are you saying that, in the future, Counterparty could possibly link directly into different block chains enabling atomic trade of currencies from both chains, nearly natively?

For example, I could have a PC with bitcoind and ppcoind fire up and counterparty running and I can sell BTC for PPC and actually see PPC appear in my peercoin wallet and BTC disappear from my bitcoin wallet, natively?

If so, then this is amazing stuff!

P.S. Does Mastercoin support this?  Does Mastercoin use OP_RETURN?

No, actually, my response was limited to talking about Peercoin implementing counterparty on its blockchain.

What you mentioned is not possible today, however, there are several parties (including Counterparty) discussing the feasibility of it.

Mastercoin will eventually support OP_RETURN as "Class C" transactions, but currently, AFAIK, there is no support for this.

[panonym]

Yup relax wizkid057.
It doesn't harm Bitcoin.
It's exactly the same as holding your coin forever, or losing your privkey.
If you see it for it's deflationary effect, it's actually a tiny up in the value of all the other BTC.
I see it as a good thing. Or neutral at worst.

Concerning the "unprunable data", I admit I do not understand this term.
What I understand is that it will last 1 month maximum.
And because the transaction are like dust (<1kB), we pay 10x the usual fee.

I absolutely refuse that my burning become a gift to the miner.
It's not their business, this money doesn't belong to them.
The value of the coin I burn is still mine. It's only abstractly transferred.

Beside, I - personally - do not want to depend on Eligius pool.
With bitcoind v0.9, OP_RETURN will be implemented, and so it's pretty much guarantee that at least many miner and a few pool will proceed these transactions.
That's my understanding at least. I do hope I'm correct about this...
Anyway we will pay the standard fee for any XCP or asset transaction.
(maybe 10x the strandard one... but I hope it's only for the burning)

it's a very important feature of this protocol that it involves trusting no one at all.

This!

there are several parties (including Counterparty) discussing the feasibility of it.

I do hope it will be possible one day

What would be awesome is to find an alternative solution to protect double spending.
Which would no longer require mining in the forms we know it today.
So we could have encrypted transaction (++anonymity).
And the possibility of descentralized exchange between all shacoin, scryptcoin, layer-protocol-assets.
No idea if that is technically possible.
But it would be a revolution in itself.

[xibeijan]

What you mentioned is not possible today, however, there are several parties (including Counterparty) discussing the feasibility of it.

May I ask... What specifically/technically is not possible right now, and why?

[xibeijan]

Counterparty Announcement

...
We are looking for community contributions of testing, bug reports, patches, and companion software (e.g. built around counterpartyd). We are also asking for donations of BTC and XCP to 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs, which funds will be used to issue bounties for the development of the project.

Sorry to see you've not received any contributions yet.  Your project looks great.  Keep up the great work.  I will be watching it closely.

I'd like to see an example or tutorial on how to setup a feed on the test net, just so I can play around with it and contribute some bug fixes.

[panonym]

DAFUQ ><
I tried:
sudo apt-get install bitcoin-qt
It worked, but it's in German...
Any link to compile bitcoin-qt from source, in English? I haven't found yet.

edit: this do the trick:

Code:

bitcoin-qt -lang=en_US

Or what is the command line in bitcoind/counterpartyd to list the address in my wallet?
(I guess I have to update counterpartyd for wallet to work)

[wizkid057]

Ah well, continue burning your coins on this ridiculousness.  I tried.

-wk

[LeoC]

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

[porqupine]

@PhantomPhreak - Very cool to see you got this project up and running.

I've got the client working on Windows. Although I did have to work around a number of install errors, I don't have logs, but I think they've been aforementioned.