Bitcoin Forum
July 11, 2024, 06:37:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Would these two wallets be equally hard to brute force attack? on: May 28, 2023, 02:18:40 AM
Would a HD wallet generated with a 24 words passphrase attached to a 24 word seed phrase that is know to an attacker be as hard to brute force as a HD wallet generated using only 24 words and no passphrase?
2  Bitcoin / Bitcoin Discussion / Seeking feedback on my HD wallet setup plan on: May 25, 2023, 05:55:49 PM
I'm in the process of creating a new HD wallet and am hoping for some constructive criticism on my plan, especially if there's anything that you think could be improved.

The objective here is to build a wallet strategy that's impervious to my own forgetfulness, potential house BBQs (aka house fires), theft, hackers breaking in to my cloud account, and even the notorious $5 wrench attack. So, let's dive into my approach:

Step 1: I'm going to concoct two passwords, hidden in plain sight within a book. I'll pick twenty random words and mark them with underlines or circles, interspersed with entire sentences and decoy notes for good measure. This book will be stored inconspicuously at home, and a duplicate copy (markings included) will be kept at my workplace or a relative's house. They'll be none the wiser about its significance. I'll also make a mental note of these passwords. I do realize that this approach might not generate the most random or high-entropy passwords possible (compared to, let's say, picking 20 totally random words from a dictionary), but I believe they will be robust enough for the job at hand.

Step 2: I'll use Ian Coleman's BIP39 tool on an offline computer to create a 24-word seed, using a deck of cards for randomness. This mnemonic phrase will be encrypted with the first password and tucked away into a .txt file, which will reside both locally and on the cloud. A physical copy will also be safely stashed among my belongings at home.

Step 3: The 24-word seed will be transferred to a hardware wallet, where I'll deposit a small amount of funds as a honeypot. This will alert me if someone manages to get their hands on my seed. Then, I'll add a passphrase using the second password and transfer the lion's share of my funds there.

Now, for the worst-case scenarios:

• Memory lapse: The marked book serves as my cheat sheet. If I can't even remember which book I used, well, that's probably dementia and at that point, I guess my wallet will be the least of my worries.
• House fire: Should my home pull a spontaneous BBQ act, I can retrieve my encrypted seed phrase from the cloud, and the passwords can be found either from my memory or from the book's doppelgänger.
• Theft: I doubt that any burglar moonlighting as a literary critic will decipher the marked book and connect it with my seed phrase. In a worst-case scenario, they might just stumble upon the honeypot and stop there.
• Cloud account hacking: Even if a hacker manages to breach my cloud accounts, they'd still need to crack two robust passwords to access my seed phrase. They might just call it a day after draining the honeypot.
• $5 wrench attack: In such a case, I'd lead the attacker to the honeypot. If they still insist on more, I guess there isn't much more I can do.

I look forward to hearing your thoughts on my plan. Thank you for your time and insight!
3  Bitcoin / Bitcoin Technical Support / Re: Problems with dumping all the contents of an old .dat wallet on: July 19, 2021, 02:55:54 AM
Pywallet will (should) find all your private keys but will only output showing them as P2PKH (aka "Legacy") addresses... whereas Bitcoin Core supports using P2PKH, P2SH-P2WPKH (aka "Nested Segwit") and P2WPKH (aka "Native Segwit") addresses from your private keys.

Chances are that the list of private keys will be the same between the pywallet output and the Bitcoin Core dump... it'll just be the list of addresses which is different.

I would suggest looking at the sets of WIF keys displayed from each and checking that they are the "same". Note that they may not be output in the same order... I know that the dumpwallet in Bitcoin Core doesn't usually output them in derivation path sequence order... not sure about Pywallet.

Sorry, I don't quite follow. Are private keys associated with both legacy public addresses and new public addresses supporting things like Nested and Native Segwit?
4  Bitcoin / Bitcoin Technical Support / Problems with dumping all the contents of an old .dat wallet on: June 28, 2021, 10:43:05 PM
I have this old wallet.dat file, originally created in Bitcoin Core around 2015-2016. Now, I'm trying to move all my Bitcoins from this wallet into an Electrum wallet because I simply cannot get Bitcoin Core to sync and load my wallet without problems (I've tried on several different platforms with different errors, and I've given up on this route for the time being).

