Full RBF

[BlackHatCoiner]

What would be the odds of a mining pool trying to replace the mined block and take the puzzle money for themselves?

Foundry USA currently has access to approximately 28% of the hashrate. This means that it has 39% probability to successfully rewrite the entire previous block and mine another one on a row. Therefore, they have two choices.

• Either continue honestly, with 28% chance of mining the next block and earning 3.125 BTC, or
• Gamble the hashpower of 2 blocks, with 39% chance of success, earning about 10 BTC.

Theoretically, it's worth the gamble, even though I haven't worked on the exact math behind it. However, in practice, destroying reputation like that is a suicide.

[vjudeu]

Theoretically, it's worth the gamble, even though I haven't worked on the exact math behind it.

It is possible to publicly announce SHA-256 of the public key, and get it deeply confirmed, and announced everywhere. Then, if any mining pool will try to overwrite a valid block, there will be a strong, publicly-verifiable evidence, that they did it.

Because the solver can announce for example "OP_RIPEMD160 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 OP_EQUALVERIFY <solverPubKey> OP_CHECKSIG", and get it deeply confirmed, without trusting anyone, and without touching the puzzle. And then, everyone can see, if the reward from the puzzle was first moved into "solverPubKey" or not.

[LoyceV]

Foundry USA currently has access to approximately 28% of the hashrate. This means that it has 39% probability to successfully rewrite the entire previous block and mine another one on a row.

Somehow this probability is always larger than I'd expect intuitively. Your answer seems to be correct:

(image source: learnmeabitcoin.com)

It is possible to publicly announce SHA-256 of the public key, and get it deeply confirmed, and announced everywhere. Then, if any mining pool will try to overwrite a valid block, there will be a strong, publicly-verifiable evidence, that they did it.

Because the solver can announce for example "OP_RIPEMD160 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 OP_EQUALVERIFY <solverPubKey> OP_CHECKSIG", and get it deeply confirmed, without trusting anyone, and without touching the puzzle. And then, everyone can see, if the reward from the puzzle was first moved into "solverPubKey" or not.

Being the first to solve the puzzle is meaningless if someone else beats you to getting their transaction confirmed. Someone else could have solved the puzzle between the time you took to create this transaction, and broadcast the real one.

[BlackHatCoiner]

Somehow this probability is always larger than I'd expect intuitively.

Remember that if Foundry turned evil, it'd "migrate" its hashrate elsewhere. Therefore, the network would have less hashrate without noticing.

It become even larger if you skip the "mine another block on a row". Foundry has 58% chance to re-write an alternative chain by simply re-writing the most recently mined block (1-conf). However, most of the nodes will have already accepted another chain, and probably most pools will be mining on that other chain. Therefore, they won't accomplish anything by rewriting the previous block. They need to rewrite the previous and mine one on top, so that everyone accepts this chain.  

[DaveF]

Somehow this probability is always larger than I'd expect intuitively.

Remember that if Foundry turned evil, it'd "migrate" its hashrate elsewhere. Therefore, the network would have less hashrate without noticing.

It become even larger if you skip the "mine another block on a row". Foundry has 58% chance to re-write an alternative chain by simply re-writing the most recently mined block (1-conf). However, most of the nodes will have already accepted another chain, and probably most pools will be mining on that other chain. Therefore, they won't accomplish anything by rewriting the previous block. They need to rewrite the previous and mine one on top, so that everyone accepts this chain.  

And then what. Would other pools just stand there and take it or would they put a filter in that looks for foundry in the Coinbase tag and invalidate those blocks.
AntPool and Via and F2 would crush Foundry out of existence if they really tried that.
People would be screaming on both sides about it, but if any pool ever tried it would not last long.

-Dave

[LoyceV]

AntPool and Via and F2 would crush Foundry out of existence if they really tried that.
People would be screaming on both sides about it

I'm not sure yet on which side I'd be screaming. On the one hand, replacing a valid block for profit is bad, but on the other hand, ignoring the longest chain to keep mining a shorter chain is also bad. I'm not sure yet which is the worst.

