How to make a bitcoin transaction and pay less than 1 sat/vByte

[TheButterZone]

Do each of you want to do the fork & PR thing to get your servers onto https://github.com/theDavidCoen/sub1sat-node-list ?

I'm not going to do that. I've seen the link a few times, it's someone I've never heard of before at Github. His list has only 4 nodes. If anyone's interested to use my node, they'll either find it on Bitcointalk or Electrum will find it on it's own.

I've looked up and down the Electrum server list multiple times, yours isn't listed by DNS. Nor IP address, judging by the tracerouted IP.

Not on https://1209k.com/bitcoin-eye/ele.php?chain=btc either.

[LoyceV]

I've looked up and down the Electrum server list multiple times, yours isn't listed by DNS. Nor IP address, judging by the tracerouted IP.

All I know it it had 200+ clients connected within minutes after I started Fulcrum server.

[Pmalek]

Why does Electrum 4.5.8 ignore manually-entered servers & refuse to switch from the connected node in the list, with Select server automatically unchecked?

I didn't have those problems when I did it. In fact, it was the other way around for me. Electrum didn't connect to electrum.labrie.ca when I pasted the port as well. The orb in the bottom right remained red. So I went into the network settings and deleted the port part. I got connected to the server then and Electrum added the port settings on its own.

I cannot safely upgrade to a higher version of Electrum without buying a new computer.

Buying a new computer or upgrading to a newer OS? If you don't mind me asking, why is that exactly? What's preventing you to perform the upgrade?

[TheButterZone]

I cannot safely upgrade to a higher version of Electrum without buying a new computer.

Buying a new computer or upgrading to a newer OS? If you don't mind me asking, why is that exactly? What's preventing you to perform the upgrade?

I am at the final supported version for my computer. I'm not going to risk bricking it, suffering any loss of original functionality, or having any internal data loss (even with a full backup on external hard drive) trying OpenCore, or to make it a Linuxtosh.

[Synchronice]

Wow, you are amazing! I often visit and check mempool.space. I noticed that transaction fees were regularly started with 0.20 sat/vByte and 0.30 sat/vByte. At first I thought that it was a glitch because I've seen the same before on Mempool and posted here, where I got told that it was a mistake because it's impossible to send transactions with lower than 1 sat/vByte fee. Now I see that what I noticed recently was not a glitch but reality and your tutorials are great for each wallet. I'm gonna test it on both, Electrum and Sparrow. Now it will be 5 times cheaper to consolidate my UTXOs with 0.20 sat/vByte.

[TheButterZone]

Wow, you are amazing! I often visit and check mempool.space. I noticed that transaction fees were regularly started with 0.20 sat/vByte and 0.30 sat/vByte. At first I thought that it was a glitch because I've seen the same before on Mempool and posted here, where I got told that it was a mistake because it's impossible to send transactions with lower than 1 sat/vByte fee. Now I see that what I noticed recently was not a glitch but reality and your tutorials are great for each wallet. I'm gonna test it on both, Electrum and Sparrow. Now it will be 5 times cheaper to consolidate my UTXOs with 0.20 sat/vByte.

There actually was a glitch a few days ago with mempool.space - it didn't show that the fee span for one block was actually 0.1 sat/vByte at the bottom despite multiple TXs at that. That block's info page eventually got corrected after I reported it, but I haven't looked at any more recent blocks to see if the span is staying correct.

[Pmalek]

I'm gonna test it on both, Electrum and Sparrow. Now it will be 5 times cheaper to consolidate my UTXOs with 0.20 sat/vByte.

Electrum will probably be easier for most people especially since we know now at least two servers that have been configured properly to support below 1 sat/vByte transactions, plus there is mempool.space for broadcasting a previously signed transaction. With Sparrow Wallet, it's a bit more challenging. If you have your own node, you can update its settings and connect to it via Sparrow. But can Sparrow connect to all public Electrum nodes? I never tested it.

[potatotom]

I also wonder how to do it in bitcoin core... (with the GUI, haven't tried command line)... it just jumps back to 1sat/vbyte...

[Pmalek]

I also wonder how to do it in bitcoin core... (with the GUI, haven't tried command line)... it just jumps back to 1sat/vbyte...

Bitcoin Core was the first client that supported below 1 sat/vByte transactions but since I don't use it and have no experience with it, I can't comment on the steps to get it to work either. Your node and software settings have to be configured to relay such transactions. Read the last 5 pages of this thread starting with this post. You will find info how to edit your Bitcoin Core's config file there.

[stwenhao]

I also wonder how to do it in bitcoin core... (with the GUI, haven't tried command line)... it just jumps back to 1sat/vbyte...

Just change the bitcoin.conf file. After reloading the client, you should be able to even make 0.001 sat/vB from GUI, sign it, and broadcast it, if you want. Another thing is if that low fees will be confirmed.

Here is how you can do that: https://bitcointalk.org/index.php?topic=5528323.msg65010827#msg65010827

Code:

minrelaytxfee=<choose_your_fees>

Probably consolidation and multisig types of transactions would benefit the most.

As we can see in practice, it is not the case, and there are just cheaper Ordinals and NFTs. And it didn't surprise me.

Also, some people set minimal relay fees to zero, so they accept even free transactions, so that nodes can be used as a free relay, and can be DoSed to some extent.

[Pmalek]

Just change the bitcoin.conf file. After reloading the client, you should be able to even make 0.001 sat/vB from GUI, sign it, and broadcast it, if you want. Another thing is if that low fees will be confirmed.

It probably won't be confirmed or relayed by many other nodes. What it will do is make your transaction become the lowest possible priority for miners. Right now there are 45-50vMB of unconfirmed transactions sitting in mempools according to data from Jochen Hoenicke. A transaction paying 0.001 sat/vB would be at the bottom of that list unless you can get a miner to include it in a block they mine before its time comes. And the majority of all other new unconfirmed transactions would pay more than you.

The average person would just be wasting time and end up with a stuck transaction that needs to be RBF-ed. Not even all miners have agreed to include 0.1 sat/vByte transactions in their blocks, so I wouldn't go lower than that right now.

[LoyceV]

I also wonder how to do it in bitcoin core... (with the GUI, haven't tried command line)...

I'm too lazy to edit config files, so I start Bitcoin Core with these options:

Code:

bitcoin-qt -minrelaytxfee=0.000001 -mintxfee=0.000001

[stwenhao]

It probably won't be confirmed or relayed by many other nodes.

Confirmed? Sure, miners won't take that dust, if they have transactions with bigger fees. But relayed? Let's see:

Code:

$ bitcoin-cli getpeerinfo | grep minfeefilter
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,

There are a lot of nodes, which declare to accept free transactions. Of course, a lot of them are probably not mining anything, but only relaying it.

However, if free, or low-fee transactions would be widely relayed by a lot of nodes, and they would be open for modifications, then guess what: users could use that kind of communication channel, to batch a lot of low-fee transactions into some bigger fee transactions, and then broadcast it to the miners.

But of course, allowing free transactions unconditionally means, that if all of these node operators are vulnerable to some DoS attacks. Unless of course they put some protections, and after accepting for example N free transactions, they stop accepting next ones, or they require a minimal Proof of Work inside some transaction, or something like that. But this is hard to detect, you can only see declared fees, it is hard to discover, if all of these nodes are really vulnerable, or if they just declare to be.

The average person would just be wasting time and end up with a stuck transaction that needs to be RBF-ed.

Note that RBF rules depends on fees. And guess what happens, if allowed fees are set to zero, and how RBF works in that case.

Not even all miners have agreed to include 0.1 sat/vByte transactions in their blocks, so I wouldn't go lower than that right now.

Why not, if there are a lot of nodes, accepting such transactions?

[potatotom]

I also wonder how to do it in bitcoin core... (with the GUI, haven't tried command line)...

I'm too lazy to edit config files, so I start Bitcoin Core with these options:

Code:

bitcoin-qt -minrelaytxfee=0.000001 -mintxfee=0.000001

Thanks, i was missing the mintxfee... haven't seen that mentioned anywhere... works now !

[LoyceV]

But relayed? Let's see:

Here's my overview:

Code:

bitcoin-cli getpeerinfo | grep minfeefilter | sort | uniq -c
     51     "minfeefilter": 0.00000000,
      1     "minfeefilter": 0.00000001,
      1     "minfeefilter": 0.00000010,
      1     "minfeefilter": 0.00000100,
     67     "minfeefilter": 0.00001000,
      1     "minfeefilter": 0.00005000,
      2     "minfeefilter": 0.09170997,

I didn't expect so many nodes to accept zero-fee transactions. I guess these settings were created before miners started accepting 0.1 sat/vbyte transactions.
The last 2 in my list are interesting: maybe they're trying to reduce RAM usage?

Not even all miners have agreed to include 0.1 sat/vByte transactions in their blocks, so I wouldn't go lower than that right now.

Why not, if there are a lot of nodes, accepting such transactions?

I've set my node to accept a minimum of 0.1 sat/vbyte. Miners are the gate keepers to blocks, so I don't see the point of going lower if miners ignore it.

[stwenhao]

Miners are the gate keepers to blocks, so I don't see the point of going lower if miners ignore it.

The point is to send partially signed transactions, and have them batched. If you have "Alice -> Bob" transaction with low fees, and then you see "Bob -> Charlie" transaction, also with low fees, then by making, and signing "Alice -> Charlie" transaction, you can increase the fee rate, while preserving all amounts.

Also, if some transaction is open for modifications, then you can add more inputs or outputs, and make one transaction with higher fees, by batching everything. In this case, fees can be low for users, but high in final transactions, confirmed inside blocks. Because there are separate settings for minimal fees for transactions put inside blocks, and minimal fees for relayed transactions.

[LoyceV]

The point is to send partially signed transactions, and have them batched. If you have "Alice -> Bob" transaction with low fees, and then you see "Bob -> Charlie" transaction, also with low fees, then by making, and signing "Alice -> Charlie" transaction, you can increase the fee rate, while preserving all amounts.

Realistically, who's going to do that if there's no GUI-wallet that can easily create such transactions? If the average (or even advanged) user has to manually do this, the risk of making mistakes isn't worth the few cents saved on transaction fees.

[stwenhao]

who's going to do that if there's no GUI-wallet that can easily create such transactions?

That's why it should be non-interactive, then miners could do all of that automatically. But as long as it is not the case, having it semi-automated is still an improvement. And if it is not worth doing, then it simply means, that savings, counted in single satoshis, are not yet big enough, to be worth implementing it. But in the future, it may be, because then, more virtual transactions with low fees could be batched into real transactions with high fees, and confirmed every 10 minutes.

[Pmalek]

There are a lot of nodes, which declare to accept free transactions. Of course, a lot of them are probably not mining anything, but only relaying it.

Your client would then have to be connected to some of those nodes because if it isn't and you are only connected to nodes that won't relay such transactions, your low-fee transaction won't propagate and spread around the network.

Not even all miners have agreed to include 0.1 sat/vByte transactions in their blocks, so I wouldn't go lower than that right now.

Why not, if there are a lot of nodes, accepting such transactions?

But will mining nodes of Foundry, AntPool, F2Pool, AntPool, etc., etc., accept those transactions? If not, then it doesn't really matter what some nodes accept.

[stwenhao]

But will mining nodes of Foundry, AntPool, F2Pool, AntPool, etc., etc., accept those transactions?

If you are not a miner, then probably not.

If not, then it doesn't really matter what some nodes accept.

If your transaction is not signed with SIGHASH_ALL, then it matters, because other nodes can change it, and batch many transactions into one, or solve your "sighash puzzle", and broadcast it on-chain.