Yes, try setting that value to 8192. It'll allow Bitcoin Core to cache more data in RAM and help alleviate some of the read/write load on the HDD and should theoretically help increase the sync speed.

Hopefully something you won't need Google Translate for:

Correct:

Incorrect:

extra space characters in commands will break things! ("des espaces supplémentaires dans les commandes provoqueront des erreurs")

The "default" server (for lack of a better term), ie. ElectrumX has some mechanisms in it that will limit a client connection if said client goes over some certain limits with regards to number of requests and (from memory) the amount of data in a given period of time.

Once a specific client/IP exceeds the set limits, it is effectively "ignored" until the time out interval has passed... It's explained "more betterer" in the ElectrumX documentation regarding "Resource Usage Limits": https://electrumx.readthedocs.io/en/latest/environment.html#resource-usage-limits


I'm fairly sure, I seen other instances before of users with wallets that have hundreds/thousands of transactions/used addresses... and when attempting an initial sync they seem to overwhelm ElectrumX servers (with default settings) and end up "syncing forever" as they keep getting "timed out".

Short of migrating to a different wallet, solutions would appear to be:
1. Run your own node/Electrum server setup and set the limits to suit
or
2. Find a friendly Electrum Server admin who can temporarily change the limits so your wallet can sync

There is no fixed schedule. If you look at the release notes, you can see the dates the various firmwares were released: https://support.ledger.com/hc/en-us/articles/360010446000-Ledger-Nano-S-firmware-release-notes

As you can see, there is often 6-8+ months (or more) between firmware releases.


I've done this on a couple of occasions.

This is most likely your issue. Multibit Classic is very old, outdated and has not been supported for a long time now. It was deprecated over 3 years ago (July 2017)!!?!

I would advise that you follow some of the guides available online for exporting your keys and importing them into Electrum. Refer here: https://github.com/Multibit-Legacy/multibit#next-steps-for-multibit-users

Once you have imported your keys into Electrum, you should be able to see your historical transactions/balances, and you should then be able to create/broadcast your transaction.


If you need any assistance, just ask.

I've been running some tests... and managed to replicate it wiping the file permissions once by editing the file in Notepad++... but then the other times it didn't change the permissions.

And my umask is definitely 0022... so I don't think umask is the issue, more just Windows writing to a "Linux FS", and it seems to be somewhat "random" as to when the file permissions get nuked.

At least OP knows how to fix the issue if it reoccurs

AFAIK, Notepad++ is Windows only... which likely means that you were editing it within the Windows environment. This will more than likely mess up the Linux file permissions. You're probably better off learning how to use "vi" or possibly "vim" (although I'm not sure if "vim" is supported under the Windows Subsystem for Linux/WSL), to prevent these issues from reoccurring.

Otherwise, you'll need to manually check/fix the permissions of every file that you edit.

What sort of transaction history does this wallet have? Do you have hundreds/thousands of transactions and "used" addresses? If so, it's likely that the servers you are connecting to, are "timing out" your requests due to the large amount of data you are attempting to sync "at once".

When you upgraded, you should not have needed to "recover from seed". You should have been able to simple install version 4.0.4 and it should have used your old wallet file. If you click "File -> Open" can you see your old wallet file?

It seems that after you edited that file, it was saved with permissions of 000... which is problematic, as it effectively has NO permissions, meaning the file is inaccessible, hence the "permission denied" error.

You'll want to figure out why the file permissions ended up like that, or you're likely to run into the same issue over and over with every file you edit.

What editor did you use to edit that file?

If you're wanting to calculate the fee programmatically, you need to add up the value of all the inputs, and then subtract the value of all the outputs. The amont leftover is what the total fee was.

To calculate the fee rate, you then need to divide this amount by the "size" of the transaction in bytes to get the sats/byte value. Note that if it is a SegWit transaction, then you will need to calculate the "virtual size" (aka "vsize") to get sats/vbyte. Refer: https://bitcoin.stackexchange.com/questions/87275/how-to-calculate-segwit-transaction-fee-in-bytes

I really wish they had not used the terminology "cancel transaction" though. It's bad enough as it is with newbies and less BTC-savvy folks who don't understand why they can't just cancel their transaction, and now you'll have one wallet which can supposedly "cancel" transactions and others that can't.

Not to mention, they'll want to know why they got charged a fee when they cancelled a transaction, and why the fee was so "large".

Perhaps "Override Transaction" might have been better? But even that isn't particularly great either... difficult to condense such a complex thing as "double-spending a transaction back to yourself, thereby overriding the original transaction" into a popup menu friendly term

Message #1 Verified


and Message #2 verified

Unlikely

More likely something with his Windows setup causing issues... I am not having any issues with 4.0.4 on Windows 10 Pro 64bit, version 2004.

I had more issues just downloading and running the installer due to Windows defender popping up with all the usual warnings about it being an "uncommon download" or some such bullshit. I reported it as safe etc, but the same thing seems to happen with every new release

That is correct. The encryption in Bitcoin Core is simply encrypting the private key data stored in the wallet file. The walletpassphrase could be "12 words", it could also be 200 random characters or non-existent or  some other combination of letters/numbers/symbols etc... it's basically just a standard "password"... and has no direct bearing on the ability to recreate any keys.

Historically though, "12 word" phrases (consisting of 12 "random" words) have been some form of backup/recovery system as opposed to a password.

In other words, if you have 12 words, they're probably more likely to be a mnemonic of some description than they are to be a "password", but that doesn't mean they aren't a password.


The crucial point is that Bitcoin Core has never used a mnemonic system for recovery/backup... it has always been "make a copy of wallet.dat". So, if these 12 words are indeed a recovery mnemonic of some description, they're most likely not related to Bitcoin Core.

That graph is a very poor illustration of the search space. For one, you only have 100 keys out of the ("slightly" less than) 2^256 that are actually available as valid keys. The sample size is so small as to be essentially worthless.

To then say that "Most of the universe seems to be empty space" is simply disingenuous, given that you have randomly picked 100 out of ((1.158 * 10⁷⁷) - 1) possible options. Of course your "universe" is going to appear to be "empty" if you simply ignore pretty much all of it contents

All great stuff.... in theory...

But saying there are <unknown things> that might, at <unknown point in the future> allow us to brute-force keys in a "reasonable" amount of time is not useful to people who need to brute-force keys NOW, is it?

You're arguing semantics, trying to look "cleverer" than everyone else in the room... but the fact of the matter is, if I give you "1JHxmgYtTADS7GpRPHbgzWdcDtkTHjj9eQ" which is an address which just received 0.23451412 BTC, the odds of you being able to brute-force the key for that address before <heat death of universe> (or even before the BTC are actually spent) are so close to zero that it may as well be zero. Which is the general meaning of "impossible" that everyone talks about when referring to brute-forcing keys.

When these "unknown methods, unknown factors and unknown parameters" are made public... I'll happily admit that it is completely possible to brute-force all private keys. However, today, it is NOT possible... if it were, BTC would be worth zero as no coins would be safe. The entire system would be rendered useless.

Feel free to maintain your "it's not impossible" stance, but until you can demonstrate the ability to brute-force the key for any given address in something resembling a standard human lifetime... well.... ¯\_(ツ)_/¯

Not sure why you didn't just go with "1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH", you could have saved yourself 6 iterations and gone with key "1" instead of key "7"

You claim that it is "inevitable" and all it requires is "time". That's great... if you happen to have unlimited time. If you don't, then brute-forcing at least some of the search space is essentially "impossible" as you just don't have the "time" available to do it all before you either die, or earth gets hit by a planet-killer, or someone starts WW3 or the sun devours our solar system etc.

The fact that some keys are able to be brute-forced, does not mean that all keys can be brute-forced.

Honestly... Merit is probably the most useless metric of how to judge a users "quality".

I see all these "self-made legendary" bragging posts on some of the boards such merit, much "quality", very wow Especially when you see some of the things people getting merit for... endless pages of "stats" posts? Yep, "quality" stuff right there... people dropping "20" merits on an [ANN] thread for a popular project? obviously 11/10 "quality"... pretty much anything in Reputation and/or Meta

I understand why merit was implemented, but unfortunately I don't think it has really been successful with regards to it's desired outcomes.

No, just like other wallets... the blockchain legacy recovery system uses a "word list". If you are getting an "unknown word" error, then either one or more of your 12 words are incorrect (check spelling etc) or the 12 words are NOT blockchain legacy recovery words.

If you also get "unknown word" type errors when trying to restore using a BIP39 wallet (like Electrum with "BIP39 seed" option set or using Ian Coleman's BIP39 tool) then the 12 words are not a BIP39 recovery seed mnemonic either.

You're left with the option of it being:

1. a brainwallet... but which wallet? and what method did it use for converting words to private keys?
or
2. some other obscure wallet with it's own recovery system

Unless you can identify which wallet these words belong to (or possibly the incorrect word(s)), your chances of recovery are relatively slim

Did you even look at that guide?

The very first sentence:


Also, because the linked version (kyuupichan) on that page is now effectively BSV only going forward... You want to use the fork of ElectrumX maintained by the Electrum Devs: https://github.com/spesmilo/electrumx

They have a copy of the docs available here that includes a HOWTO guide and links to an installer and a dockerfile: https://electrumx-spesmilo.readthedocs.io/en/latest/