Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I won't post its source, but soon I will post some software for K (examining K*sqrt required ops) - from classic 2.1 to best 1.23 so people who are interested can learn some things.
I solved #120, #125 and #130 for now, for 130 DB with DP was about 1TB.
About big DP overhead in JLP you can check my old posts, I'm glad that it's super easy for you to make less number but faster kangaroos to reduce this overhead
I solved #120, #125 and #130 for now, for 130 DB with DP was about 1TB.
About big DP overhead in JLP you can check my old posts, I'm glad that it's super easy for you to make less number but faster kangaroos to reduce this overhead
How do you managed and accessed the DP database efficiently, given its 1TB size. Did you employ any specific data structures or caching strategies to minimize access time?
You mentioned achieving a reduction in the required operations from classic 2.1 to best 1.23 in K * sqrt terms. Could you explain what methods or optimizations contributed most to this efficiency? How did you implement these changes in your software?
When transitioning from JLP's code to your custom implementation, what metrics did you use to benchmark efficiency improvements? Were there any specific areas where you saw the most significant speed gains?