Bitcoin Forum
June 17, 2021, 11:41:13 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Bitcoin consumes 'more electricity than Argentina' on: February 11, 2021, 11:26:20 AM

Cambridge researchers say it consumes around 121.36 terawatt-hours (TWh) a year - and is unlikely to fall unless the value of the currency slumps.
The online tool has ranked Bitcoin’s electricity consumption above Argentina (121 TWh), the Netherlands (108.8 TWh) and the United Arab Emirates (113.20 TWh) - and it is gradually creeping up on Norway (122.20 TWh).

“Bitcoin is literally anti-efficient,” David Gerard, author of Attack of the 50 Foot Blockchain, explained. “So more efficient mining hardware won't help - it'll just be competing against other efficient mining hardware.

“This means that Bitcoin's energy use, and hence its CO2 production, only spirals outwards.

“It’s very bad that all this energy is being literally wasted in a lottery.”

The price of Bitcoin rose rapidly on Monday after Tesla announced its investment.

But commentators say the investment clashes with the electric car firm's previous environmental stance.

“Elon Musk has thrown away a lot of Tesla's good work promoting energy transition,” Mr Gerard said. “This is very bad... I don't know how he can walk this back effectively.

"Tesla got $1.5bn in environmental subsidies in 2020, funded by the taxpayer.

"It turned around and spent $1.5bn on Bitcoin, which is mostly mined with electricity from coal. Their subsidy needs to be examined."
2  Bitcoin / Development & Technical Discussion / Using Kangaroo for WIF solving on: February 08, 2021, 02:13:23 PM

I would like to share with you my modifications of Jean-Luc's famous Kangaroo program. I adapted it to be used as a 'WIF solver'.
In general, there are 2 cases - where stride is large enough not to collide with WIF checksum or when it is more complicated and stride collides.
I described it and showed test examples on github:
but I will also rewrite it here.

Let's take WIF: 5HrdZxkxnVst8Q3qCLJkeiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu which encodes the private key 0552e025571c01bcda0297c22731d74becbd30d07e4ec355c741825fffc0a672.
Decoded WIF shows checksum 524412ca
The corresponding public key is 04777c026b8085951da7117395bf269c055f36bf2ddf623281962855edee36d4e73bec2fa87b122 a0f1b2841ef4f7afdec2443f89c151ee2597feac18ae0d62bdf

  • Search without checksum (large stride)
Let's take WIF 5HrdZxkxnVst8Q_____keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu
Now, we may find the first WIF to be tested, it will be 5HrdZxkxnVst8Q11111keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu. When we decode it, we find the private key which is the beginning of our range: 0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467
Now, we must calculate the number of WIFs in our range. Beause we have 5 missing characters, it will be 58^5 = 656356768 (271f35a0 hex)
To have the end of range for Kangaroo, we must calculate fake end which is start + range
new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467",16).add(new BigInteger("656356768",10)).toString(16) =
We check where is the most right unknown character - it's position will tell us what is the stride. In our case it is 58^32 = af820335d9b3d9cf58b911d87035677fb7f528100000000
Because WIFs encodes checksum, we must observe if stride collides with checksum. Fortunately - not, because the last 8 characters (length of checksum) are 0s. We may remove these zeros and get shorter stride.
The final configuration file is:
and test:
$ ./kangaroo -stride af820335d9b3d9cf58b911d87035677fb7f5281 test_af820335d9b3d9cf58b911d87035677fb7f5281.txt
Kangaroo v2.2
Stop :552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848E3DE3A07
Keys :1
MaxRange: 271F35A0
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 2
Range width: 2^30
Jump Avg distance: 2^15.04
Number of kangaroos: 2^11.00
Suggested DP: 1
Expected operations: 2^16.11
Expected RAM: 13.3MB
DP size: 1 [0x8000000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos

 verify PK 552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848BEA7DAF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848BEA7DAF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

  • Search with checksum (small stride)
Let's take WIF 5HrdZxkxnVst8Q3qCLJkeiLe1k4Am____hqQVUYVxVSBkf5VfUu
Now, we may find the first WIF to be tested, it will be 5HrdZxkxnVst8Q3qCLJkeiLe1k4Am1111hqQVUYVxVSBkf5VfUu. When we decode it, we find the private key which is the beginning of our range: 0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde
Now, we must calculate the number of WIFs in our range. Beause we have 4 missing characters, it will be 58^4 = 11316496
To have the end of range for Kangaroo, we must calculate fake end which is start + range
new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =
We check where is the most right unknown character - it's position will tell us what is the stride. In our case it is 58^18 = 2b85840fc1d6a480ae7fa240000
Unfortunately the stride collides with checksum (last 8 characters are not 0s). It means that for our calculations we must take into account the proper checksum And this is difficult part, because the real checksum is unknown. In our test it is known, but in real-life it could be needed to see how many possibilities there are. For example, in this case, playing with missing characters of WIF we may observe that last 4 characters of checksum are fixed. The first 4 could be changed, BUT the 4th character gets only 4 values. It means that if we want to use this method for real-life problem, we may need to do calculations for 16*16*16*4 checksums (in fact will less operations needed, because many checksums will generate the same private key in addition to the stride).
Because stride collides with checksum, we will have to use the full (long) value and pass checksum as a parameter.
The final configuration file is:
and test:
$ ./kangaroo -stride 2b85840fc1d6a480ae7fa240000 -checksum 524412ca test_2b85840fc1d6a480ae7fa240000_524412ca.txt
Kangaroo v2.2
Stop :552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC9129947400EACEE
Keys :1
MaxRange: ACAD10
Jump: 2B85840FC1D6A480AE7FA240000
Number of CPU thread: 2
Range width: 2^24
Jump Avg distance: 2^11.97
Number of kangaroos: 2^11.00
Suggested DP: 0
Expected operations: 2^13.25
Expected RAM: 12.4MB
DP size: 0 [0x0]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos

 verify PK 552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC91299473FAD12F9
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC91299473FAD12F9
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

3  Economy / Service Discussion / Wallet Recovery Service(s) - fake copy? on: January 22, 2021, 07:24:50 AM
Have you seen page -> ?
I guess it is not the original Dave ->

The other one (without s) has even this same subpages.

I must say - very nice try... In the future Dave should buy both domains...
4  Bitcoin / Bitcoin Discussion / British hospitals use blockchain to track COVID-19 vaccines on: January 19, 2021, 09:17:00 AM

Two British hospitals are using blockchain technology to keep tabs on the storage and supply of temperature-sensitive COVID-19 vaccines, the companies behind the initiative said on Tuesday, in one of the first such initiatives in the world.

Two hospitals, in central England’s Stratford-upon-Avon and Warwick, are expanding their use of a distributed ledger, an offshoot of blockchain, from tracking vaccines and chemotherapy drugs to monitoring fridges storing COVID-19 vaccines.

The tech will bolster record-keeping and data-sharing across supply chains, said Everyware, which monitors vaccines and other treatments for Britain’s National Health Service (NHS), and Texas-based ledger Hedera, owned by firms including Alphabet’s Google and IBM, in a statement.

Logistical hurdles are a significant risk to the speedy distribution of COVID-19 vaccines but have resulted in booming business for companies selling technology for monitoring shipments from factory freezer to shots in the arm.

Pfizer Inc and BioNTech’s shot, for example, must be shipped and stored at ultra-cold temperatures or on dry ice, and can only last at standard fridge temperatures for up to five days.

Other vaccines, such as Moderna Inc’s, do not need such cold storage and are therefore easier to deliver.

“We can absolutely verify the data that we’ve collected from every single device,” Everyware’s Tom Screen said in an interview. “We make sure that data is accurate at source, and after that point we can verify that it’s never been changed, it’s never been tampered with.”

Firms from finance to commodities have invested millions of dollars to develop blockchain, a digital ledger that allows the secure and real-time recording of data, in the hope of radical cost cuts and efficiency gains.

Results have been mixed, though, with few projects achieving the revolutionary impact heralded by proponents.

Everyware’s Screen said it while it would be possible to monitor the vaccines without blockchain, manual systems would raise the risk of mistakes.

The system will “allow us to demonstrate our commitment to providing safe patient care,” said Steve Clarke, electro-bio medical engineering manager at South Warwickshire NHS in a statement.
5  Other / Beginners & Help / Burning dust on: December 16, 2020, 01:32:50 PM
How can we burn dust? As far as I understand, the idea behind is to observe transactions which contain dust and see if several addresses sends dust "together" -> in one transaction or to the same address.
What if all the people would send dust to one agreed address?
6  Bitcoin / Bitcoin Discussion / Dark Horse puzzles on: December 15, 2020, 07:23:15 PM
New set of puzzles is coming:


7  Bitcoin / Project Development / LostWord - Program for retrieving lost words of Bitcoin BIP39 seed. on: November 30, 2020, 09:27:05 PM

Recently someone on this forum wrote that he has 23 words of his seed and was looking for a way to find the last, missing word, which could be on any position. As he had problems with his python for btcrecover, I wrote a very simple java program. Unfortunately for some reason it did not work for him, but as I had some time today to play with it, I publish the next release. It is nothing special, but I treat it as a way to learn something new and maybe someone will find it interesting - or even better, someone will find it useful. My idea was to make it more user-friendly than btcrecover. There is still lot of things which could be done, but let's start slowly.
Currently I use library from bitcoin core, what I was able to cover is (based of wonderful page BIP32 and BIP141/P2WPKH. Maybe it is possible to have other modes implemented, I must investigate.
It is also possible to specify derivation path, if one wants to look for address which is not the first one. And 'hardened address' option works too.
Please let me know if you have any idea what also could be useful for some people, maybe you know any other interesting use cases. I think the easiest would be to check several consecutive addresses from derivation path, but is it really important?
The code and compiled jar is available on github:

Now program words in modes:
All is described in ReadMe in github.

8  Local / Polski / BIP-39 po polsku on: September 08, 2020, 10:48:49 AM

Robimy naszą wersję?
9  Bitcoin / Development & Technical Discussion / Solving WIF in a 'hybrid' mode on: July 31, 2020, 07:57:23 AM

I would like to share with you one thing I found recently - maybe you will give me a hint how to use it in the most effective way.
Recently I published my WIF Solver ( with several ways to 'attack' problem of missing characters. I would like to talk about method called JUMP. Please let me describe the method and then I will ask a question.
In the example in my project I use WIF L5EZftvrYaSud_____zTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 (taken from a very helpful site
So, let's take the WIF and replace missing characters by '1', we will get:
L5EZftvrYaSud11111zTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 and try to decode it. We will get a hex string, starting with '80' + priv key + compression flag + checksum. Lets call it hexInit
As we see, compression flag is incorrect - so something is wrong... Go on.
I focus on fact that for any correct WIF generated from the initial one, after decoding there must be a flag '01' and given checksum. Now, let's jump to the first missing character on the right. We may say, that when we iterate Base58 characters in fact we increase our hex number (08+priv+01+checksum) by 58^34. But I realized that adding 58^34 to hexInit will change the last bytes - checksum and compression. I asked myself - is there a combination which will set '01' + expected checksum again (I mean not only in the real WIF which we look for?).
So I add 58^34 several times and yes! WIF: L5EZftvrYaSud1111uzTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 produces desired ending.
(in fact I check existence of flag '01' and not the full checksum, but last 7 characters - I found that the 8th character from right could be different)
We have our WIF which we may use as a starter for calculations.
The other question is - is there a fixed length of jump? And question is again yes - for this case length is 64.
Which means that we may now forget about working on WIF and instead start working on 'numbers'.
Let's take number starter = 80ef235aacf90d9f4a9df7ba29006cad4ec1c6610833d3a8587b4d7c662e5ce97a0166557e53 and increase it, but not by 58^34 (like it would be in brute force method - just a next Base58 character) but by 64*(58^34) - we have our jump 240921c8be82fd68a2a77fba0089f71029354609c90000000000 - as we see last 10 characters are 0, so it will not change the end of 'decoded' hex string.
This way we save some time, because we do much less number of additions.
[By the way, I also checked what are then possible characters on 34th, 33rd, 32nd... position), and we may find that we have 29*29*29... correct combinations, which is much more optimistic that 58*58*...]

Now, my question is:
Replacing missing letters by 111 -> zzzz, +- with correction for a 'valid' starter/finish, we may find a target range [starter, finish]. And we know that we may use jump as a number to add, which makes our range not 'continuous' but sparse (we may think about it like about islands). Is there any method 'smarter' than brute-force iteration? We may make an assumption that we look for pubkey, not address if it helps.

Of course we may change our variables, remove unneeded characters and pass is to BitCrack (
it would have keyspace start=ef235aacf90d9f4a9df7ba29006cad4ec1c6610833d3a8587b4d7c662e5ce97a and stride=240921c8be82fd68a2a77fba0089f71029354609c9) and then search for address. But is there any better way?

(diff: 160722da414e57a2fba781a9ec325dd3c589ce9c01397674) - full range
diff/jump = 9c7cd4 - number of strides to do

10  Bitcoin / Development & Technical Discussion / One more WIF Solver on: July 24, 2020, 11:05:34 AM
First at all 'Hello!'. After reading the forum for some time, finally I opened the account.
I would like to share with you my WIF Solver - having some free time recently I made a small application for restoring damaged WIFs.
More information you may find on github:
I prepared 5 scenarios of solving problem, I am interested in your opinion - what could be added or improved?
Especially I would like to ask what do you think about the JUMP approach. I realized that knowing how hex format ends (after decryption of part of WIF) it is possible to calculate the minimum jump length - the number which added to our private key, if converted back to hex keeps the end 'untouched'. Of course there is still matter of wrong checksum, but this could be checked later, when trying to decode generated WIF. The idea was not to test each possible combination of WIF, but only the selected one.
Maybe I cannot clearly describe how this approach works, but please check the example.
If you have any comments or questions - I am glad to hear it.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!