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

[akann46]

Hi! Could anyone help me to point out a link or a tutorial how to send/receive XCP on windows?

Thank you!

The tutorial on my signature is very detailed.

It is not detailed to me. Do you have a tutorial for easy and fast way of using xcp?

The word detailed maybe not the one you meant ? It's extremely detailed, it literally holds your hand start to finish and explains every little thing. Or try this http://counterpartyd-build.readthedocs.org/en/latest/

Hi Halfcab, can you please help me with BoottleXCP conf file?

I used the JahPowerBit's sample conf file in https://forums.counterparty.co/index.php/topic,74.0.html except that I used my login credentials.

[BitcoinTangibleTrust]

I really don't think 5 XCP is a big price to a serious issuance now. the problem is just that it is burnt. However, even there will be 10k assets, 50k XCP is still a small part of 2.6M. Moreover, the fee can be reduced later when XCP appreciate a lot.

Please don't low the fee too much and otherwise there will be a lot of rubbish asset names.

I completely agree. BTT I think what you are doing is interesting but I don't understand why you need to issue assets with unique names. If someone wants to redeem a silver coin what difference does it make which one they send to you for redemption?

We issue asset with unique names for the following three reasons which may not be exhaustive, but should give you a view into why we are trying to grow:

1. Asset diversity is massively immense: Our business objective is to digitize EVERY possible valuable hard asset in existence onto the Counterparty Protocol. As such, we need a very large name space because our owners of these assets number in the millions and their valuables are very unique. For example, there are thousands of types of silvercoins with different make, quality, size, and ownership histories. We use generic catalog names to make these assets easy to identify in our catalog and easy for our customers to discretely digitize and trade. We respect this diversity and don't aim to constrain it as we didn't create it ourselves.

2. Our customer holdings are infinitely diverse: We have many potential customers who want to issue 1 silvercoin, 100 silvercoins or even 5 GoldCoins + 100 Silvercoins. Valuable hard assets come in infintitely diverse holdings that we do not control. However, we do not aim to comingle customer physical assets into 1 asset issuance called SILVERBTT. That would devalue the uniqueness of their holdings and force them to issue these assets on their own. We want to ensure that all our customers believe that BTT will customize their digital assets as per their needs to maintain control and with as many degrees of freedom as they desire.

3. Counterparty is a Protocol: We see and want to use Counterparty as a protocol, like TCP/IP or HTML/SGML. Our objective is to build many digital asset applications and businesses on this protocol. We truly believe that millions of businesses can survive, but only if the protocol is neither too restrictive nor expensive in allowing companies to experiment, build, and eventually scale. Yes. If you are an XCP holder, you should be begging more companies to come and build on protocol by touting the lowest asset issuance fees, the fast and rapid dev team responsiveness and the amazing community here willing to give feedback and help.

If our protocol is not attractive to build an experiment, people will simply find other protocols or fork their own protocols to achieve their business objectives. Ripple, Mastercoin, Bitshares, NXT, Ethereum, and many other protocols yet to launch will gladly accept the companies we discourage because of our fears.

I hope this helps?
BitcoinTangibleTrust

[kdrop22]

For example, there are thousands of types of silvercoins with different make, quality, size, and ownership histories. We use generic catalog names to make these assets easy to identify in our catalog and easy for our customers to discretely digitize and trade. We respect this diversity and don't aim to constrain it as we didn't create it ourselves.

It makes sense now.

[BitcoinTangibleTrust]

For example, there are thousands of types of silvercoins with different make, quality, size, and ownership histories. We use generic catalog names to make these assets easy to identify in our catalog and easy for our customers to discretely digitize and trade. We respect this diversity and don't aim to constrain it as we didn't create it ourselves.

It makes sense now.

+1

We would like to digitize you on the Counterparty Protocol kdrop22...if you're ermm..amenable to having us put you into custody! </GRIN>

[halfcab123]

Hypothetically speaking; What is the value proposition for xcp, if counterparty required very little if any xcp to issue assets?

[halfcab123]

Hypothetically speaking; What is the value proposition for xcp, if counterparty required very little if any xcp to issue assets?

      I think probably the most humorous thing thats happened for me personally since I've gotten involved with XCP, is that as bad as I've wanted the web wallet to come out, I no longer care for it for my own personal use. Having been forced by necessity to use the CLI, I'm quite content with using it without a GUI. It's funny how sometimes a GUI can actually complicate things that would otherwise be much simpler just understanding a few commands.

       I do realize however, that for XCP/Counterparty to gain wide accepted use we will need a user-friendly GUI, much like basic TCP/IP protocol applications were not widely used or built upon until web browsers and email browsers amongst other User Interfaces came about which allowed the average user to take part; and when the average user gets involved thats when the usage explosion happens in any technological advancement. That's when the usage goes through the roof and inevitably incredible amount of capital are available to further develop and build even more incredible creations compounded of other incredible creations.

      There are literally everyday, geniuses building on top of things that they may not quite know they work, but they don't need to because they only need know their piece to build something useful. This is the profundity of technology and something exemplified here by XNOVA's masterpiece of a web wallet as teased in his DropBox link cross-posted on the Counterparty Forums. 

[GLaDOS]

An simple idea that seems to have been ignored on the official forums...

Wouldn't it be easier to just allow dots in the asset names (hint:  Global_trade_repo's hierarchy idea)?

That way BTT.UNIQUESILVER and BTT.RARECOIN would not collide with someone else's UNIQUESILVER and RARECOIN?
As suggested by Global_trade_repo, the asset names with dots in them could cost less to issue.

Not only that, but the buyers could be more confident that the assets were issued from BTT without rechecking/verifying the description/catalog.  An impostor could issue a VERYRARECOIN with a description poiting to BTT's catalog for example.  But the impostor cannot fake a BTT.VERYRARECOIN asset if it's required to own the BTT asset first.

We should also allow other characters such as #, $, %, and digits after the dot in the asset names.  So BTT can issue BTT.SILVER$100  or BTT.GOLD#1906 for example.


Otherwise, assuming a business can issue 100000+ assets, how does it go about organizing/tracking assets efficiently?  It much easier to match BTT.GOLD#1906 or BTT.RAREGOLD#18394 from a catalog than to search for BTT.GOLDXFR and BTT.RAREGOLDSXR to identify the asset.


If Counterparty is a protocol like TCP/IP, then we will need a flexible asset naming scheme that works almost like the domain naming system.

[halfcab123]

An simple idea that seems to have been ignored on the official forums...

Wouldn't it be easier to just allow dots in the asset names (hint:  Global_trade_repo's hierarchy idea)?

That way BTT.UNIQUESILVER and BTT.RARECOIN would not collide with someone else's UNIQUESILVER and RARECOIN?
As suggested by Global_trade_repo, the asset names with dots in them could cost less to issue.

Not only that, but the buyers could be more confident that the assets were issued from BTT without rechecking/verifying the description/catalog.  An impostor could issue a VERYRARECOIN with a description poiting to BTT's catalog for example.  But the impostor cannot fake a BTT.VERYRARECOIN asset if it's required to own the BTT asset first.

We should also allow other characters such as #, $, %, and digits after the dot in the asset names.  So BTT can issue BTT.SILVER$100  or BTT.GOLD#1906 for example.


Otherwise, assuming a business can issue 100000+ assets, how does it go about organizing/tracking assets efficiently?  It much easier to match BTT.GOLD#1906 or BTT.RAREGOLD#18394 from a catalog than to search for BTT.GOLDXFR and BTT.RAREGOLDSXR to identify the asset.


If Counterparty is a protocol like TCP/IP, then we will need a flexible asset naming scheme that works almost like the domain naming system.

Upon first glance this seems pretty damn genius. It's genius because its so simple its almost obviously the way it should be. I hope the developers strongly consider implementing this or something quite like this, as soon as robot/human-hybridally possible.

Edit: That being said this may be something left to other developers to build on top of Counterparty, but I think its fundamental enough to be included in the protocol layer itself.

Think:

Code:

Issuer.Issuance.Sub-Issuance

And so once an issuer name is chosen, that issuer can create other issuer names of course but they will be the only ones who are permitted to create issuances and sub-issuances relative hierarchically to their issuer name.

