4

There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but ...


4

Since the very beginning. Transactions have had the nLockTime field since Bitcoin 0.1.0.


4

To illustrate this let's imagine the mempool as big vertical list of transactions. Let this list be ordered by the feerate each transaction is paying, the higher the feerate the higher the transaction in the list. Miners will under normal circonstances take the highest virtual MB of transaction in this list/queue. This website is a good visualizer of this ...


4

The flaw in your thinking is that you assume your transactions will be confirmed. That is not the case. There is no guarantee that a transaction will ever be confirmed, and in fact, if the fee is too low, it is almost guaranteed that the transaction will never confirm. You should care because the person you are sending Bitcoin to cares that it confirms. You ...


4

So far, Bitcoin Core rebroadcasting is a wallet-level responsibility. Transactions that aren't relevant to any of the Bitcoin Core's internal wallet are not rebroadcast at all. There is work to change that: https://github.com/bitcoin/bitcoin/pull/21061. This makes sense, as right now, observing a rebroadcast is a very clear sign that the transaction belongs ...


3

Welcome to Bitcoin. The "balances" in Bitcoin are actually explicitly tracked bits and pieces. You can think of it akin to the coins and bills of cash: when someone sends bitcoins, the transaction explicitly states which coins or bills get spent, and describes which new ones to create. We call these bits of bitcoin unspent transaction outputs (...


3

Zero-confirmation transactions are inherently unsafe to be considered as completed payments. It is not possible to create a tool that could give a truly reliable indication of whether or not an unconfirmed transaction will in fact confirm (or not). If it were possible to reliably predict such a thing, we wouldn't need a blockchain record in the first place.


3

Do they just get rejected? No, they will just wait for another block to be included in. Note that transactions have a time to live in the mempool of 336 hours (configurable using the maxmempoolexpiry startup option).


3

$ src/bitcoin-cli getmempoolentry ed45c837d26c25fb6a763708376a87f1875ff57efbb0f56d1b26d00a16c1899e { "fees": { "base": 0.00012042, "modified": 0.00012042, "ancestor": 0.00125452, "descendant": 0.00012042 }, "vsize": 224, "weight": 896, "fee": 0.00012042, ...


2

If I had seen Andrew's great reply earlier, I would probably spared myself from writing an explainer on Reddit, but now that I did I'll post it here as well, hoping that it might complement this thread, as it is targeted more at beginner level folks. In the last days we have been experiencing a sharp rise in price, which is historically correlated with many ...


2

You are likely being scammed. An address remains valid and usable forever as long as its private key is accessible. If any service is generating and deleting private keys, it is run by completely incompetent people and should not be used. The "Delay of network" argument is equally baseless - if they have received the coins, they are in sync with the ...


2

While calculating the Transaction fee miners usually take Ancestor size into the account. But does the descendant/Output also effect the transaction fee calculation? The descendant transaction(s) do not restrict the inclusion of the examined transaction in a block, while the ancestor transaction(s) do. Hence, it would seem rational for the miner to only do ...


2

Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well. When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (...


2

Transaction selection is the prerogative of miners, and specific behavior in regard to unconfirmed transactions cannot be enforced on the network as it precedes the consensus mechanism (block creation). Therefore, as chytrik states, it's completely up to the miner who succeeds at creating the block. However, in December 2020, the prevalent transaction ...


2

On an uncongested network with an average tx fee of ~20 cents. Which transaction would most likely go through? The transaction which confirms is the one chosen by the miner which finds the next block. There is no way to know which one they may choose. It may be the first one they saw, or it may be the one with the highest fees, or it may depend on some ...


2

The maximum unconfirmed descendant count is a mempool setting, not a wallet one. Assuming most of the network run with the default of 25, even if you changed your own mempool to accept a longer chain the last child transaction would not relay. Anyways, in such an extreme case (a chain of >25 unconfirmed transactions) you likely want to bump your fees ...


2

Ledger Wallet doesn't support RBF but you can do Child Pays For Parent: Make a transaction to your address 3M6EhQL3QUQHAFkSPH3vLc3VDCrJKP3iMv with amount 0.011, set a fee rate, preview the transaction and check and confirm the transaction only if one of the inputs is 0.01187067 BTC. If this doesn't work, download Electrum and CPFP from there. But honestly, ...


2

Assuming most of the nodes on the network run with the default configuration of maxmempoolexpiry, most of the network mempools will drop your transaction after 336 hours (2 weeks). You should have crafted your transaction such that it signals BIP125 replaceability (by having at least one of the input nSequence <= 0xfffffffd). At this point, you could use ...


2

I assume that you are actually asking about the order in which miners include transactions into their block template. Miners will group each transaction grouping them its ancestry. The effective fee rate of such a transaction group is Σ(fees)/Σ(size) over all transactions in the group. Let's assume there are two transactions waiting, A and B, where B is a ...


2

I'm predicting that this transaction will confirm in less than a week considering its relative feerate. Paid $4.26 on a $133 transfer - why unconfirmed? Because the input addresses are 1... addresses instead of the newer SegWit addresses bc1. By switching to a native SegWit addresses you may enjoy faster confirmation times at any constant feerate level. ...


1

That message means that the sender created two transactions that attempted to spend the same coins. This is called "double spending" and is not allowed. One of the two transactions has to be marked as invalid by any Bitcoin node that sees the two. I believe most Bitcoin nodes will initially set aside whichever they received last. Over a short time ...


1

How do miners choose the transaction(s)? However they want. Usually by picking the ones with the highest fees, but also sometimes picking ones that have been unconfirmed for the longest, sometimes prioritizing their own transactions, etc. Does the difficulty vary depending on the number of chosen transactions? No. If not, wouldn't it be advisable to ...


1

But this doesn't make sense to me... I assumed that transactions must be mined in the next block, since your transaction also includes the hash of the previous block in order to prevent double-spending. Is this assumption correct? This is not correct, the transaction does not reference blocks, it references outputs. A block references the previous block. To ...


1

This wouldn't be effective. Say I want to transfer value worth $100. How much is it reasonable to ask me to lock up and for how long? Maybe we could tolerate forcing me to lock up $200 for an hour. But I don't just have to do a double-spend. I can do a quintuple-spend. I can get $500 worth of value for me $100 payment and then, even if I forfeit an extra $...


1

Given two transactions that spend the same input, there is no way to know which one 'came first' or is the 'rightful' transaction. Because of this, it is very difficult to enforce a 'no double spend' policy in this way. How can you guarantee that you have the transactions ordered correctly? What happens if some nodes on the network see the transactions ...


1

How is it possible to guarantee a transaction against double-spend, expiration or other fraud before it is confirmed by the Bitcoin network? It isn't really possible in the absolute sense, but you can could perhaps create an insurance fund of sorts, to help provide guarantees against the rare occasion one of your customers is defrauded. However you ...


1

No it doesn't. Only the ancestor size is taken into account.


1

I can see the transaction here: https://blockchair.com/bitcoin/transaction/c4bea179e5e772b131c475f9030088b67dea5054a545713dc32458829fa61598 This is how you can visualize your transaction in a pool of other unconfirmed transactions with different fee rates: Miners prioritize transactions with higher fee rates from this pool to add in the blocks and thats how ...


1

Those are orphaned blocks, it means while you were mining that block someone else mined it faster than you, thus you do not get the credit for those mined blocks.


1

In this case, you would need to contact the ATM operator / service provider, and provide them with some proof of your purchase and the failed transaction. When completing your interaction with the ATM, you should receive some sort of receipt that details this information, though the exact specifics will likely vary from one ATM to another. If you are running ...


Only top voted, non community-wiki answers of a minimum length are eligible