Anyhow, my mission is to export all private keys containing unspent transactions so that I can sweep them into Electrum. The first thing I did was to make a wallet dump using jackjack-jj/pywallet. This gave me all the addresses starting with "1", some of them contained in the list of receive addresses in Bitcoin Core and some of them being change addresses I assume. However, some receive addresses, starting with "3" were obviously missing from this dump.

So, I fired up a fresh install of Bitcoin Core and used the dumpwallet command to export all my keys. This gave me a lot of addresses beginning with "3", including the missing receive addresses from the pywallet dump. However, not all addresses beginning with "1" that I found using the pywallet dump showed up for this Bitcoin Core dump.

So, what I'm left with are two non-identical subsets of keys, and I don't know if there are more that I haven't been able to retrieve. However, if I were to understand why the two programs gives me different outputs, maybe I would be more confident that I've located them all.

First of all, I don't know why I have a mix of addresses starting with "1" and addresses starting with "3". Without really knowing, it seems like my wallet is some kind of mix between a HD wallet (generating addresses starting with "3"?) and an old wallet where each address is generated individually (addresses starting with "1"?). Since my wallet dump from Bitcoin Core is filled with certain concepts suggesting a HD wallet (for example, derivation paths and master private keys), I guess this is the case. If so, I still don't understand why Bitcoin Core won't dump all of the keys that pywallet can find. At least pywallet feels more consistent, since I only get addresses starting with "1" (I guess support for addresses starting with "3" are lacking).

Further, there are two things I really don't understand. If I have a HD wallet, shouldn't I be able to generate an infinite number of addresses? I realize that Bitcoin Core can't print all of them since I don't have an infinite hard drive, but how is it decided which ones that will be shown? Some kind of internal track record of all my transactions? Also, when reading the wiki page about addresses starting with "3", it says "To spend bitcoins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evaluate to true." Does this mean that the private key contained in my dump from Bitcoin Core won't be enough?

Sorry for this brain dump about my wallet dump, but I've been looking into this for months now. I would really appreciate any help. In the end, the only thing I really want to do is to get an exhaustive list of all public-private key pairs contained in my wallet (including change addresses). From the, I can write a script myself that checks the balance of each of these public addresses.
5  Alternate cryptocurrencies / Mining (Altcoins) / Re: AMD Ryzen hashrate? on: October 13, 2017, 10:26:44 AM
I've recently started to CPU mine Monero using xmrig.exe (I tried to compile xmr-stak-cpu from source, but unfortunately I can't afford to quit my daytime job to fix all problems I encountered) in administrator mode on Windows 10, meaning Huge pages are activated. I have a Ryzen 1700 processor (not overclocked) that I currently get about 300 H/s from.

Isn't this a bit low? I've seen people in this thread mention hash rates above 500 H/s. Is there any tweaking that I could perform to get a larger hash rate? I pretty much have no idea what I'm doing, but I'm eager to learn Smiley


Try this config. You should expect 590 h/s at 3.8 Ghz

"cpu_thread_num" : 8,
"cpu_threads_conf" :[
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 2 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 4 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 6 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 8 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 10 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 12 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 14 },
],

Thanks! I guess these commands are for xmr-stak-cpu, and not for xmrig, right? Can't get them to work in xmrig.
6  Alternate cryptocurrencies / Mining (Altcoins) / Re: AMD Ryzen hashrate? on: October 12, 2017, 10:42:57 PM
I've recently started to CPU mine Monero using xmrig.exe (I tried to compile xmr-stak-cpu from source, but unfortunately I can't afford to quit my daytime job to fix all problems I encountered) in administrator mode on Windows 10, meaning Huge pages are activated. I have a Ryzen 1700 processor (not overclocked) that I currently get about 300 H/s from.

Isn't this a bit low? I've seen people in this thread mention hash rates above 500 H/s. Is there any tweaking that I could perform to get a larger hash rate? I pretty much have no idea what I'm doing, but I'm eager to learn Smiley
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!