 Show Posts
|
|
Pages: [1] 2 »
|
|
I've tested cuBitcrack and Keyhunt-cuda:
Bitcrack generates starting points but checks the range sequentially from start to end !
So what is the use of these starting points?
|
|
|
|
|
Is it possible (theoretically) to Brute-force multi-sig addresses?
As far as I know the only threat to our multi-sig wallets is the risk of being hacked.
|
|
|
|
This thread broke my motivation to keep searching. I'm thinking of pausing the search if there isn't any definitive solution.
The attackers are unlikely to succeed if you make a transaction with the highest fee and non-RBF. But if you feel you're wasting time and money on the puzzle 64 just ignore it! and focus on the puzzle 120 which you are more likely to find and there is almost no risk of attacking for it. |
|
|
|
RBF activation and deactivation option is available in Bitcoin Core.
If I transfer the private key to Bitcoin Core and disable the RBF option from there, will there be a definitive solution if I start the transfer process from there?
There is no guarantee for such transaction that private key will be leaked in less than a minute but you have to disable RBF, set highest fee and pray to God that the tx will be confirmed before any attack. You haven't found the private key yet, so what are you worried about !? |
|
|
|
Yes, I'm sure they'll find it in such a short time. They can create RBF in 1 minute in total. Do you have an idea as a solution to this?
Setting highest fee and CPFP fee bumping are the only techniques that you can use to increase your chance. |
|
|
|
My computer has been searching for about a year, and I'm not hopeful.
However, today it occurred to me that the transfer of the person who finds the 64th puzzle may be cancelled.
In other words, after the transfer process starts, the public key will be revealed and thieves who do not deserve it will find the public key within minutes with Kangoroo. Then they will open a double trade with RBF by spending high, the transfer of the person who finds it will be cancelled.
It occurred to me that the thief would figure it out in about 3 minutes.
The average bitcoin transfer confirmation takes 10 minutes and can be canceled without 3 confirmations. (I could be wrong, please correct me.)
How can you get 3 confirmations in 5 minutes in Bitcoin transfer?
First, you have to know that finding a private key with Kangaroo in range 8000000000000000 to FFFFFFFFFFFFFFFF takes less than 10 seconds with a gpu like RTX 2080ti as I tested. Replacing a tx in such a situation was also a question for me: https://bitcointalk.org/index.php?topic=5361673.0 |
|
|
|
Interesting List you have. I would have given merits If I had some.
I don't think that they can be effectively searched in parallel. You have to divide each pubkey and check it with the babysteps. So not only do you need to make very expensive global memory lookup (GPU has slow global and super fast local memory) and load each key.
So if you would search multiple keys you would effectively reduce the performance by them. Like 10 keys in parallel means 10 times slower. 2800 keys means 2800 times slower.
Is there a limit to the number of pubkeys in the input txt file? I am sure there will be a limit, but it is probably in the millions. For similar programs, it usually caps out at around 30 million addresses, pubkeys, xpoints... a.a. Have you ran this program yet? It's just that some of your answers make it seem like you have not ran it at all. The program does not check keys in parallel, it runs range with one pubkey, once finished, it moves to the next, until the last pubkey has been checked for that specific range. Thanks for your good explanation, I got how it works. So multiple xpoints checking (in parallel) is only possible with KeyHunt-CUDA. |
|
|
|
New release v1.4.0
supported compressed/uncompressed format public keys
removed binsort program (don`t need sorted array any more)
baby array need only first time to create HT (or rebuild HT when -htsz changed)
After HT created and saved, next time you will need less ram and only HT, giant array to launch.
...
Thanks for your great code. Is there a limit to the number of pubkeys in the input txt file? Here is the list of 2800 top richest pubkeys: https://pastebin.com/YMr3BaiU |
|
|
|
I tested your BSGS on GTX 1660s, the speed was significantly slower than JeanLucPons Kangaroo: BSGS-cuda => 330 Mkey/s Kangaroo 2.2 => 450 Mkey/s |
|
|
|
Not without knowing the redeem script used in these P2SH addresses.
That requires the owner to spent from that address at least once and reveal that redeem script, then it is trivial to look at it and know the details.
I tried many ways to check addresses that start with 3 if it's segwit or not but I couldn't find any tool that can check the address if it's segwit or not.
Except to those addresses that already have spent transactions.
I got it Thanks for your explains |
|
|
|
|
As you know bitcoin adresses start with 3 can be p2sh or p2wsh-p2sh.
Is it possible to find out the script-type of these addresses? or the number of cosingers/signs?
|
|
|
|
Are these similar privatekeys have certain distances from each other? What do you mean by saying “similar private keys” and “distances”? Are those private keys which have same address, distributed randomly in 2^256 range? or they have certain numerical distances? |
|
|
|
I thought the number of valid private keys = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (decimal) ? My bad, thanks for correcting me! Indeed, the keys are - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140. I confused the total private keys with - fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f - which is p and F p the finite field of secp256k1. I updated my post. Thanks for your good explain. Are these similar privatekeys have certain distances from each other? or they are random in the whole range? |
|
|
|
I'll show you how detailly and decimally how many private keys can create the same address. So there are 2 256-2 32-977 valid private keys. That's: 115792089237316195423570985008687907853269984665640564039457584007908834671663 Total combinations of a 160-bit number are 2 160 which is: 1461501637330902918203684832716283019655932542976 So, each address should averagely have the division of those two numbers; 115792089237316195423570985008687907853269984665640564039457584007908834671663 / 1461501637330902918203684832716283019655932542976 That's: 79228162514264337593543950336 Each time you spend bitcoins from one of your addresses, you're signing using 1 of the 79,228,162,514,264,337,593,543,950,336 different and valid, on average, private keys. I thought the number of valid private keys = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (decimal) ? |
|
|
|
You mean how many private keys give the same compressed address? As said, approximately 2256 / 2160 = 296. That's true for uncompressed addresses too.
When you say approximately 2^96 ! then maybe there are more (or less) than 2^96 privatekeys for some addresses? Is the number of pubkeys the same? |
|
|
|
|
Hi
As I read this post, two questions came to me:
1. Is it possible that Compressed address of Privatekey_X be the same as Uncompressed address of Privatekey_Y?
2. How many private keys are in the range with the same Compressed address?
|
|
|
|
|
Thanks for all the replies.
I knew everything you explained but I don't understand why the developers has removed that option after v4.0.9 !
However, you can create any type of addresses in Electrum wizard by using BIP39 seed.
|
|
|
|
|
Hi everyone
What happened to Electrum that only generates SegWit addresses?
Why they removed the option to generate legacy Multi-signature addresses?
|
|
|
|
|
