The digger has enough and it is time to switch to stake-only )
I think the best solution is for you to update your staking copy of clam to not mine dig transactions and reject blocks with dig transactions if it is the current best block. If it is the second-best and has dig-transactions, it becomes your local best block.
This removes the possibility of prolonged fork, while applying pressure for people to also not accept dig transactions. Most importantly this can be done without modifying upstream or getting into committee driven consensus.
I originally believe in clam because i was told the initial distribution was fair, the fairest you said. But if the only point of clam is to now make a digger rich and get tokens to play on just-dice then count me out.
It sounds like you are suggesting that I should abuse my position of controlling the biggest CLAM address to effectively change the consensus rules - I would be saying "if anyone includes a 'dig' transaction in a block, I will orphan it".
That seems like a massive abuse of people's trust. People deposited their CLAM at Just-Dice with the assumption that I would stake them according to the network rules.
But, how about this for an idea? And it's just a thought I had, not a plan I intend to put into action. Comments appreciated!
What if Just-Dice ran two instances of the client (a regular one, and one that ignored all dig transactions) and allowed JD users to select which instance they want their coins staked with? The default of course is to follow the existing rules, but each user can opt to move their coins to a wallet that considers all new dig transactions as "illegal".
pros:
* the community gets to decide for themselves the future of CLAM, with each member having a vote in proportion to the size of their holdings; if the "economic majority" wants digging to stop, digging stops
cons:
* 1. if opinion is split close to 50/50 then the two clients could cause long reorgs, with associated chaos (confirmed transactions becoming unconfirmed, etc.)
* 2. creating a contentious fork like this feels 'dirty', and a bit too "Bitcoin XT" for my liking
* 3. hard to do this in a provably fair way; how can anyone be sure that I really stake their coins from the correct wallet?
* 4. such a rash move could well lose us the support of the CLAM developers
1. I suppose the 50/50 problem would be addressed the same way that XT forks the chain - only after 75% of the last N blocks somehow 'vote' for the change. ie. wait until a clear majority of the staking weight is in favour of the change happening.
2. idk
3. JD's weekly proof of solvency could include an indication of each investor's 'vote'
4. I know that xploited and creative have both said that they would be in favour of doing something to address the 'digger problem' if the community was in agreement. Maybe this is a way of finding out what the community really thinks.
Anyway, it's just a thought. Let me know what you think...
This process could be completed without scorched-earthing the chain, re: orphans, etc.
It is essentially nothing more than voting - no reason to make it live on chain, unless there is benefit in making the transition period tumultuous.
The only reasoning I can think to make such 'voting' via block consensus as opposed to wetware would be to edge in a restriction on claims prior to a final decision - which would be negligible, imho.
That said, I think everyone accepts and understands that CLAM was created with the intention of applying consensus. This can manifest as users updating their client to new "official" versions, and hence applying new rules, or in the case of JD's commanding presence on the network, a forced fork.
I think there is value in a smooth, thought-out fork and update, as opposed to competition on chain. Though, competition on chain is likely to occur regardless with a large chain to some extent.
I still think a re-alignment of the fee structure is the most logical change that would positively change the dynamics around this digging. This is also, unfortunately, a very complicated and involved change.
However, I believe the
simplest, easiest and quickest to implement "solution" which maintains the original promises of the network AND has a redeemable benefit to the network is to simply require that "digs" are restricted to staking transactions. This restriction would add incentive to stake with the client, require diggers to "contribute" in the process of digging and add some predictability to the rate of "dig" inflation.
It would not remove dig inflation, or take away un-dug coins from users who have yet to claim.
Instead, it would rate-limit and add predictability to the process.
At the moment, a ~4.6 output of CLAM un-dug would take a
great deal of time to stake.
To offset this, you would provide additional weight to "dig" outputs.
This would unfairly impact the stake rewards of currently staking users.
To offset that, you would make dig stakes not give a reward and carry the reward over into a simple pool which is distributed to normally staking users.
Finally, to head-off an attack involving the consecutive staking of increased weight claims, you limit dig staking blocks to odd/even/some_other_proportion blocks.
This ensures that diggers can not stake consecutive blocks and create a security vulnerability.
I still support the more complicated solution; but, these are all relatively simple to implement in code in a timely manner.
In Summary:1. Outputs from block < 10,000 (dig outputs) are only valid as coinstake/staking transactions.
2. Outputs from block < 10,000 are given additional weight to make digging possible in a reasonable amount of time.
3. Outputs from block < 10,000 do not get a reward when staking a block; the reward is incremented into a pool.
4. Outputs from block < 10,000 may only stake even or odd blocks.
5. Outputs from block > 10,000 are given a portion of the reward pool when they stake, to make them whole on lost "dig" stakes.
But, how about this for an idea? And it's just a thought I had, not a plan I intend to put into action. Comments appreciated!
There's my comments.
Way sick of this fucking conversation.
Oddly, this would also give your website a "service" to offer - you would be staking initial outputs for users who do not have a desire to do so and charging a premium for that service.
