Whoa, you took a while to reply. It requires permission to open. You may use pastebin.com to share the logs instead. Or does anyone know how can I recover a multisig wallet with f2a (p2wsh) into a different client (for example Bitcoin Core, Exodus or some other)?
If you have your seed phrase, you can restore it with 2fa code requirement disabled by selecting the said option during restore. Keep this restored wallet " Air-Gap" to be safe and also for it to not crash Electrum since the issue may be the number of transactions ( don't know since the log isn't accessible). Also with that, the created wallet will contain two of the required keys to " fully sign" the transactions that you'll create elsewhere. Next is to take note of your addresses from the 'Address' tab ( generate more if you think you used more) and check for transactions and output index ( output point) in variety of ways like blockexplorers, or simply through Bitcoin Core by importing those addresses to load the transactions. Then, it's just a matter of creating a transaction in Bitcoin Core and sign it with that restored Electrum wallet. The steps differ depending on the route that you'll choose. |
|
|
|
My first question is: is the master public key always used to update the wallet balance? Or is it only with ESP?
It's specifically required in EPS' config to circumvent the full transaction index requirement, but even if your server knows all of you future addresses, there wont be any issue since it's for personal use. For other server implementations, servers only acquire the scriptHash ( addresses) from the connected Electrum clients ( rather, Electrum client asks the server). Read the comment/code: github.com/spesmilo/electrum/blob/master/electrum/synchronizer.py#L131However, my second question is: where does come this address, at which my 0,01 BTC had been sent? I mean: this address wasn't a hash from my master public key. How had it been created?
It's a 2-of-2 MultiSig address created from your and the other party's public key. My third and last question is a bit stupid, but i wanna check: considering the last paragraph, does my Electrum wallet now use TOR to connect to nodes; hiddening my IP to them?
If the connection icon is 'blue' instead of 'green', it means that you're connected through Tor. |
|
|
|
Thank you for all the help & since I posted last, I decided to install Bitcoin Core on my C: drive, I have had to prune the blockchain. It is already updated & I have an install of Armory now on my C: drive also.
Armory doesn't support pruned blockchain, it wont sync properly since you're missing some blocks. If this fails I will go through everything you have all advised I do from here.
You wouldn't have to if you set the correct paths and checked if those directories actually contain the necessary files. Alternatively, share the log so that we can check what's causing the issue. You can find it inside Armory's data directory ( Yours is set in: C:\Users\anotherusername\AppData\Roaming\Armory), " armorylog.txt" file, paste it in pastebin.com ( remove usernames if you have to) and share the permalink here. For example ( the directories that you've set): - Your "D:\Program Files\Bitcoin" should have bitcoind.exe inside 'daemon' or 'bin' folder.
- Your "D:\Users\myusername\AppData\Roaming\Bitcoin" should have blocks folder with more or less 600GB size.
|
|
|
|
"-snip- sendrawtransaction RPC error: {"code":-26,"message":"too-long-mempool-chain, too many descendants for tx 369a184f3e941a501b99a2865f6c1db09f39af379ef8c63fb52689e37e3376a7 [limit: 25]"}"
This isn't about a failing script, it's just your input(s) already have 25 unconfirmed parent-children chain. The default limit is 25: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L62-L63I suspect that the other part of the error (" maximum hash string length is 64 bytes.") is unintended since it's expecting a TXID. |
|
|
|
I am attempting to discover why my wallet is so different in it's wallet seed structure and seed version number to the other electrum.dat wallets i am able to create using the older releases of the client.
Is there a chance that you've opened your old electrum.dat file with version 3.3.x at least once? Because if you did, that'll upgrade the wallet structure and the seed version indicated there. Here's one example wallet file that I created with version 1.8 ( with password = encrypted seed): ... 'master_public_key': '6d3e5a438a3732eac63424e7bf8d5a62976a443358f65cf7ec3e1e526c716addbdb738d83903e94d825152a8aedf8bb284170339a77eca1e21264bbd889ec78d', 'auto_cycle': False, 'use_encryption': True, 'server': 'electrum.bitcoins.sk:50002:s', 'blockchain_headers_path': 'M:\\ExtraLaunchers\\Electrum_1.8_installed', 'seed': '+7veyasvUYvJh/+mk6cD0zaEsulHmRP6VahtMqYIjeZgcm/85fsnvttCwOu5Wfy4+4ogc3aVL/n9A4l1XnPuhA==', 'accounts': {0: {0: ['1ChT8dU8FKZcwBTuQeJjhqaHs7oQLkY64e', '1MYH6WYXos8bbvvfzHKhayac9WZi5bavjx', '1P2CvojvqA9qtwU55diVMct2G5wwWdV6Dx', '1Jxes2KfiZfK7vXaQav8mDQXBEw3DH6FbL', '1mqG9nfCMezHe9snaC5fVdXEL7hWbGkx9'], 1: ['13BKoS6nQ1rN14esPSHt5ZYE7mZfJX9aaM', '1Ar2ZwK7NEAhUBgKQ4BNCwA1T3hfUQr2rK', '1DMrSLSDX8B1WwkkNSy3VUFqfcSS8pJHtY'], 'name': 'Main account'}}, 'proxy': None, 'imported_keys': {}, 'seed_version': 4, ...Then after loading it with Electrum v3.3.4 ( upgrading it in the process), here's what it looks like: ...
"keystore": {
"mpk": "6d3e5a438a3732eac63424e7bf8d5a62976a443358f65cf7ec3e1e526c716addbdb738d83903e94d825152a8aedf8bb284170339a77eca1e21264bbd889ec78d",
"seed": "+7veyasvUYvJh/+mk6cD0zaEsulHmRP6VahtMqYIjeZgcm/85fsnvttCwOu5Wfy4+4ogc3aVL/n9A4l1XnPuhA==",
"type": "old"
},
"proxy": null,
"seed_version": 18,
... In your use-case, you'll need intact backups that weren't opened yet by any other versions of Electrum. |
|
|
|
Is there a way to do this where I just download the program & it works without any messing about like this? I am a noob when it comes to this stuff & I really am struggling here.
If everything is installed and using the default directories, you wouldn't have to set those paths since Armory knows the defaults. But since your Bitcoin Core is installed in D: and its data directory is in D: as well, you'll have to manually set those paths for Armory to find them. Please would you walk me through the exact steps like I am a 2 year old..?
The first part of his post is the simplest ( band-aid) solution since you'll only need to open the applications in that particular order. That way, you don't have to point to Armory where to find those binaries. But the correct datadir should still be set. ( you've already set those in the GUI) - First, close Armory if it's running, open your Task Manager and check any Armory and Bitcoin Core related processes
since sometimes, it lingers in the background. Alternatively, restart the PC. - Now Open Bitcoin Core and let it sync to the tip, just let it running after syncing. (you may skip ArmoryDB)
- Lastly, Open 'ArmoryQt.exe' and it should be able to detect that Bitcoin Core is already running.
I have pointed the top Armory Bitcoin install directory to D:\Program Files\Bitcoin
Blockchain & Database Paths
Bitcoin Home Dir to D:\Users\myusername\AppData\Roaming\Bitcoin
Armory Database Dir to C:\Users\anotherusername\AppData\Roaming\Armory\databases
The username is different on the C: drive, I thought to point that out, will that be a problem?
The strange thing being my son's installation didn't need any of this & it worked until I loaded my wallet on his machine, I just can't understand what is going on.
Wait, the file folder structure in D: is suspiciously similar to a Windows system directory. It sounds like you've plugged your previous C: drive from your machine to your son's machine, then it's set to D: since it already has C: If so, that not how you load your Armory wallet to your son's machine with a functional Armory installation. You should've kept everything as is then just imported your wallet backup via " Import of Restore Wallet". It accepts exported wallet/printed backups from " Wallet Properties->Backup This Wallet". |
|
|
|
As you can see, the unencrypted backup is useless once you've used the encrypted wallet to generate new keys. That's not entirely accurate: The coins that were already in the wallet before encryping it are still there, also in the backup. But the moment you use a new receiving address, or create a transaction which sends funds to a change change, those aren't in the old backup anymore. That's why " backup" is mentioned, I and it didn't mentioned anything about the previously received bitcoins in the unencrypted backup. The point is the newly generated keys wont be recoverable using the unencrypted backup. Based from OP's situation, it looks like the case. |
|
|
|
viabtc offers to 'rectify' the situation for just ~0.09 BTC and I am not quite willing to pay for that.
In comparison to CPFP, it'll only need an extra 0.00178900BTC to bump to 20sat/vB. ( total vSize is 8945 vB) Since there's still 0.00850354 change, you can still use some of it to CPFP whether the wallet supports CPFP so or not. If you do not have any other available UTXO, you can perform CPFP by simply sending another child transaction with enough absolute fee ( fee rate multiplied by virtual size). I just hope it gets dropped from the mempool sooner or later...
Your transaction and its parents have an overall transaction fee rate of 7.89sat/vB as bundle. It's nearing the bottom of mempools with default size setting. The question is, if your wallet keeps its own mempool and wallet transactions, rebroadcasts dropped txns or need user intervention to remove dropped transactions. It's impossible to give a suggestion without knowing the wallet's name. |
|
|
|
-snip- You reason but, I saw a wiki, the encrypted wallet does not modify Hdseed! It's true / or false ? (more below) False, you might have seen an entry about " changing passphrase", which is already an encrypted wallet. How about this? The actual message that you'll see when encrypting a wallet:  As you can see, the unencrypted backup is useless once you've used the encrypted wallet to generate new keys. The reason for that message is because the HDSeed and keystore are replaced with a new one after encryption ( setting a passphrase for the first time). |
|
|
|
-snip-
How did you get this data (at least i know it's not from Bitcoin Core and mempool.space API)? Anyway, it seems to be outdated information. Looks like a result from Blockcypher's decode raw transaction page. ( the shown json output part has striking similarity) And for some reason, they currently show 0-confirmation on every decoded transaction even if it's mined already. Here's for reference: live.blockcypher.com/btc/decodetx/Has anyone experienced something similar or can shed some light on what might be happening? Any guidance or suggestions would be greatly appreciated.
As far as Bitcoin is concerned, the transaction is already sent and included in the blockchain, any missing ordinal token issue is Altcoin territory and most people here may be unable to help, you can try their forum or the Altcoins board for more fitting support. |
|
|
|
Welcome.  Thanks for accepting me. I've applied the signature, personal text and avatar ( custom, approved). The avatar may take a while to display. |
|
|
|
If you have the HD seed you should be able to recover the wallet by importing it into supported wallets like Electrum but how did you get the HD seed? Since BitcoinQT/Bitcoin core doesn't generate a seed I'm sure it was not from this wallet.
It's the " HDSeed" of Bitcoin Core ( non-descriptor) wallet files which is exported in WIF format. It cannot be imported to Electrum even if it's converted to ( xprv) master private key since it doesn't support hardened address derivation path. Another one with bitcoin-qt encryption
then I reverted to the original,
Your original HDSeed's keystore was flushed with the wallet encryption, then if you generated new addresses to receive those missing transactions, then that's the issue. Encrypting the wallet file will trigger it to set a new HDSeed; so after reverting to the original, you essentially removed the new HDSeed where the new addresses are derived from. In this case, the solution is to find a backup of that encrypted wallet file. |
|
|
|
@ decades85Better keep a copy of your transactions just in case you lost contact to the sender and the transactions got dropped from mempools. Getting those dropped completely is bad news since you're not the sender and you're using Coinbase.. Here are your " RAW Transactions" that can be broadcasted to nodes in case that happened: 01000000000101a0b7f3acd8a31879965a5345cf83ce419bcd6398efc67d78f0916c87ef77661d0100000000ffffffff02405a0b000000000017a9147c869fe76f4e14434760ca1ca80f772e7c58e589878eb90000000000001600145ef5a9f5ceedb69e9e35848bcb49d0cf599dd8c9024830450221008bb30c4b8c04d787403b0d37199985e9eba59ede6b256d7ca0acda8d1faa219c02204bb694943ea623750b4b5bb0046c44e40a0c4df32b58aab83eefeb0f661d05070121033d22ec1a852d04304d68d5243e6fdc20185c048b0831faf7cd686829dd7ad9c500000000 01000000000102f5ef60b81524f578f5aff3bf53a0948f303fe7adcee3b53fdc63c6ce5bff820f0100000000ffffffff9ea846516aed0fd082a8e06cb9ce98ff338a6aa801a764f7cb568dfe20f477570000000000ffffffff0240a713000000000017a9147c869fe76f4e14434760ca1ca80f772e7c58e58987d868080000000000160014a9149a904c63d33f93082c0f0c87b8906495a5030247304402205b6330eeae847f17ef7fa2ca389d82a0dfb21483055915a2c6c9537a1396fdaf02203b48587b339df27f5f35ef4a87d3bca22b65580d2ccfe40885128825114f1ace012102923767f74fa9b9bc4f1062f95551248cf68f657d8b34824ca9d4a0e83a32391f024830450221009bf39680eb234c9df989af41f0eca5f08bece7c7c7654dd977dcd867797041a802203186c022ed779bf212ceb5f64ac52ab7c4fd8e054a8839948f2e14c5e14255b80121029c9b825e224d4a0d8a0522a4ad3df4fee84457328e2ed1cca94ce2ae1712228e00000000 |
|
|
|
-snip- since if you use the same fee rate on both transactions, that means you are saving fees on segwit, but the amount of fees the miner gets does not increase.
Since you're saving " absolute fee" on SegWit, miners will even get less from your SegWit txn compared to Legacy txn with same " fee rate". For example: [1] A 1in-2out Legacy transaction of e.g. 250vBytes size w/ 5sat/vByte fee rate have 1,250sat absolute fee ( to miner) [2] A 1in-2out SegWit transaction of e.g. 125vBytes size w/ 5sat/vByte fee rate have 625sat absolute fee ( to miner) ( rounded values for easier calculations, virtual size can be higher or lower) Is the statement based from a source? Because I think that the statement may be applicable in overall fee from a block since the saved virtual block space from lower vSize of SegWit txns can still be filled with other transactions. For example: Let's say that the block's max size is only 1000vBytes. The miner can fill 4 txn [1] in it, that'll sums up to 5000sats of absolute fee for them to claim. The miner can fill 8 txn [2] in it, that'll also sums up to 5000sats of absolute fee. What is your address - legacy or seqwit ? I am also very suprised about the speed of your transfer !!!
Speed is your concern? Not the cost? Then it doesn't matter, just select " mempool" in the fee slider type drop-down menu and use anything below " 1mb from tip". " 0.8mb from tip" is my usual selection but I usually edit the absolute fee a few satoshi higher, my transactions never get stuck for too long. The difference with using SegWit and Legacy ( you can't make a Legacy wallet in Electrum's GUI today) is the absolute fee that you'll pay with the same fee rate. ( see the first Example) |
|
|
|
Great theories. Here is the exact format I wrote it in, but I changed all the characters. I do remember maybe converting it to hex or binary, or at least considering it.
Have you tried asking goatpig already about that " 80-characters private key" mentioned in the old Armory website? The old developer may not be active anymore, but goatpig ( the current Armory developer) is pretty much actively replying on that board. Once you have a 80 character HEX string, you can try encoding it to base 58 to obtain potentially a WIF compressed key for your wallet.
The private key in HEX is only 64characters long. The private key in HEX with the network bytes and checksum included is only 74characters long. ( uncompressed WIF) The private key in HEX with the network bytes, compressed flag ( 0x01) and checksum included is only 76characters long. ( compressed WIF) Any other length will produce an invalid WIF private key. |
|
|
|
Hi
I see it failed for you on version 4.4.4
Which is the last version it is know to work?
I'm about to edit it since I've provided logs from my previous test session. But given this reply, I think editing it isn't necessary anymore. Both v4.4.4, v4.4.6 and master branch results are the same so it's not yet fixed. |
|
|
|
Any other ideas?
I tried it with the current master build from GitHub ( source) and it also result with the same error, seems like a bug. Here's the log: Traceback (most recent call last):
-snip-
return lambda *args, **kwargs: f(method,
Python310\electrum-4.4.4\electrum\commands.py", line 192, in _run
result = fut.result()
Python310\lib\concurrent\futures\_base.py", line 446, in result
return self.__get_result()
Python310\lib\concurrent\futures\_base.py", line 391, in __get_result
raise self._exception
Python310\electrum-4.4.4\electrum\commands.py", line 155, in func_wrapper
return await func(*args, **kwargs)
Python310\electrum-4.4.4\electrum\commands.py", line 787, in bumpfee
tx.add_info_from_wallet(wallet)
Python310\electrum-4.4.4\electrum\transaction.py", line 989, in add_info_from_wallet
for txin in self.inputs():
Python310\electrum-4.4.4\electrum\transaction.py", line 781, in inputs
self.deserialize()
Python310\electrum-4.4.4\electrum\transaction.py", line 808, in deserialize
txins = [parse_input(vds) for i in range(n_vin)]
Python310\electrum-4.4.4\electrum\transaction.py", line 808, in <listcomp>
txins = [parse_input(vds) for i in range(n_vin)]
Python310\electrum-4.4.4\electrum\transaction.py", line 692, in parse_input
prevout_hash = vds.read_bytes(32)[::-1]
Python310\electrum-4.4.4\electrum\transaction.py", line 454, in read_bytes
raise SerializationError('attempt to read past end of buffer')
electrum.transaction.SerializationError: attempt to read past end of buffer I saw that you just made a new issue in GitHub ( seconds ago) regarding this issue: link |
|
|
|
|
Username: nc50lc
BTC SegWit Address: bc1q4203cyhp8gjk95ulacjqchfgut2ytzecjhpwtq
|
|
|
|
it's a relief to know I didn't do anything wrong this time.. I am rescanning the transactions to see it that sorts it. -snip- both are Armoury (0.96).
I'm surprised that it's connected since you've been using an outdated version of Armory which other users typically encounter connection/sync issues. The latest version is actually version 0.96.5 which has a link in the first sticky thread in this board. If it failed to scan, perhaps it's time for an update. |
|
|
|
|
Show Posts
