from link above 140 sats has a back log of about 2 blocks so it is iffy that you can get a tx sent at 140 sats
8 blocks, not 2 blocks.
According to the first chart, if you set the fee rate to 140 sat/vbyte, you should wait for at least 8 blocks.
Note that each block can include up to 1 vMB of transactions.
--------------
I couldn't understand how you got those numbers.
Here are my calculations for the case the fee rate used for the transaction is 200 sat/vbyte.
1 legacy input and 1 legacy output: 191 sat, 38,200 sat
1 legacy input and 1 nested segwit output: 189 sat, 37,800 sat
1 legacy input and 1 native segwit output: 188 sat, 37,600 sat
1 nested segwit input and 1 legacy output: 135 vbyte, 27,000 sat
1 nested segwit input and 1 nested segwit output: 133 sat, 26,600 sat
1 nested segwit input and 1 native segwit output: 132 sat, 26,400 sat
1 native segwit input and 1 legacy output: 112 sat, 22,400 sat
1 native segwit input and 1 nested segwit output: 110 vbyte, 22,000 sat
1 native segwit input and 1 native segwit output: 109 vbyte, 21,800 sat
I used my trezor set it to 1 sat and set it to 200 sats. custom fees
editbut you do bring up a good point.
all tests used a bc1 address
to legacy >>>>>>>>>>> address is 14xxx but with a 1 to start
to legacy segwit >>>>>>> address is 3xxxx with a 3 to start
to segwit >>>>>>>>>>> address is bc1xxxxx with a bc to start
there are so many ways to do a send.
there are 3 kinds of addresses.
so empty the input address and it was a 1 input address already merged
send all to 1 address
this means 1 input 1 output
but since there are 3 types of addresses that nine kinds of sends for the simplest send
next 1 input 2 outputs.
all my examples are using a trezor with 1 input address and 2 output addresses.
Ie an address with say 0.12345678 btc sends 0.1 to a seller of whatever. so he is send 0.1 to the seller and 0.023xxxxx back to his own wallet but a different address.
I only showed that with a:
segwit (bc1) to a {segwit (bc1) my change back address} and the sellers segwit address
segwit (bc1) to a {segwit (bc1) my change back address} and the sellers legacy segwit address
segwit (bc1) to a {segwit (bc1) my change back address} and the sellers legacy address
So simple send combinations
are 1 in fully merged and 2 out 9 kinds
are 1 in fully merged and 1 out 9 kinds
so there are 18 simple sends (never mind LN)
once you deal with complex sends it is pretty much infinite variation of what pay will be.
Ie 5 unmerged in a bc1 fully paid 50/50 to 2 outputs.
or 5 unmerged in a bc1 fully paid 33/33/33 to 3 outputs
pretty much endless payout rules. I could write 500 different combos.
which means LN needs to be easy peasy it is not
the blockchain for now needs to restrict dust payments.
Or use LTC and Doge.