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

[nioc]

any one had success to get Clam in electrum wallet?
and how long coins will mature its been 16 days now my coins havent stake yet.. last stake 11/21/2014

You might want to view   https://bitcointalk.org/index.php?topic=612143.0  

It explains a way to generate the addresses and private keys based on your master seed.  I'm not an electrum expert but it appears it wouldn't keeps them around after the funds have been moved.  You will likely have to regenerate them again.  

I would personally generate a good amount and import them all.  It would likely be tought to determine where to stop.

If that makes any sense, I'm tired and about to pass out here.

Hope it helps!

thanks for the link...i read it... its too complicated....

??

[1714030926]

1714030926

[1714030926]

1714030926

[1714030926]

1714030926

[1714030926]

1714030926

[Aggressor66]

wallet will not sync 

[xploited]

wallet will not sync  

The bootstrap
https://bitcointalk.org/index.php?topic=623147.msg9617230#msg9617230  

and  

http://blocktree.io/peers/CLAM/

should resolve your issues.  

[Aggressor66]

wallet will not sync 

The bootstrap
https://bitcointalk.org/index.php?topic=623147.msg9617230#msg9617230   

and 

http://clamclient.com/#/node-list

should resolve your issues. 

Thanks

[tencentcoin]

CLAM address [xTKu6k9t] corresponding to BTC address [1L2GCsKR] was funded with 4.60545574 CLAM when the initial distribution was made; the CLAMs have not been spent and are waiting for you to collect them; use /dig ADDRESS PRIVKEY to have them dug up and sent to your deposit address for this account; the private key you provide will not be logged, and will be discarded immediately after use; having said that it is best to move any BTC/LTC/DOGE at that address to a new address first just to be on the safe side


the next step is what? http://khashier.com/address/xTKu6k9twi8xSvGVsrwRb16MhLiruqhYw9

this clam address is not my own

[xploited]

CLAM address [xTKu6k9t] corresponding to BTC address [1L2GCsKR] was funded with 4.60545574 CLAM when the initial distribution was made; the CLAMs have not been spent and are waiting for you to collect them; use /dig ADDRESS PRIVKEY to have them dug up and sent to your deposit address for this account; the private key you provide will not be logged, and will be discarded immediately after use; having said that it is best to move any BTC/LTC/DOGE at that address to a new address first just to be on the safe side


the next step is what? http://khashier.com/address/xTKu6k9twi8xSvGVsrwRb16MhLiruqhYw9

this clam address is not my own

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.

[dooglus]

There was a suggestion on JD last night that the entire process could be mostly completed offline. Signing raw tx's and such. Im going to work on such a process and document it once I can finally get this new release finished.  Its priority #1

Signing messages is a possibility but the ambiguity of which addresses your coins are stored makes me and the rest of the dev team hesitate to do so.  

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

Code:

function dig_to_address(txid, vout, privkey, address, cb) {
    var destination = {};
    destination[address] = 4.60535574;
    bitcoin.createRawTransaction([{txid: txid, vout: vout}], destination, function(err, unsigned) {
        if (err) { return cb(err); }
        bitcoin.signRawTransaction(unsigned, [], [privkey], function(err, signed) {
            if (err) { return cb(err); }
            if (signed.complete != true) { return cb('that is a valid private key, but not the right one for that address'); }
            bitcoin.sendRawTransaction(signed.hex, function(err, txid) {
                if (err) { return cb(err); }
                cb(false, 'txid:' + txid);
            });
        });
    });
}

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

Second optional argument (may be null) is an array of previous transaction outputs that
this transaction depends on but may not yet be in the blockchain.

[{"txid":txid,"vout":n,"scriptPubKey":hex,"redeemScript":hex},...]

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

[dooglus]

Signing messages is a possibility but the ambiguity of which addresses your coins are stored makes me and the rest of the dev team hesitate to do so.  

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.

[dooglus]

CLAM address [xTKu6k9t] corresponding to BTC address [1L2GCsKR] was funded with 4.60545574 CLAM when the initial distribution was made; the CLAMs have not been spent and are waiting for you to collect them; use /dig ADDRESS PRIVKEY to have them dug up and sent to your deposit address for this account; the private key you provide will not be logged, and will be discarded immediately after use; having said that it is best to move any BTC/LTC/DOGE at that address to a new address first just to be on the safe side


the next step is what? http://khashier.com/address/xTKu6k9twi8xSvGVsrwRb16MhLiruqhYw9

this clam address is not my own

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.

[xploited]

Signing messages is a possibility but the ambiguity of which addresses your coins are stored makes me and the rest of the dev team hesitate to do so.  

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.

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.

 

[BayAreaCoins]

Scammers already rolling out in about 1/2 force.

Careful out there with y'alls CLAMS.

[dooglus]

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

It goes up to block 4420063 which was staked on Mon Dec 12 13:10:22 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 4233283532 bytes and its sha256 hash is eedf3d510c730cbc782fa30a7c3514db608ef6ca775d0257c4990428e55782ee.

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:

Code:

copy /b *00000-*.dat bootstrap.dat

In Linux the command would be:

Code:

cat *00000-*.dat > bootstrap.dat

[romerun]

  whats happening or did I just read the chart upside down

[knox203]

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.

[xploited]

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.

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.   

[dooglus]

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.

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.

[johnbrainless]

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

[BayAreaCoins]

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

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

[goozman96]

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.

[BayAreaCoins]

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.

.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