Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 605. (Read 1276933 times)

That should at least decrease asset-squatting until a more complete solution can be found.

Oh look, I invented a new word.

Announcement: The develop branch of counterparty now specifies that 5 XCP is destroyed in all future asset issuances (after block 281235 281236). If we decide to make this official, the fixed amount will be temporary, and should be determined by a distributed, proof-of-stake voting system as soon as possible.

And with this information we can now speculate and somewhat predict what kind of price ranges these fees might be. I honestly think the betting function could be one of the killer apps because people like to speculate and there will be tons of feeds. That alone will probably support XCP.

For assets it's harder. You are right we have to do due diligence to avoid scams. For assets such as credits which can be redeemed it's important to deal with reputable businesses. Someone like Maxmint for example has a good reputation as being trusted to do escrows. He has done escrows for me and many others and has a perfect reputation. Someone like Maxmint could issue a Maxmint credit token for his escrow services and I would buy some of those tokens with the knowledge that in the next 6 months I'll probably want to use his escrow services. If I change my mind then I can trade his token for the token of someone else who is trusted and offers a service.

It's still possible to get scammed even like this, but if the tokens are reasonably cheap it's not that much of a risk to buy a small portion.


I just endorsed your escrow service. It's fairly easy to burn XCP and I figured it out but I still give you some business because it's good for the ecosystem of us all.

+1 to above.

Also please don't forget to donate to the developers. Without their efforts, there wouldn't be XCP, nor it has much chances to grow further.

Remember, there is no 5M$ fund like MSC, no wealthy early investors like NXT who can sponsor the R&D, so this is a truly community project.

I can keep my xcp in my blockchain.info to any time in the future if I do not want to use them?

I provide an "escrow burning" service and burn BTC on behalf of others. Please read the details here:
https://docs.google.com/forms/d/1GY1pNSLo8PUW8cSb9WJC8OdQOdrZ510pGEXTBIvq3i0

I would like to get hold of few XCP but I'm on a Mac. Anyone that could help?

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.

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.

Couldn't that happen in any prediction market? But if they lose then they get punished so they would have to be very well organized. I'm not saying I have the most detailed or well thought out solution because I didn't put in a lot of time thinking about this but I do believe this is the direction which will lead to the solution.

So now that I've put the idea out there some people who do have the time to think about this can solve this problem. The sooner we start speculating on the fee price structure the quicker the market will determine what the fees ought to be. I do know you can't have zero fees. Free just isn't going to work for any of us who own shares in XCP, Mastercoin or anything else.

That sounds like a good strategy; however, I'd be concerned about the possibility of collusion. What if a significant minority of stakeholders decide that a certain fee level (high or low) is desirable (for whatever reason) and bet accordingly?

I think speculation is the solution to that problem. Channel speculation so that the fee always rests in perfect equilibrium with the market. The speculation will find the equilibrium point.

You could use a sort of distributed betting mechanism to allow players to predict what they expect the fees to be (guess the price of the fee for x?). So if Alice predicts the fee should be over 20 XCP and Bob predicts it should be under 20 XCP they should both bet and put their XCP on the line. The fee should be high enough that neither of them will want to be wrong. One of them will have to be right. So you can actually use speculation to find the price.

Bitshares is going to use speculation to determine the price of bitUSD. The price of Bitshares is determined by speculation via Protoshares. To determine the price for issuing an asset we have to speculate. Speculation will produce a price discovery where the market will decide the maximum amount it's willing to pay to issue an asset. That maximum amount should be the current fee. This would mean the fee would have to be dynamically adjusted in such a way that it adapts to speculation somehow.

One way I can think of to do this is to somehow have a decentralized data feed which is based on the outcome from betting/speculation. That data feed becomes the XCP fee price chart or XCP fee price index. Once the market or the network has made it's decision (consensus) the fees should be set for that hour, or that day.

I don't have it completely figured out though. I may have figured out that speculation can do it in theory but I don't have a detailed practical explanation for how to do it. I just believe that is ultimately how the problem will be solved and the direction you should take.

Practical use case: credit token scheme

If 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.

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.


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?

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.

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.

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 .

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).

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'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.)