Before We BeginWhy not create a distribution to clam holders/supporters before the digger started and call it Pearl or something more clever
The new coin could be an experiment that exists with Clam and will allow people to have a choice
I am thinking similar property's with clam and just a smaller distribution
If the dice sites supported the new coin, that would be awesome as well.
Unless I have missed an important memo, it is quite agreed upon that any changes will need to meet a preponderance of wet-ware consensus.
The CLAM network belongs to the community; thus, we will attempt to shepherd CLAM, in all situations, toward the consensus of the community it serves.
The last I checked, dooglus, xploited and I were in agreement on this concept.
Conversations about other networks/coins are off topic for this thread; sorry.
If you were interested in creating your own network - please feel free to stop in to #clams on freenode IRC.
We would be happy to help you along when you run into problems in implementation.
Maybe it would be a good idea to try having the discussion here too.
...
Some suggestions that came up last night:
a) CreativeCuriosity has for a while now had an idea of changing the fee structure for CLAM. It's quite wide-ranging, and aims to stop us ever having to go through the whole "large block" debate that is currently dividing the Bitcoin community. Her plan is to have the block size limit and transaction fees adjust based on historical block sizes such that the market finds its own level. As a part of this the transaction fee would depend on the amount of this an output spent on the blockchain before it could be pruned, since it costs everyone more to store an output for 5 years and to store it for 5 minutes.
While interesting, I don't think this really addresses the problems caused by the ongoing digging activity.
b) Some kind of a hard fork could reduce the value of un-dug CLAMs over time in some way or another.
The reduction could range from a total end to digging (which some argue removes one of the unique selling points of the coin) to such a small reduction that it would have no effect. The hard fork would need to be planned and announced in advance to give people a chance to update their client software, and so the digger would simply dig all his coins before the fork happened, unless he really isn't paying attention.
c) CC seems to be of the opinion that we can just ride this out, and everything will be fine. Since the price of CLAM is down, the digger will for some reason start selling much faster and run out of his stash within a month or two.
I think the reasoning is that he wants a certain number of BTC per day from his dumping, and so that requires ever increasing numbers of CLAM per day - but the dig chart doesn't support that idea. His rate of digging over time seems pretty constant despite the big price drop.
d) Just-Dice should stop using CLAM and use something else instead, with a predictable supply going forward. It could be a fork of CLAM, so everyone keeps their current balance, but on a separate chain.
This seems much like (b), but presumably without the blessing of the CLAM devs. Such a contentious hard fork isn't good for anyone.
Personally I have no idea what's best. I just know that the current situation is making a lot of people unhappy.
War or PacifismWe are sitting at a crossroads. Either the chain, and original promises of the network are sacred; or they are not. But, even beyond this, the situation is nuanced.
If we do nothing, the price will almost certainly go lower. At a lower price, less demand(BTC) will be required to absorb the supply(dumps). This means that eventually there will be a balance/equilibrium. It is possible that the price falls and at this lower price demand is capable of completely liquidating the digger's CLAM. At that point, if the digger is paying attention, they
could choose to liquidate much more quickly than the present rate. It is important to note, as dooglus mentioned, that this would be a change in pattern from the methodology the digger is currently using to dump - possibly making it unlikely. This maintains the initial "promises" and sanctity of the chain, distribution and network. It also, however, requires what could be a long drawn out period during which supply increases via the digger's dumping. This will almost certainly, inevitably result in a decrease in price/value.
Alternatively, we could choose to quickly act to change the rules of the network. The new rules would dis-allow the transfer of CLAM from the initial distribution blocks. This would prevent additional "claims"
from the time the fork is successfully implemented. There is a great deal of long and short term risk associated with this decision. In the short-term, the digger could choose to dig the CLAM immediately. This, on it's face, is not a bad outcome. At worst, in the short-term, it results in the digger moving and holding/staking his CLAM, moving and dumping his CLAM. At "best", in the short-term, the digger does not notice the change and subsequently loses their CLAM. The long-term implications are more worrisome. Future investment requires some modicum of "trust". One of the enduring and utility providing aspects of a p2p value network such as CLAM is the distinct and protected lack of blacklists. A primary attribute of any value system is what is often called "fungibility". If a network project such as CLAM is willing to protect one class of user over another via removing CLAM from the network..... that is a
very troubling precedent for future users who may be considering storing value in the network.
DiplomacyThere is another option.
This idea came about long before the digger arrived on the CLAM network and was not actually designed or intended to prevent claiming at all.
It does, however, have some impact on future claims.
It can be implemented with various levels of complication and reach; from the extremely simple to all encompassing.
We will talk about a more simple implementation at the moment (which doesn't include block size at all).
I've chosen to go this route as the more complicated versions will only confuse what is already a rather complicated change.
Further, the additional complication concerns fee markets, bloat, DDoS and a variety of other issues which are not currently being discussed.
The concept is deceptively simple:
When markets operate efficiently they find their own balance/equilibrium.In Economics, there is the concept of what is called an "
externality".
The basic implication is that a market can't operate efficiently when there are costs or benefits which are
related to, but not
reflected in the market.
For instance: Air pollution causes a cost on society. Air pollution clean-up should be paid for by those who create it. When it is not, the cost of creating air pollution is arbitrarily held down and the market demand for air pollution creating devices is arbitrarily higher than it should be if it accurately reflected it's "true" cost. Everything we do/create has costs and benefits. When all of those costs and benefits are illustrated in price/value of those actions; the market will, theoretically, provide exactly the appropriate level of supply/demand.
The above is a long-winded explanation; but, it is important that we have a foundation of exactly how important externalities are to an efficient market.
The problem:
The costs and benefits of users utilizing the CLAM network are not properly reflected in the protocol.
When a user makes a transaction on the CLAM network, that transaction must be stored and kept by every node in the CLAM network for what could potentially be
forever.
Transaction fees are currently based on the size of the transaction. This is measured in terms of data storage and enumerated in bytes. It is a per-byte fee.
If all transactions existed on the CLAM network/chain for an equal amount of time - this concept would make perfect sense. They do not.
In actuality, assuming equal byte-size, a person holding 1 CLAM for 1 day on the CLAM network pays the same fee for that storage as a person holding 1 CLAM for 1 million days.
Time is not considered at all; despite the
fact that time is clearly part of the cost equation.
Yet, currently, the one day user pays the same rate as the one million day user.
This discrepancy in time is an externality; an unpaid for benefit enjoyed by the one million day user at the expense of the network.
The solution:
Ensure that costs and benefits of users utilizing the CLAM network are properly reflected in the protocol.
We introduce the element of time into the required fee to transact on the CLAM network.
It is a per-byte-per-block fee.
In this way, the externality/discrepancy of time is reflected in the cost of using the network.
The network/stakers are, essentially, adding the variable of time into the equation of what to charge users for using the network.
This includes those users who have not claimed distribution CLAM yet - they are being charged for storing their CLAM on the network, just as every other user.
The incentives make more sense(staking/security is incentivized, bloat is dis-incentivized) and cost is
more properly, though not perfectly, reflected.
The network/stakers gain an additional source of income, for some time to come, due to the linear rise in cost associated with claiming old/distribution CLAM.
This change is fair and makes free/efficient market sense - regardless of the distribution method that CLAM utilized.
It is not specifically designed to harm claimers, and does not choose or target specific groups of CLAM users.
It does not destroy fungibility.
Assuming a fee market and a competing restriction of space due to a dynamic block size, our DDoS and bloat protections increase.
This change would also require the addition of other positive features:
* Efficient rebroadcasting of transactions via something similar to RBF(Replace-by-fee) or CPP/CPFP(Child-pays-for-parent).
* Fee pooling/smoothing to prevent the incentive to avoid fees via self-staking.
* Sensible wallet logic to make the change seamless to users.
* Likely, a handful of other changes as well.
Regardless of the decisions we make as a community - let us make them together, and CLAM will remain strong.
