You sent someone 0.1 BTC and also paid some fee. That couldn't be covered using a single input worth 0.1 BTC.
For example, if you had sent 0.9 BTC, the transaction could be made either using the input worth 0.1 BTC or using two inputs.


That's the change and it was sent back to you.

The total value of inputs was 0.13679383 BTC.
0.1 BTC of that was sent to the recipient, 0.00025896 BTC of that was paid as transaction fee and the remainder (0.03653487 BTC) was sent back to you as change.

Nodes accept the replacement transaction even if the fund is sent to different address(es).

According to BIP125, the replacement transaction must have at least 1 same input as the original transaction and it must pay sufficient fee.
BIP125 rules don't say anything about outputs.

Each time you receive bitcoin, you recieve a coin which can't be split into smaller parts without making a transaction and must be spent in full.

Assume that you have received two bitcoin transactions and you have two coins now. The coin A  is worth 1 BTC and the coin B is worth 0.5 BTC.
If you want to make a transaction sending someone 1.2 BTC, your transaction will have two inputs and two outputs. One of the outputs will be owned by the recipient and the other one will be the change and will be owned by yourself.
If you want to make a transaction sending 0.2 BTC, you don't have to use both coins A and B and you can use either of them.

We already have electrum seed phrase which doesn't rely on any fixed wordlist.
Unlike BIP39 seed phrase, you can always derive the correct private keys from an electrum seed phrase even without knowing the wordlist used for generating the seed phrase.

Regardless of the transaction has been flagged as RBF or not, you should never accept an unconfirmed transaction.

Take note that even non-RBF transactions have been always possible to get invalidated and with full RBF, it's now more risky to accept unconfirmed transactions.

Even if you run your node, enable full RBF and broadcast the replacement transaction using your own node, that doesn't guarantee a good propagation of your transaction.
For the replacement transaction to be propagated well, your node needs to be connected to nodes that have enabled full RBF.

There are nodes that have enabled full RBF.
Any node that has enabled full RBF treats all transactions as RBF-enabled and accept the replacement transaction, even if the original transaction has not been flagged as RBF.

Most probably, more and more nodes will enable full RBF in the future.

I tried to find your transaction in some block explorers and none of them had your transaction.
So, it seems that your transaction has not been broadcasted at all and it's displayed only in your wallet.

Right-click on your transaction and see if there's "abandon transaction" option. If so, click on it and after that, you will be able to make a new transaction.

My point was that if the private key had been leaked and multiple people had access to it, there would be probably someone making a non-RBF transaction.
There are many wallets that don't flag transactions as non-RBF.


With full-RBF, it's possible to replace the transaction with a new one even if it hasn't been flagged as RBF, but I doubt there's any SPV wallet allowing doing so.

If you want to replace a non-RBF transaction with a new one, you need to broadcast it using your own node or build the raw transaction and use a tool with enabled full RBF setting. That's not easy for everyone.

With using RBF feature, you can replace a transaction with a new one paying higher fee. But in CPFP, you make a new transaction spending the fund received in the unconfirmed transaction.
In CPFP method, you don't make any replacement.


Maybe, the private key had been compromised and there were some people competing to steal the fund.
But if I had the private key of someone's address and I wanted to steal the fund, I would make a non-RBF transaction.

I just submitted the second transaction to ViaBTC free accelerator successfully. It will be likely confirmed in the next block mined by ViaBTC.
ViaBTC has around 11% of the total hashrate and it's estimated that they mine 1 block in every ~ 90 minutes on average.

They are in sat/vbyte. Miners prioritize transactions based on the fee paid for each virtual byte of data and that's why the numbers displayed in that table should be in sat/vbyte.
It doesn't make sense to give estimate of the required fee rate in sat/byte at all.

You are right. There is no doubt it's more profitable to include the transaction paying 1350 sat/vbyte.
But the question is will nodes relay that transaction and will other mining pools receive that? I doubt it.

There's a big probability that a mining pool includes the original transactions and I think that's a risky game.


