12

Replace-by-fee means transactions spending the same coin to the same addresses are not considered double-spends by the network and are still relayed, as long as they pay a higher fee than the preceding transaction. Example: Alice pays Bob with a coin worth 1 BTC, sending 0.5 BTC to Bob, 0.49995 BTC to herself as change, and 0.00005 BTC to fees. Alice sees ...


7

In addition to Mark S.'s answer, since Bitcoin Core 0.12 there actually is an expiration in the mempool, which evicts unconfirmed transactions after N hours, where N is set by -mempoolexpiry, and defaults to 72 hours. This is not a reliable feature, as wallets (and really, anyone) can rebroadcast the transaction, but helps keeping the mempool fresh.


6

There are 3 cases. Case 1a: if Fee(Tx1) < Dust Fee then Tx1 gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx1 will never be committed to the blockchain, even though descendent transactions may or may not be accepted into the mempool of a subset of nodes in the network. Case 1b: if Fee(...


6

All three proposals attempt to solve the same problem, the issue of stuck transactions. Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have ...


5

According to an offshoot reply in bitcoin-talk it appears that the only mention of this protocol comes from Luke-Jr on Github. Another topic on bitcoin-talk mentioned that his pool, elegeius, implements this patch. https://bitcointalk.org/index.php?topic=173169.0 On the eligius FAQ page http://eligius.st/~gateway/faq/following-applies-transactions-being-...


5

No, it's not a matter of sending to the same address multiple times, rather, CPFP works by spending the output of a previous transaction in a second transaction with a higher fee. Example: An unconfirmed transaction A with 500B size paid 20000 satoshis fee which corresponds to a fee rate of 40 satoshis per byte. The transaction has two outputs: A:0 is ...


5

Right now, for the most part, Bitcoin miners follow a First-Seen-Safe rule: If 2 conflicting transactions show up in the mempool, the miner sticks with the one it saw first. Replace-By-Fee would enable miners to remove transactions from the mempool based on which transaction pays the higher fee. This is problematic because it enables fraud. If I pay a ...


4

To my knowledge there is not a widespread practice of miners to do this, but it certainly can be programmed. As transaction fees continue to rise and these type of stuck transaction become more of a problem I would expect more miners willing to scan the mempool and cross check inputs for use in later transactions (with higher fees). This CPFP concept ...


3

Because there must always be exactly one directly spendable output per party, in order to avoid one party to be able to "exhaust" the carve-out. With two CPFP-ble outputs, one party could both create a chain of descendants transactions on the first outputs so that it meets the standard mempool limits and then trigger the carve-out mechanism using ...


3

Bitcoin Core by default does not forward a transaction to its peers, when the full tree of its ancestor transactions contains more than 25 unconfirmed transactions or 101 kvB of unconfirmed transaction data. This limit helps curb spam attacks using long chains of unconfirmed transactions. Example1: If you have no unconfirmed transactions associated with ...


3

The newest version of bitcoin core 0.12 introduced a feature called replace by fee. This can be used to issue a transaction with a higher fee spending coins that have not yet been picked up in a block. This can be used to send funds in a stuck transaction to a new address and the hope is that by including a fee this will get picked up by the miners faster ...


3

Answer reposted from: How does first seen replace by fee work? Right now, for the most part, Bitcoin miners follow a First-Seen-Safe rule: If 2 conflicting transactions show up in the mempool, the miner sticks with the one it saw first. Replace-By-Fee would enable miners to remove transactions from the mempool based on which transaction pays the higher fee....


3

Very interesting brain teaser. I agree that this could be interesting in combination with CPFP. The sender could defer the transaction fees to the recipient which would probably be an interesting proposition for some services in the Bitcoin space. There are a few problems with negative fees from an operational perspective, though: The sender defers ...


3

It won't confirm because the grandparent and parent of your child transaction aren't confirmed. The grandparent transaction was also paid with a really low fee(51.573 sat/B). I did the math for you. Grandparent + parent + child = total transaction size: 3878 Bytes + 226 Bytes + 225 Bytes = 4329 Bytes Add up all paid fees: 200000 Sat + 200000 Sat + ...


3

If we run the getrawmempool true RPC, we can look at the data Bitcoin Core has for each of its mempool transactions. Here's an example: "3a0af489e500322159db85ad95174ffa3dd9924dbd0b68b041364a8c8eac03cc": { "size": 226, ...


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, ...


3

It sounds like you have rediscovered a mechanism called child pays for parent. Generally, no, two independent transactions could get included in any order even when they were sent from the same wallet or involve the same address. There is no efficiency benefit to reusing addresses, in fact it has significant downsides especially for privacy.—Miners will ...


2

The answer is getmempoolentry. https://chainquery.com/bitcoin-api/help/getmempoolentry


2

Does it also work the other way - that is, does transaction with high fee pays for child transaction that has low fees, given that they are both in the mempool? Or is the policy only "one way", from child to parent. The policy is one-way: the parent doesn't pay for the child. The child can't be included unless the parent is included, so effectively the ...


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

Only if the state changes fees are negotiated (and for mutual closing the channel) so in case the onchain fees change and the channel is not used for a long time just send a fake payment hash to adapt to onchain fees. Regarding 2 and 3. Nothing Alice can do. She just has to wait until the traffic on chain decreases. There are some ideas to include a dust ...


2

It depends on your wallet software. Some may simply refuse to create the transaction. Others will spend the change output of the unconfirmed transaction. CPFP and RBF typically only occur when you specifically request for it in order to increase the fee of an unconfirmed transaction. Wallets will not do this automatically for you.


1

I got a sweep TX (from a force closed channel) stuck, also due to low fees. This answer is inspired by OPs answer. I got it working with: lncli openchannel \ --sat_per_byte=${fees per byte for the funding transaction of the new channel} \ --min_confs=0 \ ${remote nodes id} \ ${local amount} The --min_confs=0 part is the important bit, it allows lnd to use ...


1

I solved the problem whit CPFP (children pay for parent). I used the unconfirmed change of the fund TX stuck in mempool to open a new channel. At the time of broadcasting TX the median fee is around 150sat/vb, so i chose to slight increase at 200 sat to ensure good probability to push the first fund tx and the second one in the next block avaible.


1

Seems like your 589 Sat/Byte went through now, however that transaction is not a double-spend of your 1st transaction because the total output Total Input amount is different. Transaction e9723fdf6c923a278304e7bffcd3089f4175dabf2ca1702516718195e005e5dd is also not a CPFP of the 3 transactions you mentioned above. If you want to attempt a CPFP on those 3 ...


1

In order for a node to relay a transaction, the transaction must satisfy the node's minRelayTxFee. This fee rate cut off is by default set to 1000 satoshi per kvB (= 1 satoshi per vbyte). Your first transaction could get included in a block if the miners were aware of it, but likely it doesn't reach them. You should try to either broadcast the first ...


1

(updated based on Pieter's comments below) There are (essentially) two sets of UTXOs at play. One is constructed from the blockchain itself, by reading the blocks on disk and updating with any new blocks that are broadcasted. This set is saved to disk, and can be reconstructed from the blockchain data if erased. Another UTXO set is the mempool itself. Each ...


1

The best way to get the change address is to check the transaction corresponding to the "known" address from your wallet from where the transaction was originated. Blockchain does not keep a track of the addresses it generates for change BTC for the wallet users. Also the blockchain wallet is BIP44 compatible which is basically a more standardized ...


1

Go to https://iancoleman.io/bip39/ and download the page to use it offline (you should never enter private keys into a website). Scroll down and choose the BIP 44 tab. In the text box next to "External / Internal", change the 0 to 1. You should then get all of your change addresses derived below.


1

If you're doing CPFP right, The two transactions you sent are both originating from the same UTXO, but one spends the output of the older transaction with a higher fee. If the miners want to get the fees of the last transaction ( the transaction with the higher fees), they will need to mine the first one aswell. So, if your first transaction gets processed ...


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