What happens to transactions in stale shares or orphaned blocks that end up on a minority chain?

"What happens to transactions in stale shares or orphaned blocks that end up on a minority chain?" If any transactions in the orphaned block weren't [also] in the block that replaced it, they go back in the mempool. Every node will remove the transactions that actually were [included in a mined block]. If a block is orphaned or the chain reorganises, then all the transactions go back in the mempool, unless they are on the [majority] chain. Generally speaking, if you have two blocks that get mined near simultaneously, one of those blocks... will be successful and the other one will eventually get orphaned. As a result, that block will have its transactions replayed. Most of those transactions will coincide. Two blocks mined at approximately same time may have 90-95% of the same transactions. The five percent or so that didn't [make it] need to go back in the mempool for inclusion in the next block. Nothing is lost though, they just wait a bit longer. It would be the same as if they didn't have sufficient fee. If they [weren't] picked in that round, they will get mined eventually.

I submitted a small transaction to send BTC to another address. It has been pending for over a week. I was testing to see if I could send a transaction for the lowest fee of one satoshi per byte. I'm afraid the transaction is stuck and cannot be double-spent with a higher fee; the wallet gives me an error that says the transaction is already in the mempool.

"Andreas, I submitted a small transaction to send BTC to another address. It has been pending for over a week." "I was testing to see if I [could] send a transaction for the lowest fee of one satoshi per byte." "I'm afraid the transaction is stuck and cannot be double-spent with a higher fee; the wallet gives me an error that [says the transaction is already] in the mempool." "Is there anything I can do to cancel my transaction, or will I have to wait... until it drops off the mempool in order to resend it with a higher fee? Thank you." All right, great question. This is a really important question that affects a lot of beginners in Bitcoin. What you are experiencing is a combination of... a mempool -- a marketplace for [prioritising transactions through fee competition] -- and your own wallet, which may have certain policies and approaches to how transactions are done, that may not be ideal. First of all, is it possible to send a one-satoshi-per-byte fee? Absolutely. [In] every single transaction I do, I pay one satoshi. I have not paid more than one satoshi per byte since February. It is absolutely possible to send [transactions] with one satoshi per byte [as the fee]; those do get confirmed. However, in order to do that, I'm using a wallet that gives me options for managing the narrow cases. [For about] one in ten transactions, I will have a problem where it gets stuck, just like you have experienced here. When that happens, my wallet gives me two ways to un-stick that transaction.

My wallet gives me two ways to un-stick transactions (RBF and CPFP)

The first one is called replace-by-fee (RBF). My initial transaction is marked as RBF, meaning it can be replaced by a [similar] transaction with a higher fee. [The initial transaction may] not be the final version of that transaction, if you like. There may be subsequent transactions that spend [the same UTXO] with a higher fee. By doing that, it is just an extra signal to the miners, who can choose to take a [replacement transaction instead], if your wallet can create it. Regardless of whether it's replace-by-fee or not, miners will use an algorithm that maximises profit. If they have two transactions [in the mempool], and one of them is a double-spend of a previous transaction... with a higher fee than the first (which hasn't been confirmed), they will take the higher fee. It doesn't matter if you are signalling RBF or not, although some miners will look for RBF transactions... and if there is a replacement transaction, their algorithm will treat them favorably. [These techniques] are really about your wallet knowing how to manage that double-spend situation. The other technique is called Child Pays For Parent (CPFP). Again, this is not a magical feature that tells miners what to do. It is simply recognizing that miners will maximize their profit and take the transaction(s) with the highest fee. Child Pays For Parent says, "My first transaction doesn't have enough fee per byte to confirm; [here is] a second child transaction, with a higher fee, that depends on spending the first one." What the miner's algorithm will do is select transactions from the mempool [based on] the satoshis per byte... in each chain of unconfirmed transactions. If you have a parent [transaction] and a child [transaction], their total satoshi fees... are divided by the total bytes. The miner's algorithm can make a determination, in their best interest, that if they confirm both of them together, they can get a better satoshi-per-byte rate. If they don't confirm the first one, you can't confirm the second one. Again, Child Pays For Parent is a technique used by the wallets, recognising that miners' transaction selection algorithms will be based on maximising their profit. The wallets I use, Samourai and Electrum for example, tend to support these capabilities. You can manually construct a Child Pays For Parent (CPFP) transaction if your wallet isn't allowing it.

Back to your question: you are afraid the transaction is stuck and cannot be double-spent with a higher fee...

Back to your question: you are afraid the transaction is stuck and cannot be double-spent with a higher fee, because the wallet gives [you] an error that it is [already] in the mempool. That doesn't mean it cannot be spent [with] a higher fee, that means your wallet is refusing to do it. If you manually construct a double-spend transaction with a higher fee, using another wallet that supports it, [the transaction] will go through [to] the mempool. The way I do transactions, I always start with the lowest fee possible and mark the transaction as replace-by-fee. I let it sit in the mempool. If it is urgent and I have a fifteen minute window because I am doing a retail transaction, I will check on it and I might bump it immediately if I miscalculated the fee. If it's not urgent and I [can wait] a day [for it to confirm]... For example, today is September 1st. I am about to run payroll, which in my company is bitcoin. I am about to [send] a bunch of transactions, multi-recipient transactions, where I pay my staff. Those are the kind of transactions that don't need to [be confirmed] the next fifteen minutes. As long as it goes through today or early tomorrow, it is good enough. That means I have a 144 block window. I don't need to worry about the fee. One satoshi per byte will work. If by some weird coincidence, the moment I decide to [send it] there is a massive rally... or the mempool [becomes] absolutely full, I might have to bump it. I will replace my fee. I use Child Pays For Parent, which sometimes works faster, to confirm the transaction and get my payroll through. You