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

[SyRenity]

Devs, I just found a nice QA plan for MSC:
https://github.com/marv-engine/QA

Perhaps we can fork and adapt it for XCP testing needs, so community could submit bug reports in proper manner?

[panonym]

I usually don't get answers here, but well, let's keep trying

Does anybody else have this problem? This happens everytime I try do build the database. I even can't surf for a few seconds, while this happens. Anybody got an idea what could be causing this? I only have this problem while running counterparty. I use bitcoin-qt.

Code:

Block: 278461
Block: 278462
Block: 278463
Block: 278464
Block: 278465
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Block: 278466

It doesn't appear to be a big deal.
My guess is that it is linked with your Internet connection (low probability, over using bittorrent?) or your hardware (stronger probability).
May be something else, I'm no expert.
I don't get this message, but I get the same effect once in a while.
I guess pretty much at each block, I get 5~30sec unavailable.
Result is that sometimes counterpartyd tell me bitcoind is behind (while it run 24h/24), 2 min max after it's okay.
I have only 2GB ram and cheap hardware.

[panonym]

- if asset == 'BTC': raise exceptions.BalanceError('Cannot send bitcoins.')
  it's such a pity, can't you modify it to be able to send (only) BTC from a selected pubkey?
  bitcoind miss this basic feature, which is annoying
  Beside, *it is possible* to send BTC trough counterprotocold, as send-cmd sent 0.0001086 BTC

I'm strongly considering adding this feature.

Correct me if I'm wrong:
If you add this feature, as a bonus btcpay would not be needed anymore.
Therefore fastening exchange between BTC and XCP/assets (and lowering the total fee).
That would be great.

[xnova]

I usually don't get answers here, but well, let's keep trying

Does anybody else have this problem? This happens everytime I try do build the database. I even can't surf for a few seconds, while this happens. Anybody got an idea what could be causing this? I only have this problem while running counterparty. I use bitcoin-qt.

Code:

Block: 278461
Block: 278462
Block: 278463
Block: 278464
Block: 278465
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Block: 278466
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 1/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 2/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 0/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 1/12)
Could not connect to Bitcoind. Sleeping for five seconds. (Try 2/12)
Block: 278467
Block: 278468
Block: 278469
Block: 278470
Block: 278471

As far as I can tell, bitcoind sometimes seems to have performance issues that cause it to putz out like this when there are a lot of RPC API calls being made against it (especially on a slower over overloaded machine). I committed a patch to counterpartyd that attempts to keep the HTTP connection open between RPC calls. This may help.

[PhantomPhreak]

- if asset == 'BTC': raise exceptions.BalanceError('Cannot send bitcoins.')
  it's such a pity, can't you modify it to be able to send (only) BTC from a selected pubkey?
  bitcoind miss this basic feature, which is annoying
  Beside, *it is possible* to send BTC trough counterprotocold, as send-cmd sent 0.0001086 BTC

I'm strongly considering adding this feature.

Correct me if I'm wrong:
If you add this feature, as a bonus btcpay would not be needed anymore.
Therefore fastening exchange between BTC and XCP/assets (and lowering the total fee).
That would be great.

The 'btcpay' message type needs to have data attached to it, so that it cannot be confused with regular BTC payments.

[qwertyasdfgh]

Sorry if this question was already answered but I was wondering. Is there a command of some sort to check your total balance of XCP in linux or window command prompt?

[OOO]

I burned via blockchain.info wallet a few days ago and can see that it has been recorded in the blockscan. It has registered XCP against it.

I understand the Private Keys need to be imported from the blockchain.info wallet into BitcoinQT and then we need to use CounterPartyd to send XCP to the Bitcoin address.

Is that correct?

[maxmint]

Sorry if this question was already answered but I was wondering. Is there a command of some sort to check your total balance of XCP in linux or window command prompt?

If you are running counterpartyd installed, just use this:

Code:

./counterpartyd wallet

This will show all XCP as well as all other assets in your wallet.

[panonym]

The 'btcpay' message type needs to have data attached to it, so that it cannot be confused with regular BTC payments.

Yup, send BTC or using btcpay have different function.
I didn't test btcpay.
But from what I understand, it's only purpose is to actually transfer BTC when an order has matched.
XCP for BTC for example.
When the order match, you have x blocktime to use btcpay with data attached to it (the Matched Order ID).

My point/wonder was:
If send-cmd did allow to directly send BTC,
then maybe btcpay-cmd (could) become useless / no longer required.
For as soon as the both order matched, the transfer of BTC could be instant (and not anymore require manual transfer of BTC with btcpay).

XCP/asset fund transfer is instant at match.
XCP/BTC or asset/BTC should be too, for a convenient/fast/quality decentralized exchange.

Could this be improved?
(ex. keep using btcpay (if still required) but in hidden background, all automatic)

[maxmint]

Are there any restrictions (besides having more than 3 letters) when creating assets?

Also, I think there should be a significant fee for asset issuances, otherwise we'll get spammed with "parked" assets from people who just want to reserve nice names.

[PhantomPhreak]

