Quote from: o_e_l_e_o on March 07, 2019, 02:14:50 PM

Quote from: figmentofmyass on March 07, 2019, 07:55:12 AM

you don't need to double spend (in the mining sense) to screw them over if they accept zero confirmations. you just need to use a simple script to re-spend the same outputs with a higher fee before the first transaction gets confirmed.

My understanding, and correct me if I'm wrong, is that to re-spend the same outputs with a higher fee, the transaction has to be opted in to RBF.

nope, RBF has no effect on zero confirmation security as peter todd eloquently pointed out a few years ago: https://twitter.com/peterktodd/status/686365181241212928

it won't work 100% of the time because of how some miners process transactions on their side. some pools will perceive it as a double spend and refuse to mine it. but it's easy to do and is very possible to confirm the double spent transaction. businesses accepting zero confirmations are straight up reckless!

Quote from: o_e_l_e_o on March 07, 2019, 02:14:50 PM

That is to say, the transaction must have an nSequence of less than MAX-1. Provided the transaction does not have an nSequence of less than MAX-1, the transaction cannot be replaced in the time between broadcasting and confirming. Any sender accepting zero confirmation transactions would include a stipulation that these transactions could not be opted in to RBF, which would prevent this vector of attack. This doesn't prevent other more complicated "double spend" mechanisms, of course.

this is just the nsequence signalling logic from bip125. not flagging RBF =/= the inputs can't be double spent. there is nothing at the consensus level that would prevent a double spend from being mined.