LoyceV's 0.1 sat/vbyte Electrum Server Adventure

[LoyceV]

I don't care how long it takes, but it's not getting accepted for an error message other than "maximum clients connected"

That's weird: my previous post shows the number of connected clients has been higher, and I assume you don't have more than 12 different clients running:

Code:

        "max_clients_per_ip": 12,

Nevermind, I switched from yours (with the console message linking back to this topic) to a random server in the list that happened to be ElectrumX, did the console command & pushed successfully into unconfirmed status.  

Thanks for posting anyway, even though I'm not sure what causes it.

Code:

    "txs_sent": 5272,
    "txs_sent_bytes": 3836535,
    "uptime": "2.211 months",

On average, my server processes a few transactions per hour. I'm posting this counter so I can compare later.

[TheButterZone]

I don't care how long it takes, but it's not getting accepted for an error message other than "maximum clients connected"

That's weird: my previous post shows the number of connected clients has been higher, and I assume you don't have more than 12 different clients running:

Code:

        "max_clients_per_ip": 12,

I had considered using the Tor proxy might be an issue (could that mean it sees >12 per IP?), but wallet.relayfee = (lambda: 0) & push gives the same "min relay fee not met" error, switched between either dark or clear net connection to your server.

[nc50lc]

0.1 sat/vbyte TX push after >>> wallet.relayfee = (lambda: 0) gets me "min relay fee not met"

I can't really test it as I don't need to make a transaction, but based on mempool.space's future blocks, 0.1 sat/vbyte is not going to confirm any time soon. But mempool isn't full either, so the minimum fee should still get accepted.

I have some dust to play with, so here's a successful test (txid redacted but it's in mainnet):


@Butterzone, the "(lambda: 0)" command isn't necessary now if you're using Electrum v4.6.2 and above. Although I don't think that using it is the cause.
If you're using an older version instead, it must be the previous "fee rounding issue" that can cause it to be 1 sat below the set minimum.
Other servers where you broadcasted it might have lower than 0.1 sat/vB fee relay settings.

[TheButterZone]

0.1 sat/vbyte TX push after >>> wallet.relayfee = (lambda: 0) gets me "min relay fee not met"

I can't really test it as I don't need to make a transaction, but based on mempool.space's future blocks, 0.1 sat/vbyte is not going to confirm any time soon. But mempool isn't full either, so the minimum fee should still get accepted.

I have some dust to play with, so here's a successful test (txid redacted but it's in mainnet):


@Butterzone, the "(lambda: 0)" command isn't necessary now if you're using Electrum v4.6.2 and above.

(v4.5.8 & I cannot safely upgrade to a higher version of Electrum without buying a new computer)

[nc50lc]

(v4.5.8 & I cannot safely upgrade to a higher version of Electrum without buying a new computer)

Okay, it's in a reply posted last year.

Then it must be the other case that I've mentioned.
There's a fee rounding issue before v4.6.2 that's specially apparent on sub 1sat/vB transactions.
Commit: github.com/spesmilo/electrum/commit/392400295e733e1dd3f0cb14189466e8a76890ef

For example: my screenshot above has 20sat (0.0000002 BTC) absolute fee rate and a size of 191vB.
Previous version might round it down to 19sat instead making it lower than the required min fee rate of 19.1 sat/vB,
it has decimal so it must be rounded but since it can't be lower, it should be rounded up to 20.

[TheButterZone]

eli5: If my signed TX is 144 vbytes, the absolute fee should be 0.00000015 to achieve a 0.1 sat/vbyte push without rejection on servers that allegedly support 0.1?

ETA: Apparently that worked. I am dumb. I saw "min relay fee not met, 14 < 15" on a few of the pushtx websites that I tried in frustration. I guess I'll never see that or a similar post-calculation warning in my older final compatible version of Electrum, unless I get a new brain & am able to edit (easy, just one line?) & recompile the source (historically a nightmare for me - and looks like it's impossible, as I read 4.5.8's OSX readme for Building macOS binaries
& my version is below the sanity check version & cannot be upgraded any further without a new computer).

P.S. I remember the name of the random server that accepted my 14 sat fee yesterday, and it's not on my local server list or even https://1209k.com/bitcoin-eye/ele.php anymore. Weird. Did that fee bug them off the network?

[LoyceV]

eli5: If my signed TX is 144 vbytes, the absolute fee should be 0.00000015 to achieve a 0.1 sat/vbyte push without rejection on servers that allegedly support 0.1?

Correct.

my version is below the sanity check version & cannot be upgraded any further without a new computer).

Maybe I'm missing some OPSEC reason here, but why not just get a cheap second hand laptop for this? I'm a big fan of "old" business laptops: anything with low-power CPU, 8+ GB RAM and working battery is great to wipe and install Linux.

P.S. I remember the name of the random server that accepted my 14 sat fee yesterday

If it's under 0.1 sat/vbyte, I don't think any miner will confirm it even if mempool is empty.

[TheButterZone]

my version is below the sanity check version & cannot be upgraded any further without a new computer).

Maybe I'm missing some OPSEC reason here, but why not just get a cheap second hand laptop for this? I'm a big fan of "old" business laptops: anything with low-power CPU, 8+ GB RAM and working battery is great to wipe and install Linux.

I have too many old computers (& battery issues) already & not enough desk/room space, UPS outlets & router ports to run them on without unplugging my roommates or resurrecting a 26-year-old switch & going nearly-raw (surge-protected) AC.

The last time I installed Linux was on iMac G5 1.8 GHz 20 inch (M9250LL/A) & its wired ethernet worked fine on whatever macOS version was on it... before Lubuntu. I'm pretty sure I had my router set (like it is now) to dynamically assign 1 IP from a range of 1 IP so it didn't matter what MAC the iMac had, while every other device on the network had static DHCP reservations (& per the device list, none grabbed the 1 IP by accident), so I believe it was a Linux-on-PPC/Apple hardware issue, not a network issue.

P.S. Even though I can't compile a binary, I was able to

Code:

git clone --branch 4.5.8 --single-branch https://github.com/spesmilo/electrum.git

(and the other run from source readme steps, that I adapted to MacPorts) & run from source after editing in that commit only

Code:

if feerate < Decimal(self.relayfee()) / 1000:

since the

Code:

and not is_future_tx

didn't appear in the 4.5.8 clone.

"min relay fee not met" remains the error message for a 14 sat fee on a 144 vsat TX, as expected. What code will it take for Electrum to tell me "add 1 satoshi to meet min relay fee" or whatever it calcs needs to be added? While I'm at it, I may want to have that console command auto-execute on every server connection too. I may need to hit up Gemini or ChatGPT for this, but it's a lot of work for 1 TX out per year & 0 in, LOL

[LoyceV]

"min relay fee not met" remains the error message for a 14 sat fee on a 144 vsat TX, as expected. What code will it take for Electrum to tell me "add 1 satoshi to meet min relay fee" or whatever it calcs needs to be added?

Can't you just enable manual fee editing, and add 1 sat?

[TheButterZone]

"min relay fee not met" remains the error message for a 14 sat fee on a 144 vsat TX, as expected. What code will it take for Electrum to tell me "add 1 satoshi to meet min relay fee" or whatever it calcs needs to be added?

Can't you just enable manual fee editing, and add 1 sat?

I will always be exactly 1 sat short from Electrum's existing static fee calculator, no matter the size of the TX?

[LoyceV]

I will always be exactly 1 sat short from Electrum's existing static fee calculator, no matter the size of the TX?

There's probably a scenario in which it pays the exact right amount. Electrum's interface changed a few times with different versions, so I'm just guessing here, but if you enable Preview you should see both the exact size and the exact fee.

[nc50lc]

P.S. Even though I can't compile a binary, I was able to
-snip-
What code will it take for Electrum to tell me "add 1 satoshi to meet min relay fee" or whatever it calcs needs to be added?

Your manual patch to v4.5.8's source code should've fixed the rounding issue if you're running Electrum from that source code,
So this shouldn't be necessary anymore after that.
But that only affects the new transactions that your patched Electrum will create, not existing ones with already wrong fee rate.
And that can be an issue since most miners wont accept your <0.1sat/vB transaction into their mempool.

There's a way to remove that original transaction and create a replacement (skip to the alternative below),
but it'll subject to RBF rules to nodes that already relayed it so, you can't just add 1sat fee to its replacement, it'll have to add an extra 0.1sat/vB fee based on its vSize to be valid.
Here's a reference: github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details

In that regard, "increase fee" option with a new fee rate of its "original fee + calculated 0.1sat/vB" is your best option to bump it to a reasonable fee rate.

Alternatively, if you feel that there are more nodes that rejected your transaction than those that relayed it (I think it does),
you can do this instead:

First, select Loyce's server to make your Electrum mark it as "local" because it's not in that server's mempool,
that way, you can right-click on it and select, "remove" so that the UTXO it used as input can be spent again
(you can export a backup from its transaction preview before removing it if you want)
Then, use coin-control to spend the same UTXO that it spent when creating a new transaction with extra 1sat fee.

Since the original transaction is even lower than 0.1 sat/vB, there's a high chance that its replacement will propagate better.
Note: with rbf's rules, it'll be rejected by nodes that already have the original transaction.

[TheButterZone]

There's a way to remove that original transaction and create a replacement -snip-

eli5: If my signed TX is 144 vbytes, the absolute fee should be 0.00000015 to achieve a 0.1 sat/vbyte push without rejection on servers that allegedly support 0.1?

ETA: Apparently that worked.

There is no original transaction in memory/mempool. No conflict. No problem. The replacement worked.

After that, I was just seeing if the patch worked on a new 144 vbyte TX with a different UTXO. It didn't. Patched Electrum keeps static 144 x 0.1 (typed by me) at 14 sats (calculated by patched Electrum), it doesn't automatically round up to 15 sats. I need Electrum to automatically round up to the exact fee digit for any size of TX that will qualify as the minnest of 0.1 min fee so I will never receive an error message. Not one satoshi less, not one satoshi more, than absolute minimum required rounding. That is the actual patch that needs to be made.

[nc50lc]

After that, I was just seeing if the patch worked on a new 144 vbyte TX with a different UTXO. It didn't. Patched Electrum keeps static 144 x 0.1 (typed by me) at 14 sats (calculated by patched Electrum), it doesn't automatically round up to 15 sats.

That's weird, you did the same necessary patch as the commit which made v4.6.2+'s fee rate consistent.
And the missing is_future_tx shouldn't be a problem since that's pertaining to saved transactions with future time lock used by a later version's feature.

Maybe there's more pre-requisite other than that commit but I'm not so sure of it, I'll check it out later.

-update-
Turns out, this commit should be added as well: github.com/spesmilo/electrum/commit/5432228d17819865fe559e5073974c895fc08d7d

[TheButterZone]

As planned, I just made a source edit that appears to have the same effect as if I had done

Code:

wallet.relayfee = (lambda: 0)

in Console.
In simple_config.py make

Code:

FEERATE_DEFAULT_RELAY = 0

NOT = 1000 - then Electrum no longer warns when merely building a 0.1 sat/vbyte TX while connected to electrum.loyce.club:50002.

But I don't think this solves the roundup patch issue; were I to go all the way to push a new 144 vbyte TX with a 14 satoshi fee, it should still be rejected at that stage.

Code:

if feerate < Decimal(self.relayfee()) / 1000:

remains in wallet.py

P.S. I also made this modification to network.py

Code:

        async def get_relay_fee():
            actual_fee = await interface.get_relay_fee()
            print(f"Actual relay fee for {interface.server}: {actual_fee}")

That prints in Terminal, not Electrum Console. You see on run if the server you had selected most recently has a high fee, before passwording into your wallet (so you know if you need to switch servers afterward) - then any server switches, you see their fee in Terminal as well. I checked the server that allowed the 14 sat pushtx, disappeared & reappeared, now I see why: their actual relay fee is "1", Loyce's is "100", most of the 7 I randomly checked are "100" but there was one "1000".

[nc50lc]

As planned, I just made a source edit that appears to have the same effect as if I had done

Code:

wallet.relayfee = (lambda: 0)

in Console.
In simple_config.py make

Code:

FEERATE_DEFAULT_RELAY = 0

NOT = 1000 - then Electrum no longer warns when merely building a 0.1 sat/vbyte TX while connected to electrum.loyce.club:50002.

Close, but that should do its purpose.
Just "Close" because the command's target is the "relayfee" function in "wallet.py", here: /electrum/wallet.py#L1806-L1807
It forcefully sets it to zero.

BTW, Electrum's permanent approach was different, they've added FEERATE_MIN_RELAY and use its value to set the new minimum fee that Electrum supports.
while still keeping FEERATE_DEFAULT_RELAY to its original value.
Ref: github.com/spesmilo/electrum/commit/58af1c493de0a620f164ac025f10c58280af36b1

-snip- now I see why: their actual relay fee is "1", Loyce's is "100", most of the 7 I randomly checked are "100" but there was one "1000".

Interesting result.
Most are using 100sat/vkB since it's today's standard but there are those who still chose to use the old 1000sat/vkB or even lower than standard.

[TheButterZone]

BTW, Electrum's permanent approach was different, they've added FEERATE_MIN_RELAY and use its value to set the new minimum fee that Electrum supports.
while still keeping FEERATE_DEFAULT_RELAY to its original value.
Ref: github.com/spesmilo/electrum/commit/58af1c493de0a620f164ac025f10c58280af36b1

Great, so it all got so complicated they had to add electrum/fee_policy.py which wasn't in 4.5.8, instead of editing the existing files.

[TheButterZone]

Your server cert just expired

verify error:num=10:certificate has expired
notAfter=Aug 18 09:19:47 2026 GMT

[LoyceV]

Your server cert just expired

Thanks! I didn't notice, as my Electrum was still connected. But when I restart it, it doesn't connect.
I really hate dealing with certificates I didn't expect I'd still be running Fulcrum after a year.

It looks like it's exactly one year old:

Code:

-rw-rw-r--  1 electrum electrum 1196 Aug 18  2025 server.crt
-rw-------  1 electrum electrum 1704 Aug 18  2025 server.key

By the time it expired, I forgot how I created it.... This is a reminder for next year:

Code:

openssl req -new -key server.key -out server.csr
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
rm server.csr
~/Fulcrum-1.12.0-x86_64-linux/FulcrumAdmin -H 127.0.0.1 -p 8504 stop
cd ~/Fulcrum-1.12.0-x86_64-linux/; ./Fulcrum quickconfig.conf &

I can't add this to a cronjob: "openssl" asks interactive questions. Remind me before August 18, 2027

[TheButterZone]

Your server cert just expired

Thanks! I didn't notice, as my Electrum was still connected. But when I restart it, it doesn't connect.
I really hate dealing with certificates I didn't expect I'd still be running Fulcrum after a year.

It looks like it's exactly one year old:

Code:

-rw-rw-r--  1 electrum electrum 1196 Aug 18  2025 server.crt
-rw-------  1 electrum electrum 1704 Aug 18  2025 server.key

By the time it expired, I forgot how I created it.... This is a reminder for next year:

Code:

openssl req -new -key server.key -out server.csr
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
rm server.csr
~/Fulcrum-1.12.0-x86_64-linux/FulcrumAdmin -H 127.0.0.1 -p 8504 stop
cd ~/Fulcrum-1.12.0-x86_64-linux/; ./Fulcrum quickconfig.conf &

I can't add this to a cronjob: "openssl" asks interactive questions. Remind me before August 18, 2027

Reconnected. Ya got lucky, if was still running the 4.5.8 binary & not from source, I wouldn't have seen the certificate has expired terminal prints, just a red ball in GUI. At least I think so... that's what seemed to happen back with the binary when I tried to connect to servers & waited long enough that they should have connected.