[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[smooth]

About the current/future whale diggers, one possibility I haven't heard mentioned would be very simple and would dilute the initial distribution: increase the reward. There's at least a precedent for changing the reward system in Clams.

That certainly has a couple of benefits over decreasing the 4.6 CLAM reward:

It might also very well prompt a massive increase in the rate of digging. This digger very likely sped up his digging in response to talk of a fork that would prevent him from digging the rest. If a big increase in the staking rate is proposed, others will likely accelerate their digging as well.

Instead we should leave well enough alone, stop creating more evidence in support of the law of unintended consequences, and allow confidence to recover. With the damage that is already done that will take some time already, but it can happen.

1) We don't have to break any promises. "If you owned BTC you may already own CLAM!" stays true. The 4.6 per address that you "may already own!" stays there. We aren't accused of deleting people's property.

No, you will be accused of diluting people's property instead. Congratulations.

It's a rolling window of 1 week. It's not like a petition has a week to gather support. It lives until it gains 50% (or whatever) support over any 1 week period

What happens when support subsequently changes after the 50% support is reached? Coins change hands, opinions change and suddenly something that had 50% support last week doesn't this week. This week being an excellent example since apparently 200K+ coins have apparently changed hands.

The most meaningful proposals will be ones that are ready to implement quickly if supported. Otherwise the voting should continue and the 10K window be viewed as just that, an ongoing "window" into current opinion of stakeholders. Or alternately a second vote can be held at a later date to reaffirm, once an implementation is ready.

This of course won't be an issue for uncontroversial proposals that will get significant support regardless of the time window. It is my hope that stakeholders are enlightened enough to decline to vote for controversial proposals where the inevitable conflict will cause damage to the community even if they personally believe the idea is a good one (and instead work to educate the community such that if the idea really is a good one, support can be achieved). This will force those putting forth a proposal to craft it in a manner that gains overwhelming support instead of trying to use the voting mechanism as a PR tool to legitimize a 51% attack. I'm not entirely optimistic, but we will see.

[smooth]

If I don't use -staketo  where do they end up going?  Just to the same address that staked?

Yes

[USB-S]

By removing the core distribution process from clam, would kill this coin.

Yesterday Creative posted her draft "CLAMour" voting proposal, allowing the community to vote whether they want to change things like the distribution process. The coin didn't die.

However they didn't change the initial distribution method. Voting is just an extra feature to let community decide.

If you can't take the volatility of an altcoin you shouldn't even be here. You still have the option of cashing out before the digger dumps the rest of his stash. Give the market some time to shift into place.
Clam will end up being around 10k sats before it starts rising again.

CLAM hit a low of 72k then a high of 300k a few hours ago:

The digger now claims to have sold his remaining CLAMs. The price started rising as soon as he said this.

Is there any proof that this is true? If I recall correctly he had over 300k coins left. How do we know that he just didn't say that just to pump the price up before he dumps on us again.

[smooth]

By removing the core distribution process from clam, would kill this coin.

Yesterday Creative posted her draft "CLAMour" voting proposal, allowing the community to vote whether they want to change things like the distribution process. The coin didn't die.

However they didn't change the initial distribution method. Voting is just an extra feature to let community decide.

Some skepticism is warranted given the basic premise that you don't ask a question when you don't already have some expectation that you will like the answer. Someone decided to implement this feature and roll it out on an accelerated schedule. Consider what that implies.

I'm hopeful that the community (including some insiders who almost certainly own a lot of coins themselves) will rise to the occasion, stop being manipulated by FUDding short sellers, and leave the distribution alone.

[smooth]

JD bankroll just crossed 1 million.

[USB-S]

By removing the core distribution process from clam, would kill this coin.

Yesterday Creative posted her draft "CLAMour" voting proposal, allowing the community to vote whether they want to change things like the distribution process. The coin didn't die.

However they didn't change the initial distribution method. Voting is just an extra feature to let community decide.

Some skepticism is warranted given the basic premise that you don't ask a question when you don't already have some expectation that you will like the answer. Someone decided to implement this feature and roll it out on an accelerated schedule. Consider what that implies.

I'm hopeful that the community (including some insiders who almost certainly own a lot of coins themselves) will rise to the occasion, stop being manipulated by FUDding short sellers, and leave the distribution alone.

My hope for the community is the same.

The distribution debate is much like the block size debate. In the end the community will most likely chose what's best for the coin to survive.


Gz on JD for making bank

[TooDumbForBitcoin]

JD bankroll just crossed 1 million.

dooglus needs to invent a tradeable JD instrument that polo can list.  that way people can participate in JD (and CLAMs?) without dooglus holding all the CLAMs.

Is this a good CLAMidea, or is my CLAMidea bad, by definition?

inb4 anybody else who thinks I'm a CLAMidiot

[jaysabi]

The CLAMour voting system looks interesting. Good work!

About the current/future whale diggers, one possibility I haven't heard mentioned would be very simple and would dilute the initial distribution: increase the reward. There's at least a precedent for changing the reward system in Clams.

Maybe I'll make a CLAMour petition to increase the reward from 1 clam per block to, oh, say, 100 clams per block. This would increase the supply by about a million clams a week. Before long the initial distribution would be a relatively small percent of the total supply.

This would likely be terrible for the price. It might push us below 0.001. (<- That's intended as dark humour. I have looked at the price today.)

The problem isn't the ratio of initial distribution to total float, it's inflation as a whole. The whale digger only accelerated a problem that is inherent to CLAM. Creating faster inflation to make whale digger inflation smaller by comparison doesn't solve any problems.

[dooglus]

how long do clams have to sit there before they start staking?

They need to have not been involved in a transaction for 4 hours, and not involved in staking for 500 blocks (or around 8 hours). That's before they will start trying to stake. After that it's just down to luck how long it takes.

[dooglus]

If I don't use -staketo  where do they end up going?  Just to the same address that staked?

They stay at the same address, yes.

[jaysabi]

Our CLAM - The CLAMour Specification

Looking great. Thanks for all the work put into this. Not sure about the 10,000 block time frame though, it doesn't seem like enough time for a real vote to occur. Is the Clamour name a take on the word clamor?

About the 10,000 block frame: That's a moving frame. There is no deadline for votes; instead, whenever >50% of blocks staked in any 10,000 block window express support of a petition, that's considered a majority. So in effect, the vote can occur any time.

Is there no way to defeat a proposal then? All proposals are simply pending until they reach consensus?

[smooth]

Our CLAM - The CLAMour Specification

Looking great. Thanks for all the work put into this. Not sure about the 10,000 block time frame though, it doesn't seem like enough time for a real vote to occur. Is the Clamour name a take on the word clamor?

About the 10,000 block frame: That's a moving frame. There is no deadline for votes; instead, whenever >50% of blocks staked in any 10,000 block window express support of a petition, that's considered a majority. So in effect, the vote can occur any time.

Is there no way to defeat a proposal then? All proposals are simply pending until they reach consensus?

It's just a survey of opinion of stake holders over a time window, nothing more. It can't bind future stakeholders or even the same ones at a later time. If someone were to interpret it as "approval" and try to push through a soft fork on that basis where opinion had later shifted against, the fork would fail. Conversely if someone proposes a soft fork that previously failed to gain support in a survey but was later supported by a majority of stake holders, that fork would probably succeed.

Some sort of mechanism for timing them out to avoid clutter might be reasonable. At that point if there is still interest in continuing to measure stakeholder opinion on that question, it could be resubmitted.

[rocoro]

Dooglus or other devs..  I need help.

I'm using the daemon on linux.   I don't know how to explain this, I'll try.

How do I do the splitting '{"count":c,"amount":a}'  thing but within the same wallet - after having done once before with new coins that I deposited to wallet,  I'm finding that it might "pull" from the other address to do the splitting ... and mess up. 

So,  like how do I just split *from* the one address without having touched or messed with coins sitting in other addresses??? 

Does that make sense?

Thanks in advance..

[dooglus]

So,  like how do I just split *from* the one address without having touched or messed with coins sitting in other addresses??? 

Does that make sense?

It makes sense, but I don't have a good answer for you. For some reason, coin control (input selection) was added directly to the GUI and isn't available from the command line, and the count,amount stuff is only available from the command line, not the GUI. So you get one or the other.

Possible workarounds include making a separate wallet and importing only the private keys you want to spend from, or using raw transactions (create|sign|send)rawtransaction to manually select the inputs and outputs (createrawtransaction accepts the same count,amount syntax), but be careful with that, because you need to calculate the 'change' yourself. If the inputs sum to more than the outputs, the difference is considered a transaction fee.

[rocoro]

Possible workarounds include making a separate wallet and importing only the private keys you want to spend from

I made a separate wallet.dat,  had coins deposited to that, then just did the splitting from there to an address that is in the other wallet.dat.
I don't know if that's ok, but seems to have worked.... ?

[smooth]

Possible workarounds include making a separate wallet and importing only the private keys you want to spend from

I made a separate wallet.dat,  had coins deposited to that, then just did the splitting from there to an address that is in the other wallet.dat.
I don't know if that's ok, but seems to have worked.... ?

Yeah that's a good approach and that's what I'm doing for the pool. If you've already mixed outputs of different sizes in one wallet you can use splitto to get them split down as they stake. I'm also using that in the pool since the first couple of investments went together with some already-split coins.

[romjpn]

JD bankroll just crossed 1 million.

Good indicator that investors are remaining confident indeed. Let's go back to that 1~1.5$ range   .
Now we should try to get on a major exchange for example, with a DOGE/USD pair. It would be good to be integrated directly into some payment gateway as well, like DOGE with GOcoin.

[dooglus]

It might also very well prompt a massive increase in the rate of digging. This digger very likely sped up his digging in response to talk of a fork that would prevent him from digging the rest. If a big increase in the staking rate is proposed, others will likely accelerate their digging as well.

That's OK. I would prefer inflation now over lingering uncertainty.

Instead we should leave well enough alone, stop creating more evidence in support of the law of unintended consequences, and allow confidence to recover. With the damage that is already done that will take some time already, but it can happen.

It's not clear to me how much of the drop in price was due to fear of the digger dumping and how much was due to potential buyers being put off by the talk of a change to the rules. I suspect it's much more the former than the latter, but I know you think the opposite.

1) We don't have to break any promises. "If you owned BTC you may already own CLAM!" stays true. The 4.6 per address that you "may already own!" stays there. We aren't accused of deleting people's property.

No, you will be accused of diluting people's property instead. Congratulations.

True enough. It's impossible to please everyone.

What happens when support subsequently changes after the 50% support is reached? Coins change hands, opinions change and suddenly something that had 50% support last week doesn't this week. This week being an excellent example since apparently 200K+ coins have apparently changed hands.

That's an issue with this CLAMour thing. It's possible to buy votes, in the form of CLAMs. You need 500k CLAMs or so to get 50% support for your petition, so maybe for a million dollars you could get your petition some attention.

The most meaningful proposals will be ones that are ready to implement quickly if supported. Otherwise the voting should continue and the 10K window be viewed as just that, an ongoing "window" into current opinion of stakeholders. Or alternately a second vote can be held at a later date to reaffirm, once an implementation is ready.

This of course won't be an issue for uncontroversial proposals that will get significant support regardless of the time window. It is my hope that stakeholders are enlightened enough to decline to vote for controversial proposals where the inevitable conflict will cause damage to the community even if they personally believe the idea is a good one (and instead work to educate the community such that if the idea really is a good one, support can be achieved). This will force those putting forth a proposal to craft it in a manner that gains overwhelming support instead of trying to use the voting mechanism as a PR tool to legitimize a 51% attack. I'm not entirely optimistic, but we will see.

Yes, "we will see" sums up how I feel about it pretty well.

[dooglus]

The next 24 hours are extremely busy for me; I will try to check in periodically if I can.

dooglus will likely keep us updated on the progress of the UI for the users of Just-Dice.

Initially I was thinking I would allow Just-Dice users to enter any 8-digit petition-IDs they wanted to, and use those in the CLAMspeech when staking blocks. Each user would get their fair share of chances to stake a block based on their investment size.

Then I figured it would be better if I only allowed 'voting' for petition-IDs which had been correctly registered with a 'create clamour' message.

So I set about making changes to the client to have it track valid petition-IDs.

The place to track them is in the block index, so you don't have to keep re-parsing the CLAMspeech every time you start the client. That means I need to change the block index database format, and so users will need to "clam-qt -reindex" after upgrading.

Except it turns out that -reindex doesn't work, and never has. So I set about fixing that. I have some code which now does make the wallet try to reload the blk0001.dat file when you ask it to -reindex.

Except it turns out that when loading my blk0001.dat file (which I know contains all the valid blocks), it gets stuck. Like this:

2015-11-30 04:01:48 SetBestChain: new best=dcfa7e4952dc67913af4e6411136f0a944a69397fa74a2006d81d5c58961ef4a  height=230252  trust=992559058268678270  blocktrust=47672287752932  date=11/29/14 19:38:24
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230252 timestamp=2014-11-29 19:38:24 UTC for block from timestamp=2014-11-19 05:09:04 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1416373744 nTimeTxPrev=1416373626 nPrevout=18 nTimeTx=1417289952 hashProof=0000464a6d7fdf299d6cb552ed2183e932c3e72c686745a2d38fccd57b76dc1e
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230252 timestamp=2014-11-29 19:38:24 UTC for block from timestamp=2014-11-19 05:09:04 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1416373744 nTimeTxPrev=1416373626 nPrevout=18 nTimeTx=1417289952 hashProof=0000464a6d7fdf299d6cb552ed2183e932c3e72c686745a2d38fccd57b76dc1e
2015-11-30 04:01:48 SetBestChain: new best=793a7f762ea19e0960c61e7151e6103c63f4e5962493bbceae1cfe5a6c73425d  height=230253  trust=992606706175219479  blocktrust=47647906541209  date=11/29/14 19:39:12
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230253 timestamp=2014-11-29 19:39:12 UTC for block from timestamp=2014-11-29 10:20:48 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1417256448 nTimeTxPrev=1417256448 nPrevout=1 nTimeTx=1417290096 hashProof=0000170c754848f3ea304426c91bee86653722588093902247c03d79693d572d
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230253 timestamp=2014-11-29 19:39:12 UTC for block from timestamp=2014-11-29 10:20:48 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1417256448 nTimeTxPrev=1417256448 nPrevout=1 nTimeTx=1417290096 hashProof=0000170c754848f3ea304426c91bee86653722588093902247c03d79693d572d
2015-11-30 04:01:48 SetBestChain: new best=fe68e35cea86b443c9a627a23a683dfa244e3409dad55a2c980df19cd0b3e369  height=230254  trust=992654354081760688  blocktrust=47647906541209  date=11/29/14 19:41:36
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230254 timestamp=2014-11-29 19:41:36 UTC for block from timestamp=2014-11-22 14:33:52 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1416666832 nTimeTxPrev=1416666832 nPrevout=1 nTimeTx=1417290112 hashProof=0000a92cb4a5e765047b4533ae01f26d97f2836f5404a733c506d617e490d66f
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xd891dd792afb83b0 at height=230254 timestamp=2014-11-29 19:41:36 UTC for block from timestamp=2014-11-22 14:33:52 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xd891dd792afb83b0 nTimeBlockFrom=1416666832 nTimeTxPrev=1416666832 nPrevout=1 nTimeTx=1417290112 hashProof=0000a92cb4a5e765047b4533ae01f26d97f2836f5404a733c506d617e490d66f
2015-11-30 04:01:48 SetBestChain: new best=7f8a17cf772ee23d824f1c691c7b5185c509aa231fcf39d1809960099fe61a87  height=230255  trust=992701953177795485  blocktrust=47599096034797  date=11/29/14 19:41:52
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xb87513256eaf240d at height=230255 timestamp=2014-11-29 19:41:52 UTC for block from timestamp=2014-11-19 22:59:44 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xb87513256eaf240d nTimeBlockFrom=1416437984 nTimeTxPrev=1416437964 nPrevout=674 nTimeTx=1417290144 hashProof=00008f23d6df7658fd16a7c2065de6eb071e8031221ba97496de482c0620bbb0
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xb87513256eaf240d at height=230255 timestamp=2014-11-29 19:41:52 UTC for block from timestamp=2014-11-19 22:59:44 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xb87513256eaf240d nTimeBlockFrom=1416437984 nTimeTxPrev=1416437964 nPrevout=674 nTimeTx=1417290144 hashProof=00008f23d6df7658fd16a7c2065de6eb071e8031221ba97496de482c0620bbb0
2015-11-30 04:01:48 SetBestChain: new best=5812e11089399a7d41f5675bb5a1aed7f4ddf1e0c9e7ab7c78ff59738958d10f  height=230256  trust=992749503563224479  blocktrust=47550385428994  date=11/29/14 19:42:24
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xb87513256eaf240d at height=230256 timestamp=2014-11-29 19:42:24 UTC for block from timestamp=2014-11-29 04:37:52 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xb87513256eaf240d nTimeBlockFrom=1417235872 nTimeTxPrev=1417235872 nPrevout=1 nTimeTx=1417290160 hashProof=000011528c9dc4f88dbb95bf274d03b4ab654fd130cc98fe37d2f2719b3ad0d7
2015-11-30 04:01:48 CheckStakeKernelHash() : using modifier 0xb87513256eaf240d at height=230256 timestamp=2014-11-29 19:42:24 UTC for block from timestamp=2014-11-29 04:37:52 UTC
2015-11-30 04:01:48 CheckStakeKernelHash() : check modifier=0xb87513256eaf240d nTimeBlockFrom=1417235872 nTimeTxPrev=1417235872 nPrevout=1 nTimeTx=1417290160 hashProof=000011528c9dc4f88dbb95bf274d03b4ab654fd130cc98fe37d2f2719b3ad0d7
2015-11-30 04:01:48 SetBestChain: new best=b38d40e2670d3193e4fbb041ba03987e7037d2664fa44858969d07926f0979c2  height=230257  trust=992797005337641892  blocktrust=47501774417413  date=11/29/14 19:42:40
2015-11-30 04:01:48 ProcessBlock: ACCEPTED
2015-11-30 04:01:48 ERROR: ProcessBlock() : duplicate proof-of-stake (COutPoint(33bb7c7471, 1), 1417290096) for block 5db0b2b31f4f6b8ed11031c3782cf48dbbee8cae45a9d2ddedd474a72c59b947    "height" : 230254,
2015-11-30 04:01:48 ERROR: ProcessBlock() : duplicate proof-of-stake (COutPoint(41ec06a7dd, 1), 1417290112) for block 35e0d330e75dbc20a0c6f3030f13811d7a82e8c0d3568df78f6d1202521adabc    "height" : 230255,
2015-11-30 04:01:48 ERROR: ProcessBlock() : duplicate proof-of-stake (COutPoint(cfbeb87f48, 674), 1417290144) for block e57018e94e9857e83eb3b0e9a4d70d2202853a076e091db342b9b19d2c1f0a32    "height" : 230256,
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=e57018e94e9857e83eb3b0e9a4d70d2202853a076e091db342b9b19d2c1f0a32    "height" : 230256 in real chain
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=c8703390494e472a59b6aabc216a7f26e57dc817e2202a98b995dd462d22f2f3    "height" : 230257 in real chain
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=074ea8da9cd6ae3a51353508f96956955cf4a13fa0be239f9b15b2081b09c610    "height" : 230258 in real chain
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=510c0f05358658783b67b2a1f5fe51828c408735848273e84eb850426f86ce41
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=91be5991b706661f1567f91c0caa8d7b7fb3f97426533dc6ca754b4a66e20ec1
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=c1bd50724722570a3c8edc9193c4e4afd60721331fb5e42077703bbbf8d65ff9
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=91be5991b706661f1567f91c0caa8d7b7fb3f97426533dc6ca754b4a66e20ec1
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=a740cbc91995360bd956aa8983fe30a35f7336dfebfbf4c2e4d9388cffcf577f
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=8451a72733e0e52cd3bbcd7a1af42d5ca1807c456e9a2f9efeff400b3214c32e
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=b59029a8485ce7887f69d38acd974b5d2b54edf830d73262d6f43ed24457ce2f
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=fd6773c2752d7340e2ce02611c17a7e13fd7cc8263a358e42a3c35d821f7441d
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=912fe8ef120f4421be4808d99b8550392aabc40241759e84a58441e9bf9f0d56
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=956e1b3fd78e7dd4d58eb6b66a9b1ea5b01096fc0ea1e7128110cb5b9dcd1eda
2015-11-30 04:01:48 ProcessBlock: ORPHAN BLOCK 0, prev=da0c90177d0f706177d6693b9504d5fb731352bdd83c7c1dbf47ea4ac08a02d6

This is very likely the same bug that was reported recently - the client is unable to sync the chain over the network without multiple restarts. It is also unable to sync from a local blk0001.dat file if it contains a few orphan blocks with duplicate proofs of stake in them.

So that's where I'm at - bogged down in the reference client's C++ code, trying to figure out how to get it to -reindex properly.

[freedomno1]

I'm all out of CLAMs. I sold 50 btc at 0.00076 and about 50 btc more around 0.0008. That's it for me. The price should go up now. Great for those that got in at such a cheap price!

Good to hear, enjoy your Btc
Interesting recovery