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

Is there a way to import the (DOGE) private keys?

The console's importprivkey gave me


Thanks

So why does one say 15.09M and the other says 14.91M?

Where's the missing 0.18M CLAM? It was burned after distribution:

http://khashier.com/address/xCLAMBURNXXXXXXXXXXXXXXXXXXX1HaxZH

Total Received   179551.63935654 CLAM

troll box using /supply

00:56:17 INFO: 28,357 of 3,208,032 sets of 4.60545574 CLAM were dug up so far from the initial distribution
00:56:18 INFO: 130,593 CLAM were dug up and 138,120 CLAM were staked for a total of 268,713 CLAM
00:56:18 INFO: if all the distributed CLAMs were dug up, the total money supply would be 14,912,522 CLAM

Currency   Code   Block   Time   Started                   Age (days)                    Coins Created        Avg Coin Age   % CoinDD
Clam          CLAM   242454   2014-12-08 08:39:28   2014-04-14   237.448   15092053.16439007   202.338   1.23692%


  CLAM's market cap is about 41500 BTC, a top 10 coin

I don't use multibit and haven't looked at this, but AK was on the site earlier and said:

.014 BTC each valid address according to www.claams.com... your time must be worth a lot

/dig gets them without trusting any download via www.Just-dice.com

Chrome won't let me open the zip file for the software. Kinda shady.. I've looked and I have several addresses that have been sent clams, but the problem with Chrome thinking the zip file is shady, the low price of clam, and the inconvenience of obtaining the privatekey and moving funds around doesn't make this a worthwhile endeavor for me.

The priv key needs to be in QT form.

BE SURE TO EMPTY THE ADDRESSES PRIOR TO CLAIMING CLAMS.

Worth a read (the whole FAQ not just this link)

https://just-dice.com/#a26

how can i import my multibit private keys to clam wallet i get an error URI CANNOT BE PARSED

It's in satoshis.

I made a few changes to this stuff recently for the next release, so the estimate is much better now.

Here's how it looks on the JD bankroll wallet:

$ clamd getstakinginfo | grep -e weight -e expect
    "weight" : 59535.05603665,
    "netstakeweight" : 192234.98843445,
    "expectedtime" : 210

That's saying JD has 59k of 192k staking, and expects to stake a block every 210 seconds, which sounds about right.

Edit: if you're wondering why the weight is 59k when the bankroll is 66k, it's because recently moved and recently staked coins don't count. Coins need to rest for 510 blocks after staking, and 4 hours after moving before they can stake, and during that resting period they don't contribute to 'weight' (or netstakeweight).

Big deposits get split up the first time they stake, like this:
  http://khashier.com/tx/f92d43d0788e9f937f032b1101a81874769a7cf9baf9536481973cb385787a7f

It'll be out of action for 8 hours (510 blocks) but then will be fine as after than, only a few blocks of 4 CLAM at a time will be resting.

The numbers are not correct, they'll be fixed in the next update.   Although, the network weight is correct, just it should be divided by 100000000 to get a more expected number.   

Anyone have any ideas why my network-weight is showing impossibly high? I'm fully synced and am following the block count according to the block explorer.

  whats happening or did I just read the chart upside down

I made an updated bootstrap.dat file for people having trouble syncing their client.

It goes up to block 4075017 which was staked on Thu Apr 14 21:15:07 UTC 2022.

It's available here:

    bootstrap.dat

Download it, put it into the same folder as your CLAM wallet.dat, then restart the client.

If you are using the QT client, it will say "importing blocks" in the lower left corner while the bootstrap.dat file is imported. That is how you can tell that the file is being used. It will take a while to import it, but it will be a lot faster than trying to sync using the p2p network. When it is done, the client will rename the file to bootstrap.dat.old and won't look at it again. Once it has been renamed you can delete it if you like.

To verify that you have the right file its size is 4053221580 bytes and its sha256 hash is a218e2a508c9cc019ed106b0de328dde40cce45de2ca829a5054e27959227fa3.

There is also a folder called 'partial' which contains a collection of smaller files, each with 100k blocks in them.

Download whichever ones you need and either import them one at a time by renaming each one to 'bootstrap.dat' in turn and restarting the client for each, or append them all together into a file called 'bootstrap.dat'.

In Windows you can append the files together by running cmd, and using something like:


In Linux the command would be:

Scammers already rolling out in about 1/2 force.

