Damn, was about to post my NACK with reasoning and then core locked the post 10 seconds before I posted it :(
I'll post here so it doesn't go unsaid somewhere lol
NACK.
I appreciate all the considerations laid out in the mailing list post but I don't see it as a reason to revert the move toward progress that has already been in motion with the RC.
However, it seems to me that similar problems exist for such a protocol
even in a fullrbf world...
Just because other problems and DoS vectors exist with Lightning and transaction pining, doesn't mean that we can't try to remove them one step at a time. I think you make a great argument about why it helps but doesn't stop it. Are you proposing that we delay until we fix those problems, which you later make the argument that we'll never really fix because user policies can always disable things like transaction v3? It gets to the point where you're arguing that policies don't really matter in the end and that any effort toward progress is pointless. To be fair, I don't know if transaction v3 is good enough to solve our problems or not and I think your thought experiments around -disable_v3_transaction_enforcement is interesting and should be a consideration as devs make progress towards it but I feel like it's a different issue that full RBF shouldn't be pinned to as a reason for not going forward with it.
Does fullrbf offer any benefits other than breaking zeroconf business
practices? If so, what are they?
You can't break what is already broken. These were terrible assumptions to begin with. If you want instant transactions with delayed settlement, there's a thing called Lightning.
To start with, let's chat about why this doesn't change anything for them. If their arguments for why it's necessary revolve around the fact that they can do proper risk assessment and manage it appropriately, that doesn't change. Let them continue to do their risk assessment. There's still going to be a % of users that may decide to double spend given X amount of sats.
Secondly, I find the original motivation for this change coming from Muun to be overstated and a use case that should not be advocated for. There's a difference between a merchant delivering a product on 0 conf and Muun providing 0 conf submarine swaps with the illusion that they are atomic. They are not and they are lying to their users, there's nothing atomic about them when it's 0 conf. Furthermore, there are many ways that their model is both unsustainable and insecure. There are plenty of ways to steal money from them regardless of 0 conf. I bring it up as an example of why users and use cases may be wrong in general, so why not rip the bandaid off now? You agree it should happen eventually, why not happen when it's at the top of everyone's minds and also to prevent other businesses in the future from falling trap to the illusions given by non-RBF and non-RBF companies?
The 0-conf risk is negligeable completely LOW RISK, as the attackers have no incentive to do it for low value trxs, and it is in no one's authority to restrict such flexibility to merchants who accept the risk for customer convenience. Why for instance sybil attack never happened and it is a likely risk suddenly? This is about FLEXIBILITY on-chain, always independent from any L2. LN may become outdated but Bitcoin must stay resilient, IMMUTABLE and flexible. Others must addapt to Bitcoin, that should stay STABLE with few to minimum but fixing changes. This is NOT A BUG. BITCOIN IS FINE. There is currently a "Bitcoin Hub" that is out of control and keeps pushing non-bug fixing CHANGES to Bitcoin like in this proposal 24.0. Bitcoin Devs should not even, due to obvious bias, be involved AT ALL in PROMOTING non-bug fixing CHANGES. DOING NO CHANGE WHATSOEVER to Bitccoin and continue to allow 0-conf is good for Bitcoin and Satoshi as I understood also considered such 'risk' as very low. So why the proposal for a CHANGE at all present in this useless CHANGE proposal 24.0 on that (pardon my French skills) that restricts merchants to continue having a seamless on-chain/LN option for their users only great for more hyperbitcoinization with minimum to NO proven risk, to which acceotcance should be SOLELY at the acceptance criteria of the users?
@petertodd irrespective of node rbf mempool policies, is it possible to construct and sign a transaction, perhaps with some clever choice of sighash flags, which in practice makes the transaction irreplaceable?
Thank you for sharing your perspective, @petertodd.
For folks not knowledgeable enough about this topic like me:
This article from BuyBitcoinWorldwide.com provides a good summary about RBF (Replace By Fee).
-disable_v3_transaction_enforcementis interesting and should be a consideration as devs make progress towards it but I feel like it's a different issue that full RBF shouldn't be pinned to as a reason for not going forward with it.