What command would you type in to derive change addresses? (I imported the change addresses "internal\": true), but wasn't sure how to display addresses to cross check.

From memory, aren't change addresses just derived from a slightly different derivation path? (m / purpose' / coin_type' / account' / change / address_index) -> I attempted to change it to deriveaddresses "sh(wpkh([00000000/49'/0'/0'/1]xpub...." but got a checksum not matching error.

Thanks a lot everyone.

o_e_l_e_o, regarding the change addresses, when running the below command:



(with xpub replaced and fingerprint replaced), I got the following error:




It worked when I replaced the range with that. Is this a reference to how many addresses have already been used in the first wallet? I'm not sure why it required that range change.

Further to that, I was attempting to run the command without rescan, and tried timestamp "now", but it gave an error:



The rest worked well.

If wanting to add another xpub to the same wallet, to have the sum of balances displayed, I assume I just repeat the process in the same wallet with the new xpub/fingerprint? Hopefully combining multiple xpubs in one wallet for watching total balances is possible?

Thanks again.

Thanks for the link.

importdescriptors "[{\"desc\": \"wpkh([66bb13d5/84'/0'/0']xpub6CtDSW4S3XVd5uYp9CgsLTZKQcKieJSmjehcvfVJBSy1rPbkKNU3T6UmZ3mn7DoSsTsM6uH8ZKe m7LQh3PHyrBAtZopSvF2tonEE7foTWFe/0/*)#v3w0q0zv\", \"range\": [0, 1000], \"timestamp\": 1647182091, \"internal\": false, \"watchonly\": true, \"active\": true}]"

What do the bolded parts mean? And where would I get them from?

I have researched and just don't have the technical acumen to understand how to do this.

Is there a simple line I can post in the GUI console to create a watch-only wallet with an Ypub?

