Nice win! 
Topic: Introducing PevPot.com The Bitcoin Lottery - page 12. (Read 12236 times)
Nice win! 
The tentative winner of 23.87646599 BTC is:
https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d
cowbay on
https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d
cowbay on
Code:
1FuckThatToyjr....
gg cowbay!
The tentative winner of 23.87646599 BTC is:
https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d
cowbay on
https://www.pevpot.com/registrations/bae5393d-8d1c-40d9-8ec5-9d16fdfed84d
cowbay on
Code:
1FuckThatToyjr....
Okay, yeh with some basic testing parseInt() indeed messes up bigger numbers.
So I guess we do have a lucky/surprising winner.
So I guess we do have a lucky/surprising winner.
I'm getting the same result as dooglus with my recompiled openssl, and same outcome:
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
Code:
> var bignum = require('bignum');
> bignum('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5', 16).mod(2370006599).toString()
'2341821270'
> 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
I did:
parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16)%2370006599
> 693288453
Does that make any sense? Lol.
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
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.
Yeh, it could be that I did that part wrong as I wasn't sure about it:
I did:
parseInt('6e466cdd13cc80b1137addf46362bbe3714fc9bf7faef9aba930554d3e080ba5',16)%2370006599
> 693288453
Does that make any sense? Lol.
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.
Meaning the winner only bet 0.15 BTC!
I also could be wrong, and would like to see NLNico's working, since this is a relatively surprising result.
Quote
b6abba202c99971e59021cef44a03904ec847f3344067bea85f8fd12d01678ca 0.00097120 : 2336305993 - 2336403112
b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8 0.14997120 : 2336403113 - 2351400232 <-- this guy
b96d2df7cced243d4c729e26698f48e3b6f129120767812ff84e493f5efe8e6b 0.00997120 : 2351400233 - 2352397352
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
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.
> 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
#include
#include
#include
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");
}
#include
#include
#include
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
$
$ ./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
2341821270
Meaning the winner only bet 0.15 BTC!
Quote
b6abba202c99971e59021cef44a03904ec847f3344067bea85f8fd12d01678ca 0.00097120 : 2336305993 - 2336403112
b83f1fa87c86f9f1ccfe4050f07d89cd42c9e6670f4ac2a50fb353b626e2cac8 0.14997120 : 2336403113 - 2351400232 <-- this guy
b96d2df7cced243d4c729e26698f48e3b6f129120767812ff84e493f5efe8e6b 0.00997120 : 2351400233 - 2352397352
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.
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.
> 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
It'll probably run into the same fate, I imagine.
( 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
Code:
int main()
{
printf("int is %d bits\n",sizeof(int)*8);
}
{
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
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.
> 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. 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?
) 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.
lol shit. Can someone run this node.js
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 =)
Code:
var crypto = require('crypto');
console.log(
crypto.pbkdf2Sync('000000000000000009b7fb236187f120a0c86eb8785f099a8d197dd34b9d2553', 'pevpot', 5000000000, 32, 'sha256')
)
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 =)
Hm no. I used PHP. Example one is correct:
> 39aed3d2eff372916100106e355384495d1794320d4c3cb4c2e0e48cc36bbd06
Then with:
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.
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.
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.
: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 :Xedit: I actually hope I am wrong, so my small bet still has a chance lol.
Did you get: 18328b652ef5ceba4b92e0094abf3de9b30cd5d6aaa1d1c4afc72a04907629b8 as the stretched block hash?
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)
From Moneypot to Pevpot , op is always playing with ideas , and i like that.
Wow! Ok sorry about the lack of automated drawing. Just woke up, and figuring out who won now =)
Jump to: