hah - there’s tons of regulations affecting Bitcoin to altcoin exchange.
Much of the desire for Bitcoin is as a method of payment for goods and services which are unserviced by fiat. That demand heavily weighs into the exchange value of Bitcoin. Additionally, The conversion service itself is so risky for american businesses to process, that the majority of these exchanges have operated out of the US. (Poloniex and Cryptsy are testing the regulations here - and we shall see what the regulations offer)
I don’t see how this market is free of regulatory pressures.
In that sense I agree - it’s not a free market, regulation does exist, but but a fair number of crypto-brokerages operate as if regulations don’t apply or exist. It’s a regulated market that’s working as free market - simply because the fish is too small to fry.
IMO - If the referenced crypto brokerages are ‘too small to fry’, then the regulatory environment is such that they’re regulated to perform their business in a way that captures whatever inefficiencies aren’t being captured by larger exchanges. And, as soon as they hit the regulatory threshold - they’ll be fried. (Thus incentivizing the next round of small-fish exchanges to start up)
It’s hard to find an unregulated market. I suspect it’s even completely impossible. This is why ‘regulation existing’ doesn’t bother me much - I suspect it’s a reflection of nature in an anarchic world.
I’ve been claiming the same for a long while. Whatever important uses people come up with, they will be rendered useless by the state.
If bitcoin can’t break out of niches without economic and political relevance and significance, what does that say about its future? If one can only use it for apps which can also use Visa or PayPal, there would be little point in using it at all. This post explains why the only uses that matter are free market apps and without them we might as well use a permissioned garbagecoin.
@JPJA I think you have enough support to submit a draft CIP to Github for any final comments.
If the asset owner holds the entire supply and the asset is not locked, then allow the owner to reset the supply (e.g. set the supply at zero) and change the divisibility status.
More than 30,000 assets are unused. If or when they get a use case it may be beneficial to change the divisibility status and/or reset the coin supply.
The best asset names have been registered by squatters for the sole purpose of reselling them later. Future projects may want to buy these names. Currently an asset is stuck at the initial divisibility status and coin supply. By allowing the owner to reset these, the projects involved will benefit. If this is limited to assets where the owner holds the entire supply and the asset is not locked, I cannot see anyone being harmed by allowing this.
The create_issuance API call will include a new reset flag. A reset is valid only if the owner holds the entire supply and the asset is not locked. The divisibility status can be changed. The supply can be set at any value >= 0 (and below the upper limit).
Example use cases
Alice owns GOLD. The supply is 88,888,888 shares. Bob is setting up a GOLD ETF on Counterparty and intends to let one share represent 1 oz of gold. The ETF’s total supply is only 10,000 oz. Alice wants to sell GOLD to Bob, and Bob would have been interested if he could set the supply to 10,000 shares.
Carol registered ODIN long ago. Now she plans to make a card game with ancient gods. Players are encouraged to trade on the DEX but ODIN is divisible and cards should not be that. If someone puts an ODIN card for sale, a troll may match the order with a millionth of a card, hence destroying the card (this actually happened with a Spells of Genesis card)
I have the following suggestions and I am ready to merge this as a draft as CIP 3:
Please remove my name as an author. I don’t require authorship credit in the proposal.
Please change the Type to Standards.
Change “use-case” to “use case”
Move “Technical implementation” to “Specification”, write it as a more declarative specification and remove all of the “I think…” statements. (e.g. The create_issuance API call will include a new reset flag… ).
The next step is to work up a pull request with an implementation. And before writing any code, I recommend discussing the plan of the technical implementation details with @robby_dermody or one of the founders.
A wider (and the one that I’m also interested in) use case of callability, in my case, would be the ability to buy back portion of a float/issuance. When does this become useful?
Use Case 1: Reusable Tokens
Certain assets - if you want to reuse them - should be callable. Let’s say bus tickets (reservations).
In this case, these should be callable at 0 fee (why not, but the issuer could pay more; we could make the fee optional, but default would be 0).
I think this case is simple because there are no restrictions whatsoever. Tokens get simply swept from the current owners, no questions asked.
Use Case 2: Loans and Rentals
Note: who gets the dividend during the time an asset is rented out?
If the issuer issues 10 LOAN’s, sells each for 27 XCP while promising to buy back at 30 XCP before block 498’000. (It’d get tricky if buyback tokens ended up in nLock transactions or other unclear states).
Rental / Subscription
Another use case is where we want to hold 1 GYM token for a period of 5 days. You could pay not the full price of gym membership for the year, but just rent it (say, for 30 XCP). I assume you’d have to leave a deposit of 40 XCP and the owner would buy back their GYM token for 10 XCP.
Maybe this is similar to the first case (reusable tokens), but the duration and buy-back price could both be variable.
Smart Contracts or Expanded Basic Use Cases?
I don’t want CP to become too complicated, so if we could have a way to build these features in a Smart Contract layer, that would be a better option IMO
@something - This CIP is already written in such a way that you can only reset a token that has either no balances or one balance owned by the asset owner. Your ideas may be more fit for a separate discussion.