More specifically, I am trying to import a YPUB address into Core with standard derivation path (m/49'/0'/0').

I have tried to figure out how to do this but find myself confused.

Is this possible? Please help

Ok, I've made an attempt: https://github.com/spesmilo/electrum/issues/7257

I haven't made a GitHub post before, so please let me know if I need to do anything differently.

Thanks for everyone's time.

Yes, using the Electrum Scanner, but I even used non-Electrum QR Readers/Creators on both ends to construct the transaction to QR and deconstruct the transaction to text on the offline machine and then import as text. Both attempts had the same issue.

Yes, both clients are 4.1.2. But I also tried both with an older version 4.x.x before updating in an attempt to fix this error.



I probably should have added that I'm using a Nano S to sign the transaction, but I didn't think it relevant, because it works when the transaction is transferred via USB and signed with the Nano S on this offline device, but not via QR.


Google of that error message (txtmp = bitcoinTransaction(bfh(utxo[0]))) takes me here: ( https://github.com/spesmilo/electrum/issues/3302 ) which looks like it was fixed for segwit transactions (and hence it works for my situation when transferring via file and USB) but doesn't explain why it won't work when transferring via QR. Is less information transferred (even when using Export -> For hardware device, include Xpubs -> Show as QR) when using QR Code?

The transaction is a nested segwit transaction.

When attempting to use QR Codes to transfer unsigned bitcoin transactions, when using Electrum to build the transaction, after clicking 'sign' I get the following message: fromhex() argument must be str, not None

I am aware Electrum uses non standard QR Codes, but I don't believe my issue lies there, because I have used both Electrum to Electrum QR as well as non-Electrum to Electrum via QR. Both methods have been able to contruct the transaction for viewing (and it has the correct inputs/outputs etc) but get the same error when attempting to sign.

All else appears to work fine, and when the exact same work-flow is done via 'file' over USB rather than QR code, everything is able to be signed perfectly. I have attempted saving the file once imported via QR and then loading that file and trying to sign, but I get the same error message.

I have also used all variations of (export via QR, export for hardware wallet via QR, etc) without success.


Any idea what I could be doing wrong?

Latest Electrum Version running on an offline machine (and one on an Online machine).

Thanks for the reply.

I assumed the mempool was gossiped by nodes on an ongoing basis; I assume I was incorrect and it is only transactions that are recently broadcast that are gossiped between nodes.

I take it then that a node cannot 'request' transactions in the mempool over the network to cross check against? I guess this could be used to drain resources/ddos.

With Bitcoin Core, I am looking at the mempool in my node and it is sitting at 3mb (1,809 transactions).

I am aware of transactions that are unconfirmed (visibile on explorers) but not on my node. Further to this mempool.space has a mempool size currently of 23mb 28,781 (unconfirmed transactions).


I am aware that every mempool is different, but is my core mempool artificially limited to be 1/8 the size of other mempools? Can I change this to have a fuller picture of the network/mempool/unconfirmed transactions?

DBCache is set to 8,000.

When a Ledger Nano S is connected to Electrum, and the HWW contains the corresponding private keys for the attached Electrum wallet, the ledger symbol lights up in green.


How does Electrum confirm the device is holding the correct private key to spend the UTXO's contained in the Electrum wallet?


Does it simply receive the XPub stated by the device, and trust that the device holds the private keys for said XPub, or is there verification (ie: some type of signing) to confirm it?



In short, does Electrum verify that a device is accurately stating the private keys it holds or is verification only done during signing and prior to this the green ledger light on Electrum is an indicator only (trusting that the device holds the corresponding keys because the device says so)?

Thank you to everyone who responded.


NeuroticFish, you were right.

Adding the flag --offline in my Electrum shortcut fixed it and allowed signing the transaction completely offline.

Thank you very much for your time.

Having read through some of the recent Electrum release notes, I think this issue may have been fixed, although I haven't tested it myself, and reading the code/github is beyond my ability

Is it possible to use Electrum and a Nano S to sign unsigned transactions via a permanently offline computer?

I am having some trouble with this:

Setup:

With an online computer using Electrum watch-only wallet, Electrum Personal Server, Bitcoin Core, and a USB to save the unsigned transaction to.

Method:

Transaction is created using the UTXO inputs and the output I want. This transaction is then saved to a USB and transported to the offline computer which has the Nano S plugged in.

I have been unable to get unsigned transactions to be signed by Electrum and Nano S on an offline machine (never connected). This seems like something that should be possible? The Nano S is connected (green light on Nano S symbol in Electrum, and Electrum is offline (red circle).

Obviously there is no transaction history in the offline computer, is this causing the issue? If so, it seems odd that this is required.

Error:

"no interface to do request on ... gave up"


I am unsure whether it is due to Electrum not having UTXO's history or due to another part of the set-up requiring a direct connect.


I have read through https://github.com/spesmilo/electrum/issues/3302 and it doesn't seem to be clear either way. It appears that it isn't as straight forward as I'm thinking, but Sombernight states "Ledger:
legacy does not work, no plan to implement support
✔segwit works" and I'm trying it with P2SH so I assume it should work?

Any help would be much appreciated, but please save yourself the lazy non-answer of 'a Nano S is an offline computer'. I am aware of that line of thinking, it isn't answering my question.




Solved: Adding the flag --offline in my Electrum shortcut fixed it and allowed signing the transaction completely offline.

How have you been using Electrum and Nano S on an offline machine?

I have been unable to get unsigned transactions to be signed by Electrum and Nano S on an offline machine (never connected).

Error: "no interface to do request on ... gave up"


I am unsure whether it is due to Electrum not having UTXO's history or due to another part of the set-up requiring a direct connect.



(Online computer using Electrum watch-only wallet, Electrum Personal Server, Bitcoin Core, and a USB to save the unsigned transaction to).


Edit - Created its own topic.

Further thinking about this rule:


The only time this error would ever occur, is when the original fee was <2 sat per byte.

Electrum appears to suggest increasing the fee by 1.5x, and this rule would always provide a high enough bump if the original fee were 2 or more sat/byte.

Example: 225 byte transaction @ 2sat/byte = 450 sat transaction
RBF Electrum - 1.5x fee = 675 sats (225 sats higher than the original fee, thus paying for its own bandwidth as per rule 4).  <- Accepted

Example 225 byte transaction @ 1sat/byte = 225 sat transaction
RBF Electrum - 1.5x fee = 338 sats (113 sats higher than the original fee, thus not paying its own bandwidth as per rule 4). <- Rejected

Example 225 byte transaction @ 10sat/byte = 2250 sat transaction
RBF Electrum - 1.5x fee = 3378 sats (1,126 sats higher than the original fee, thus paying its own bandwidth as per rule 4). <- Accepted


A simple fix would be to suggest the bump as: whichever is the higher of either [1.5x the original fee] or [an increase of sats equal to the bytes of the new transaction].

Hi djhomeschool,

Thanks for taking the time to reply.

I am most definitely not connected to a phishing server as I am connecting to my own node via Electrum Personal Server. I have figured out (I believe) the issue, and am suggesting an improvement to help others who come across this error


TLDR: RBF has a rule that requires your RBF fee bump to be at least the size of your transaction in bytes above the original fee. (So a transaction that's 225 bytes, paying 1,000 sats can only be bumped by 225 sats or more).

This isn't reflected in Electrum, and took me some research to figure out, so I am suggesting the error message be updated to better reflect it (and potentially the algorithm for suggesting the fee bump too).

Using Electrum RBF, I attempted to increase a transaction fee (by an arbitrary amount) to learn the process.



This fee that Electrum selects ( 1.5sat/byte over the previous 1sat/byte) appears to be fine for my learning (I'm happy to wait or have it fall from the mempool eventually).

But when trying to broadcast the transaction the following comes up:



I am using my own node so it wasn't the server. So I was trying to think why this would be. I tried a variety of different unconfirmed transactions before trying one at 2 sat/byte. Which worked.

Was the error in actual fact just trying to increase the fee by too small an amount?

If so, I believe changing the error message to reflect this (or a message suggesting minimum increase/multiple) would be helpful.


Edit - Reading through BIP125 I see the following which probably explains why my transaction required a higher fee-bump:


Maybe the suggested minimum RBF fee suggested/allowed by Electrum could reflect this rule (if that is indeed the current network rule).

So my 316 byte transaction required a fee bump of at least 316 bytes to be accepted by (most) of the network). <- Maybe an explanation of this requirement could be included in the error message?

Thanks Jerome. I figured it out.

In case anyone else has this question, my problem was because I was using '-reindex' in the console, rather than adding it to the bitcoin-qt.exe to run (via command line- "Z:\Bitcoin\bitcoin-qt -reindex").

I am not sure whether deleting chainstate would have cause issues, but it does seem that reindex has done that and synced from block 1 to (currently) August 2018 in 3 hours using only 13MB of bandwidth. HDD bottlenecked for the first 8 years, and CPU for the last 2 years worth.

Edit - Finished reindex in ~4 Hours on a 5 year old PC (7200rpm HDD, i5 4690 CPU, 16gb RAM (dbcache set to 12,000)).

-reindex:


-reindex

Method not found (code -32601)

And

-verifychain  checks something but only takes 5 seconds to do.