Maybe you or anyone else can test this on his own full-node, preferably one without txindex enabled to compare apples by apples. I have no clue why I didn't work on my side, that's why I posted this question here.
As requested, I tested this on my full node Bitcoin Core v26.0.0 and it works if I included the blockhash. The test node doesn't have txidex=1 in the config and has pruned blockchain. The errors also work as intended. - If I provide a non-existing block hash:
Block hash not found (code -5) - If I provide the hash of a pruned block:
Block not available (code -1) - If I provide a TXID from another block:
No such transaction found in the provided block. Use gettransaction for wallet transactions. (code -5)
|
|
|
|
So that seems to be the main argument for "running your personal node" instead of connecting to a public node / public server, right?
Right, the only for-public-use option is the " Public Server" tab. The two server options " Bitcoin Core" and " Private Electrum" are meant for private use. Thanks for the explanation. Okay, that reassures me, sort of. It's still a mystery to me why Sparrow "needs that wallet".
Those public Electrum servers that you can connect to have their own database built from the blockchain that the client Sparrow query to sync. On the other hand, if you use Bitcoin Core as server, Sparrow needs to use the cormorant wallet that it created with your Sparrow wallets' descriptors to scan the blockchain for transactions. Then it uses RPC to query the needed data from that wallet or node, some require a loaded wallet to work. |
|
|
|
Nothing is written to the log file, the menu stays open and then after a couple minutes closes as if nothing happened.
You may be looking at a different directory or file. It should be the " debug.log" file inside bitcoin data directory, if you've set a custom datadir in the Welcome Menu, look for the log file there. After finding it, share the last session here ( from the earliest "Bitcoin Core version v26.0.0 (release build)" line to the last). If you mean " nothing related to the open-menu", the issue can be related to the scan process after loading the wallet which errors could be written in the log. Also, please indicate your machine's specs. |
|
|
|
|
Sparrow needs that "cormorant" wallet to sync your sparrow wallets.
It does that instead of relying on database like Electrum server does.
It doesn't contain any private keys so you can't manage your funds from there, it only displays it.
You can see that it has ""private_keys_enabled": false," in the result if you go to console, select the wallet in the drop-down menu, then enter: getwalletinfo
|
|
|
|
I am now waiting for a response on the forum of the exchange. Earlier, I had resynced the SPV file of the decentralized exchange to try re-sending (in vain). But now, the interface of the exchange still has that re-send transaction pending. I imagine I have to restore the backup folder of the decentralized exchange I made before resyncing the SPV file, but I am not sure.
I am thinking I want to clarify the exchange part before I return to Electrum to broadcast and CPFP the 'Local' transaction.
Okay, so it's from a DEX, not a centralized Exchange. Then you still have control over the transaction, the problem is it depends on the Decentralized Exchange's features. If there's an option to export the address' private key, you can import it to a new imported Electrum wallet in " New->Import Bitcoin Address or Private keys" and bump the transaction by utilizing " full-rbf" ( not opt-in rbf) by following this: http://bitcointalk.org/index.php?topic=5474986.msg63198878#msg63198878But I'm not familiar with most decentralized Exchange so I can't help you with that. |
|
|
|
I have the feeling that someone has someone managed to get hold of my wallet file from AppData.
I noticed that it had disappeared a few weeks ago, and I restored it.
This looks like planned. The most probably reason why the hacker deleted your wallet file is because he was aiming for you to restore it back so that he can get your seed phrase where the 2 keys are stored during that restore process. And even if he didn't managed to get it that time or if you imported the seed while offline, he can still get it from the wallet file and password since you've disabled 2FA. Hi Im doing this now, do I use wallet.adb.remove_transaction("bdf3d2cd0a45d69d2b91f3a0d99c266641c80ff180e8fe35f060e2a5ad1559e3") in console?
An error says: NameError: name 'et' is not defined
Not useful since the hacker followed the instructions faster, but: it means that you've pasted the command with a breakspace ( enter) in front of it. For some reason when that happens, the first four characters will not be read, leaving you with " et.adb.remove_transaction()" instead and Electrum doesn't have any command for "et". You can reproduce it by using this command ( copy including the empty character above it):
wallet.adb.remove_transaction()
|
|
|
|
Well since you figured it out, would you like to create a hosted version of this on Github Pages (or anywhere else) first?  For those guests out there reading that don't like to change code and also in case bip39-standalone changes the line counts. For the record, HCP has it in his GitHub repo for 7 years now: https://github.com/HardCorePawn/electrumBIP39The later versions also came with instructions on how to use in different wallet types in the readme. Obviously, the downside is he didn't implemented Electrum's seed version system that counts as a checksum and script type indicator. |
|
|
|
Although, it will get dropped for good once any of its input is spent by another transaction.
I'm curious to understand what I am missing here. When sending bitcoins, a wallet will have to pick a UTXO/Coin ( let's say, a $20 bill) that it can spend. So, since your transaction isn't actually sent yet but " in the process", if that $20 bill is used to successfully send to another person, your transaction cannot be completed. Bitcoin works different, it's not like a back account where transactions deduct balance from the sender. Wallets show a total balance for simplicity that but it uses " UTXO model" under the hood ( more info). I am the sender and I can't increase the fee from the wallet of the exchange.
Unfortunately, unlike Electrum, Exchanges are custodial. It's up to them if they are willing to bump a transaction, but I'm most certain that most custodial services do not do that. Or wait for it to be able to broadcast again then use CPFP to the transaction to bump its fee (right-click->"Child pays for parent"),
That's what I am most comfortable doing. I will try changing server now and then until the inbound transaction get "picked up" again, and CPFP. I have a couple of precautionary questions: is it safe to: - update Electrum - receive and send other transactions while I have this 'Local' transaction hanging? Those are safe to do while having an inbound local transaction. The only issue I find is when sending while " spend only confirmed coins" is disabled because the output of your local transaction may get selected that'll cause the new transaction to be invalid for spending non-existing coin. If that setting is disabled in " pay" new transaction dialogue's settings icon, you can temporarily disable the setting or freeze its output in the 'Coins' tab. The former will prevent you from spending the change from your other unconfirmed transactions. That local transaction is saved in your wallet file but not in all bitcoin nodes, if you want to keep a backup of it; you either create a backup of wallet or create a backup the transaction by opening it ( RClick->Details) and use the " Share" options ( via "save to file" recommended). You can import that back via " Tools->Load transaction->From File' and broadcast in case it got totally dropped and deleted as long as its input is still unspent. |
|
|
|
Is 2 enough to assume that the transaction was dropped by the network? I am asking, however I must say, I actually tried to re-send the UTXO (not sure I am using the term correctly) 9 days ago.
With how the nodes relay and drop transactions nowadays, it's hard to assume that a txn is totally dropped by the network since it might propagate again in the right condition. Reason is, not all nodes have the same relay and mempool settings, some of them may keep a transaction for months and some wallets are re-broadcasting transactions. Specially yours that's only unavailable in two blockexplorers, I bet that it'll be relayed back to your server's mempool once its fee rate made it in the default relay fee policy. Although, it will get dropped for good once any of its input is spent by another transaction. I have a receiving transaction showing as "Local" in Electrum, so, I understand no longer on the network.
Unfortunately, since it's inbound, you can't do anything to it but to contact the sender to increase the fee if it's possible in his wallet; Or wait for it to be able to broadcast again then use CPFP to the transaction to bump its fee ( right-click->"Child pays for parent"), Alternatively, instead of CPFP, use " coin control" ( instructions) to use its output to your next transaction but set a higher fee rate to bump those two txn's overall fee rate. |
|
|
|
Any ideas? Thanks a lot, i appreciate your help:)
I've edited your code to work in legacy addresses at derivation path m/44'/0'/0'/0/0~19: import bip32utils
from bip32utils import BIP32_HARDEN
from mnemonic import Mnemonic
words="hidden common actress negative cactus quote hole filter aunt confirm neutral voice"
mnemo = Mnemonic("english")
seed = mnemo.to_seed(words)
print(f'BIP39 Seed: {seed.hex()}\n')
root_key = bip32utils.BIP32Key.fromEntropy(seed)
root_address = root_key.Address()
root_public_hex = root_key.PublicKey().hex()
root_private_wif = root_key.WalletImportFormat()
print('Root key:')
print(f'\tAddress: {root_address}')
print(f'\tPublic : {root_public_hex}')
print(f'\tPrivate: {root_private_wif}\n')
purpose = (44)
coin = (0)
for account in range(1):
for chain in range(1):
for address in range(20):
child_key = root_key.ChildKey(purpose + BIP32_HARDEN).ChildKey(coin + BIP32_HARDEN).ChildKey(account + BIP32_HARDEN).ChildKey(chain).ChildKey(address)
child_address = child_key.Address()
child_public_hex = child_key.PublicKey().hex()
child_private_wif = child_key.WalletImportFormat()
print(f'Child key m/{purpose}H/{coin}H/{account}H/{chain}/{address}:')
print(f'\tAddress: {child_address}')
print(f'\tPublic : {child_public_hex}')
print(f'\tPrivate: {child_private_wif}\n') You can test the mnemonic seed above in IanColeman's BIP39 tool and compare the results in BIP44 tab. Unfortunately, bip32utils doesn't support SegWit so even if you put the correct derivation path index ( 84) for " purpose", it'll only display legacy address but with the correct public and private keys of your Blockchain web wallet's SegWit addresses. You'll have to use another library to display the correct address. Note: The " H" in the derivation paths in the result means that it's derived with " hardened" derivation path. You can increase the range of " account" depending on how many extra private key wallets you've created in 'Accounts and Addresses' page. |
|
|
|
This is so confusing because one topic says that there IS a work-around and then something else or someone else says that it does NOT work and that money is just gone even though it's sitting right friggin' there  Please show where it says that there's a workaround so we can see the other info that you've shared where they came to the conclusion that it's recoverable. BTW, this thread started with an entirely off-mark issue that isn't actually the issue, the " QR Code warning", perhaps they're talking about the work-around to that, because it's just about the exportation of the unsigned transaction. Anyways, Here's an easy-to-understand explanation: Bitcoin isn't something like a bank account. It is " self-custodial" and every bitcoin is recorded in every Bitcoin Node's blockchain, not in anyone's wallet, Electrum is a self-custodial wallet. Even the nodes where the Blockchain is stored have no control over the funds stored in them since those can only be unlocked by the correct private key. Wallets just display coins that it can watch or spend depending on what's stored in it: " Spending" bitcoins require the " private key" of the address where it's sent to. " Watching" only requires the public info which can be the address, public key or xpub key ( in Electrum: Wallet->Information). Your watching-only wallet doesn't contain any private key. I hope that the terms I've used here are not confusing. I created that wallet about a year ago when I first downloaded electrum and started using BTC. It's always worked and have made hundreds of transactions. Until the last one.
Are all those hundred transactions inbound? If not, you may have more than one wallets available in your wallet list and you've just loaded the watching-only wallet that you've ( accidentally) created. How about the 12-word " seed phrase" that the wallet instructed to write on a paper/backup? You can't proceed without backing it up. If yes, it's normal that you can receive bitcoins to a watching-only wallet because all it needs to receive is to provide an address to the sender. But you can't spend it without the usual non-watching-only pair where the xpub/address came from. |
|
|
|
-snip-
-snip- Not that it will automatically change the transaction to a RBF one I think it's needless to explain that to an Electrum developer  The logic of his question is because all transactions created by Electrum since Dec 11, 2022 already have opt-in RBF set to true, so it's unnecessary to try full-rbf on Electrum unless it's imported from another wallet that created a transaction with opt-in RBF false flag. |
|
|
|
This might be helpful as a solution: -snip-
He can only do that if he has the standard/imported wallet that has the private key(s) of his watching-only wallet. Based from OP's replies, it seems like he's unaware that he's been using a watching-only wallet all this time. I am using Android and am on version 4.4.6
I have tried transferring the entire amount in my wallet and have tried transferring much less than the total amount in the wallet. Every time I get the same error. One thing I noticed is that the wallet details say it is "watch only." I created a new wallet and the wallet details info is much newer. Might be because I've had the original wallet for a long time?
-snip-
It seems that might be my issue is that somehow the wallet became watch only. Or, am I wrong?
Electrum wallets do not change from standard to watching-only for whatever reason. It's watching-only because it's created via importing a " master public key", an address or set of addresses. The former will create an HD watching-only wallet that's capable of generating new addresses. The latter has fixed amount of addresses depending on how many was imported. Both are incapable of spending bitcoins sent to them. The " QR code issue" isn't always an issue but standard warning for those who want to use the QR code to export the transaction. So, the question is, how did you created that wallet? Had someone or a shady tutorial instructed you? |
|
|
|
Then i made a copy of the 12 words mnemonic from the blockchain account.
-snip-
So my question is: how to get a list of the address corresponding to non zero balance from the seed of a HD wallet?
You mean Blockchain's online wallet? They use standard derivation paths of BIP44 for legacy and BIP84 for SegWit HD wallets. Here's info about the paths: bip-0044 | bip-0084And if you created a second or third " private key wallet" ( not address), you'll need to modify the derivation path's account_index accordingly. |
|
|
|
A few weeks ago, it was functioning properly, but then I encountered a parsing error while opening it.
Despite this issue, I was able to access the wallet successfully several times afterward.
Unfortunately, the parsing error has now become persistent. Is there any way to resolve this issue?
Unfortunately, before you can decrypt the master private key in your wallet file, the wallet file itself needs to decrypted before it and with the error, it looks like it's not in proper Base64 format, other decrypting tools may result with similar error. It's rare to hear of parsing error that intermittently fixes itself ( at least for a while). Perhaps it's an error in your RAM that was the cause of the parsing error, then it persisted once a persistent corrupted encrypted state was saved to your disk. In any case, it's worth to check for hardware issues first before attempting to use the machine. Plus your drive may still contain a working version of your wallet file when scanned by recovery tools, so I'll advice you to copy the wallet file and use another machine or at least another system drive to work on its recovery. |
|
|
|
-snip-
It should be 10, not 11. BlackHatCoiner is correct, 11 is the maximum possible outbound peers. Here's Bitcoin's current " net.h": github.com/bitcoin/bitcoin/blob/master/src/net.hThe lines MAX_OUTBOUND_FULL_RELAY_CONNECTIONS, MAX_BLOCK_RELAY_ONLY_CONNECTIONS and MAX_FEELER_CONNECTIONS all count toward the maximum outbound connections. |
|
|
|
In this case, hypothetically if there were 8 witness items, they would not be specified as 00 x8 times, but 08 as the stack length and then each stack (containing the relevant scriptsig)?
It's each input's number of stack items followed by the stack items. To be simpler, here's an example for 3 witness items: <number of stack items for input0> <size of stack item0 of input0> <stack item0> <size of stack item1 of input0> <stack item1> ...
<number of stack items for input1> <size of stack item0 of input1> <stack item0> <size of stack item1 of input0> <stack item1> ...
<number of stack items for input2> <size of stack item0 of input2> <stack item0> <size of stack item1 of input0> <stack item1> ... And if only half of them were witnesses, then it's 04 as stack length and then the 4 stack items?
If there are non-witness amongst the inputs, witness data should be ( let's say input1 above is p2pkh): <number of stack items for input0> <size of stack item0 of input0> <stack item0> <size of stack item1 of input0> <stack item1> ...
00
<number of stack items for input2> <size of stack item0 of input2> <stack item0> <size of stack item1 of input0> <stack item1> ... Refer to BIP143 for examples of mixed witness and non-witness inputs: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#exampleThe number of witness items doesn't have to be specified and the arrangement is based from the inputs' index as mentioned in BIP144: The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. |
|
|
|
I have tried all versions of Electrum. Those that are older than version 3.8.0 cannot see my funds. In the newer ones of 3.8.0 I can see my funds but when I try to send them I always get an error. The error is RuntimeError("Process error: Failed to compile output")
You can try this but I don't have any means to test this myself: In version 3.3.8 ( do not use newer ones since the older versions don't support PSBT of v4.x), Get your wallet's master public key from " Wallet->Information", if it's not available, you may have to remove your Electrum password. ( Trezor hodls the keys anyways) Then create a watch-only wallet using that xpub via: " File->New/Restore->(New Wallet Name)->Standard Wallet->Use a master key", then let it sync. In that watch-only wallet, use send to create an 'unsigned transaction' and export it via " Export->..." In the old version ( v2.7.13~v3.0.3), import ( Tools->Load transaction->...) that unsigned transaction to your wallet that's connected to Trezor. Sign it and export the 'signed raw transaction'; Now if you encountered any error, try those versions from 2017, here's the old binaries: download.electrum.orgThen import it back to the newer version and broadcast it. -edit-I just recalled, it may require Electrum to be online ( synced) to sign if it's not SegWit or if it's too old so this may not work. Offline signing is only implemented in the later versions: github.com/spesmilo/electrum/issues/3302#issuecomment-379303347 |
|
|
|
We wrote the plugin for our own use, to replace Boltz, as they changed their license from AGPL to a non-free license around 2023-04. Since around 2023-08 we are no longer using Boltz. That is, the official swap server is now an electrum daemon with this plugin enabled. Okay, so this is the reason why there's always a " The swap server errored or is unreachable" error whenever I try using submarine swap. It would've been great if this info is mentioned in the release notes, though. |
|
|
|
-snip- Does anyone know how I transfer my Breez BTC to Electrum? Thank you!
If you decided to follow the initial instructions in the first reply, it should be noted that a newly opened lightning channel in Electrum doesn't have any inbound capacity. And opening a channel requires a minimum amount of Bitcoins that you'll use to fund your channel's initial sending capacity. ( depends on the remote node: 0.002BTC+ and on-chain transaction fees) In other words: you'll need on-chain funds in Electrum and you cannot immediately send your bitcoins from Breez via LN without spending your sending capacity first or by using Electrum's " submarine swap" feature to gain inbound capacity. |
|
|
|
|
Show Posts
