Pages:
Author

Topic: Full RBF (Read 3060 times)

legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
October 05, 2024, 07:07:29 AM
And in such case, most of the stolen coin goes to miner as TX fee.
That's the beauty of it: it makes hunting compromised private keys futile Smiley

Yes, but people will still do it.



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

The other thing I still find interesting is looking at https://bitnodes.io/nodes/ and seeing how many old versions are still running out there.
We are talking about 28.0 now and yet more then 1/3 of the reachable nodes are on 25 or earlier.

What we don't know from that is how many are nodes that are used by people for transactions and how many are just sitting out there.

-Dave
hero member
Activity: 714
Merit: 1298
August 10, 2024, 02:51:30 AM

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.

Wow, completely forgot about A.  Grin Nevertheless that is not a rule punctually kept. Miners may  accept and include into block transaction with the feerate literally equal to zero. They do it sometimes when this involves either  their own transactions (RBF included) or payment receiving (in cash for instance) outside the blockchain.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
August 09, 2024, 06:55:06 AM
And in such case, most of the stolen coin goes to miner as TX fee.
That's the beauty of it: it makes hunting compromised private keys futile Smiley
legendary
Activity: 2380
Merit: 5213
August 09, 2024, 04:52:36 AM
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.
hero member
Activity: 714
Merit: 1298
August 09, 2024, 04:47:29 AM
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:
Quote
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?
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
August 09, 2024, 04:33:23 AM
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
August 09, 2024, 04:31:26 AM
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:
Quote
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.
hero member
Activity: 714
Merit: 1298
August 09, 2024, 04:15:23 AM
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?
legendary
Activity: 2380
Merit: 5213
August 08, 2024, 01:42:37 PM
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.
hero member
Activity: 1659
Merit: 687
LoyceV on the road. Or couch.
August 08, 2024, 01:11:49 PM
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
August 08, 2024, 12:59:23 PM
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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
August 08, 2024, 12:56:57 PM
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.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
August 08, 2024, 06:30:28 AM
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.
legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
August 08, 2024, 06:25:07 AM
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.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
August 08, 2024, 05:34:31 AM
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.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
August 08, 2024, 02:09:49 AM
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
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
May 04, 2024, 05:14:06 AM
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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
May 04, 2024, 03:07:25 AM
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.
legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
May 03, 2024, 03:23:09 PM
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
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
April 29, 2024, 04:03:08 AM
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.  
Pages:
Jump to: