Nice win today by kapi18wro, hitting a 8.24x with a 0.742 BTC bet. That brings his total net profit to 17.77 BTC for those watching his slow-and-steady assault on the bankroll =)
|
|
|
|
Option a) could be, I just hope it won't make it more confusing? (making it as simple as possible is the best point of the lottery.) Does it also mean that your "commission" is 0% at start and 50% at end? (not that I really care about that, just wondering.)
Or I could just transfer the extra money to the next rounds sponsorship. The main point would be that the +EV hunters would want to bet early in the round, which then would make the pot size attractive for casual betters who just want a chance of winning $LARGE_POT But the disadvantage is, as you say, complexity  |
|
|
|
|
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'm still curious about how NLNico's php code gave the right answer, if it's using openssl which has a 32 bit iteration counter? I guess I'll need to take a look at the php source code later. Anyway, the results are definitely right as my javascript check finally terminated (after 14 hours) which confirms it. I started working on: https://www.pevpot.com/verify but it's not quite working yet. I'll finish it off tomorrow Very generous gesture, and nicely done =) |
|
|
|
I've updated the draw page: https://www.pevpot.com/draws/1And 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). If anyone wants to dispute the outcome, now is your chance or it will be considered valid and paid =) Once again, congratulations to cowbay. And thanks everyone for participating! |
|
|
|
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 getting the same result as dooglus with my recompiled openssl, and same outcome: > 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 |
|
|
|
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.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  |
|
|
|
It'll probably run into the same fate, I imagine. 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 |
|
|
|
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? ) |
|
|
|
lol shit. Can someone run this node.js 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 =) |
|
|
|
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? |
|
|
|
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) |
|
|
|
|
Wow! Ok sorry about the lack of automated drawing. Just woke up, and figuring out who won now =)
|
|
|
|
Just 27 blocks to go!The pot is currently a rather incredible +EV 2.55%! I've updated the FAQs, and provided some concrete examples to the provably fair to remove ambiguity. Unfortunately for technical reasons, this draw will not automatically finalize itself, and I'll need to do it tomorrow morning. Good luck all! Also if you want to sponsor a site (or help one of the existing ones, now's your chance! https://www.pevpot.com/sponsors )
|
|
|
|
I'm working on publishing a draw verification script, which you can run in the browser, which gets its data from blockcypher (a completely independent source) to be able to verify the outcomes. This will help me crosscheck my results, and make it easy for people to verify themselves.
Looks like I'm running into bugs with blockcypher API, and unlikely will have the independent tool ready by this draw. After much debugging, I've been able to find what the bug is and reproduce on their block explorer as well: https://i.gyazo.com/9c560a8632d76dd20a5fc57f8e36967c.pngNote how there's no transactions between 383,906 and 383,845 ( same as their API actually ) but there's actually one: https://blockchain.info/tx/ddbb43f5cad891a5938a2e9764fd450bb96e8c97b02004147b3abcde38e49ad6Guess, I'll just use blockchain.info .. lol |
|
|
|
Does Moneypot show where the commission on investors go to? or is it just hidden and is sent to your own (MP OWNER) account?
No, they're just wiped from the liabilities. As a simple example: if someone deposits 1 BTC with cold addresses, my assets go up by 1 BTC but I only increase my liability to them by 0.99 BTC. Same logic applies to all types of commissions. (Although, everything is double-entry, so can easily be queried to audit) I'm sort of interested as an investor, and how goes the legal activities and licenses and such?
I'm far from qualified to give legal advice. You'll need to speak with a lawyer who knows the laws of where you live. |
|
|
|
In 6 blocks (when the height ends in xxx006) we get its block hash (in hex) and apply the key-stretching This is a little ambiguous. Do you include the "0x" prefix? Do you use uppercase or lowercase hex? Do you include leading zeroes? I propose you specify that you will use the 64 lowercase characters given by getblockhash, for example: $ bitcoin-cli getblockhash 383006
00000000000000000ef86b27c174df6a412c0ce43eab1d532034555749294137
Here's an example with a smaller iteration count using that block hash, to check we arrive at the same result: > Buffer(forge.pbkdf2('00000000000000000ef86b27c174df6a412c0ce43eab1d532034555749294137', 'pevpot', 100000, 32, 'sha256'), 'binary').toString('hex')
'39aed3d2eff372916100106e355384495d1794320d4c3cb4c2e0e48cc36bbd06'
Or in Python: $ python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac, pbkdf2
>>> pbkdf2.PBKDF2('00000000000000000ef86b27c174df6a412c0ce43eab1d532034555749294137', 'pevpot', 100000, hashlib.sha256, hmac).hexread(32)
'39aed3d2eff372916100106e355384495d1794320d4c3cb4c2e0e48cc36bbd06'
Confirming that is the case, and that for block 383006 I also arrive at at 39aed (with the smaller iteration count). I'll add this to the provably fair as an example. I'm working on publishing a draw verification script, which you can run in the browser, which gets its data from blockcypher (a completely independent source) to be able to verify the outcomes. This will help me crosscheck my results, and make it easy for people to verify themselves. |
|
|
|
|
Show Posts
