Trying to do the math on the Proof-Of-Chain distribution. CLAMS has a total POSSIBLE distribution of 15 Million. I think that is not taking everything into consideration, however. Actual Total Distribution = Total Possible - Lost BTC/LTC/DOGE privateKeys - Destroyed BTC/LTC/DOGE privateKeys - Un-Redeemed BTC/LTC/DOGE privateKeys The question is, what does that mean? I would expect the total distribution of CLAMS to be EXREMELY LESS than 15 Million at any given time. In order to get to the full 15 Million possible distribution it would have to be one of if not THE world's leading crypto-currency. Mining inflation normally destroys coins. For every coin created by mining, there must be an equal in-flow of dollars of demand. If there isn't then the value of the coin drops. With CLAMS, there is no mining and only 1% Proof-Of-Stake. So each unit of demand should only be counter-acted by new users who redeem their CLAMS. And, new users who redeem their CLAMS are in and of themselves a source of demand. If you add to that equation the kHashier.com multi-pool, which has been stacking BTC while waiting for the markets to adopt and have a stable market for CLAMS..... I still think those who dump their CLAMS immediately after redeeming, or those who don't keep an eye on this one will deeply regret it. I don't see a single negative when the economics are considered. Just my two-cents.
^^ We think all of those assumptions are reasonable. We designed CLAMS with the idea that inflation cause by claiming CLAMS would correlate to and be counter-balanced with an increase in demand. The idea was to create stability, instead of the extreme mining pump and dump inflation cycle. You seem intelligent, and we are glad you agree ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) I think people will look back on these posts in some months and wonder how the hell they missed it. Maybe not. But with all the billion coin supply cryptos, it is rare to see one that makes economic and adoption sense. More Users = More Coins. So simple, yet it makes so much sense. If this one ever catches fire, watch out world. Now I'm confused. Aren't you two the same person?
|
|
|
When someone wins the lotto, we get the block-height of their transaction and figure out: (1000 - BLOCKS_SINCE_STARTING)/1000 You get this fraction of "Early bird bonus pool". What ever is left over, will be carried to the next months early bird bonus pool. Just to be clear, this scales the sponsorship from 100% down to 0% over the 1000 blocks, instead of the 100% -> 50% you originally proposed. Is that what you intended?
|
|
|
He who has the private keys owns the money. It is most certainly "Doog's money" at the present because he has the power to control it.
I disagree. When you lend me your car for the day does it become my car just because I have the keys? Just because I could steal it if I wanted to? When you call the cops on me do they say "well, he has the key, so it's his car now". They don't. Ownership is something more than simple control. The fact remains that this decentralized currency is very centrally concentrated under the control of one person presently.
Indeed. One look at http://blocktree.io/richlist/CLAM tells you that.
|
|
|
1. Certain people creating shady services that benefited from the value you brought to Clam
No need for me to point any fingers I am sure its very clear to most
I have NoAreaClue who you could be referring to. 2. The uncertainty of more large holders/diggers with questionable ways they happened to have so many addresses
Clearly the large digger benefited immensely from the Value you brought to clam
Its just seems to me like many variables are out of your(most everyones) control
I guess everyone knows another 500,000 free clam holder could pop up tomorrow and its what we all signed up for
OK, I see. Undoubtedly the digger made (and will make) a whole lot of money that he wouldn't have made if Just-Dice hadn't adopted CLAM. I don't have a problem with that though. I guess your word "skimming" made it sound like you were implying some kind of a scam, whereas I don't think either of your examples are scammy - just opportunistic.
|
|
|
At this point, a digger would have to dig roughly 250k wallet addresses to be able to 51% attack the coin - an exceedingly unlikely proposition, and the number increases by approximately 300 per day.
Well, he could dig some and buy some more. The entire market cap of CLAM is less than a million dollars at the moment, so it's by no means impossible for someone wealthy to mess with the coin "for the lulz". The thing that I have wanted to write a long post about and have not gotten around to is that value is created by having something to do with the coin, and while there are certain other sites where you can transact with CLAMs, its adoption for non-gambling purposes has been very low. And it seems like the people involved in CLAM at the high levels have been content to not extend any effort into anything other than JD.
That's true, but I don't think it's their responsibility to do so. They make the coin available to us, and we are free to use it how we like. I found the coin and decided to use it at Just-Dice. The client wasn't in a state that worked for me, so I made a bunch of changes to it to make it work how I needed it to work, and contributed those changes back to the open source codebase. That's how it's meant to work - provide the services you want to see, and don't wait for "people at the high levels" to do it for you. In fact there are no "levels" - you're free to use and build CLAM however you like.
|
|
|
The danger of 51% control is low.
It's cute that people say this, but JD has controlled more than 50% of the coin supply ever since I've been using it. It's over 70% currently, peaked around 77% recently, somebody big divested, it would seem. I think there are a lot more CLAMs than usual on the poloniex orderbooks. I made updated "dig charts". It's pretty clear that the rate of digging has picked up dramatically: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FHZVovH9.png&t=663&c=5jDUpR7baJjKWg) ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FxbNWvYd.png&t=663&c=gwWQhgOpBKB0Tw)
|
|
|
Its becoming very apparent how many people have been skimming off the back of dooglus
I don't understand what you mean. Can you explain?
|
|
|
I think digger came out and will dig up all his clam fast because digger afraid there will be a vote on reduce or remove digging.
He said that he will do that. No vote is going to be able to stop him doing it, even if that's what people wanted. I guess the vote is about whether to change the rules for future diggers. There's another 14 million undug CLAMs out there, some of it in big wallets...
|
|
|
Hey, Curious,
I checked your post history. I'm curious (no wait, you're curious) about the 30-month posting gap between 2/13 and today.
Curiosity killed the cat but got revived by clams! Hi Mr. Digger. Isn't it a curious curiosity that your name is so similar to the creative creator of CLAM? Congrats on digging so many CLAMs. Some random intrusive questions - feel free not to answer any you don't like, of course: * is this mostly all one big BTC wallet, or have you been collecting a bunch of wallets? * is it from a real service, or was it created just for the sake of having a lot of addresses? * how many BTC did you make so far from digging and selling? * do you have an account on Just-Dice? I'm sure people there would like to talk to you "live"
|
|
|
Thanks very much! I wasn't expecting to see any of that back again. I'll use it to fund JD ads over the coming weeks. So one thing I've been thinking about, is how to incentivize people to play at the start of the draw (as opposed the last couple of blocks).
One ideas I've had:
a) The winner gets the total amount sent to the lotto, plus X of the sponsored amount. X is dependent on the block you buy your lottery tickets, and starts off at 100% and trends towards 50% by the end of the draw? So the earlier your buy in, the higher +EV it is (but the less known the EV) is. The later you play, the lower the EV is but the more known it is. (But regardless of when you play, it's still +EV)
b) The winner is paid 50% in BTC and 50% in next-draws lottery tickets. This would make the pot start with a nice healthy amount right from the start, hopefully attracting more players. Players would be eligible to win multiple times in a row of course. (Although it seems a little shitty to me, to pay lottery winners in lottery tickets)
Or maybe I'm over thinking it, and last-minute play isn't a problem? I just have this impression that the bigger the pot, the more attractive it is for most lottery-ticket buyers to participate.
What are your thoughts?
I agree that it's best to encourage people to play early, to grow the pot early, to make it more attractive for others. I don't think it's OK to pay lottery winnings in lottery tickets. I like the first idea. I think you should take your 10% off the top first, and split the remaining 90% like you stated, with the left over sponsorship money (0% to 50% of the remaining 90%) going into next week's sponsorship pot.
|
|
|
And I will shortly make the payment of 23.87646599 BTC to cowbay after my last script for verification has finished running (or Dooglus' python one).
For the record: >>> time.ctime(time.time()); pbkdf2.PBKDF2('000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553', 'pevpot', 5000000000, hashlib.sha256, hmac).hexread(32); time.ctime(time.time()) 'Tue Nov 17 01:50:44 2015' '6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5' 'Tue Nov 17 23:44:24 2015'
|
|
|
I've been asked to make my current thoughts clear.
I don't plan on making any kind of a new coin at the moment. SuperCLAM has stepped up and proposed a polling system (that I don't yet fully understand), and so I am willing to see how that pans out. If we as a community can use the forthcoming polling system to make changes that we want then I don't see the need for a new coin.
I'm not committing to never making a new coin, but I don't think it's likely that I will make one. CLAM is niche enough as it is without further splitting the community into two pieces.
|
|
|
By the way, why only one prize, and not multiple prizes?
I'm a bit of a sucker for simplicity, so I do like the idea of "winner takes all". Provably fair doesn't imply that you're probably going to win, it just means that you can verify it's fairness. =)
|
|
|
I got the same as NLNico using a modified openssl version. I ran into the 32 bit integer limit too, so did this to bypass it - it saved me having to rebuild openssl - I just copied and modified the function with the 32 bit limit:
Thanks for doing that BTW, I created a mini repo for it: https://github.com/moneypot/pevpot-stretchI'll try wrap it in a node module too later. (But for now, I'm still running the verification in the native php and native js solution. Make sure they corroborate the same stretched hash. ) Update: The native PHP solution is matching <modified openssl>, so I'm getting quite confident it's correct. I'm still waiting for the native javascript one to terminate, before I'm sure though =) I'm running a Python version too. It has been running for 12 hours so far: >>> time.ctime(time.time()); pbkdf2.PBKDF2('000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553', 'pevpot', 5000000000, hashlib.sha256, hmac).hexread(32); time.ctime(time.time()) 'Tue Nov 17 01:50:44 2015'
I'm a little butthurt that my last minute snipe bets didn't pay off for me. The 10.8 BTC was my 10 BTC investment at moneypot plus profits over the last couple weeks, and the 5.x was as much as polo would let me withdraw in a single day. But I'm glad to see them go to a long-standing JD player. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
Told you it wasn't a surprising result... cowbay always wins those high multiplier bets on all sites :XD![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Nice win! It's kind of cool that every ticket bought has a direct impact on the outcome by changing the modulus used. A difference of a single satoshi in either direction completely changes the result: >>> print 0x6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5 % 2370006598 1757345155 ... and the 5.92947120 bet wins >>> print 0x6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5 % 2370006600 886980269 ... and the 10.82969911 bet wins
|
|
|
I did:
parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16)%2370006599
> 693288453
Does that make any sense? Lol.
I'm guessing the parseInt() is giving you a 64 bit integer, and losing all the more significant bytes. I do prefer your answer however... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) Edit: I was wrong - it's actually converting to floating point, and losing the least significant bits: > parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16) 4.9878843987532516e+76 > parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16) == parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16)+1 true
So I'm more sure now that the lucky winner is the owner of 1FuckThisFRNcH8eJkhWAMBndxRVZBVBdE and 1HoLyShitRw7dNvPvgPMDndTid5FDmvDnh ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) See https://blockchain.info/tx/d3e9e97d8981136a189dad329527085c7a72ee2335acac00e1893ed547c419eb and https://blockchain.info/tx/b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8.
|
|
|
Well PHP also uses OpenSSL in background and it seems to force the iterations into 'int' too ( source code) - but I seem to be running 64-bit version: > php -r 'echo PHP_INT_MAX;' > 9223372036854775807 edit: for the lulz I am now running with 2147483647 iterations ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) might be not finished before I go to sleep though. I found a native PHP one: https://defuse.ca/php-pbkdf2.htmwhich should avoid the 32 bit problems. It passes the test-vector, and I'm testing it on the full data. Also running a native javascript one, and rebuilding openssl with using a 64 bit integer for the iteration count ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) I got the same as NLNico using a modified openssl version. I ran into the 32 bit integer limit too, so did this to bypass it - it saved me having to rebuild openssl - I just copied and modified the function with the 32 bit limit: #include <stdio.h> #include <string.h> #include <openssl/hmac.h> #include <openssl/evp.h>
int pbkdf2(const char *pass, const unsigned char *salt, long iter, const EVP_MD *digest, unsigned char *out) { unsigned char digtmp[32], itmp[4]; int k, mdlen, saltlen = strlen(salt); unsigned long j; HMAC_CTX hctx_tpl, hctx;
mdlen = EVP_MD_size(digest); HMAC_CTX_init(&hctx_tpl); HMAC_Init_ex(&hctx_tpl, pass, strlen(pass), digest, NULL); itmp[0] = itmp[1] = itmp[2] = 0; itmp[3] = 1; HMAC_CTX_copy(&hctx, &hctx_tpl); HMAC_Update(&hctx, salt, saltlen); HMAC_Update(&hctx, itmp, 4); HMAC_Final(&hctx, digtmp, NULL); HMAC_CTX_cleanup(&hctx); memcpy(out, digtmp, mdlen); for (j = 1; j < iter; j++) { HMAC_CTX_copy(&hctx, &hctx_tpl); HMAC_Update(&hctx, digtmp, mdlen); HMAC_Final(&hctx, digtmp, NULL); HMAC_CTX_cleanup(&hctx); for (k = 0; k < mdlen; k++) out[k] ^= digtmp[k]; if (j % 10000000 == 9999999) { int i; printf("%lu ", (j+1)/1000000); for (i=0;i<32;i++) printf("%02x", out[i]); printf("\n"); } } HMAC_CTX_cleanup(&hctx_tpl); return 1; }
void main() { size_t i; unsigned char out[32]; const char pwd[] = "000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553"; pbkdf2(pwd, "pevpot", 5000000000, EVP_sha256(), out); printf("out: "); for(i=0;i<32;i++) { printf("%02x", out[i]); } printf("\n"); }
It shows the output after every 10 million iterations, to show that it's really doing all the work: $ gcc -O3 pbkdf2.c -lssl -lcrypto $ ./a.out pass: 000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553 ITERATION: 5000000000 salt: 706576706f74 10 4e54363ee4f5a8f0a13f36fcbe46568e496c787ac24ab466e18b80f959c4e426 20 1c08cfe17c6b036075fb45ea1d5b95073ebdfdd4a329cd1a30030e34f26cb8b1 30 110a65fb8928595ad797371bf1f77db371d62af560b6431704b7e91157a89065 [...] 4980 522f0ace7099f90c9a358014500f702fb10ab7f3a0ebeb3a7c221be91309a0d8 4990 38ca9ef690e27bcef846ef9852161f8f33223499fc2c57c1f0116995cb09744c 5000 6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5 out: 6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5 $
That last line is the same as NLNico's PHP output, so I'm reasonably confident in it. Then: >>> print 0x6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5 % 2370006599 2341821270
Meaning the winner only bet 0.15 BTC! b6abba202c99971e59021cef44a03904ec847f3344067bea85f8fd12d01678ca 0.00097120 : 2336305993 - 2336403112 b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8 0.14997120 : 2336403113 - 2351400232 <-- this guy b96d2df7cced243d4c729e26698f48e3b6f129120767812ff84e493f5efe8e6b 0.00997120 : 2351400233 - 2352397352
I also could be wrong, and would like to see NLNico's working, since this is a relatively surprising result.
|
|
|
Actually I just concluded that based on: PBKDF2 is defined as PBKDF2(PRF, Password, Salt, iterations, dkLen) which I'll use as PBKDF2('sha256', BLOCK_HASH, 'pevpot', 10000000000, 32)
The fastest implementation I could find was openssl, which when compiled with -O3 took about 2h47m to run. With the fastest virtual machine I could get my hands on (c4.8xlarge), I got it running in about 2h1m. Since it's 5B instead of 10B, I figured it's around 1 - 2 hours. Well alright then!
|
|
|
You can calculate it that fast? I timed 5,000,000 iterations and found it took 93 seconds. So 5 billion iterations would take me 1000 times longer, or 25.8 hours. I guess it's possible there's a faster way of doing it. Here's my attempt at producing the sorted list of qualifying bets: 008922cf634846778343074c6994c9e39584bf1a891c14cdcb2d1b89c7244a99 0.00400000 : 0 - 399999 0b8d8888ad813aaa2135b4483e0f08fa2e51b425e093edb65502313d3e238970 0.01237280 : 400000 - 1637279 105f88313a78eaee08b00cd8aac14dd1a5679323174166a2e3bf4a089779a016 0.01494000 : 1637280 - 3131279 108272f527838860d2a69fd35f3f0aeffdd2fa3cf371f1cba4218a76968991ed 0.20000000 : 3131280 - 23131279 <-- me 1efba412cbd39315079eecac684cbebe4cad5dc6060fae67ca6448c9b357996d 4.99997120 : 23131280 - 523128399 257b6b842d50af5ba7622655a9e01f33fdbe797b3386ff7284de9a5dd3be5e25 0.00097120 : 523128400 - 523225519 2842d8640b3a0cc5b2a587449a6920305a62bfff7f72b1d02a07fefb20a9ab64 0.00097135 : 523225520 - 523322654 3044f6f79a05ba0a946543a943d8052baef0e3f8b6f079d727ac8ebc3c223668 0.09990000 : 523322655 - 533312654 33e38d95c430df1174135a0105b1ca8e0722bbf891966b1bbc7d3e072cd15e1e 0.00128000 : 533312655 - 533440654 35a837ae03e7c4da8af2e4b84ed1ffcc86ce3444b683dfd5c62167521aa6c350 0.00282422 : 533440655 - 533723076 3bdf09d87f85beab37105858c608346e3c0a8743fc9bc49019c7d5bc5e8c47a4 10.82969911 : 533723077 - 1616692987 4544f527dc04e5b6321beabd7e182a898c1e0342fd6a37381b59f63d507869e2 0.00100000 : 1616692988 - 1616792987 46718ce9f295d6ab58823245c049a252fde1167327ecc932b231d9d2291fd0ab 0.00020000 : 1616792988 - 1616812987 46ef2aec2aad64364e40581d8e1de01ab4eecf9396e00218070980c594587e4f 0.02497120 : 1616812988 - 1619310107 47b32e99b12c0d28f4794d686a97e0e75a3090669fde6218a11fa60900e1713a 0.00200000 : 1619310108 - 1619510107 4cd1f8d05f8727761204843b3de9e37959da7ead8ef9d3b955555aace30f3915 0.00297135 : 1619510108 - 1619807242 529d66622b0fd4c2e5d9c66b158fc789abf66bb55f2e17867401244f244825b4 5.92947120 : 1619807243 - 2212754362 56fb6cf4c16d443ec11a81e14684509e16d8ff0fd01cb08e5332d00b9090182a 0.04997135 : 2212754363 - 2217751497 577cdd0adee0e85da3c17f054bc9f02aa126c37267904b9907d4427a2c2fd22e 0.99990000 : 2217751498 - 2317741497 59d7e4447f805793b0a776e0f5e14fcd0761af067ae7cc89ff7f327d3c22236f 0.00487135 : 2317741498 - 2318228632 6658e43f7f65cef2578aa98bb09db14c06ecb86d31c77b216238cab3b5876521 0.00010000 : 2318228633 - 2318238632 67b5fc0c3086f1c0c0436c3e9d9cc0ab1591b4a2624f634336b94c050ecf4aca 0.00809920 : 2318238633 - 2319048552 69a67d0f266927a7dbb6b64c46d89c72d5c80c707a07134ded751a9ffff314ee 0.00067120 : 2319048553 - 2319115672 6b77502e40baf085bab0b9999085f165360a27f6b92c9162a5124976ea1f36ec 0.00010000 : 2319115673 - 2319125672 6d76aa4d3684fd392d71f271b44f7fce26368933368b5a86c979c434a91eb7e6 0.02500000 : 2319125673 - 2321625672 6e1eaac7b74cd74bb916fc17a9817271ddf09e0ef48f7b79e3179591a712949f 0.00097135 : 2321625673 - 2321722807 74ccf8ca8bd0ef8061601ce76c6d1af6169cef926c541ea38c58dbcc9d9ce75a 0.00060000 : 2321722808 - 2321782807 7506e19fc92c0feac90164c46cdfd3e7b7b1e6366a53bcd4c777fc7fa46060d9 0.00997035 : 2321782808 - 2322779842 80d0dc5d3e976a79a8902eccaf5b1c74322a5759b2c1e81d5d27fc436dbe2e3d 0.00287135 : 2322779843 - 2323066977 85cec4d3a20c582145c88f46210ddd8cdf82879ea7bc02cb779a9381a9f82028 0.00097120 : 2323066978 - 2323164097 91730b6ece70de9dde9d09da66d2f23f112b0494f0efb0b837483eb0f8821049 0.00120535 : 2323164098 - 2323284632 96421ff7299afde33df2bd968580d7576579adc3392948743a9c2ba0816aae24 0.00050000 : 2323284633 - 2323334632 9bd9d3e96f007dc5ec53ebd32219afd0e49e0e4c514824fe0b65b5c58d705e4b 0.00097120 : 2323334633 - 2323431752 9fd4add5da8ff544a0b833b3348a276e5f4cb6d49b3137bb5ab090b740829b14 0.00040000 : 2323431753 - 2323471752 a1f8dddf6d5863c18fdb79680769e60f3ea085f84c4268782e528335c12dae2c 0.00040000 : 2323471753 - 2323511752 a497201c7fa64a5c0b8fd09657f9d2188b31d07e4fecebac9364abaf1ba2c967 0.00010000 : 2323511753 - 2323521752 a5d197065cd68b9fd91bb8043dee47015aa63bbdd4fcb06a66c1deca565360fc 0.02497120 : 2323521753 - 2326018872 a6cc9adda0a5c541b21b1f4f0bf5d1cd8e32d8a7afbdfb44a699a49631377cd5 0.00290000 : 2326018873 - 2326308872 aa02a98b2dada8c3e3f5cf1ccc7a2f0ea1cc2cfaecc4e3be4f8df51a92505cb8 0.09997120 : 2326308873 - 2336305992 b6abba202c99971e59021cef44a03904ec847f3344067bea85f8fd12d01678ca 0.00097120 : 2336305993 - 2336403112 b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8 0.14997120 : 2336403113 - 2351400232 b96d2df7cced243d4c729e26698f48e3b6f129120767812ff84e493f5efe8e6b 0.00997120 : 2351400233 - 2352397352 c27881c210b492468a5ae6344f55960f683ac29aa3a275c8f2d524fce763707f 0.00283020 : 2352397353 - 2352680372 d0680226592913af48e6d8e934cdfa931125a2f790a1b416e7bf3c9d1114062c 0.00219435 : 2352680373 - 2352899807 ddbb43f5cad891a5938a2e9764fd450bb96e8c97b02004147b3abcde38e49ad6 0.00300000 : 2352899808 - 2353199807 e6b98443e0c869ef64c28ea6f88b3aed31c9ff8873640c849dca76038c188173 0.01000000 : 2353199808 - 2354199807 e8787010b58516976f0a5265d619ace80f407d0bdb369cfb4531cab606de3437 0.00030000 : 2354199808 - 2354229807 f26019e9dbdc23d3ef57177ffd511175ce5898204306ca500d0e1525a0ee6402 0.01987120 : 2354229808 - 2356216927 f261e94b28a953b44068679e76aaa1cf66a1a2740505616d3508d4b4c0e41464 0.04997120 : 2356216928 - 2361214047 f76c2e724c57313478d4d69c81d7515f9951256a74d786c94ec221b3ad91addf 0.07777777 : 2361214048 - 2368991824 fd1b7b53ca97a676f2db025a5ba2574c05d7603002e95520b3ddca327676325c 0.00030000 : 2368991825 - 2369021824 fef4b4696a1aa17caef79c06caff67f86bbcfa7616d39b44d0bf10a9b3169951 0.00984774 : 2369021825 - 2370006598
modulo 2370006599 Can anyone confirm or deny that? Edit: https://www.pevpot.com/draws/1 shows the wrong block? ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FloihCXh.png&t=663&c=BAeQcnYqLv7Izw) It should link to the xxx006 block, right? Also, "1 blocks": ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FUiqLvWv.png&t=663&c=hkpDM3c9UmnKWw)
|
|
|
|