Introducing PevPot.com The Bitcoin Lottery

[zeraTunerse]

From Moneypot to Pevpot , op is always playing with ideas , and i like that.

[1715670462]

1715670462

[RHavar]

Can anyone confirm or deny that?

Looks perfect, it seems to exactly match: https://www.pevpot.com/draws/1

(I also like how you use inclusive bounds, I'll update to that)

[RHavar]

Actually after 2h 40m my script is finished. But because I made my own script I am bit afraid to share the result as it might have mistakes lol :X (I only had it for verification, didn't expect to be the first.) Hint: if my result is correct, the winner would be not surprising. I would hope Ryan can run it first though, just in case I made a mistake :X

edit: I actually hope I am wrong, so my small bet still has a chance lol.

Did you get: 18328b652ef5ceba4b92e0094abf3de9b30cd5d6aaa1d1c4afc72a04907629b8  as the stretched block hash?

[NLNico]

Hm no. I used PHP. Example one is correct:

echo hash_pbkdf2("sha256", "00000000000000000ef86b27c174df6a412c0ce43eab1d532034555749294137", "pevpot", 100000, 64);

> 39aed3d2eff372916100106e355384495d1794320d4c3cb4c2e0e48cc36bbd06

Then with:

echo hash_pbkdf2("sha256", "000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553", "pevpot", 5000000000, 64);

I got:

> 6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5

Anything wrong with the block hash I used or something? 5000000000, correct too right?


edit: note the 64 is because PHP parameter is in hexits, not bytes.

[RHavar]

lol shit. Can someone run this node.js

Code:

var crypto = require('crypto');
console.log(
   crypto.pbkdf2Sync('000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553', 'pevpot', 5000000000, 32, 'sha256')
)

which I believe gives: 18328b652ef5ceba4b92e0094abf3de9b30cd5d6aaa1d1c4afc72a04907629b8  but I think the answer is wrong (32 bit overflows in openssl?).


Give me a couple hours to debug this =)

[NLNico]

obviously my PHP one could be wrong too.. so hope I am not wasting your time lol. I mean PHP doesn't really like big integers, potentially it's messing up that function too.

[RHavar]

obviously my PHP one could be wrong too.. so hope I am not wasting your time lol. I mean PHP doesn't really like big integers, potentially it's messing up that function too.

Or they both could be.  =)  

It seems that openssl (which is also used by node.js) the itereration count is restricted by the max size of a 32 bit integer  

Will test on some libraries that don't have this limitation.  (Or anyone know a compile flag that makes `int` be 64 bits? )

[NLNico]

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 might be not finished before I go to sleep though.

[RHavar]

It'll probably run into the same fate, I imagine.

Code:

int main()
{
 printf("int is %d bits\n",sizeof(int)*8);
}

( gcc test.c -o test && ./test )


As the int in openssl itself is probably only 32 bits :/  (even on a 64 bit system).



(Probably should have just used bcrypt. /sigh

[RHavar]

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 might be not finished before I go to sleep though.

I found a native PHP one:
https://defuse.ca/php-pbkdf2.htm

which 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

[dooglus]

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 might be not finished before I go to sleep though.

I found a native PHP one:
https://defuse.ca/php-pbkdf2.htm

which 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

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:

Code:

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

Code:

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

Code:

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

[Falconer]

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.

If this is correct then this guy would be the most happy guy ever to bet 0.15 and win 23 + BTC. Surprising result however this at the same time would be a shocking loss for the guy that buy 10 btc worth of tickets. I would love to hear an official winner statement regarding this from ryan soon

[NLNico]

Yeh, it could be that I did that part wrong as I wasn't sure about it:

So if we calculated the result hash, can we just do: parseInt('hash',16)%tickets) or do we need some big int special since it's a 256 bit number ? I don't know much about that

I did:

parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16)%2370006599

> 693288453


Does that make any sense? Lol.

[dooglus]

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

Edit: I was wrong - it's actually converting to floating point, and losing the least significant bits:

Code:

> 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


See https://blockchain.info/tx/d3e9e97d8981136a189dad329527085c7a72ee2335acac00e1893ed547c419eb and https://blockchain.info/tx/b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8.

[RHavar]

I'm getting the same result as dooglus with my recompiled openssl, and same outcome:

Code:

> var bignum = require('bignum');
> bignum('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5', 16).mod(2370006599).toString()
'2341821270'

I do however want to wait until the other solutions I have running  (in native js, and native php) terminate before sending the winner the money. But it's strongly looking like: b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8  is our winner

[NLNico]

Okay, yeh with some basic testing parseInt() indeed messes up bigger numbers.


So I guess we do have a lucky/surprising winner.

[RHavar]

The tentative winner of 23.87646599 BTC is:

https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d

cowbay on

Code:

1FuckThatToyjr....

[dooglus]

The tentative winner of 23.87646599 BTC is:

https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d

cowbay on

Code:

1FuckThatToyjr....

gg cowbay!

[NLNico]

Told you it wasn't a surprising result... cowbay always wins those high multiplier bets on all sites :XD

Nice win!

[dooglus]

Told you it wasn't a surprising result... cowbay always wins those high multiplier bets on all sites :XD

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