[BlackHatCoiner]

And then what. Would other pools just stand there and take it or would they put a filter in that looks for foundry in the Coinbase tag and invalidate those blocks.

Practically speaking, they wouldn't have done this beforehand, so when Foundry mines two blocks on a row and creates a longer chain, their full node software would automatically switch to that. At least, I'm not aware of a mining pool which has altered their node software for that particular case; makes no sense.

AntPool and Via and F2 would crush Foundry out of existence if they really tried that.

Followed by their reputation. No sane miner would mine on a pool that wants to crush other mining pools out of revenge.

On the one hand, replacing a valid block for profit is bad, but on the other hand, ignoring the longest chain to keep mining a shorter chain is also bad. I'm not sure yet which is the worst.

Ignoring the longest chain for the sake of ethics is one of the most destructive ideas. Bitcoin is based in a game theory, and it shall be based in this forever.

[NotATether]

Full RBF will be enabled by default (for all users who haven't explicitly turned it off) in the next Bitcoin Core release, v28.0.

https://github.com/bitcoin/bitcoin/pull/30493

[ABCbits]

Full RBF will be enabled by default (for all users who haven't explicitly turned it off) in the next Bitcoin Core release, v28.0.

https://github.com/bitcoin/bitcoin/pull/30493

I guess this is last blow to 0-conf TX which used to be accepted by merchant. On a side note, i didn't expect not enabling full RBF reducing advantage of compact block.

[nc50lc]

I guess this is last blow to 0-conf TX which used to be accepted by merchant.

Those centralized wallet and casinos that require KYC could still pull it off because it's easy to punish any attempt to game their "feature"
since the account is tied to the user's identity, it's not just the IP address or account that can be banned.

Plus since all of those that accept 0-conf deposits are centralized, the wallet/casino will lose nothing if withdrawals require confirmations on the deposit
aside from "free bets" in casinos (by replacing the deposit in losing bet) which is already part of the risk even before full rbf.

[NotATether]

I guess this is last blow to 0-conf TX which used to be accepted by merchant. On a side note, i didn't expect not enabling full RBF reducing advantage of compact block.

Is anyone else besides casinos even accepting 0-conf transactions now?

I'd be surprised if there were any left, now that it is exceedingly cheap to send sats via Lightning Network, with many merchants adopting that now. And regarding that, the only problem is somehow receiving them back in order to re-balance your channels to enable you to send more sats.

[LoyceV]

Full RBF will be enabled by default (for all users who haven't explicitly turned it off) in the next Bitcoin Core release, v28.0.

I'm very curious to see what this is going to do to funds sent to compromised addresses. I expect RBF between several parties to lead to almost 100% of the funds being burned as mining fees.

[BlackHatCoiner]

I'm very curious to see what this is going to do to funds sent to compromised addresses. I expect RBF between several parties to lead to almost 100% of the funds being burned as mining fees.

I don't think so. If that were the case, couldn't you DDoS the network by simply double spending with 0.01 sat/vb increments each time? There has to be a standard limit.

[LoyceMobile]

I don't think so. If that were the case, couldn't you DDoS the network by simply double spending with 0.01 sat/vb increments each time? There has to be a standard limit.

I think there's a minimum increment. That doesn't matter for compromised private keys: if 12 bots are fighting for the money, they have nothing to lose.

[hosseinimr93]

I don't think so. If that were the case, couldn't you DDoS the network by simply double spending with 0.01 sat/vb increments each time? There has to be a standard limit.

I think there's a minimum increment. That doesn't matter for compromised private keys: if 12 bots are fighting for they money, they have nothing to loose.

Yes, there is a minimum increment
According to BIP125, the increase in fee can't be less than the virtual size of the replacement transaction × the minimum relay fee rate.

Assuming the relay fee rate is 1 sat/vbyte and the replacement transaction has the same virtual size as the original transaction, the fee rate must be increased by at least 1 sat/vbyte.

[satscraper]

I don't think so. If that were the case, couldn't you DDoS the network by simply double spending with 0.01 sat/vb increments each time? There has to be a standard limit.

I think there's a minimum increment. That doesn't matter for compromised private keys: if 12 bots are fighting for they money, they have nothing to loose.

Yes, there is a minimum increment
According to BIP25, the increase in fee can't be less than the virtual size of the replacement transaction × the minimum relay fee rate.

Assuming the relay fee rate is 1 sat/vbyte and the replacement transaction has the same virtual size as the original transaction, the fee rate must be increased by at least 1 sat/vbyte.

The virtual size of replacement transaction must not be equal to that one relevant to original trx. Let's say one will double   the size of replacement transaction (by choosing more UTXOs for instance). Then following the formula you have mentioned the fee rate must be increased  by at least 0.5 sat/vbyte. Is this correct?

[BlackHatCoiner]

According to BIP25

You probably meant BIP125.

The virtual size of replacement transaction must not be equal to that one relevant to original trx. Let's say one will double   the size of replacement transaction (by choosing more UTXOs for instance). Then following the formula you have mentioned the fee rate must be increased  by at least 0.5 sat/vbyte. Is this correct?

In BIP125, it says:

The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.

If TX_A is 500 bytes paying 1 sat/b, and TX_B is 1000 bytes, it must pay 1 sat/b + 500 sat = 1500 sat in total, which would be 1.5 sat/b. However, I'm not sure if the exact same proposal takes effect with Segwit.

[ABCbits]

I guess this is last blow to 0-conf TX which used to be accepted by merchant.

Those centralized wallet and casinos that require KYC could still pull it off because it's easy to punish any attempt to game their "feature"
since the account is tied to the user's identity, it's not just the IP address or account that can be banned.

Plus since all of those that accept 0-conf deposits are centralized, the wallet/casino will lose nothing if withdrawals require confirmations on the deposit
aside from "free bets" in casinos (by replacing the deposit in losing bet) which is already part of the risk even before full rbf.

Fair point, although how many services would risk that considering cheater might try cheat with fake identity.

I don't think so. If that were the case, couldn't you DDoS the network by simply double spending with 0.01 sat/vb increments each time? There has to be a standard limit.

I think there's a minimum increment. That doesn't matter for compromised private keys: if 12 bots are fighting for they money, they have nothing to loose.

And in such case, most of the stolen coin goes to miner as TX fee.

[satscraper]

According to BIP25

You probably meant BIP125.

The virtual size of replacement transaction must not be equal to that one relevant to original trx. Let's say one will double   the size of replacement transaction (by choosing more UTXOs for instance). Then following the formula you have mentioned the fee rate must be increased  by at least 0.5 sat/vbyte. Is this correct?

In BIP125, it says:

The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.

If TX_A is 500 bytes paying 1 sat/b, and TX_B is 1000 bytes, it must pay 1 sat/b + 500 sat = 1500 sat in total, which would be 1.5 sat/b. However, I'm not sure if the exact same proposal takes effect with Segwit.

Can not get you calculations.  In my understanding A (having 500 bytes and 1 sat/b)  pays 500 sats . B (having 1000 bytes) should pay at  least the same 500 sats for consumed bandwidth,  thus fee rate for it may be as low as 0.5 sat/b  . Did I misunderstand something in  math?

[hosseinimr93]

According to BIP25

You probably meant BIP125.

Yes, it was a typo. Thanks for the correction.

Can not get you calculations.  In my understanding A (having 500 bytes and 1 sat/b)  pays 500 sats . B (having 1000 bytes) should pay at  least the same 500 sats for consumed bandwidth,  thus fee rate for it may be as low as 0.5 sat/b  . Did I misunderstand something in  math?

The transaction B must pay 1000 satoshi more for its own bandwidth and since the transaction A paid 500 satoshi, it should pay at least 1500 satoshi in total.
So, as mentioend above by BlackHatCoiner, the fee rate for the replacement transaction must be at least 1500/1000 = 1.5 sat/vbyte.