Full RBF | Bitcointalksearch.org

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: LoyceV on August 09, 2024, 06:55:06 AM

Quote from: ABCbits on August 09, 2024, 04:33:23 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

Yes, but people will still do it.

Quote from: NotATether on 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

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

satscraper

hero member

Activity: 714

Merit: 1298

Quote from: hosseinimr93 on August 09, 2024, 04:52:36 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.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: ABCbits on August 09, 2024, 04:33:23 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

hosseinimr93

legendary

Activity: 2380

Merit: 5213

Quote from: BlackHatCoiner on August 09, 2024, 04:31:26 AM

Quote from: hosseinimr93 on August 08, 2024, 01:42:37 PM

According to BIP25

You probably meant BIP125.

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

Quote from: satscraper on August 09, 2024, 04:47:29 AM

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.

satscraper

hero member

Activity: 714

Merit: 1298

Quote from: BlackHatCoiner on August 09, 2024, 04:31:26 AM

Quote from: hosseinimr93 on August 08, 2024, 01:42:37 PM

According to BIP25

You probably meant BIP125.

Quote from: satscraper on August 09, 2024, 04:15:23 AM

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?

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: nc50lc on August 08, 2024, 06:25:07 AM

Quote from: ABCbits on August 08, 2024, 05:34:31 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.

Quote from: LoyceMobile on August 08, 2024, 01:11:49 PM

Quote from: BlackHatCoiner on August 08, 2024, 12:59:23 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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: hosseinimr93 on August 08, 2024, 01:42:37 PM

According to BIP25

You probably meant BIP125.

Quote from: satscraper on August 09, 2024, 04:15:23 AM

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.

satscraper

hero member

Activity: 714

Merit: 1298

Quote from: hosseinimr93 on August 08, 2024, 01:42:37 PM

Quote from: LoyceMobile on August 08, 2024, 01:11:49 PM

Quote from: BlackHatCoiner on August 08, 2024, 12:59:23 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 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?

hosseinimr93

legendary

Activity: 2380

Merit: 5213

Quote from: LoyceMobile on August 08, 2024, 01:11:49 PM

Quote from: BlackHatCoiner on August 08, 2024, 12:59:23 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.

LoyceMobile

hero member

Activity: 1659

Merit: 687

LoyceV on the road. Or couch.

Quote from: BlackHatCoiner on August 08, 2024, 12:59:23 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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: LoyceV on August 08, 2024, 12:56:57 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.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: NotATether on 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.

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: ABCbits on August 08, 2024, 05:34:31 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.

nc50lc

legendary

Activity: 2618

Merit: 6452

Self-proclaimed Genius

Quote from: ABCbits on August 08, 2024, 05:34:31 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.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: NotATether on 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

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: DaveF on May 03, 2024, 03:23:09 PM

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.

Quote from: DaveF on May 03, 2024, 03:23:09 PM

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.

Quote from: LoyceV on May 04, 2024, 03:07:25 AM

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.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: DaveF on May 03, 2024, 03:23:09 PM

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.

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: BlackHatCoiner on April 29, 2024, 04:03:08 AM

Quote from: LoyceV on April 29, 2024, 02:25:30 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.

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

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: LoyceV on April 29, 2024, 02:25:30 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.

Topic: Full RBF (Read 3080 times)