Transaction fee should be "per byte" instead of "per kilobyte".

[Skybuck]

After many many many years I try to send a bitcoin transaction.

I had to set the fee manually, because automatic was not working.

For whatever reason I felt it was natural to express the transaction fee in "per byte".

Thankfully I checked again and noticed, the bitcoin core software displays "per kilobyte".

I was also under the impression that it showed "per b" or "per kb" but now that I look again it seems to be "per kilobyte".

There are some issues with "per kilobyte".

1. It's easy to overlook.
2. The windows operating system always shows everything in bytes for file sizes.
3. BTC is shown in smallest form 0.00000000 so this it's not using milli satoshi but simply satoshi so to speak, the smallest unit is possible, so the brain will be tricked into believing bytes are also set in it's smallest form.
4. Not everybody knows what a kilobyte is, it's a hard to use number: 1024.
5. Setting it per kilobyte requires some kind of division, which is harder to do.

Mempool website seems to show transaction fees in "per vbyte".  Sometimes for large values it seems to show "per kvbyte".

Anyway I've been observing the mempool space website, and I have seen many transactions where the ammount to transfer is small, and the transaction fee is unusually large, much larger than needs to be, so as far as I am concerned this is a clear issue with the bitcoin software and many people are making mistakes with it, it should be looked at.

I feel this is a bit scammy in it's current form... to easy to make a mistake.

It should be more clear what it is calculating, perhaps even given an estimate of many usd dollars or euros it is.

I am concerned, because I do believe many people are losing a lot of bitcoin, because for the first time in a long time, they are trying to transfer it to an exchange to try and sell it, now that bitcoin is near an "all time high" !

Furthermore there were some issues with the software which slightly shocked me, but was somehow solved:

1. The address formats have changed many kinds, not all compatible.
2. Software was not capable of performing transactions: "not enough keys in keypool" or something.

The solution seemed to be: "update/upgrade wallet" or something... and refill keypool.

First time I try these commands in console window, it returned null, must also first give in bitcoin wallet password, I tried restarting the latest bitcoin software after a few times it seemed to work and the key pool was refilled.

Fortunately I have access to Microsoft Copilot and it was able to help me and suggest the following commands to fix the problem:

1. walletpassphrase "password" timeoutInseconds

