Bitcoin Forum
March 16, 2026, 10:10:11 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 [641]
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 373872 times)
anyone_future_again
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
Today at 03:05:35 PM
 #12801


[/quote]
I tried to duplicate your claim and could not. The only opportunity I know of to implement a double sha256 without completely violating parameters would be on the pubkey before  ripem160 yea?
[/quote]
After you make first SHA256 you apply the RIPEMD160 and you will find the BTC address without the last 4 bits.

After i was studying the problem, i see that everybody want to have his own pool and work alone, instead of working in group and share...

If anyone have his work and database, this means everyone will scan almost the same ranges and this is not ok...all that hard work to be lost for nothing...

So i am thinking to create a public database where everyone who contribute with good information to have access and  free and will be a rule like this: add at least 10 ranges of B9 of 5 ranges of B9j(with script that will verify behind if really are real) and after that the registration will be done!

It's a good ideea?
kTimesG
Full Member
***
Offline Offline

Activity: 770
Merit: 236


View Profile
Today at 07:35:45 PM
 #12802

It's a good ideea?

No, your database would have zero reliability and zero trust. You'd also not be the first to do this, and neither the first to quickly get roasted pretty hard around here that your database is neither reliable or trustworthy.

Off the grid, training pigeons to broadcast signed messages.
danielcec2
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
Today at 08:34:12 PM
 #12803

The key lies within 93 to 97% of the total range.
anyone_future_again
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
Today at 08:36:52 PM
 #12804

It's a good ideea?

No, your database would have zero reliability and zero trust. You'd also not be the first to do this, and neither the first to quickly get roasted pretty hard around here that your database is neither reliable or trustworthy.

I see the point. Yes, you are right about this.

Regarding the the bitcrack and vanitysearch there is a big problem using it. Normal users are seeing a speed and they are happy that the numbers are big, but the real problem is the process behind.
The authors was cutting from the process and increasing the speed, but forgot about this:
Endomorphism — What It Is and Why It Matters
The secp256k1 curve (Bitcoin) has a special mathematical property. If you compute one EC point k·G = (x, y), you get 5 more valid keypairs for almost free:
Check
Operation
Cost
k
Direct point
Full EC step
λk
(β·x mod p, y)
1 field multiply
λ²k
(β²·x mod p, y)
1 field multiply
-k
(x, -y mod p)
1 negation (free)
-λk
negate above
free
-λ²k
negate above
free
Cost ratio: 1 expensive EC step → 6 address checks. The extra 5 come from two cheap multiplications + negations.

Until puzzle 135 is ok to use it, but on the real BTC addresses is useless without Endomorphism. On my software version i added this option so when you search, you have all 6 addresses checked besided the versions from Github that check only 1.
0xastraeus
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
Today at 09:59:53 PM
 #12805

Dear god buddy lay off the AI. what are you on about. Endomorphism is not useful here, it'll search outside the range. All that mumbo jumbo you spewed out has nothing to do with what kTimesG said.

It's a good ideea?

No, your database would have zero reliability and zero trust. You'd also not be the first to do this, and neither the first to quickly get roasted pretty hard around here that your database is neither reliable or trustworthy.

I see the point. Yes, you are right about this.

Regarding the the bitcrack and vanitysearch there is a big problem using it. Normal users are seeing a speed and they are happy that the numbers are big, but the real problem is the process behind.
The authors was cutting from the process and increasing the speed, but forgot about this:
Endomorphism — What It Is and Why It Matters
The secp256k1 curve (Bitcoin) has a special mathematical property. If you compute one EC point k·G = (x, y), you get 5 more valid keypairs for almost free:
Check
Operation
Cost
k
Direct point
Full EC step
λk
(β·x mod p, y)
1 field multiply
λ²k
(β²·x mod p, y)
1 field multiply
-k
(x, -y mod p)
1 negation (free)
-λk
negate above
free
-λ²k
negate above
free
Cost ratio: 1 expensive EC step → 6 address checks. The extra 5 come from two cheap multiplications + negations.

Until puzzle 135 is ok to use it, but on the real BTC addresses is useless without Endomorphism. On my software version i added this option so when you search, you have all 6 addresses checked besided the versions from Github that check only 1.
Pages: « 1 ... 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 [641]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!