Sorry if we have been a bit quiet;
We are trying to take stock and figure out what the best/most helpful way to move forward might be.
The first step will likely involve some type of tool to make it easy to import the walley/keys for less technical users.
One of the reasons we chose not to hold off launch for such a tool, is that we figured a foreign tool would be more off-putting to users.
Using client software that you are familiar with, and using some tool a stranger assures you is safe we figured were two very different propositions.
Plus, we are admittedly more "stimulated" by the technical side of things as opposed to the marketing aspects - sorry in advance if we ever fall short in that regard.
On to posts!
Heh, so if it is txout based (how CLAMs were given), and the dev's didn't try to give themselves a huge advantage, then the luckiest clam holders are probably p2pool miners that never merge their coins into single txouts.
Some major analysis on the CLAM chain and the prior imports is needed I think. Should be very interesting.
In all honesty, this may be possible. We have more than one pool administrator on the team, but it seems none of us has ever administered a p2pool. I have personally mined p2pool, but at the time wasn't overly interested in whether or not the incoming coinbase transactions were routed to one address or many.
That said, if I am not mistaken, don't you use your wallet address as the worker name when you mine p2pool?
If that is the case, and your incoming payments are routed there (I believe that is how it works) -> then this wouldn't be a concern.
Addresses with more than one unspent output were still only counted once in the distribution, and additional occurrences would have been weeded out when duplicates were eliminated.
An interesting issue though, we would be interested to hear from any users who have a great deal of knowledge concerning p2pool.
Did you run -salvagewallet during the first load? Otherwise your wallet.dat will hold tx information for invalid tx's, thus the "too high" and "negative" errors i suspect.
Yes... There are still tons of exceptions in the debug.log with -salvagewallet.
Renamed wallet.dat to wallet.1401006085.bak
Salvage(aggressive) found 1210 records
:
ERROR: CTransaction::CheckTransaction() : txout.nValue too high
ERROR: CTransaction::CheckTransaction() : txout.nValue negative
WARNING: CWalletDB::Recover skipping key:
Dratts! I am not the resident expert on the team, and they happen to be sleeping at the moment, but I know in my personal testing I certainly never ran into this issue.
In the interest of attempting to be useful, and the risk of sounding un-informed while the real brains of the operation slumbers:
Might it be worth a go to do a sanity check and start the import from scratch again?
Of coarse, always have a BACK-UP, especially when I don't have the wallet guy here to ensure I'm on the right track
I.e. Delete the entire AppData/clams/ folder, make sure the source client (BTC/LTC/DOGE) is NOT running (check tasks, give it a minute to finalize the DB as it shuts down), launch the CLAM client alone with the generated wallet, letting it sync, shut down the CLAM client ensuring that it also shuts down and detaches the DB, then move the import wallet.dat into the folder and run with "--salvagewallet".
Another command line argument that might (don't quote me please) be helpful: "--rescan".
Possible console commands that might be helpful: checkwallet, repairwallet.
I wouldn't be horribly surprised if all of that was drivel -> but that is the type of wack-a-mole procedure I would go through given I was flying solo, trouble-shooting and knew I had a safe and sound back-up lying about.
Frankly, when we first got the framework set-up, I imported a wallet in all three chains to make sure all was working as planned (one of which was a very active pool wallet) and didn't run into any issues at all.
Kind of has me stumped
I only really use my Android wallet so I can't get these
That should not be true.
The majority of wallet providers that I am aware of do provide some means to gain access to your privateKeys. At bare minimum, using an open-source tool such as pywallet.
^ However, we don't expect the average user to be able to consistently get that accomplished. That is why one of our major next priorities is to begin chipping away at the dozens of wallet solutions for tools and tutorials that can help ease the import and transition for new users.
If anyone has a knack for explaining things in a less... superfluous..... manner, and some knowledge of how the wallet and key system works... We would certainly welcome help in getting all of this together with open arms. Unfortunately, we do not have any conventional bounties or what-not to bribe you with - it would have to be just because you want to help out fellow CLAMS in getting their coins
Every community needs ambassadors
I will say this for the devs.
They have not removed negative comments from the thread.
They have replied to people's concerns and tried their best to answer them. They have done this in a mature and measured way which scam coins, if they are one, very rarely do.
I am not involved with them and will not be installing clam.
But I offer my respect for their endeavours - even if I think they are little misplaced - and the effort they have put in to both create clam in the first place and to resolve the questions that have been asked.
I have a growing feeling that their intentions may be honourable - but the complexity of installation, the uniqueness of the coin distribution and the cloud of unknowing that surrounds it all is putting a lot of people off.
Good luck.
Thanks for vote of semi-confidence
I still hope to some-day convince you to get your CLAMS
Give it some time though, we knew going into this that it was sensitive and would take a bit for people to understand and be willing to go through the process.
From which date was the data dump? I only have one btc private key from a multibit wallet that held different amounts of btc in the recent past, but unfortunately importing it to the CLAM wallet didnt yield any CLAM, so I guess the data dump was made before I received btc on this address
The data dump was from roughly a week ago now, possible a tad more than that. We ran into some problems with the send script if we stacked too many outgoing transactions into the mem-pool or set the block speed too high during the sending process, so the server ran non-stop for quite a period of time rolling out the sends.
Long story short, it took a while. We tried to hurry and get everything in order for the launch as quickly as possible, but alas, things never move quite as quickly as one would hope.
Assuming you had coins in your wallet during that time period, and you didn't attempt to import a single key (as the coins might have been at what is called a "change" address at that time), they should be there!
From which date was the data dump? I only have one btc private key from a multibit wallet that held different amounts of btc in the recent past, but unfortunately importing it to the CLAM wallet didnt yield any CLAM, so I guess the data dump was made before I received btc on this address
How did you do this?
first make sure you understand that you shouldnt be exposing a private key to a address that still hold coins, so understand it and dtake the appropriate measures.
on multibit go tools -> export private keys
select "do not password protect" so you can read the keys in plaintext, then export it to a file, read the file in a text editor and copy the private key(s)
on CLAM go to help -> debug window -> console
importprivkey x (where x is the private key you are importing)
restart clam and launch the wallet with the -salvagewallet argument
See! That is just the type of enthusiasm I was talking about when I mentioned community ambassadors
Sure your not just dying to write up a plain english tutorial for Multi-Bit?
I kid, I kid; but if by chance your willing, I think everyone would really appreciate it!
Seeing how the dev's have reacted so far, and the system seems to be working well, this could be a very interesting experiment.
What is missing, is a proper UI for importing private keys in the core client.
Agreed, 100%
I think we were in a bit of a 'bubble' as they say.
"Using the --salvagewallet parameter is a great method for users! I mean everyone knows how to do that and it doesn't get any simpler! We can write up the Omni-Tool for importing later when non-crypto-community users start to get interested!"
^^ Sometimes it is too easy to forget that not everyone understand a terminal and command line arguments.
Sincere Apologies -> that we intend to retract sometime in the near future after we hack, slash, and hammer out a better solution
Phew!
Enough for now!
Think CLAMS is a cool idea?
Let the exchange
Poloniex know how you feel!
Might be just the nudge they need to join the CLAM party
