Announcement: The Counterparty team will be paying out a bounty on February 14th, at 00:00 UTC (three weeks from today, midnight on Saint Valentine's Day) for work on a desktop GUI Counterparty client built on top of counterpartyd. The size of the bounty will be the balance of our donation address, 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs (both BTC and XCP), at the time that the bounty is closed, and the winner(s) will be chosen, thereupon, by a consensus of PhantomPhreak, xnova and myself. N.B. We prefer, but will not require, that clients be cross-platform. Also, xnova is hard at work on a Counterparty web client, which should be available for preview in the next couple of weeks. More bounties will be offered in the near future. This announcement was cross-posted from https://bitcointalk.org/index.php?topic=430998, where formal submissions should be made.
|
|
|
|
The Counterparty team will be paying out a bounty on February 14th, at 00:00 UTC (three weeks from today, midnight on Saint Valentine's Day) for work on a desktop GUI Counterparty client built on top of counterpartyd. The size of the bounty will be the balance of our donation address, 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs (both BTC and XCP), at the time that the bounty is closed, and the winner(s) will be chosen, thereupon, by a consensus of PhantomPhreak, xnova and myself. N.B. We prefer, but will not require, that clients be cross-platform. Additional requirement: All submissions must be open sourced and freely licensed by the end of the burn period (but the earlier the better). For more information about Counterparty, please see the 'Announcement' thread: https://bitcointalk.org/index.php?topic=395761.0 |
|
|
|
A practical question that I have:
Say we have an investor, who we want to allocate shares using XCP asset mechanism, how we actually reflect the real value he invested into us in XCP asset?
For example he placed X BTC for Y shares issued, which set the post-money valuation of the asset to = X BTC * Z shares we have now / Y shares issued.
How do we reflect that this was real - perhaps by receiving the funds at same BTC address, which was used for asset creation?
Speaking off, is there a way to change asset details after it was generated (i.e. amount of shares, divisibility, etc...)?
Please correct me if I've misunderstood you, but I believe you are asking: How can market valuation be reflected in reality? Using counterpartyd, an address uses the 'issuance' function to create an asset (let's call it ASSET), and then uses the 'order' function to put ASSET on the distributed exchange, (where, in your example, syntax would be --give-asset=ASSET --give-quantity=Y --get-asset=BTC --get-quantity=X --fee=FEE --expiration=EXPIRATION). Whoever wants to buy ASSET will have to put up an order to match yours, and, once matched, will have to use the 'btcpay' function to send BTC to the address which put up the 'trade ASSET for BTC' order. Users must send BTC to the address which is selling ASSET in order to complete the transaction. So, if Z shares of ASSET are exchanged for X BTC per share (where Z<=the total number of shares of ASSET), then ASSET'S valuation is indeed X BTC * Z shares, just as you said. However, whoever bought shares of ASSET can then put them on the distributed exchange in exchange for any other asset, and so the greater the number of assets for which ASSET is exchanged, the more conversions you will need to do to get the market valuation in BTC, however, as long as every asset *has* a market rate, it should always be possible to determine ASSET's valuation. The way to change the total number of ASSET, is to issue more ASSET. Only the address that issued ASSET originally can issue more ASSET. Addresses can, however, transfer ownership of an asset name to other addresses. At the moment, I don't believe there is a way to divide shares, though one of the team members may correct me on this. I am sorry if this explanation is a bit unclear, but hopefully it helps! |
|
|
|
Nice they mention XCP! Also, how come coindesk knows about new counterparty site earlier then us the loyal supporters?  http://counterparty.cocounterparty.co was and is not ready for release, and that is why we didn't let the community know about it. Whoever wrote that article did not try to get in touch with anyone on the Counterparty team. If it had been up to us, we would have referred them to the actual protocol, as opposed to our very much incomplete website. |
|
|
|
Would it be a good idea to try to keep this coin on the DL until after the burn period is over?
We can all keep it hush and try to keep the thread bumping and promoting at a minimum until the burn is over.
yes, except that there is already 1,400+ BTC burnt. So.... cats out of the bag. This will not be another NXT moneymaking bonanza. It seems there is more money to be made in scammy altcoins and promise-to-do-something protocols than the actual thing..-- Nevertheless in terms of a protocol/currency being adopted the later has much better chances (even if the devs do not get super rich from it). Regarding PoS and asset issuance: while it would be tenable to have a PoS multi-sig requirement for asset issuance, I'm not sure it would be altogether fair. Basically a big stake owner in XCP could still issue as many assets as he would like, and low stake owners would have to scramble,if only to enable the use of a certain feature inherent to the protocol. I think asset balance maintenance is significantly more solid - say .5 btc (200xcp) is not that much to maintain one's own asset for accounting purposes (even if its just for internal bets/accounts between a limited number of people), (and if someone has 50000 xcp sure let them make 100 assets it still won't enable them to monopolize available asset names, and it will commit their funds to non-liquidity, the later only being reasonable if they have a real use for these assets. Whatever XCP balance were required to maintain an asset name could just be made a fee to purchase the asset name. Having to keep 200 XCP at an address in order to maintain ownership of an asset name is tantamount to paying a 200 XCP fee for that asset name. Asset names can, moreover, be transferred to other addresses, and so one could theoretically transfer an asset to another address in exchange for XCP (or any other asset), but as this is not an atomic transaction, one would need to trust that the latter will send the XCP. |
|
|
|
What about linking XCP generated Assets to the original Issuer address by limiting an address to a single issued asset per address and requiring it to maintain a certain balance of XCP?
As Counterparty stands, only one address can issue each asset, and each address can issue only one asset. Why do you think an address which issues an asset should have to maintain a certain balance of XCP? I think it could be a reasonably effective way to prevent one person from, issuing as mentioned, numerous Assets just by generating addresses just to sit on them. It's pretty trivial at the moment to write a scrip to issue all possible 3/4 letter assets, and I don't think that a tiny fee is a real deterrent. I spoke imprecisely last time: there are in fact 256^8 asset names in all, but there only around 10,000 single common English words that could possibly be asset names. The problem, then, is rather different from how I initially described it. |
|
|
|
What about linking XCP generated Assets to the original Issuer address by limiting an address to a single issued asset per address and requiring it to maintain a certain balance of XCP?
As Counterparty stands, only one address can issue each asset, and each address can issue only one asset. Why do you think an address which issues an asset should have to maintain a certain balance of XCP? |
|
|
|
Links are nor authoritative.
Put a hash of the entire asset contract. Even then anyone who can manage to fabricate a document that turns out to have that exact hash can pass it off as being the real contract, but that should be hard - computer-science hard, math hard - to do.
It also means here you get hold of a copy of the document is irrelevant, either it is the right document as it hashes to the hash recorded in the blockchain, or it is not.
You can get it by offering a reward on television or by finding it in a garbage bin or by searching for it on google or by making it up yourself by trying all posible documents that can be made for a few billion trillion lifetimes-of-the-universe, who cares how you got it as long as it is correct aka hashes to the right hash.
anyone who cares could pirate a copy and put it on a file-sharing site or DHS or whatever, it just doesn't matter. It could be a deep secret, an asset very few people have found the contract for. Or it could be a full page printed in all major global newspapers. Just hash it to see if it is the one you are looking for.
-MarkM-
We are talking about two different things: asset descriptions and asset contracts. Any hash of an asset contract that is put in the blockchain would be for a contract that is itself off-chain, and so we are still left with the problem: How does a user actually know what he is buying? Moreover, since we still need a reference an off-chain source in order to provide a satisfactory description of the asset, there is no reason why the hash of any contract involved in the purchase of the asset would need to be on-chain. |
|
|
|
If the data could be interpreted externally then any webpage built on top of that wouldn't be centralized it would just be a layer on top of the exchange for a nice interface/presentation of the data.
Counterparty could have a site that works as a back end for asset issuers i.e. to upload images into a library of a certain size or to add any other sort of information to add to their listing/bet.
If it's a possibility this could be achieved then it would be a case of working out how you'd like the information to presented at the top level and working backwards. I.e. would it be nice to have a site with the current bets separated from current assets, would it be nicer to then have those bets and assets broken down into different categories. What's the best way for the information at the top level to be presented?
It would be cool if you could build something at a higher level that's erring towards ebayish or betfairish fed from the chain.
Right now there is no way to encode such data in the blockchain, and as a result it would need to be hosted on a particular server, so there would still need to be some centralization. We may look into ding something similar in the future, but for now now putting links in asset descriptions is, in our view, the simplest and most decentralized way to describe assets. |
|
|
|
Is there anyway the asset description could be written in such a way as to pull information from elsewhere, which then in turn could be interpreted by a client or HTML page to show it's full meaning for example within the asset description using something like a # followed by a letter meaning information's drawn from an external source say www.externalcounterpartysources.com. In this example #i321 could look up image 321 at the above address or #t458 could look up text. The benefit being you could then use the asset description to create a full listing on a layer above the chain like a client or webpage? The devs and I were of the opinion that asset descriptions should *have to* include a link to an external source; anything else is untenable within the blockchain. Note that this decision has not been implemented, nor is it final. If Mt. Gox created MTGOXUSD e.g., they would provide a link to an official website where they: a) have a list of all the addresses that are their own - thereby allowing users to verify that it is in fact Mt. Gox which issued MTGOXUSD and b) a description of the assets issued by each address - thereby allowing users to determine whether (e.g.) MTGOXUSD is what they are looking for. As to the recommendation of purchasing assets from certain addresses, I think this will most effectively be done through forums such as this one. And what about the description being interpreted by an external source to summarize the asset description including the information linked to In other words, you would like both a link to an official website for the asset and an official summary by an external source of the asset? What are the criteria for choosing the external source which summarizes the asset description? It would be out of line with the spirit of Counterparty to centralize summaries, and I don't see how to circumvent that problem. Did you have something in mind? |
|
|
|
Is there anyway the asset description could be written in such a way as to pull information from elsewhere, which then in turn could be interpreted by a client or HTML page to show it's full meaning for example within the asset description using something like a # followed by a letter meaning information's drawn from an external source say www.externalcounterpartysources.com. In this example #i321 could look up image 321 at the above address or #t458 could look up text. The benefit being you could then use the asset description to create a full listing on a layer above the chain like a client or webpage? The devs and I were of the opinion that asset descriptions should *have to* include a link to an external source; anything else is untenable within the blockchain. Note that this decision has not been implemented, nor is it final. If Mt. Gox created MTGOXUSD e.g., they would provide a link to an official website where they: a) have a list of all the addresses that are their own - thereby allowing users to verify that it is in fact Mt. Gox which issued MTGOXUSD and b) a description of the assets issued by each address - thereby allowing users to determine whether (e.g.) MTGOXUSD is what they are looking for. As to the recommendation of purchasing assets from certain addresses, I think this will most effectively be done through forums such as this one. |
|
|
|
Might be some security issues to iron out (like getting robbed at gunpoint) but I suppose getting cash in and out locally could be tied to an asset, redeemable in the same way as local bitcoins .
So if bob wants to purchase $100 in exchange for a crypto from issuer cashlondonbitcoin840to1 (or whatever the format is for issuing assets). Than for him the chain not only works as a way to fund/cash out locally and instantly but also as a central medium for advertising traders in his areas.
Right, but it should be noted that in order effectively to advertise traders in his area, Bob or the trader(s) will need make advertisements off-blockchain, since the asset description will likely not be long enough to specify everything necessary to create an appropriate advertisement. Moreover, the initial risk associated with helping traders gain reputation will probably be much greater on account of meeting in person. On the other hand, such local trades will help decentralize asset sales, since you will not need to (e.g.) connect your bank account to a website. |
|
|
|
|
One possible use of asset issuances is to create a sort of currency peg. Here's one way to do this.
Let's suppose Mt. Gox issues MTGOXUSD and John buys "100 MTGOXUSD" for $100 worth of XCP plus some premium, on the premise that he can redeem his 100 MTGOXUSD for $100 worth of XCP before a certain block, which can be specified either off-chain or in the asset description on-chain. John can redeem his MTGOXUSD either through the distributed exchange or by sending his MTGOXUSD to an address provided by Mt. Gox. John can of course also trade his MTGOXUSD with other users.
Mt. Gox can offer MTGOXUSD1, MTGOXUSD2, etc. each with its own expiration block; presumably the further in the future the expiration block is, the higher the premium the voucher will carry.
The risk that the vouchers will not be redeemed is inversely proportional to the price premium, and to the issuer's reputation.
|
|
|
|
I have created a thread to discuss assets within Counterparty: https://bitcointalk.org/index.php?topic=424439.0. In my opinion, asset creation is one of the broadest features of Counterparty, and as a result a complete understanding of its functionality (and the best way to take advantage of it) is quite difficult to achieve, and a community effort is the best way to do so. A thread dedicated to the discussion of assets will help make the Counterparty protocol more usable, and so I encourage users to direct their questions regarding assets to that thread. |
|
|
|
|
This is a thread to discuss assets within the Counterparty protocol. Users are encouraged to discuss: asset issuance, advertising assets, asset recommendations, the functionality of asset creation, dividends on assets, and anything else related to Counterparty assets.
|
|
|
|
I have 10,250 XCP sitting here, where and how do I donate ??
XCP donations can be sent to 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs using counterpartyd. All donations are greatly appreciated. |
|
|
|
if you put in fees, someone will just fork your code and lower the fee welcome to open source Right now transaction fees are ~20 cents, and the average (American) vocabulary is approximately 10,000 words, so it would only cost ~$2000 for someone to buy every single asset name - certainly, in any case, all the attractive asset names. The fee has to be large enough to prevent this from happening. The Counterparty team does not want to implement fees, but the peculiarity of the circumstance makes it necessary. It also follows, however, that every fork will have this same problem, and thus will also have to implement fees. |
|
|
|
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. Practical use case: credit token schemeIf we really want to see Counterparty blow up in usage and in utility, one of the best uses for it is to issue credit tokens. A credit token is basically a coupon which anyone can issue which represents a promise that they will redeem the credit coupon for their goods or services by a specific date. The idea is everyone will start issuing these credit coupons and due to the expiration date there can be no hoarding. Everyone would be able to trade these credit coupons to get anything they could ever need. In my opinion any kind of issuance should allow for an expiration date. If I issue a token then it must be redeemed by the expiration date or it is invalidated. The main problem I see with Counterparty, Mastercoin or any of these is that we are all expected to buy XCP or Mastercoins but then there seems to be no fee structure in place. What can we spend our XCP for in the XCP ecosystem? If that isn't figured out then XCP really has no value until we know what the prices will be in the system. Fees are fine. I want to know the fees so I can know how much XCP I will need to buy or burn. Not knowing the fees means we might not even need 1 XCP to do all of our transactions. In my opinion the fees should be high enough to make people keep buying XCP but low enough that anyone who really wants to do certain things can do what they want to do. If it turns out that 1 XCP is all we will ever need then that is clearly too cheap. If 100 or 1000 XCP is all we will ever need it's still probably too cheap but that would depend on the total amount of XCP. So before we can say whether or not a fee is expensive or not we have to know how many XCP will ever exist. With Mastercoin we know how much Mastercoin will ever exist and still don't know the fee structure. If we talk about demand then I think credit tokens will be in major demand. If fees are too high or too low the market can decide if we put in the ability for people to vote or speculate on the price of fees. So you could actually build a speculation or prediction market to discover the prices of the fees in a similar way to how Forex discovers the prices of different currencies. So how much should issuing a credit token cost? Use Proof of Stake voting to allow the network to collectively determine or use the market to allow the network to speculate on the fee prices prior to there being any prices. So to speculate we could set it up as a bet like: "The fee for issuing credit tokens in XCP will be over 50 XCP?" Yes? No? Or more generalized "The fee for issuing an asset in Counterparty will be over 1 XCP?" Yes? No? Everyone would then bet XCP that it will either be over 50 or under 50. Or they'd bet it would be over or under 1 XCP. One side has to be right. The winning side profits so no one would want to be on the losing side. Price discovery is going to be critical and if developers don't know what the fees should be then why not build it in so the network/market can decide either by a client based vote or a decentralized betting market? If we wanted to we could start betting on what we think it will be right now. Speculation is probably going to be one of the main uses of Counterparty along with betting. So should a decentralized bet even have a fee? My opinion is the fee should be set by whoever sets up the bet. So some bets can have fees bigger than others and let the free market determine if people are willing to part with XCP. XCP must be used for dividends, bets and paying fees for making bets on feeds. Fees for betting on broadcasts are determined by the feed-operator, and if someone wants to bet on a feed, he has to match the fee given by the operator. |
|
|
|
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: 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4XgsIf 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? If I issue GOLD or CHASEUSD or any other attractive sounding asset, users will still need to do their due diligence in order to figure out whether the asset I have issued is worthwhile, and such due diligence would need to be done outside of the protocol itself. The 'market' should not be primarily thought of as the place where one discovers assets one would like to buy, but rather the place where one goes to purchase an asset one has read or heard about elsewhere. Since users can search for specific assets they are interested in purchasing, I don't think preventing spam should be a top priority. |
|
|
|
I think XCP is a very promising project and I think I will do something on it (maybe an counterparty explorer soon).
Nonetheless, I don't think this project is able to give you huge return (more than 10x) like Nxt, so please be warned if you want to be rich over-night.
The reason is simple. Since this is an open-source project, so anyone could replicate it without any cost. They just need to create a new un-spendable address and then there's another XCP-2, XCP-3. Once people find the price of XCP is too high, they can freely goes to XCP-2 and XCP-3.
The smart or sneaky part of Nxt is that they postpone opening their source until the price is already more than 1000x. For master-coin, they have no code at all even at current stage.
Therefore, XCP in my opinion is the most honourable project and it's the project really want to create a decentralized market rather than a be-rich-soon game (the only other one similar is colored-coin).
Any thinking about this is welcome, especially from the developers.
Thanks for the kind words! The Counterparty team makes no promises regarding returns-on -investment. Our goal. moreover, was not to make investors rich overnight, but rather to create a working and relatively full-featured client, and to that extent returns-on-investment were secondary. At the same time, however, I believe that the situation you describe does not preclude XCP significantly increasing in value. Specifically, unless a Counterparty fork offers some real technical improvement, I think that XCP-2, etc. will be minted only when Counterparty has proved itself a financial success. And even if a Counterparty fork does offer technical advantage, the importance of being the first Counterparty must not be forgotten. In my opinion, certain alt-coins offer definite advantages over Bitcoin (e.g. faster block-time), and yet Bitcoin has still increased in value and the alt-coin market has, in my opinion, at least for now, proven itself to be by-and-large a bubble. Nothing suggests to me that the situation wouldn't be same if alt-Counterpartys were to appear. There're years between bitcoin and its copicats, so bitcoin has enough time to grow. XCP, however, may have only months to be mature enough to secure the first arriver advantage. Nonetheless, I agree with you that there're still considerable upsite for XCP, because people will copy it and will to burn for the copicat only after XCP is successful and the price is high enough. I'm just saying that the price will not increase as much as Nxt (>1000x) and all investors had better to keep this in mind IMHO. I suppose this is a good time to announce my intent to borrow some of all of the counterpartyd code and put it in my catbox development tree ( https://bitbucket.org/dahozer/catcoin ) . I was going to say sandbox, but it's going to be crap until either: a) I get a consulting/development contract to work on this full time b) I can make enough offering and trading counterparty commodities futures (I need some buyers who want to take physical delivery of Iowa soybeans) EDIT: Sorry, I misunderstood. |
|
|
|
|
Show Posts