I am not saying it's not possible to play such a game.
It's even possible that the bad mining pool play the game more dishonestly, but as I said it can be so risky.

Let's say I am running a mining pool and I benefit from high fees. My mining pool owns 25% of the total hash power and we can mine 1 block in every 4 blocks on average.
I broadcast 1000 transactions with the fee rate of 100 sat/vbyte. Each transaction includes 100 inputs and they have created some long chains of unconfirmed parents.
I have made some  transactions with 1 input and 1 output that can invalidate all those 1000 transactions. If my mining pool manage to find a block and those 1000 transactions are less than x vMB from the tip of the mempool, I will include the 1 input-1 output transactions in the blockchain and invalidate all those 1000 transactions.



A correction to your calculations:

67 of those transactions.
Each block can contain up 1 vMB of transactions.

Right.
Now miners are including transactions with the fee rate of around 120 sat/vbyte in the blockchain. A few hours ago, the required fee rate for getting confirmation was more than 200 sat/vbyte.


The CPFP transaction was made with the fee rate of 242 sat/vbyte.
It increased the effective fee rate to 123 sat/vbyte and that was enough for the transaction getting confirmed.

Unless you (the mining pool) manage to find a block and include the replacement transaction, you will still lose a big amount of money.

According to BIP125, the fee paid for the replacement transaction must be greater than the total fee paid for all the transactions that are evicted from the mempool after the replacement.

Let's say I have made a transaction with 100 inputs and 100 outputs with the fee rate of 100 of sat/vbyte and now I want to replace that with a transaction with 1 input and 1 output.
Even if I use the fee rate of 250 sat/vbyte for the new transaction, almost all nodes will reject it.

It's not possible to submit this transaction to ViaBTC free accelerator.
They don't accept transactions larger than 500 bytes for free acceleration. Your transaction size is 563 bytes.

Edit:
Your transaction was just confirmed with the help of a CPFP transaction.

Do you have control over the receiving address? Does it belong to a non-custodial wallet or you got it from a custodial service like an exchange?

If you have full control over the receiving address (which means that you own it private key), you can use CPFP method.
CPFP means spending the fund received in the unconfirmed tranaction in a new transaction with high fees, so that miners include both transactions in the same block.

We don't set the transaction fee in dollars. We set the fee rate which is in sat/vbyte and that's what miners prioritize transactions based on.
The total fee you pay for a bitcoin transaction equals to fee rate (in sat/vbyte) * virtual size of the transaction (in vbyte).

Miners include up to 1 vMB of transactions in each block.
Assume that there are 0.5 vMB of transactions with the fee rate of 100 sat/vbyte. If you set the fee rate to 100 sat/vbyte, your transaction will be likely confirmed in the next block. If you set the fee rate to 150 sat/vbyte, you waste your money.

For fee estimation, I always use jochen-hoenicke website. The tool allows me to analyze the mempool by myself.


They refer to different address types.
For example, With using segwit addresses instead of legacy addresses, you can decrease the (virtual) size of your transaction and pay less fee.


That's not the correct use of trust system.

The maximum value you can set for the nlocktime is 4,294,967,295 (0xFFFFFFFF in hexadecimal system)
That's equivalent to February 7, 2106 6:28:15 AM.


it may worth mentioning that nodes reject any transaction with a locktime into the future.
If you have a transaction with a locktime into the future, you have to wait until its locktime and after that you will be able to broadcast it.


We don't know how much fee rates will be required for getting confirmation in the future.
If the fee is low, as mentioned above by Charles-Tim, you will need to do CPFP after broadcasting the transaction in the future.

To add to o_e_l_e_o's reply:

With increasing the fee rate of the CPFP transaction to 250 sat/vbyte, you would increase the effective fee rate of your transactions to around 48 sat/vbyte.
Now, such amount of fee rate would put your transactions around 0.5 vMB from the tip of the mempool and would likely give you fast confirmation.

Note that that the required fee rate may increase or decrease before you read this post.