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

is there a staking pool planned? I currently found out about just-dices shared staking... but you have to invest your coins so it comes with a certain risk I'd love to see dooglus setup a stake pool

i think in the first post are all the features added, but i believe clam will slowly surprise us more and more.

I would not recommend doing this..... just a fair warning. 

Are they allowing deposits to bitcoin still? If yes, is it possible to deposit bitcoin, buy CLAMS and withdraw them? I don't think so. What are the new features did CLAMs added recently? This is a huge thread, I can't read it all at this time.

They realised thats the only coin worth to have so they have the rest locked.

http://blog.cryptsy.com/


Time to get them out, in case someone still has some CLAM sitting there

7 kilometers!

You're getting warmer

Though the way he wrote it sounds like it would be valid when watching the past of created blocks too. Or when he chose a time in the future then the blocks that are solved around these points in time, when the time went time finally, would make it correct too.

Maybe he meant it different but if that statement is only true theoretically then it might have stated.

The error is in your final assertion, "Wouldn't you expect ...".  No I wouldn't expect that.  First, statements A and B don't make sense.  The average amount of time from the chosen point in time is a singular number.  You probably mean the average of a distribution of randomly chosen points.  If you do mean that then A, B and C are all saying the same thing, because the occurrence of blocks is a poisson distributed random process.  The time a block is created is as good a chosen time as any.  Thus I would expect 1 minute = 1 minute = 1 minute.

I'm saying that t denotes the time block xyz was generated as recorded by the blockchain.

 I repeatedly shout out different random historical block numbers, and write down the time t that the blockchain says each was generated.

A)  The average of "time from t to the next block" is one minute
B)  The average of "time from t to the previous block" is one minute
C)  The average time between CLAM blocks is also 1 minute

Dooglus is picking random points in time t.  I am picking random block numbers.

The set of three conditions A, B, and C, are equivalent for Dooglus's pick and my pick.

Does this equivalence make Dooglus's "random point in time" equivalent to "the time a random CLAM block is generated"?

It sounds like no, because my set of times contains x members, where x is the CLAM block height.  Dooglus's set of times has an unbounded quantity of members. 

I don't understand what you are asking? Are you saying that a block is generated at the exact instant you pick? That is not the case in general.

If t denotes the time a random CLAM block is generated, then

A) the average amount of time from that point t to the next CLAM block is 1 minute
B) the average amount of time from that point t to the previous CLAM block is also 1 minute
C) the average time between CLAM blocks is also 1 minute

Does this make Dooglus's "random point in time" equivalent to "the time a random CLAM block is generated"?

As I said before, read the problem statement VERY carefully. The solution is there.

He wrote it himself so i guess he used some wording to trick us with his theory.

Well, i can't find out. When i would chose a random point in the future then the next block after that point should be a half minute later, i think, too. At least when the blockchain reaches that point in time. So i can't figure it out.

Doog the Deceiver! 

Are you sure that you used the same point in time to calculate the first 2 points? If C is correct then in average you should always find a point in or on a 1 minute timeframe. When judging a and b for the same point then this would mean the average has to be a fraction of a minute in each direction because when C is correct then the average for A and B can't be higher. I think that goes against probability.

Can you check if your script has no error really?

Edit: I see, you know the result? Then i guess i wait for where you deceived us.

Heh, probably not in this case.


Organ of Corti : https://en.wikipedia.org/wiki/Organ_of_Corti

   I guess I still don't get it.  If I just pick a random time, IE not when a block is found.  And not knowing when the last block was found, I can only estimate that the next block will be found in less then 60 seconds (based on a 1 minute block time average). And the same with the previous block less then 60 seconds assuming the time I choose is not exactly on a block found time. 
 
  Your example 30 + 30 = 60 (or 1 minute)  Makes sense.
  But 1+1 = 1 doesn't. 

I can almost see a) if nothing else is know and you select a time, then a block should be found within 1 minute.  But it's not a fact that, "If you select a random time the next block will be found in 1 minute".  If you change in to within, then I buy it.  Same for B. 

  I'm sure I'm just taking this to literal....         

Why on earth not? If the last block was B seconds ago and the next block is in A seconds, then how far apart are the two blocks?

Isn't it A+B?


What is "average block time"? Suppose blocks were found every minute, at the top of the minute, and my random point is 30 seconds past the minute. It's 30 seconds since the last block and 30 seconds to the next block. The time between blocks is 30+30.  ie. A+B=C

I did mean for A to be the expected time to the next block (ie. 1 minute), not the time of the next block (ie. Tuesday at 12:34 or whatever).

A, B, and C are all 60 seconds.

A) From a random point in time we all agree that the expected time to the next block is 60 seconds. I don't think anyone's going to argue with that (except that we find blocks a little too fast, so it's actually 59 seconds or something, but let's ignore that.

B) I don't think anyone can really make a reasonable argument that the same isn't true about the expected time to the previous block. Just record the block creation process happening and play it backwards. It's indistinguishable from playing it forwards. Like smooth's sliding paper revealing the blocks. You can slide in either direction and the expect time to the 'next' block (which is the 'previous' one when sliding backwards) is 60 seconds.

C) Can anyone argue that the expected time between blocks is not 60 seconds?

I put it to you that A, B, and C are ALL equal to 60 seconds, and that this isn't a contradition.

There is a rational explanation for this. I just like to make people figure it out for themselves

  -- dooglus the deceiver