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

Is this the right place? https://www.altquick.co/ ?

I tried clicking 'sell' at the bottom. Got this:



It's not entirely clear what the site is. Is it only for converting between altcoins and US dollars?

Appears Altquick has added CLAMS

https://www.youtube.com/watch?v=9D-QD_HIfjA

*cums*

Edit:  Wait can ppl sell here or are they only letting people buy...?

Double Edit:  Looks like they list everything Shapeshift does.

I guess I see things differently. I use satellite Internet and have a hard cap on monthly data transfers. I don't want to be downloading a relatively large bootstrap.dat if I know that I only need the last 2% of it. The fact that the CLAM client will take a few minutes to skip through the 98% I already have isn't that big a deal. The wasted file transfer is. (Chopping the big bootstrap.dat into little parts happened on remote servers with proper Internet connections and didn't involve my having to upload or download anything other than a few command lines over the satellite connection).


The problem with that is that you're trusting me to provide the true longest chain. It adds another kind of centralisation to CLAM. Of course, the client validates every block it reads from the bootstrap file, and only adds it if it is valid, but I still don't like the idea of having the client know about my particular copy of it.

Having said that, what do people think about updating the checkpoints in the CLAM client? I bet that hasn't been done for quite a while now:


So we have checkpoints up to block 250k, staked on Sat Dec 13 15:14:24 2014, but nothing since. I think that means that theoretically MtGox (say) could dig up a whole load of CLAMs tomorrow, and use them to completely rewrite the chain from last December, wiping out all the transactions and blocks that have happened since.

The "reasonable timestamps" isn't an issue any more I don't think, since we no longer accept timestamps out of order.

Block 530000 was staked 5 days ago, has no weird times around it and contains only a simple staking transaction:

529995 Sat Jun 27 17:35:12 UTC 2015
529996 Sat Jun 27 17:36:00 UTC 2015
529997 Sat Jun 27 17:36:32 UTC 2015
529998 Sat Jun 27 17:36:48 UTC 2015
529999 Sat Jun 27 17:37:04 UTC 2015
530000 Sat Jun 27 17:37:20 UTC 2015
530001 Sat Jun 27 17:37:36 UTC 2015
530002 Sat Jun 27 17:39:12 UTC 2015
530003 Sat Jun 27 17:39:28 UTC 2015
530004 Sat Jun 27 17:40:00 UTC 2015
530005 Sat Jun 27 17:40:16 UTC 2015

I guess I'll add a checkpoint for it.

Edit: note those 11 timestamps just above, and how they are all exact multiples of 16 seconds apart from each other. That's the 16 second window I keep going on about. As far as CLAM staking is concerned, there is no point of time between 17:40:00 and 17:40:16. Time passes in 16 second lumps.

JD has a 75% chance of finding the next block because JD has 75% of the total staking weight on the network. I don't know how much effect network connectivity has. JD's wallet isn't connected to many peers most of the time - and I don't know if that helps or hinders it. I figure the 16 second length of the time windows means network latency isn't a big deal for the most part but I could be wrong there.

If the solo staker has 5% of the staking weight and JD has 75% then there's 20% elsewhere. We don't know whether they'll be working on JD's block or the solo-staker's block - it would depend which of the two they saw first. So the 75% chance for JD is a minimum.

The situation is further complicated by the fact that we don't know with any accuracy what the total network staking weight is. People who are trying to stake with small amounts but failing are effectively invisible. There's no way of knowing how many CLAMs are trying to stake other than trying to infer it from the network difficulty and the rate at which blocks are found. But the difficulty swings up and down quite drastically many times per day, making such calculations tricky.

It's not particularly easy to find out.

When I first discovered CLAM, I couldn't find out how staking worked, so I read the source code and summarised it like this:


It has changed since then. There is no longer the concept of "age" - the weight of an output is simply its size (once it has matured and not been involved in a transaction for 4 hours). And the "every second" changed to "every 16 seconds". And the difficulty became about a million times easier.

But basically, every 16 seconds your client looks at each of your unspent outputs, finds the ones which are mature and haven't moved in the last 4 hours, and hashes a bunch of information together (including the current time, the txid, etc.). If the hash is smaller than the current network-wide target times the value of the output then that output gets to stake a block. Multiplying the target by the size of the output makes the ease of staking proportional to the size of the output.

It's "random" in the same way that Just-Dice rolls are random: it isn't, but it appears to be due to the nature of hashing. Imagine hashing "abc123"+current_time_in_seconds with sha256 until you got a number less than a million as the hash result. There's a particular time in the future when that will happen, but without trying it for every current_time_in_seconds you can't predict when it will happen.

Thanks for lending a hand, it took a while but, I finally got those lost clams dug up

   It would be nice to have this automajically in the client, to go out and download the bootstrap that is needed to get up to date.... 

Yes sorry about the delete I meant to press edit then deleted, then got too lazy to do anything else:P

Anyways, this gist of my post is that I didn't quite see the use, and that a normal bootstrap skips over blocks that you already have. But now that I more fully understand your reasoning behind this, and how much faster this actually will process the blocks that you already have... this is amazing! This could really be useful when you stop a bootstrap midstream and need to start it backup. Or if you have been out of sync for a month or two.

Trying to make sure I follow Dooglus' explanation of orphaning in CLAM:

When you gave the example of a solo staker vs JD finding a block at the same time then you said that JD has a 75% chance of being able to build on it's block and the solo staker I guess has the other 25%.  Is this because of the volume of clams that JD is holding?  By holding such a large amount JD has a better chance of finding the next block and orphaning sologuy's?  Or is it because of better connections to peers than solog guy?  Or some combination thereof?

Thanks in advance for the clarifiication!

Thanks, looks like i understood the orphan thing correctly then.

Youre numbers might be right and it might be, that the one who only got 2 orphans for 50 good ones, was connecte to jd directly. Though was able to propagate practically instantly and jd had to confirm that block before jd could orphan it by creating its own.

Though i wonder how blocks are found at all. It sounds like calculating like with bitcoin but its not the case. I heard its random but that doesnt account for how orphaned blocks can happen then. You dont need to explain when you think i should investigate myself.

Another advantage is that you get the profits off players losing as well.

Try to stake solo vs JD and compare your data.  I imagine a JD investment with 100x leverage is going to shit on solo staking 9 times out of 10.

Be sure to post your results <3!
[/quote]

Right, i forgot to add that.

And yes... the results are great. Yesterday i was deep red, today i check and see the profit went down even further... until i realize that its not a negative number anymore... its positive. It seems king lost 7.5k clams.

Profit still can fluctuate highly but it worked out for now.

There was a guy in the JD chat yesterday who couldn't ever get a single connection to a CLAM node, although he had managed to sync part of the Bitcoin blockchain in the past.

After a few hours of back and forth with him, it turned out that he was on a college network and couldn't make outgoing connections on most ports. Port 80 was open, and so was port 8080. If I ran a CLAM node and told it to listen for incoming connections on port 8080 (port=8080 in clam.conf), and gave him the IP address. Using an "addnode' command he was able to get a connection and finish syncing the blockchain.

Edit: I should mention that http://portquiz.net:31174/ is a good tool for diagnosing such issues. Replace 31174 by various ports until you're able to get a connection. If you see:


it means you are able to connect out on that port.

Take a look at the OP post, at the bottom.

1. You will find a list of nodes.
- Go to your data directory, on Windows it is at:
- Add the node lines you find in the OP post to the clam.conf file, if it doesn't exist, create it.
- Restart the client.

2. You will find a link to a bootstrap file.
- Place the bootstrap file in the data directory.
- Restart the client.

If neither of these solutions help you with the problem, please feel free to stop in to freenode IRC channel #clams and we would be happy to help you debug the problem.

---

If you have a wallet.dat file, you can claim by simply clicking file->import wallet.

If you do not: can we get some specific information about exactly what type of wallet/keys you are attempting to claim with?

As BAC said, it's to do with the orphaning.

CLAM divides time into blocks of 16 seconds. You only get to check for opportunities to stake each 16 seconds. Let's say there are 4 of these blocks per minute (it's close).

We aim to set the difficulty such that a block is found once per minute. That means that there's about a 25% chance of a block being found by someone in any particular 16 second time slot. If you (solo staking) and JD both find a block in the same time slot, you will start trying to build on top of your block, and JD will try to build on top of its block. The rest of the network will try to build on top of which ever one of the two they heard about first.

So when we both find blocks in the same time slot, if JD has 75% of the staking weight, it has a 75% chance of building on top of its block and orphaning yours. Of course there's a chance that the JD block gets orphaned too. If you solo-stake, find a block at the same time as JD and then stake again shortly after, or one of the peers who saw your block before he saw the JD block stakes next, he'll build on top of your block not JD's.

I've attempted to do some back-of-an-envelope calculations to determine what that means it real terms, and came up with a number like 14% orphan rate I think (*). Someone posted recently saying that they tried solo-staking and only got 2 orphans out of 50 or so blocks they staked, so maybe 14% is too high.

Basically if the orphan rate inflicted by JD is higher than the commission charged by JD, then you would make more staking at JD than solo staking. But we don't have a good number for that orphan rate.

Here's a list of the blocks that JD's staking wallet found recently which ended up being orphaned. Only one on 28th, 5 on 29th, 10 on 30th, 5 on 1st. So you can see there's a lot of variance:


