Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 213. (Read 1151373 times)

He claims to have:


I bought 10k CLAMs at 0.00082, and know of several others who bought similar or large amounts at around the same price.

There's no guarantee that the new buyers won't be selling or that a new digger won't appear. But for now it seems the downward price pressure is on hold.

True. I noticed the stake weight too.
Thanks.

If you believe what he says, yes. Beyond that it is impossible to know.


Other people, including whoever supposedly bought his 100 BTC worth of CLAMs, might dump.

The stake weight on the network has gone up by about 200K CLAMs, so someone is staking coins that weren't be staked yesterday. That is unambiguous.

Does the whale digger really sold all his CLAMs yesterday? No more dumps?

That's an issue, but not the issue I raised.

Indeed... Polo's fees will add up quickly while you're faking market activity by buying your sell orders back.

Gullable as you may be.. your shillery makes you an accessory to this fraud/ crime.

Speaking of which..
https://bitcointalksearch.org/user/creativecuriosity-210646

Any day now with the taking down of your scam promo/sig, "Creative".

Good to hear, enjoy your Btc
Interesting recovery

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:


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.

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


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.


True enough. It's impossible to please everyone.


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.


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

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.

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.

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

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.

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

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.

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

They stay at the same address, yes.

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.

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