Careful out there with y'alls CLAMS.

This is absolutely on point, and articulate as always. I hadn't considered a few of your points, especially a scammer tricking someone into sending then a message signature they could use to redeem the clams.

How you suggest doing it was exactly what I had in mind, and your right, it would need careful consideration.

I am a big supporter of the bitaddress style page that could allow everything to happen safely offline, its a great idea imo. As for moving the information, a usb key, while it does have some associated risk is a reasonable option.  there are also QR codes which would be easier if you were using a mobile device with a camera.

Offline signing seems like it should be looked at first. It provides a level of security that you can be sure your private keys are not going anywhere and requires no modification to the protocol.

 

That CLAM address *is* your own. Its private key is the same as the private key for the 1L2G BTC address you own.

The question is how you get access to the coins it controls.

You could import your wallet.dat file containing the BTC private key into the CLAM client. But maybe you don't trust the CLAM client not to steal your BTC.

You could use the /dig command on JD, giving it the BTC address and the BTC privkey. But maybe you don't trust JD not to steal your BTC.

The recommended way forward is to move any BTC from your old wallet into a new wallet and then import the whole wallet into the CLAM client - because they way you also get to claim any CLAMs that are in old change addresses that you may not even know exist.

Alternatively, you can move the balance from just that address to a new address, then get the private key for the address (> dumpprivkey 1L2G... in the bitcoin wallet debug console), and then "/dig 1L2G... PRIVKEY" in JD. That will move the 4.6 CLAM from the xTKu address to your JD deposit address.

I think it's too late for that now, anyway. The way things are set up, distribution CLAM coins are at addresses which have *the same* private key as the corresponding BTC/LTC/DOGE addresses.

I guess a change to the protocol could theoretically allow it, and I don't think the ambiguity you mentioned is important - if I can sign a message with the BTC form of a private key, I can trivially convert the private key to DOGE, LTC, or CLAM and sign a message with that form instead. So the protocol would need to modify the meaning of "OP_CHECKSIG" to be "the provided signature is valid for the provided pubkey (as before) OR (the input being spent was created before block 10k AND the provided signature is a valid message signature of "CLAMDIG" as signed by the BTC, LTC, or DOGE address corresponding to the provided pubkey)".

Then people could dig up their outputs without needing to provide anything more than a useless message signature.

There's a risk that people could be tricked into providing a scammer with a message signature that the scammer can then use to dig up the victim's CLAMs.

Oh, but there's a bigger risk that the scammer just scans the network for people digging up their CLAMs using message signatures, and modifies the outputs of those transactions to send the dug CLAMs to their own address... to prevent this, the message to be signed would need to include the destination address rather than being a constant (like "CLAMDIG" above). Then what if there are multiple destination addresses. We can limit this kind of transaction to only work with a single destination address (then the scammer sends 0.001 to the destination address and gives the rest to the miners, so we have to fix the amount too, to be 4.60xxx minus the 0.0001 fee - etc.)

I think in theory it's possible to find a workable solution that would allow people to safely dig up their distribution CLAM using just a signed message, but it would need careful consideration.

Here's how Just-Dice digs up CLAMs and sends them to users' deposit addresses:


There's not much to it, and it doesn't require anything online at all to work, just a running clamd instance with a copy of the blockchain. You could remove the blockchain requirement too if you provided the unspent output's scriptPubKey to bitcoin.signRawTransaction's 2nd argument (it's [] in the code above, because I know my clamd will be able to find the details it needs in the blockchain):



The 'redeemScript' part is only needed for spending P2SH outputs, which we aren't.

So the 2nd argument can be something like:

'[{"txid":"dbdd78f351c4d316fa8ab8613ccd7937fdd095ef86297f4f7d4e616455ad23df","vout":1,"scriptPubKey":"76a914339caf9d4692d9cf981470abcba485844d73a74888ac"}]'

I can imagine an offline page (like bitaddress.org) which takes:

* txid
* vout
* scriptPubKey
* destination address
* privkey

and outputs a signed raw transaction that moves the standard CLAM distro amount from txid:vout to the given destination address. The first 4 of those could easily be provided by the /dig command on JD, for copy/pasting to the offline machine (somehow).

Not sure I follow the question. 

Did you use the /dig command on just-dice.com?    if so they would be automatically put into your balance at just-dice.com   

If your bitcoin address corresponds to  1L2GCsKR....   then that does look like the correct clam address.