Edit: I've not checked, but it's quite possible that most of these orphaned blocks were orphaned by JD's hot wallet. They run completely separately, and don't "go easy" on each other. They're competing with each other for stakes just like every other wallet is.

(*) Suppose JD has 75% of the stake weight, and that there are 4 16-second blocks per minute. Suppose you are solo staking. Suppose you just staked a block. There is a 1/4 probability that someone else staked in the same 16-second period (1 in the 4 windows per minute). And there is a 3/4 probability that it was JD. So there's a 3/16 probability that JD stakes at the same time as you when you stake. To orphan your block, JD would also have to stake the next block. That's also a 3/4 probability (JD has 3/4 of the stake weight). So for each block you stake, there's a (3/16)*(3/4) = 9/64 = 14.0625% that JD will orphan it. That was how I got the 14% figure, but I don't know whether my reasoning is valid or not. I'm not taking a bunch of things into account, like the chance of you orphaning a JD block, or the change of us both finding the next block in the same time period as well.

Step one is have the private key for your old btc address in hand.  It sound like you might have gotten stuck before that (given that you're having trouble unlocking your wallet).  If that's the case, can you confirm you're using bitcoin-core (it sounds like you are) and that at least some of the RPC commands are working well?

Once you get your private key in WIF format (starts with a 5) then you can either trust dooglus to dig for you by putting that key into the just-dice chat, or you can dig with the clamd software yourself.  Which one are are you trying to do?

Another advantage is that you get the profits off players losing as well.

Try to stake solo vs JD and compare your data.  I imagine a JD investment with 100x leverage is going to shit on solo staking 9 times out of 10.

Be sure to post your results <3!

Hi, I am trying to dig up some old clams from my oldest btc address, and am having some trouble, no matter what I

do I keep getting errors. The first error I was getting was "Error: Error parsing JSON: mywalletpassphrase", them I

switched around where I was getting the .dat file from, now I am getting the error
 "value is type int, expected bool (code -1)"

any help would be greatly appreciated!

I've been stuck at 34 weeks behind for the past week. When I hover over the progress bar it says 183635 blocks, then if I hover over it again it says 183635 blocks processed, minutes later. If I start from scratch, it'll be catching up but eventually just locks up again and stops making any progress. How can I fix this?

I disagree... i invested shortly before the drop.

So let away the -10% fee, the clams from the gamblers that stake for the investors on top and the potential profit from gambling, you say there is an additional income from "JD orphans blocks of those who dont stake with it?" Do you refer to clams that arent in a wallet that is online? I heard those clams dont stake because they dont take part in the network. I did not find info about what orphaned blocks mean for clams. In bitcoin it means a block that is found but another block won. But clams are propagated differently. Does orphan mean that a clam address that isnt online gets theoretically a block but jd finds one a bit later and wins the dispute instantly because of centralization? Wouldnt the solution simply be to make sure to be connected to jd and send the block there as fast as possible?

So there is the variance of you staking alone, you might find a block early or later, but overall it should be the same like a big address. It would average out over time.

So the advantages of jd are:

- wins every dispute because instant confirmation of own found blocks.
- is always online so it stakes automatically
- gamblers clams stake too. Though dooglus wrote in chat thats not much.

Disadvantages:

- -10% fee

Im not sure but shouldnt the -10% fee already eat up all the advantages when you could stay online all the time too? I doubt orphaned blocks are so many, at least propagating shouldnt happen so fast that jd finds a block more earlier. I now realize that it cant work that way. Staking isnt done by calculating hashes to find a block. So how does orphans happen then?

JD orphans blocks of those who don't stake with it due to how many coins are staking there.

House edge as addition income on top of the stakes.  (this varies... if you invested 2 weeks ago you'd disagree)

Say someone only has 10 CLAMS... well staking on their own is a up hill battle with time + orphans and by going just with the Just-dice centralization they get instant returns.  Otherwise they may wait a year and never hit a block sucessfully (or maybe they hit one right away... the very base of these cryptocoins is gambling through mining/staking.)