Bitcoin puzzle transaction ~32 BTC prize to who solves it

[adaseb]

Cross posting this



Congrats on finding the private key. I don't think you know but you can also claim BitCore and Bitcoin GOLD with that private key. I see you or somebody already claimed Bitcoin Cash.

I sweeped both your BitCore and BitcoinGold funds before somebody else got to it. Post a BitCore and BitcoinGold address in this thread and I will send them back to you.

Here are those transaction ids

https://chainz.cryptoid.info/btx/tx.dws?172551.htm

http://btgexp.com/tx/f78617a5e6bf438c7a310639f6d8fe10c194a74be6ac98b2c329024a4d1df745


EDIT: Please post your addresses where you want the coins sent in the 32btc contest thread since its unmoderated.

[1715122409]

1715122409

[1715122409]

1715122409

[1715122409]

1715122409

[rico666]

I sweeped both your BitCore and BitcoinGold funds before somebody else got to it. Post a BitCore and BitcoinGold address in this thread and I will send them back to you.

Here are those transaction ids

https://chainz.cryptoid.info/btx/tx.dws?172551.htm

http://btgexp.com/tx/f78617a5e6bf438c7a310639f6d8fe10c194a74be6ac98b2c329024a4d1df745

EDIT: Please post your addresses where you want the coins sent in the 32btc contest thread since its unmoderated.

Thank you for the noble offer, but it seems not worth the hassle to go for every BTC fork. (We didn't even claim Bitcoin Cash).

If you want to support the project - which would be greatly appreciated - you can keep both BitCore and BitcoinGold funds you sweeped and transfer whatever you deem appropriate to the LBC Pot (https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6).

Thank you.

If this "mode of operation" is ok for you, feel free to send me an email address via PM, we could inform you in advance of private keys found, so you could see if you can process the BitCore and BitcoinGold attached to them.

[adaseb]

I sweeped both your BitCore and BitcoinGold funds before somebody else got to it. Post a BitCore and BitcoinGold address in this thread and I will send them back to you.

Here are those transaction ids

https://chainz.cryptoid.info/btx/tx.dws?172551.htm

http://btgexp.com/tx/f78617a5e6bf438c7a310639f6d8fe10c194a74be6ac98b2c329024a4d1df745

EDIT: Please post your addresses where you want the coins sent in the 32btc contest thread since its unmoderated.

Thank you for the noble offer, but it seems not worth the hassle to go for every BTC fork. (We didn't even claim Bitcoin Cash).

If you want to support the project - which would be greatly appreciated - you can keep both BitCore and BitcoinGold funds you sweeped and transfer whatever you deem appropriate to the LBC Pot (https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6).

Thank you.

If this "mode of operation" is ok for you, feel free to send me an email address via PM, we could inform you in advance of private keys found, so you could see if you can process the BitCore and BitcoinGold attached to them.

I can sweep for you keys in the future only from the 32btc contest. So for the 55bit key and so forth. I can't sweep any other address due to the fact that it might belong to someone.

Its really not that difficult. For Bitcore you just download their wallet with the included blockchain (300mb) and it syncs quick since their blockchain is mostly empty and just go to Debug and put in "importprivkey XXXXX" and you are all set. You can sell on Crytopia.

For BitcoinGold I just used the Coinomi app from the Android app store. Just build a new wallet and there is an option there to sweep a BitcoinGold address.

Thanks for letting me keep the funds, I will keep half and donate the other half to your LBC Pot. As soon as either Poloniex or Bitfinex allows BitcoinGold deposits.

[rico666]

I can sweep for you keys in the future only from the 32btc contest. So for the 55bit key and so forth. I can't sweep any other address due to the fact that it might belong to someone.

Its really not that difficult. For Bitcore you just download their wallet with the included blockchain (300mb) and it syncs quick since their blockchain is mostly empty and just go to Debug and put in "importprivkey XXXXX" and you are all set. You can sell on Crytopia.

For BitcoinGold I just used the Coinomi app from the Android app store. Just build a new wallet and there is an option there to sweep a BitcoinGold address.

Thanks for letting me keep the funds, I will keep half and donate the other half to your LBC Pot. As soon as either Poloniex or Bitfinex allows BitcoinGold deposits.

Sure - all of what you said goes d'accord with our stab at it - limited to the puzzle transactions it shall be.

It's just that we do only care about the BTC as that is where the project started off. So transferring the funds to a custodial address then publishing the privkey refers to BTC only and means the forks become at the time of publishing the privkey accessible to everybody else.

NOT OUR PROBLEM. I might add.

So by transferring these also to custodial addresses, you would actually save them for their rightful owners, because we do not care.
Also we certainly know technically how to sweep the funds, but the hassle of another blockchain and another exchange-account seems not worth it.

[1Trash]

We should find a solution instead of brute forcing. What do you think?

The newest approach is very promising. As a basis we use the binaries of the private keys in a descending order and a special cellular automaton:

██░░█░░█░░██░██░     
██░█░░░████░░██   
█░█░░█░░██░░░░     
█░█░░░██░░░░░     
█░█░░████░██     
█░░█░░░░░██     
█░░░░░░░█░           
███░█░░██     
███░░░░░     
█░░██░░     
██░░░█     
█░█░█           
█░░░               
███           
██           
█           

Cellular Automaton:
Input:    ██░  █░█  ░█░  █░░  ░░░  ░░█  ░██  ███  ░░█  ░██
Output: ██░  █░█  ░█░  █░░  ░░░  ░░█  ░██  ███  ░░█  ░██

The automaton speciality is that there isn't one static rule for the output, but the output depends on how often the rule has been executed before (same column). One big hint that someone has come up with this is: All the rules in- and outputs are the same!!

Example (See beginning of first row -> second row):

██░   
  █

██░ => █    because the function is executed the (3 % x = 1) th time

then second -> third:

██░ => ░    because the function is executed the (3 % x = 2) th time

██░
  ░


When you double check the results with 6 digit US patents ( US137821, US497622 !!! ) you see where this leads to ...

Keep up the good work!

...

https://1trash.github.io/

[BurtW]

You are wasting your time.  The person who created the puzzle has already posted exactly how he did it.  It is random.  You will not find a pattern to predict the private keys.

[Bausa]

Haha, this reminds me of https://www.funnyvideosapp.com/watch/

[bigvito19]

Y'all gave up yet.....

[adaseb]

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.

[bigvito19]

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.

is it going to find the 55th key or start finding it in a few hours?

[lamcouz]

Don't fully understand but ok.

[holy_ship]

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 ?!

[cozk]

This is still going on.

GL

[bigvito19]

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 ?!

It exhausts each sequential search space, its not brute forcing the whole range

[holy_ship]

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?! 

[bigvito19]

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

[holy_ship]

So, LBC is going through first 160 bits of 256? But Rico says it is not.

[bigvito19]

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

[ZafotheNinja]

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%

[holy_ship]

actually 134.58 bits

Are you on topic, man? 134.58 is just an AVERAGE distance in 2^256 between addresses. And nothing more.