And then perhaps blockscan can implement a nice new GUI feature which will allow for collapsing and expanding assets based on this hierarchy of issuance. This will make searching for assets and trusting assets that are issued much much easier and much cleaner of an experience. Good idea GLaDos.

Edit 2: In addition, fees can be adjusted, say... maybe 5 - 10 XCP more or less to register an issuer name, but the issuance might be half that and then the sub-issuances might be even half of half etc., This makes sense to me, but I'm waiting for someone to tell me I'm an idiot or that its not feasible as is common round these parts. -___-

[kdrop22]

An simple idea that seems to have been ignored on the official forums...

Wouldn't it be easier to just allow dots in the asset names (hint:  Global_trade_repo's hierarchy idea)?

That way BTT.UNIQUESILVER and BTT.RARECOIN would not collide with someone else's UNIQUESILVER and RARECOIN?
As suggested by Global_trade_repo, the asset names with dots in them could cost less to issue.

Not only that, but the buyers could be more confident that the assets were issued from BTT without rechecking/verifying the description/catalog.  An impostor could issue a VERYRARECOIN with a description poiting to BTT's catalog for example.  But the impostor cannot fake a BTT.VERYRARECOIN asset if it's required to own the BTT asset first.

We should also allow other characters such as #, $, %, and digits after the dot in the asset names.  So BTT can issue BTT.SILVER$100  or BTT.GOLD#1906 for example.


Otherwise, assuming a business can issue 100000+ assets, how does it go about organizing/tracking assets efficiently?  It much easier to match BTT.GOLD#1906 or BTT.RAREGOLD#18394 from a catalog than to search for BTT.GOLDXFR and BTT.RAREGOLDSXR to identify the asset.


If Counterparty is a protocol like TCP/IP, then we will need a flexible asset naming scheme that works almost like the domain naming system.

Upon first glance this seems pretty damn genius. It's genius because its so simple its almost obviously the way it should be. I hope the developers strongly consider implementing this or something quite like this, as soon as robot/human-hybridally possible.

Edit: That being said this may be something left to other developers to build on top of Counterparty, but I think its fundamental enough to be included in the protocol layer itself.

Think:

Code:

Issuer.Issuance.Sub-Issuance

And so once an issuer name is chosen, that issuer can create other issuer names of course but they will be the only ones who are permitted to create issuances and sub-issuances relative hierarchically to their issuer name.

And then perhaps blockscan can implement a nice new GUI feature which will allow for collapsing and expanding assets based on this hierarchy of issuance. This will make searching for assets and trusting assets that are issued much much easier and much cleaner of an experience. Good idea GLaDos.

Edit 2: In addition, fees can be adjusted, say... maybe 5 - 10 XCP more or less to register an issuer name, but the issuance might be half that and then the sub-issuances might be even half of half etc., This makes sense to me, but I'm waiting for someone to tell me I'm an idiot or that its not feasible as is common round these parts. -___-

+1
Agreed, this is a good suggestion.

[td services]

+1 A major limitation of Ripple is the asset naming. This would be a major improvement.

[BitcoinTangibleTrust]

An simple idea that seems to have been ignored on the official forums...

Wouldn't it be easier to just allow dots in the asset names (hint:  Global_trade_repo's hierarchy idea)?

That way BTT.UNIQUESILVER and BTT.RARECOIN would not collide with someone else's UNIQUESILVER and RARECOIN?
As suggested by Global_trade_repo, the asset names with dots in them could cost less to issue.

Not only that, but the buyers could be more confident that the assets were issued from BTT without rechecking/verifying the description/catalog.  An impostor could issue a VERYRARECOIN with a description poiting to BTT's catalog for example.  But the impostor cannot fake a BTT.VERYRARECOIN asset if it's required to own the BTT asset first.

We should also allow other characters such as #, $, %, and digits after the dot in the asset names.  So BTT can issue BTT.SILVER$100  or BTT.GOLD#1906 for example.


Otherwise, assuming a business can issue 100000+ assets, how does it go about organizing/tracking assets efficiently?  It much easier to match BTT.GOLD#1906 or BTT.RAREGOLD#18394 from a catalog than to search for BTT.GOLDXFR and BTT.RAREGOLDSXR to identify the asset.


If Counterparty is a protocol like TCP/IP, then we will need a flexible asset naming scheme that works almost like the domain naming system.

The BitcoinTangibleTrust team supported this approach on the official forums, as well. Global_trade_repo's suggestion was genius. We like it for more extensive naming degrees of freedom.

[Anotheranonlol]

Anybody who is interest in creating such an asset like below? if it is possible?

example; Asset issuer creates BTCEUSD asset with qty 10,000 (equating to 10,000 'shares/tokens' of 1 BTC- EUSD and total value of 10,000 USD) . They make sure to keep a balance of min 10,000 USD in BTC-E exchange

The issuer would show a public API key and publish this with read-only query privileges enabled in the asset description area to demonstrate they hold full reserves of USD
This can be transparently verifiable by public. example below

Code:

{
	"success":1,
		"return":{
		"funds":{
			"usd":10000,
			"btc":0,
			"sc":0,
			"ltc":0,
			"ruc":0,
			"nmc":0
		},
		"rights":{
			"info":1,
			"trade":0
		},
		"transaction_count":0,
		"open_orders":0,
		"server_time":xxxxxxx
	}
}

   

Users, at any time can visit a website and redeem the number of shares for BTC-E vouchers amounting to the corresponding BTCEUSD they hold. (maybe they would first select amount and provide mail address, then sign a message stating number of shares to be transferred, then make the transfer, voucher would then be mailed to them)

This way, the users could trade in/out of USD seamlessly on DEX whilst still keeping BTC off-exchange. and not being exposed to the associated risks that brings. Of course they would still be at mercy of trusting the issuer will always give redemption of these USD, with trusted persons managing the assets this risk could be negated somewhat.

is it even technically achievable to do this using counterparty?

[PhantomPhreak]

Anybody who is interest in creating such an asset like below? if it is possible?

example; Asset issuer creates BTCEUSD asset with qty 10,000 (equating to 10,000 'shares/tokens' of 1 BTC- EUSD and total value of 10,000 USD) . They make sure to keep a balance of min 10,000 USD in BTC-E exchange

The issuer would show a public API key and publish this with read-only query privileges enabled in the asset description area to demonstrate they hold full reserves of USD
This can be transparently verifiable by public. example below

Code:

{
	"success":1,
		"return":{
		"funds":{
			"usd":10000,
			"btc":0,
			"sc":0,
			"ltc":0,
			"ruc":0,
			"nmc":0
		},
		"rights":{
			"info":1,
			"trade":0
		},
		"transaction_count":0,
		"open_orders":0,
		"server_time":xxxxxxx
	}
}

   

Users, at any time can visit a website and redeem the number of shares for BTC-E vouchers amounting to the corresponding BTCEUSD they hold. (maybe they would first select amount and provide mail address, then sign a message stating number of shares to be transferred, then make the transfer, voucher would then be mailed to them)

This way, the users could trade in/out of USD seamlessly on DEX whilst still keeping BTC off-exchange. and not being exposed to the associated risks that brings. Of course they would still be at mercy of trusting the issuer will always give redemption of these USD, with trusted persons managing the assets this risk could be negated somewhat.

is it even technically achievable to do this using counterparty?

That's definitely possible.

[BitcoinTangibleTrust]

Anybody who is interest in creating such an asset like below? if it is possible?

example; Asset issuer creates BTCEUSD asset with qty 10,000 (equating to 10,000 'shares/tokens' of 1 BTC- EUSD and total value of 10,000 USD) . They make sure to keep a balance of min 10,000 USD in BTC-E exchange

The issuer would show a public API key and publish this with read-only query privileges enabled in the asset description area to demonstrate they hold full reserves of USD
This can be transparently verifiable by public. example below

Code:

{
	"success":1,
		"return":{
		"funds":{
			"usd":10000,
			"btc":0,
			"sc":0,
			"ltc":0,
			"ruc":0,
			"nmc":0
		},
		"rights":{
			"info":1,
			"trade":0
		},
		"transaction_count":0,
		"open_orders":0,
		"server_time":xxxxxxx
	}
}

   

Users, at any time can visit a website and redeem the number of shares for BTC-E vouchers amounting to the corresponding BTCEUSD they hold. (maybe they would first select amount and provide mail address, then sign a message stating number of shares to be transferred, then make the transfer, voucher would then be mailed to them)

This way, the users could trade in/out of USD seamlessly on DEX whilst still keeping BTC off-exchange. and not being exposed to the associated risks that brings. Of course they would still be at mercy of trusting the issuer will always give redemption of these USD, with trusted persons managing the assets this risk could be negated somewhat.

is it even technically achievable to do this using counterparty?

That's definitely possible.

+1

Let the Counterparty Asset Issuance innovation grow!

[Matt Y]

The XCP will never make it. You bastards are more interested in having pride that u created something. But hey, this altcoin era is about making money. whatever you have done is not invincible. I have been watching this shit since it conception in January. This coin is dead. XCP has given the worst return to its investors. Developers are boasting themselves as genius and busy rather than supporting price of XCP. If you all burners want atleast your investment back, get out of this shit now.

This is very likely blow back from what occurred here over the last day or so: https://bitcointalk.org/index.php?topic=265488.msg5750361#msg5750361

[crypto era]

The XCP will never make it. You bastards are more interested in having pride that u created something. But hey, this altcoin era is about making money. whatever you have done is not invincible. I have been watching this shit since it conception in January. This coin is dead. XCP has given the worst return to its investors. Developers are boasting themselves as genius and busy rather than supporting price of XCP. If you all burners want atleast your investment back, get out of this shit now.

I saw a person just lash out at you for your opinion. that person in the wrong just like you. About the investment return it will be a gradual increase when the online wallet hits mainnet. It's unpredictable because most are just using a command line. The developers have not boasted at all. They have been low profile and only talk to give help on there creation. They just give the information on what the coin does. Not sure that's boasting, it's more informative. You look at cryptocurrency as a flash in the pan/get quick rich kind of thing. "this altcoin era is about making money" if you honestly think this than you don't see what they can be and you are just scrambling around like a chicken with it's head cut off. Just following another chart for another thing to trade. I want you to inform yourself before you decide to write slander on something you do not understand. Please write another reply with at least a fact in it.

[Anotheranonlol]

That's definitely possible.

+1

Let the Counterparty Asset Issuance innovation grow!

Thanks. I would like to begin but not the best person for the job. currently don't have a full enough understanding of the protocol to be able to  offer., also I think the right person to issue such an asset would need to have established a history of trust, so users will be somewhat assured they will make good on their promise of redemption.

I will wait a while to see if anyone with more credible history/fuller understanding of counterpart offers, then try and get stuck in learning more about the procedure if nobody steps up because I do believe such a thing will be beneficial

[ASIC-8Tile]

Upgrade.

Tried to run counterpartyd server command
1.) Received following error.
C:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 598, i
n <module>
    util.versions_check(db)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 300, in ver
sions_check
    raise exceptions.ClientVersionError('Please upgrade counterpartyd to the lat
est version and restart the server.')
lib.exceptions.ClientVersionError: Please upgrade counterpartyd to the latest ve
rsion and restart the server.

2.) Tried C:\counterpartyd_build>git pull origin master
From https://github.com/xnova/counterpartyd_build
 * branch            master     -> FETCH_HEAD
Already up-to-date.

What am I missing to upgrade?
Please add upgrade paths/instructions to main BTT page and/or GIT/reddit.

Thanks

[kdrop22]

Upgrade.

Tried to run counterpartyd server command

a) Rename the counterparty install folder.
C:\counterpartyd_buildTEMP
(You can delete this later, once you get a working install)
b) Pull from Github again, it should download a fresh copy
c) Follow the instructions to complete the reinstall.
http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html#on-windows

If still not resolved, post in the Technical Support/Build thread in : https://forums.counterparty.co/

[porqupine]

Upgrade.

Tried to run counterpartyd server command

a) Rename the counterparty install folder.
C:\counterpartyd_buildTEMP
(You can delete this later, once you get a working install)
b) Pull from Github again, it should download a fresh copy
c) Follow the instructions to complete the reinstall.
http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html#on-windows

If still not resolved, post in the Technical Support/Build thread in : https://forums.counterparty.co/

Check if your counterpartyd is up to date - cd into /dist/counterpartyd and git pull from there