Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 248. (Read 192015 times)
LBC is down ??
Partially done!
I've payed my $500 to the programmer who modified oclvanitygen for searching 32BTC bounty (or any other address actually)
...delete
Moving here https://bitcointalksearch.org/topic/faster-and-autonomous-large-bitcoin-collider-fork-3102823
I've payed my $500 to the programmer who modified oclvanitygen for searching 32BTC bounty (or any other address actually)
...delete
Moving here https://bitcointalksearch.org/topic/faster-and-autonomous-large-bitcoin-collider-fork-3102823
.
For those interested:
Cool. So, LBC is going through first 160 bits of 256? But Rico says it is not.
https://lbc.cryptoguru.org/stats
actually 134.58 bits
Theoretically LBC only needs to search from private key 20 through 2160 in order to find all possible Bitcoin addresses. This is because there are 296 public/private key pairs that map to every Bitcoin address. Assuming the aliasing is even remotely evenly distributed then by the time they get to 2160 they will have exhausted all possible Bitcoin addresses - so they will not need to search from 2160 through 2256.
actually 134.58 bits
Are you on topic, man? 134.58 is just an AVERAGE distance in 2^256 between addresses. And nothing more.
Can you read??? I posted the link where it said that
https://lbc.cryptoguru.org/stats
actually 134.58 bits
Are you on topic, man? 134.58 is just an AVERAGE distance in 2^256 between addresses. And nothing more.
For those interested:
| Puzzle 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 | Key 1 3 7 8 21 49 76 224 467 514 1155 2683 5216 10544 26867 51510 95823 198669 357535 863317 1811764 3007503 5598802 14428676 33185509 54538862 111949941 227634408 400708894 1033162084 2102388551 3093472814 7137437912 14133072157 20112871792 42387769980 100251560595 146971536592 323724968937 1003651412950 1458252205147 2895374552463 7409811047825 15404761757071 19996463086597 51408670348612 119666659114170 191206974700443 409118905032525 611140496167764 2058769515153876 4216495639600700 6763683971478124 9974455244496710 | Low 0 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 2147483648 4294967296 8589934592 17179869184 34359738368 68719476736 137438953472 274877906944 549755813888 1099511627776 2199023255552 4398046511104 8796093022208 17592186044416 35184372088832 70368744177664 140737488355328 281474976710656 562949953421312 1125899906842620 2251799813685250 4503599627370500 9007199254741000 | High 1 3 7 15 31 63 127 255 511 1023 2047 4095 8191 16383 32767 65535 131071 262143 524287 1048575 2097151 4194303 8388607 16777215 33554431 67108863 134217727 268435455 536870911 1073741823 2147483647 4294967295 8589934591 17179869183 34359738367 68719476735 137438953471 274877906943 549755813887 1099511627775 2199023255551 4398046511103 8796093022207 17592186044415 35184372088831 70368744177663 140737488355327 281474976710655 562949953421311 1125899906842620 2251799813685250 4503599627370490 9007199254740981 18014398509482000 | % In the space 100.00% 100.00% 100.00% 0.00% 33.33% 54.84% 19.05% 75.59% 82.75% 0.39% 12.81% 31.02% 27.35% 28.71% 63.99% 57.20% 46.21% 51.57% 36.39% 64.66% 72.78% 43.41% 33.49% 72.00% 97.80% 62.54% 66.82% 69.60% 49.28% 92.44% 95.80% 44.05% 66.18% 64.53% 17.07% 23.36% 45.89% 6.94% 17.77% 82.56% 32.63% 31.67% 68.48% 75.13% 13.67% 46.11% 70.06% 35.86% 45.35% 8.56% 82.86% 87.25% 50.18% 10.74% |
So, LBC is going through first 160 bits of 256? But Rico says it is not.
https://lbc.cryptoguru.org/stats
actually 134.58 bits
So, LBC is going through first 160 bits of 256? But Rico says it is not.
It exhausts each sequential search space, its not brute forcing the whole range
Thanks for the answer! And what's the magic of extracting 2^160 from 2^256? That's totally unclear
adr1 = ripemd160(sha256(pubkey(rand(2^256-2^160)+2^160)))
this line makes no sense to me
2^256 is from 1 to 115792089237316195423570985008687907853269984665640564039457584007913129639936.
2^160 is from 1 to 1461501637330902918203684832716283019655932542976
But the sha256-hash of LONG==1 is almost in the end of 2^256
48635463943209834798109814161294753926839975257569795305637098542720658922315
LONG==1461501637330902918203684832716283019659932542976 (around 2^161 ) is also near hash of 1.
So, if LBC is not going sequentally from PK == 1 to 2^256, does it really solve this puzzle?!
Example it cracks keys like this:
00001
000011
0000111
00001000
000010101
0000110001
00001001100
000011100000
0000111010011
00001000000010
000010010000011
0000101001111011
00001010001100000
000010100100110000
0000110100011110011
00001100100100110110
000010111011001001111
0000110000100000001101
00001010111010010011111
000011010010110001010101
0000110111010010100110100
00001011011110010000001111
000010101010110111001010010
0000110111000010101000000100
and so on
It exhausts each sequential search space, its not brute forcing the whole range
Thanks for the answer! And what's the magic of extracting 2^160 from 2^256? That's totally unclear
adr1 = ripemd160(sha256(pubkey(rand(2^256-2^160)+2^160)))
this line makes no sense to me
2^256 is from 1 to 115792089237316195423570985008687907853269984665640564039457584007913129639936.
2^160 is from 1 to 1461501637330902918203684832716283019655932542976
But the sha256-hash of LONG==1 is almost in the end of 2^256
48635463943209834798109814161294753926839975257569795305637098542720658922315
LONG==1461501637330902918203684832716283019659932542976 (around 2^161 ) is also near hash of 1.
So, if LBC is not going sequentally from PK == 1 to 2^256, does it really solve this puzzle?!
Hey, guys!
Please, anyone can explain how do you predict when LBC will find the key?
I've read (lbc.cryptoguru.org/man/theory) several times, but do not understand that pseudo code (I'm programmer, but noob in crypto)
The point I do not get completely: rico claims that they do not brute 2^256 range, because it is too large and do some hack to make range 2^159.
I of course understand that after sha256 we get a compression of range. But shouldn't sets 2^256 and 2^159 overlap chaotically? So how LBC chooses the right keys from 2^256 that map to unique addresses in 2^159 ?
For solving this puzzle shouldn't LBC brute 2^256 range ?!
Please, anyone can explain how do you predict when LBC will find the key?
I've read (lbc.cryptoguru.org/man/theory) several times, but do not understand that pseudo code (I'm programmer, but noob in crypto)
The point I do not get completely: rico claims that they do not brute 2^256 range, because it is too large and do some hack to make range 2^159.
I of course understand that after sha256 we get a compression of range. But shouldn't sets 2^256 and 2^159 overlap chaotically? So how LBC chooses the right keys from 2^256 that map to unique addresses in 2^159 ?
For solving this puzzle shouldn't LBC brute 2^256 range ?!
It exhausts each sequential search space, its not brute forcing the whole range
This is still going on.
GL
GL
Hey, guys!
Please, anyone can explain how do you predict when LBC will find the key?
I've read (lbc.cryptoguru.org/man/theory) several times, but do not understand that pseudo code (I'm programmer, but noob in crypto)
The point I do not get completely: rico claims that they do not brute 2^256 range, because it is too large and do some hack to make range 2^159.
I of course understand that after sha256 we get a compression of range. But shouldn't sets 2^256 and 2^159 overlap chaotically? So how LBC chooses the right keys from 2^256 that map to unique addresses in 2^159 ?
For solving this puzzle shouldn't LBC brute 2^256 range ?!
Please, anyone can explain how do you predict when LBC will find the key?
I've read (lbc.cryptoguru.org/man/theory) several times, but do not understand that pseudo code (I'm programmer, but noob in crypto)
The point I do not get completely: rico claims that they do not brute 2^256 range, because it is too large and do some hack to make range 2^159.
I of course understand that after sha256 we get a compression of range. But shouldn't sets 2^256 and 2^159 overlap chaotically? So how LBC chooses the right keys from 2^256 that map to unique addresses in 2^159 ?
For solving this puzzle shouldn't LBC brute 2^256 range ?!
Don't fully understand but ok.
LBC is going to start finding the 55th key in a few hours.
With 3GH/s should take around ~37 days
0.55 BTC plus BCH plus BTG yields around
~0.66 BTC = $8,500
Basically about 2x as profitable as regular ETH mining with a RX470/570 if you can find it in 37 days and not closer to the end around 74 days.
With 3GH/s should take around ~37 days
0.55 BTC plus BCH plus BTG yields around
~0.66 BTC = $8,500
Basically about 2x as profitable as regular ETH mining with a RX470/570 if you can find it in 37 days and not closer to the end around 74 days.
is it going to find the 55th key or start finding it in a few hours?
LBC is going to start finding the 55th key in a few hours.
With 3GH/s should take around ~37 days
0.55 BTC plus BCH plus BTG yields around
~0.66 BTC = $8,500
Basically about 2x as profitable as regular ETH mining with a RX470/570 if you can find it in 37 days and not closer to the end around 74 days.
With 3GH/s should take around ~37 days
0.55 BTC plus BCH plus BTG yields around
~0.66 BTC = $8,500
Basically about 2x as profitable as regular ETH mining with a RX470/570 if you can find it in 37 days and not closer to the end around 74 days.
Y'all gave up yet.....
Haha, this reminds me of https://www.funnyvideosapp.com/watch/
Jump to: