Have you tried downloading the Dogecoin Core wallet and opening the wallet.dat files with that?

You don't need the dogecoin blockchain synced to be able to open the wallet. Just shutdown Dogecoin Core, then replace the wallet.dat in the Dogecoin data directory with a copy of one of your old wallets (renamed as wallet.dat) and then restart Dogecoin Core.

If the wallet file is actually corrupt, you'll likely get errors from Dogecoin Core saying so. If you don't get any errors, you can try using walletpassphrase and dumpwallet from the Core client console to dump the keys from the wallet file.

I believe that this issue is likely caused by the transaction being dropped from the mempool of the Electrum server you are currently connected to, but still being available in others.

Your transaction was visible on a number of block explorers (but not all), which indicates that some nodes had dropped/purged it... and others had not.

If it happens again in the future, you can try:

1. Connecting to a different Electrum server to see if it can "find" your missing transaction
or
2. Shutdown Electrum, delete the blockchain_headers file from the Electrum data directory and then restart Electrum
or
3. Try restoring your wallet from seed to force a recheck of all the data

For now... waiting is probably the best thing you can do... However, even with fees dropping quite a bit the last 24 hours, given the current state of the network... I still don't fancy your chances with only a 9.5 sats/vbyte fee You're most likely going to need to try and use RBF at some point.

Is your Bitcoin Core node fully synced? Is your Bitcoin Core node pruned or unpruned?

One thing to note... Ledger Live will only let you create 1 "empty" account... so if you have "Bitcoin Account #1" with a positive balance and/or history... and then create "Bitcoin Account #2", but it is "unused"... you will not be able to create a "Bitcoin Account #3"

I believe the reason for this is so they could set the "account" level "gap-limit" to 1... so that during a restore, it will only ever lookup 1 extra "account" for history before giving up.

Note that Electrum does not have this restriction, you'll be able to create as many "accounts" as you like by simply modifying the derivation path during wallet setup and specifying wallet "account" value you like.

Unless you're able to find a binary executable floating around... you'll probably need to try and build your own version from the source code on GitHub: https://github.com/KomodoPlatform/Agama

Noting that:
- There seem to be various "security" warnings about this wallet
- The codebase hasn't been updated since 2019

I was awake and bored... and keen to try my luck. Hopefully they find a block soon


EDIT: lol... seems quite a few people have your back Royse

The short answer is "Yes"... the long answer is: I don't know if you can remove it later, there are personal servers that run on Pruned nodes, with the caveat that if you attempt to import addresses/keys or a new wallet, it may not show the full balance given that blocks are "missing". However, ElectrumX requires the full blockchain, AFAIK.

Why don't you try and prune the blockchain after ElectrumX has synced and then report your findings here?


Don't use rpcuser and rpcpassword... they're being deprecated... either use the rpcauth or the .cookie file...

The .cookie method is easiest... if you used the "default" datadir then you should just be able to not specify anything and it will just work... if you've specified a custom datadir, then you'll then to provide it on the commandline using -datadir or you can just use datadir=your/custom/path in the bitcoin.conf file.

About the only thing you can do is use a wallet that allows the setting of custom fees and try to be more aware of the network status at the time you go to send a transaction...

https://mempool.space/ and https://jochen-hoenicke.de/queue/#BTC,24h,weight give good overviews of the current state of the network and with a bit of practice you can determine a "decent" rate that will suit your purposes (ie. cheapest option, don't care about how long it takes to confirm vs. must be next confirmed in next block etc).

A lot of wallets try to simplify fees to things like "low", "normal" and "high"... but don't give any indication as to what those rates actually are (or mean)... and because the network can be quite volatile, you can end up over (or under) paying by a substantial amount!

I'd have to look at all the transaction details to see exactly why your total fees paid were so high, but the normal causes are:
- Using legacy UTXOs as inputs. Legacy UTXOs are much larger than SegWit UTXOs, so using older Legacy addresses will mean that when you go to spend the coins, your transaction will have a larger total data size. As the total fee is (size * fee rate), then logicially a larger total data size == higher total fee.

- Using multiple inputs to a transaction. Having multiple inputs (Regardless of SegWit or Legacy) will result in a transaction with a larger overall data size. As above, larger data size = higher total fee. This is usually the result of collecting a lot of small amounts of BTC from mining or faucets etc and then trying to spend them all at once. Can be somewhat mitigated by occasionally consolidating your inputs when the network is not busy and the fee rates are low. That way, when the rates are higher... you'll likely only need 1 input and the smaller transaction size helps offset the higher fee rate required.

Were the seeds initially created using Electrum or were they imported seeds from another wallet? If they were Electrum generated seeds, then they would be "versioned", so would automatically restore using the correct derivation path and script type.

If they were imported seeds that were generated by another wallet, are the addresses that are generated in Electrum of the same type as they used to be? ie. "1"-type, "3"-type or "bc1"-type addresses? Or has this now changed? ie. they were "1"-type addresses, but now start with "bc1"? If they address type has changed, then the derivation path and/or script type is likely incorrect and Electrum is generating the wrong addresses.


Another likely reason is that you "extended the seed with custom word(s)" when you originally setup your wallet... if you did add an extra word or words (aka a "Seed passphrase"), then you must use the same extra words when restoring your wallet, otherwise the wallet generated will be completely different.


Finally, and less likely... is that the seed you have for your 2nd wallet is just wrong. Have you ever used this seed to restore your wallet before? Or is this the first time you have used it? If you haven't tested it before, it's possible that you have written down a "valid" seed, but one that was for a different wallet It's not common, but it does happen... although it is more common with the desktop version.

Correct... I just logged in and it is currently quoting the following amounts to accelerate 644417ca91a9c16e1cb11ec0ed5a0928e203119d4f1bc00a93eb7da3ece1feb3:

0.0045472 BTC ≈ 228.90
0.2915 BCH ≈ 228.90
0.8557 LTC ≈ 228.90

You would need to create an account, enter your TXID, then click the "Paid Service" button and it will give you the amount required then. There is a "deposit" button on the quote window that will let you deposit the appropriate amount into your ViaBTC account... and then you would be able to pay for the acceleration service.

Then you have no direct control over the UTXOs as coinbase.com is a custodial wallet... you effectively have an "account balance", and deposits are added to your balance... This means if you attempt to send, Coinbase will just be using funds from one of it's hotwallets to fund your transaction.

That rules out the option of CPFP

It builds the index from the bitcoind blockchain, hence why you need it.


I don't think you can use systemd with WSL... you can however use it with WSL2: https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950

note that systemd is not entirely necessary to use ElectrumX... it's just a method for setting it up as a background service and autostart etc. You should be able to just "run" ElectrumX assuming you have the config etc setup correctly.

Be wary of any storage, bandwidth or CPU caps that your VPS has... an Electrum server isn't necessarily "huge" in terms of requirements, but cheap VPSes often have relatively low caps.