(Kinda akward command, pass+phrase, must type it in correctly, first one/two times I made typoes.

I was not sure if " " was necessary so I tried both.

2. upgradewallet

apperently version can be specified, but I left it out.

3. keypoolrefill

I did not set a new size...

I was a little bit disappointed the return is simply "null" this could be better...

The address type for my addressed was apperently P2PKH. The destination address is something with bc1 in the front of it, not sure what it is called... I don't see it in the filter from mempool, but it has something to do with segwit.

Fortunately I got lucky and/or the software and exchange is compatiblity/capable of handling this automatically, few, I would have hated it if I had lost fraction of bitcoins because of address format incompatibility.

Right now there are at least 125000 transactions waiting to be processed.

The fastest transactions/best block are paying between 14 and 302 sat/vB.

The second best block are paying 12 sat/vB.

The third block are paying 12 sat/vB.

OK, I payed 16 sat/vB. but increasing the transaction fee 3 times, so in total there are 4 transactions performed by the software.

To increase transaction fee, again copilot helped me and said to "right click" the pending transaction and choose "increase transaction" fee otherwise I would not have known how to do it...

It would have been more intuitive to simply click the transaction and somehow "open" it and then simply adjust the parameters... but apperently it must be done with a pop-up menu.

I found it a bit akward how it increase it automatically.

I also found it akward how it does not allow a label per different try.

I tried to label them from, roughly:

+0.00005000 BTC
+0.00010000 BTC

What then surprised me is it goes to
+0.00015000 BTC

I expected it to "double" but apperently it did not, which is kinda nice.

This set the sat/vb at a very competitive 16 sat/vb !

Which I just found out the transaction was processed and is now in this block:

https://mempool.space/nl/block/000000000000000000027a328fbd130718b803e6a725255aec235a97e8158cc9

Apperently mined by f2pool:

Hash   ‎000000...8158cc9
Tijdstempel   ‎2024-03-07 20:07:36 (9 minuten geleden)
Grootte   ‎2.01 MB
Gewicht   ‎4 MWU
Health
100%
Vergoedingbereik   15 - 446 sat/vB
Gemiddelde vergoeding   ~18 sat/vB US$ 1,70
Totale vergoedingen   ‎0,255 BTC US$ 17.268
Subsidie + vergoedingen   ‎6,505 BTC US$ 440.168
Gedolven door   F2Pool

Verwachte Blok

   
Totale vergoedingen   ‎0,261 BTC
Gewicht   ‎3.99 MWU
Transacties   2419
Werkelijke Blok
   
   
Totale vergoedingen   ‎0,255 BTC -2.05%
Gewicht   ‎4 MWU +0.15%
Transacties   2397 -0.91%

^ Dutch !


Well very interesting experience so far ! Maybe you can figure out which transaction it was based on my details ! LOL.

Lot's of fun to watch this mempool block thing in action. I do wish it was possible to find the exact yellow block by transaction id... I just had to move my mouse around and had to find it manually... there was no other way to find it in the visualization.

There is a search box which allows to find transaction details though, but it does not link back to the visualization in the block. The visualization was a bit akward it seems to change after a refresh of the webpage and the block was somewhere else.

The visualization is a bit weird/akward, hard to understand where is what. Apperently the most valuable transactions are to the right and maybe to the bottom, it seems to be inconsistent with already mined blocks where it's horizontall instead of vertically or maybe I saw that wrong.

Apperently blocks/transactions get pushed out into "slower/less profiteable" blocks.

I have a question about these yelllow blocks still to be mined though:

1. Are they all mined in parallel, or only the fastest one ?

One more question though, I just checked the exchange.

It has received one transaction, the otherwise are still "pending/awaits to confirm" what will happen to the other transactions with less fees ? I guess these could be "flagged" as double spend attempts ?!

I assume these transactions will eventually be removed/dropped from the mempool ? I think the original one was already dropped, because a block explorer could not find it anymore, however the mempool website could still see it ?!

I also hope that using the replace-by-fee feature does not flag me as a "double spend" attemptor !

Bye for now,
  Skybuck.

P.S.1: Maybe later I add some screenshots to show this website in action for historal purposes, it might be gone in a few years, I do have some screenshots on disk of this event... but I am eating sandwiches right now and have to go back to eating =D

P.S.2: All in all I am happy to see that bitcoin after many years with old wallet is still working ! One must also make absolutely sure to not forget the wallet password, otherwise it's going to be a hassle !

[Mia Chloe]

Transaction fee should be "per byte" instead of "per kilobyte".

Who said it isn't?. The fees you pay depend on how much block space your transaction occupies and that block space is measured in sat/ byte.
If you are saying sat / kilobyte, you are still saying same thing as sat/1000 bytes. Byte is just a measurement scale for digital data and sat/byte is used for Blockchain because of the relatively small size of individual transactions compared to the whole block. If you make use of sat/ kilobyte you will end up with decimals which could get messed up and confusing unlike whole numbers you get when you make use of sat/byte. A whole block besides can't exceed 5mb which actually contains 5000000bytes so it's easy to be used as a way of expressing thousands of transactions that occur in a single block.

It's almost similar to why nowadays people just prefer to say 1mBTC instead of saying 0.001BTC. Decimals can be a bit messy sometimes.

[Skybuck]

Transaction fee should be "per byte" instead of "per kilobyte".

Who said it isn't?.

The Bitcoin Core GUI displays under "custom": "per kilobyte".

Apperently you are oblivious to this as well ! =D

[vjudeu]

4. Not everybody knows what a kilobyte is, it's a hard to use number: 1024.

Fee is counted per 1000 bytes, not 1024.

5. Setting it per kilobyte requires some kind of division, which is harder to do.

It requires just moving a comma by three decimal places.

It should be more clear what it is calculating, perhaps even given an estimate of many usd dollars or euros it is.

In practice, you can set any fee in satoshis, exactly to a single satoshi. Which means, if your transaction takes 500 bytes, you can set 500 satoshi as a fee, but you don't have to jump from 500 to 1000 satoshis, and you can use for example 501 satoshis per this transaction instead.

1. Are they all mined in parallel, or only the fastest one ?

Each mining pool creates its own block. Which means, that some website can show you a candidate block #1 and #2, but an actual block can contain some transactions from the first, the second one, and even some custom transactions, added manually by that pool, and not broadcasted before at all. Those unconfirmed blocks are only predictions, nobody knows, how the final block will look like, until it is mined, and broadcasted.

what will happen to the other transactions with less fees ?

If some transaction is not picked by any mining pool for whatever reason (for example too low fee), then it just stays unconfirmed.

[ABCbits]

Thankfully I checked again and noticed, the bitcoin core software displays "per kilobyte".

Rather than creating this long thread, why don't you ask such feature or submit a pull request on https://github.com/bitcoin-core/gui ?

I also hope that using the replace-by-fee feature does not flag me as a "double spend" attemptor !

RBF and full-RBF are the norm these days.

[Skybuck]

Fee is counted per 1000 bytes, not 1024.

User don't know that... another problem...

It requires just moving a comma by three decimal places.

Moving a cursor is relatively easy, knowing where to put the cursor/comma, that is the problem.

In practice, you can set any fee in satoshis, exactly to a single satoshi. Which means, if your transaction takes 500 bytes, you can set 500 satoshi as a fee, but you don't have to jump from 500 to 1000 satoshis, and you can use for example 501 satoshis per this transaction instead.

Another problem with the current client is: The user has no idea how large the transaction will be, is it really that hard to compute and show it in the GUI

The problem is with the confusion, there are a couple of possibilities:

1. User believes the fee is in bytes, user makes an assumption: transactions are 1000 bytes on average.

Given these two beliefs/variables the user enters:

0.00000001 BTC to start with.

However the user is then confused with the "per kilobyte" which says 0.00001000 and wonders what this is ?

Then user is further confused... should he/she put in the total or indeed per byte ?

The whole per byte thing does not make much sense ?! Why not enter a total number and let the give compute what it results in per byte, perhaps round it and multiply it back up... at least this way the user has some idea what he/she getting himself/herself into. Excuse my exclusion of AI/sentients and other genders lol.

Anyway.

2.  User believes the fee is in kilobytes and has to do some weird calculation... maybe ends up dividing the number by 1024 or more likely multiplieing it...

User sees: 0.00001000, think this is per byte, thinks that is not enough and types in some random number cause he/she in a haste.

Anyway setting this fee requires a lot of technical know-how,insight and clear mind and manipulating a tiny tedius edit box, doing BTC calculations to dollars, investigating other websites to see what the going rate is, yadadada.

*** HERE IS A BETTER IDEA FOR THE TIME BEING ***:

Instead of all this nonsense do the following:

1. Consult with miners with fee should be, via a protocol.

2. Consule with exchange what the current price is for BTC in dollars and/or euros or any other currency.

3. Allow to set fee in dollars or euros and calculate into BTC.

Conclusion:

Bitcoin should stop isolating itself from the rest of the world and integrate itself somewhat with the real world and the old financial system...

Bitcoin should become aware of the dollar and the euro and other currencies and play nice with it.

There is really no reason why not too.

In the future when all FIAT currencies collapse the currencies can be removed.

Or even cutier:

Have a protocol to query some server to see if these currencies still exist.

Yes there is some centralization concerns here, but that would be somewhat minor, allow peer to set different exchanges and such.

The current way of setting fees should stay present as well, in case the old automatic mode and this new fiat currency to btc mode fails.

^ This would be a lot nice, the core of bitcoin core will remain p2p and decentralized.

Or another idea it to integrate a little button which leads to a form for a "fee calculator" and show extra information about the transaction, and here also dollar and euro prices could be shown for BTC and the transaction fee etc, so that user gets some idea of what he/she is doing.

A last by not least, the user should also be able to choose out of:

1. Set fee per byte.
2. Set fee per kilobyte.
3. Set fee per megabyte.

Also a kilobyte should be 1024, makes no sense to deviate into 1000. This is about storage space on blockchain, not network bandwidth persee.

Each mining pool creates its own block. Which means, that some website can show you a candidate block #1 and #2, but an actual block can contain some transactions from the first, the second one, and even some custom transactions, added manually by that pool, and not broadcasted before at all. Those unconfirmed blocks are only predictions, nobody knows, how the final block will look like, until it is mined, and broadcasted.

This cannot be correct, the blocks have different prediction times and different fees, those are future blocks, probably from a single pool. I still wonder if they all compute in parallel on a single pool ?

If not, what is the use of these predictions ? Is this perhaps some dynamic knap sack problem ? Is it to include new high value transactions ? Is that even possible ? I guess so, for hashing transactions could be re-selected until a difficulty hash is found, maybe this reduces their chances of finding one faster or perhaps not/opposite, at least it gives them better value.

If some transaction is not picked by any mining pool for whatever reason (for example too low fee), then it just stays unconfirmed.

This is unstatisfactory answer, eventually it should be removed from the mempool, otherwise systems would run out of memory, or new transactions cannot be entered into the mempool, full.... unless some are processed into blocks... but it seems new transactions enter faster than those that are processed/recorded.

Also makes little sense to keep transactions which are already encounted for in the blockchain in another form... so makes no sense to keep "double spends" in memory pool/unconfirmed, unless it gives a higher transaction fee and blocks can be rolled back and re-computed, so called "bribery attack"

[Skybuck]

Rather than creating this long thread, why don't you ask such feature or submit a pull request on https://github.com/bitcoin-core/gui ?

To describe my experience from programmer perspective and very infrequent bitcoin user. Many people hodl and thus it's likely they not very experienced with the GUI.

I'd rather discuss it with some people to see what they think about my story/experience/description and suggestions to see if they like it or not, instead of wasting programmer/developer time in case it's not a good idea.

Also to warn and see what others think about this feature in bitcoin.

As far as I know I am the only person in the world to send 1 / 100.000.000 bitcoin over the network, and back then I complained I got robbed by 0.0005 transaction fee, which at the time was set automatic, and would now be worth 34 bucks or so (at a price of 68000). Prophetic vision/rant it was. Now it's much much much worse according to https://mempool.space/nl/

I believe my rant may have led to this custom transaction fee option... hmmm...

Also why did the automatic transaction fee mode fail ? Any idea ?

Now it does seem to work... maybe it needed some blocks of some kind of confirmation ? But since I don't send any blocks there was nothing to confirm ? The blockchain was already synced ? So I found that weird a few day ago when I did all of this...

Right now it recommends: 0.00029671 BTC/kvB

Kinda sucks how this value cannot be copy/pasted or further modified...

I see it has a confirmation time target, this is apperently how fast it wants to confirm the transaction... could have been named a little bit different:

"Confirmation speed" or something

I also hope that using the replace-by-fee feature does not flag me as a "double spend" attemptor !

RBF and full-RBF are the norm these days.
[/quote]

I wonder if mines also allow transactions to be re-send which are already recorded in the blockchain ! =DDD and then re-mine blocks and perform "bribery attack/reward".

It might become a thing of the future or even now, since the halving is coming.

Example:

Transaction 1:
User A sends 100 million to exchange with a transaction fee of normal fee.


User A sells 100 million on exchange.

Transaction 2 (re-send transaction 1, double spend attack):
User B sends 100 million back to itself, with a transaction fee of 1 million

Very tempting for miner to re-mine transaction 2 and pocket 1 million in transaction fees.

That is also why I am a little bit suspicious of high transaction fees.

Could also be an investigation by possible hackers to see how miners behave !

[vjudeu]

makes no sense to deviate into 1000

The block size limit in bytes is one million (1 MB), not 1,048,576. And the witness size limit in bytes is four million bytes, so 4 MB. Sticking with 1000 makes more sense, because if you pick 1024, then you will see strange limits, like for example 976.5625 kiB, or 3,90625 MiB. Also, when it comes to used amounts, it is more likely that someone will manually pick 1,000 satoshis as a fee, than 1,024 satoshis.

But the most likely reason is just about fractions: if you have satoshis per byte, then you need to use numbers like 1.23. If you have satoshis per kilobyte, then you can stick with whole numbers, like 1230. But personally, I prefer just putting the total amount per transaction in satoshis, and going into feerate later, after seeing transaction size.

Is this perhaps some dynamic knap sack problem ?

Yes, of course it is. Bitcoin mining is NP-hard

Is it to include new high value transactions ?

Yes, in theory, you can look at your mempool, or see some predictions, given by some website, send your transaction, and have it never confirmed, if people will constantly pay higher fees than you, and get their transactions confirmed faster, knocking your transaction out of the next candidate block.

maybe this reduces their chances of finding one faster or perhaps not/opposite, at least it gives them better value

1. Hashing the block is not easier or harder, if you include more or less transactions. You always hash 80-byte block header, and just some 32-byte merkle root hash is changed, if you change any transactions. Even changing the order of transactions can change the merkle root.
2. Today, the basic block reward is still quite significant, but in the future, the system will be based only on fees alone, and then, it will be more important, than it is now.

eventually it should be removed from the mempool

By default it is, but you cannot force people to "forget" what you broadcasted, if it is valid. Which means, that anyone can re-broadcast your transaction forever, and then it will never be forgotten.

but it seems new transactions enter faster than those that are processed/recorded

It depends. Sometimes it is the case, sometimes not. When it is, then fees are going up, and then people stop making new transactions, because it is too expensive. And then, the flow of new transaction slows down, and mempools are cleared, as more and more transactions are confirmed.

so makes no sense to keep "double spends" in memory pool/unconfirmed

It depends on each node individually. Old rules said "first-seen-safe". New rules, based on full-RBF, just keep the transaction with the highest fee. But any node operator can apply any rules to its own node. As I said: each mining pool create its own candidate block, and then the 80-byte block header is passed to the miners. Which means, after each block, there are N different candidates, and only one of them is finally mined, when it goes below the target hash.

I believe my rant may have led to this custom transaction fee option... hmmm...

You can set any fee you want. If you create a transaction with no fee, and sign it, then it will be valid. It may be non-standard, and many nodes may not accept it, but the transaction will be valid. More than that: you can create a transaction with negative fee, that will have different sighashes than SIGHASH_ALL, and will be open for modifications, like additional inputs and outputs, which will not invalidate existing signatures.

Many things are possible, just some of them are not yet reachable from GUI. But they can be created in console.

Also why did the automatic transaction fee mode fail ? Any idea ?

I don't know. I simply assume it never worked correctly, and I always pick all amounts, coins, addresses, and everything else manually. But maybe there is a way to use it as intended.

Very tempting for miner to re-mine transaction 2 and pocket 1 million in transaction fees.

There is nothing new. If some transaction is unconfirmed, then it cannot be trusted. But there are legitimate use cases for replacements like that, for example if you have Alice->Bob transaction, which is unconfirmed, and then you have Bob->Charlie transaction, which is also unconfirmed, then it is possible to create Alice->Charlie transaction, preserve all fees, and get a smaller transaction (which will increase the fee rate, because of decreased transaction size).

Since full-RBF is enabled, everything can be replaced, if it has just some higher fee. Which means, you cannot trust unconfirmed transactions. And when it comes to confirmed ones, then "coinbase coverage" seems to be a good estimate. Which means, if the block reward is 6.25 BTC plus fees (so for example 7 BTC in a particular block), then if you send 7 BTC or less, you probably can stick with one or two confirmations. And, in the same way, if you send 70 BTC, you would need something like 10 blocks, to be 100% sure, that it is set in stone, and that reversing it is no longer worth it.

[potatotom]

It should be more clear what it is calculating, perhaps even given an estimate of many usd dollars or euros it is.

In practice, you can set any fee in satoshis, exactly to a single satoshi. Which means, if your transaction takes 500 bytes, you can set 500 satoshi as a fee, but you don't have to jump from 500 to 1000 satoshis, and you can use for example 501 satoshis per this transaction instead.

I don't see this is possible. You cannot provide a "blanket fee". you can only provide a fee per vbyte. Not sure if you work with PSBT then perhaps you can, I'm not sure.

1024 is now what's called a "kibibyte", or 'KiB". A kilobyte traditionally was always 1024 but the definition has changed a while ago. I normally now just default to 1000 bytes when I hear kilobyte. I blame hard drive vendors for this, you always get less than they advertise for! (they use kb, nob KiB).

Actually in bitcoincore it's very simple to see the fee per vbyte as there is a thousands separator (a space). Not sure I can paste images here. seems can't.

https://paste.ec/paste/iqaJ2Ckj#TJ94EoDy-7B4uvd0hPiNTpbp34MeQV3IHY1VDWZ4j1F

Cheers!

[vjudeu]

I don't see this is possible.

From GUI it may not be possible. But if you manually pick all amounts, then it is perfectly valid.

Some example: https://mempool.space/tx/000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51

As you can see, not only transaction fee is set to 31,337 satoshis, but also this transaction was mined on CPU, because it starts from nine leading zeroes.

Another example: https://mempool.space/tx/16b51459cf0811b1babfe333b5dd53eaf7769c7b7b87c996b52ff2da180c4030

See? Transaction fee set exactly into 10,000 satoshis. Which means, that it is possible to use exact amounts, if you really want to do so. (note that if someone would use 29 satoshis per byte, the fee would be something like 9997 or 9998 satoshis, because transaction size is 344.75 vBytes and 587 bytes, and those are not-so-round numbers).

[ABCbits]

I also hope that using the replace-by-fee feature does not flag me as a "double spend" attemptor !

RBF and full-RBF are the norm these days.

I wonder if mines also allow transactions to be re-send which are already recorded in the blockchain ! =DDD and then re-mine blocks and perform "bribery attack/reward".

It might become a thing of the future or even now, since the halving is coming.

Example:

Transaction 1:
User A sends 100 million to exchange with a transaction fee of normal fee.


User A sells 100 million on exchange.

Transaction 2 (re-send transaction 1, double spend attack):
User B sends 100 million back to itself, with a transaction fee of 1 million

Very tempting for miner to re-mine transaction 2 and pocket 1 million in transaction fees.

That is also why I am a little bit suspicious of high transaction fees.

Could also be an investigation by possible hackers to see how miners behave ! 

1. All exchange these days require few confirmation before the deposit is confirmed.
2. If it's centralized exchange or they exchange BTC or fiat, the criminal will leave lots of trace.
3. Double-spend attack don't rely on RBF or full RBF.