Devs, I just found a nice QA plan for MSC:
https://github.com/marv-engine/QA

Perhaps we can fork and adapt it for XCP testing needs, so community could submit bug reports in proper manner?

I'd like to hear what xnova has to say about this, especially with regard to any potential insufficiency in the current unit test suite.

[jimhsu]

Who exactly owns asset DOGE? I seem to duking it out with someone who issued later, but in a proper amount. Ownership has changed hands 3-4 times already with different counterpartyd versions.

And is it just me or can no asset start with the letter "A"?

... you're going to need a bigger list. Lol.

[xnova]

Devs, I just found a nice QA plan for MSC:
https://github.com/marv-engine/QA

Perhaps we can fork and adapt it for XCP testing needs, so community could submit bug reports in proper manner?

I'd like to hear what xnova has to say about this, especially with regard to any potential insufficiency in the current unit test suite.

counterpartyd does have some unit tests, however as PhantomPhreak alluded to, the coverage definitely isn't fully there. In any case, human exploratory QA is always a big plus with ferreting out problems. I think having QA test procedures make sense, if there are members of the community that are willing to do QA.

SyRenity (or anyone else who may be interested), feel free to fork off the QA docs and put together some for counterpartyd. I'd be happy to include them within the main docs, or we can have a separate site for them (either works). It would basically be documentation with how to get the environment up and running for QA (which could mostly just refer to the existing build system documentation), as well as QA testing/bug submission procedures (i.e. file any bugs in github), and possibly the start of a manual test plan (or we can just leave it to be ad-hoc testing, since most all fixed tests we should be able to implement in an automated function).

I can see manual QA testing being particularly valuable with the build system (i.e. someone to keep up a VM of each supported platform, and test any new releases against that platform to make sure they build correctly).

Also, we would also be happy to accept any code enhancements to the existing automated tests -- ESPECIALLY around making API calls. Anyone possibly interested in this should contact PhantomPhreak or I.

QA isn't the sexiest thing out there, but it's needed, especially for financial software like Counterparty.

EDIT: If you do fork, please fork from the original Bitcoin version of the test plans that Gavin made, as the Mastercoin fork is pretty much identical (or different in non-applicable ways) and I don't see the value in forking from that.

[PhantomPhreak]

Who exactly owns asset DOGE? I seem to duking it out with someone who issued later, but in a proper amount. Ownership has changed hands 3-4 times already with different counterpartyd versions.

And is it just me or can no asset start with the letter "A"?

... you're going to need a bigger list. Lol.

I'm working an changing the asset name to asset id encoding scheme right now, to make it more intuitive (but in a not backwards-compatible way).

EDIT: In the current scheme, 'A' is zero, and decimal numbers, too, cannot start with a zero. (Asset names are Base 26-encoded integers, for compression.)

[PhantomPhreak]

Also, I think there should be a significant fee for asset issuances, otherwise we'll get spammed with "parked" assets from people who just want to reserve nice names.

The problem with having fees for asset issuances is finding a way to keep them floating. Any fixed fee we would pick now would be too high, and then too low, if Counterparty scales as I hope it does.  If anyone has a suggestion for a fee schedule that will scale well, I'd love to hear it.

The current system does allow for the transference of asset ownership, so valuable names may indeed be sold for their market value when appropriate.

[jimhsu]

Also, I think there should be a significant fee for asset issuances, otherwise we'll get spammed with "parked" assets from people who just want to reserve nice names.

The problem with having fees for asset issuances is finding a way to keep them floating. Any fixed fee we would pick now would be too high, and then too low, if Counterparty scales as I hope it does.  If anyone has a suggestion for a fee schedule that will scale well, I'd love to hear it.

The current system does allow for the transference of asset ownership, so valuable names may indeed be sold for their market value when appropriate.

I really don't think any "fee" structure (BTC or XCP) is in the spirit of XCP. So...

Could a "proof-of-stake" method work?

Pseudo-code proposal:
1. Each "address" that wants to issue an asset can call an issuance command to create a "local" asset (just like right now, except that others can't view this asset). All existing assets are converted to local assets (not sure how to handle this for assets that have already been distributed, such as TEST)
2. Add in "global" as a property for an asset. A "global" asset is one that is visible to the network at large (orders, send, etc work). A local asset is one that exists only in a local instance of counterpartyd (the user's computer).
3. To "globalize" an asset, for each block a proof-of-stake calculation is run for addresses controlled by a running instance of counterpartyd (against some random function derived from BTC block hash, for instance). A "globalize" command can be called by the user to denote the asset to "submit" to the PoS function. (I'm no good at the maths, so looking to existing PoS implementations to figure out how to do this). If no asset is selected to globalize, the client automatically chooses the "first" one (in lexicographical order, for instance).
4. If successful, the asset and details are published to the network at large, and other commands (orders, sending, viewing asset on other counterpartyd clients) works.
5. In case that two local assets from two different users are submitted to "globalize", the "winning" one is the one that "mines" the PoS block first.

Things to figure out:
1. Should counterpartyd clients that aren't actively "globalizing" an asset / or don't have a valid asset to globalize try to mine PoS blocks? If so, what should they do?
2. What happens to existing assets? (see 1)
3. What is the PoS function?
4. What is the target asset "creation rate"? What is the retargeting?
5. Can users elect to globalize assets other than their own? This can lead to some very interesting possibilities, such as an "XCP pool" that votes on worthy projects to "IPO", so to speak.

Summary: Proof-of-stake does not have to translate into inflation of the base currency. It can be used for "other" purposes as well (in the spirit of DACs).

[SyRenity]

Just a quick idea, what if any fees paid for new assets allocations, will be donated to the developers of XCP?

Thus both limit the spammers, and motivate the developers pushing the technology further, potentially doing it as full-time work.

My two mXCP .

[SyRenity]

3. To "globalize" an asset, for each block a proof-of-stake calculation is run for addresses controlled by a running instance of counterpartyd (against some random function derived from BTC block hash, for instance). A "globalize" command can be called by the user to denote the asset to "submit" to the PoS function. (I'm no good at the maths, so looking to existing PoS implementations to figure out how to do this). If no asset is selected to globalize, the client automatically chooses the "first" one (in lexicographical order, for instance).

The whole idea is good, though this might imho cause that an asset lower in priority, will be never globalized. We need to think of some way to compensate for that.

[jimhsu]

3. To "globalize" an asset, for each block a proof-of-stake calculation is run for addresses controlled by a running instance of counterpartyd (against some random function derived from BTC block hash, for instance). A "globalize" command can be called by the user to denote the asset to "submit" to the PoS function. (I'm no good at the maths, so looking to existing PoS implementations to figure out how to do this). If no asset is selected to globalize, the client automatically chooses the "first" one (in lexicographical order, for instance).

The whole idea is good, though this might imho cause that an asset lower in priority, will be never globalized. We need to think of some way to compensate for that.

As I mentioned, allowing users to "pool" their "asset-globalizing" power to support projects that otherwise wouldn't hit the markets. Not in the NXT sense of "send all your money to me so I can mine PoS blocks", but something that better fits the "trust, but be trustless" model of XCP. And without requiring a centralized pool.

Suggestion: now would be an opportune time to get that 'dev' branch of the github set up to test ideas such as these. Alterations to assets are definitely not ready for prime-time yet.

[Luckybit]

About the future value of XCP: could you just realize that nobody has a clue, please.
Anybody saying that he know is just trolling. Up or Down, same same.

Indeed an instant x100 is very unlikely.
We may even suffer a relative lost during the first week/month after-burn.
Yet MSC is valued at 60 million.
XCP despite it's alpha-stage and few bug has already more presently working functionality than it's concurrent.

Both may succeed, both may crash, one may succeed better than the other.
But if MSC is valued at 60 millions, theoretically there is nothing preventing XCP to reach 30/60/120 millions.

Just don't expect such valuation too fast.
It could happen in 4~6 month, it could happen in 1 month, or it could never happen.
Just as BTC itself could lose most of it's value if a really amazing innovation appear in 6 month.

I personally plan to hold my XCP a few month, and will not sell them at loses.
If I must way 6 month for that, then 6 month it will be.
Middle term I hope a very nice ROI, but it's gambling.

Are we done?
If a troller come trying to lower XCP credibility without quality argument, just ignore him.
Don't feed the troll.
Everyone can think for him/herself.
If you guys can't resist talking about that, open a dedicated topic for speculation.
Most here are not interested in the "tiny war" between metacoin.
Let's keep focusing on XCP testing and improvement in all field.

Obvious reminder:
Don't invest more than you can afford to lose.

Hope everyone who have invest to making fast money have also remember make small donations for XCP project...

Developers: PhantomPhreak, xnova (Bitcointalk usernames)
BTC and XCP donations: 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs

If donate to quoted post, remember look address is right from first orginal post

This is the best advice you can give someone to secure thier investment. If you're the type of person who can sink 10+ BTC into this project you should be willing to give a few BTC to allow development to speed up, otherwise you might not get the x100 gains you're hoping for.

Also, I think there should be a significant fee for asset issuances, otherwise we'll get spammed with "parked" assets from people who just want to reserve nice names.

The problem with having fees for asset issuances is finding a way to keep them floating. Any fixed fee we would pick now would be too high, and then too low, if Counterparty scales as I hope it does.  If anyone has a suggestion for a fee schedule that will scale well, I'd love to hear it.

The current system does allow for the transference of asset ownership, so valuable names may indeed be sold for their market value when appropriate.

If we use a fee then you have to do some really trivial up front fee and then have a renewal fee after the expiration date which is a bit larger than the up front fee. If there are no fees at all you will have spam and hoarding. If there is no expiration date at all you end up with the same problems. We will have to find a creative solution.

If the asset is valuable at all then they should have the means to pay the fee. Honestly though this is a difficult problem and I see no way around it. There must be a fee to assign value to any object. So if a name is of value then it must have a cost associated to reflect it's value. Anything in the system must have a way of assigning value to it so how exactly else would you do it if not by a fee?