Possibly... I've run other Electrum servers on WSL (ie. electrs) but it's obviously not ideal for performance reasons (and you're also doubling up on OS storage space requirements.)


usually you need a fully synced, unpruned node, running with txindex=1... and you set the "network" type in electrumx and then point it at the appropriate data directory.

you'll want to read up about SPV and bloom filters. but ElectrumX basically builds its own index of the blockchain


Will generally depend on how you set it up and firewalls etc

peer discovery is also explained in the ElectrumX docs: https://electrumx-spesmilo.readthedocs.io/en/latest/

I'd vote for Electrum simply because it gives you better control over your coins/transactions than Ledger Live does... It's also, imo, easier to setup your own node and connect a "personal" Electrum server to it than trying to use a personal node with Ledger Live, if you don't want to rely on "random" Electrum servers and/or relay everything through Ledger servers using LL.

However, having said that... Electrum can be a bit of a nuisance if you have several Bitcoin "accounts" setup on your Ledger. Electrum can only handle one "Account" per wallet, so you'd need to create multiple wallet files (each with the appropriate account derivation path)... it's not a huge deal, but definitely not quite as easy as simply having your old "legacy", "segwit" and "native segwit" accounts all in one place like they can be in Ledger Live.

Additionally, as o_e_l_e_o has mentioned, you need Ledger Live for firmware updates and "coin app" updates... so you'll still need to have LL installed to ensure you have the latest firmware and bitcoin coin apps installed on your device.

Yes, quite likely everything was working OK... but there was just a timeout between Bitcoin Core and Armory so you got the weird error about the transaction not being able to be sent OK.

Then, after you cleared everything... and tried to send again... you get the "mempool conflict" error, as the coins have already been "used" in the currently unconfirmed transaction.

I would say that your current options are:

1. Just wait... your transaction will either confirm, or after 14 days is likely to be dumped by the majority of nodes and you should be able to create a new transaction (with an appropriate fee! ) and send that out without issue

or

2. Attempt to accelerate the transaction using the free ViaBTC accelerator (assuming your transaction fee rate was >= 10 sats/byte). It's hard to get one the 100 hourly slots tho... you have to send within the first second of a new hour (ie. when the clock turns XX:00!) or you'll get "submissions beyond limit" which means the 100 slots have been filled.

or

3. Check if the transaction on the block explorer is marked as RBF... blockchair.com and mempool.space show pretty clearly whether the transaction is RBF or not... if it is RBF, you can attempt to broadcast a replacement transaction that bumps up the fee... however, given the error that you are getting, it seems like it might not be RBF enabled

I have hosted a copy of the multibit classic 0.5.19.exe on my keybase.io file repo here: https://keybase.pub/hcp/multibit-classic-windows-0.5.19.exe

I feel like I should put a disclaimer in here that I make no representations that this file is virus/malware free. It was simply an old copy that I found on one my backup drives and I put it up to try to assist other users trying to gain access to their multibit wallets who were not able to use alternative methods (like my multibit-recovery python scripts, the "openssl" method or the "read-multibit-wallet-file" tool created by the MultiBit devs here: https://github.com/Multibit-Legacy/read-multibit-wallet-file etc)

I have in fact used this installer to install 0.5.19 on one of my personal rigs for testing purposes (creating .wallet, .key files, testing password recovery/cracking scripts and key extraction etc)... so it *should* be OK... but no promises. Use at your own risk etc


Alternatively, there are other versions floating around if you google... or you can attempt to download and compile the original source code from here: https://github.com/Multibit-Legacy/multibit/releases/tag/v0.5.19

Not necessarily, imo... I read that as "we're going to do our best to make it completely open-source, but it is possible that it won't be 100% open source due to <reasons>™".

In any case, it'll be interesting to see what they end up delivering and how close to 100% open source they end up making it.

If you're worried that the "edited" tag will negate the use of the post, the "edited" link shows the datetime when the last edit was made. Given it will only be a day or so out, it's not really a big deal. The problems are when the original post was like 5 years ago, and the edit was yesterday

However, if it is important for you to have an unedited post, then you should probably consider just creating a completely new post with the correct format.

interesting... I was wondering why you mentioned earlier you had made a deposit

So, has the deposit transaction that you sent actually confirmed or is the transaction still unconfirmed? The network is insanely busy at the moment with high fees etc... so make sure the transaction has at least the minimum number of confirmations as required by wolf.bet.

If you're using Bitcoin Core... you can simply start the application using the -addresstype and -changetype parameters and set it to "legacy" (for "1"-type addresses) or "p2sh-segwit" (for "3"-type addresses).

Alternatively, you can edit the bitcoin.conf file and add:

or



I don't really recommend using either legacy or p2sh-segwit... but if you must, at least use p2sh-segwit, as you'll be getting partial benefit of SegWit using those addresses.