Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime

2022-11-10 Thread David A. Harding via bitcoin-dev
On 2022-11-07 11:17, Peter Todd via bitcoin-dev wrote: We can ensure with high probability that the transaction can be cancelled/mined at some point after N blocks by pre-signing a transaction, with nLockTime set sufficiently far into the future, spending one or more inputs of the transaction

Re: [bitcoin-dev] Refreshed BIP324

2022-11-10 Thread Pieter Wuille via bitcoin-dev
Hi, Thanks for the comments so far. I think these are all reasonable ideas. Comments inline below. On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote: > From what I understand we'll have about 35 message types on the network > with the addition of BIP324. 256 possible IDs sounds like

Re: [bitcoin-dev] Merkleize All The Things

2022-11-10 Thread Salvatore Ingala via bitcoin-dev
Hi ZmnSCPxj, Bram, Peter, David, Thanks for all your comments; replies below. On Tue, 8 Nov 2022 at 13:01, ZmnSCPxj wrote: > Modulo bugs, operator error, misconfigurations, and other irrationalities > of humans. > I agree that making footguns impossible is a much more difficult problem to

Re: [bitcoin-dev] On mempool policy consistency

2022-11-10 Thread yancy via bitcoin-dev
I read Antoine's original post on this and got the general gist, and here also, it makes sense, but I'd like to ask: is it necessary that (B, C) in the above not *see* A's opt-out "pre-replacement" (inputs: A1, outputs: A, fees: low; call it TX_2)? I get that they cannot replace it Is it

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

2022-11-10 Thread ZmnSCPxj via bitcoin-dev
Good morning ArmchairCryptologist, > --- Original Message --- > On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > I mean, if you think the feedback is wrong, that's different: maybe we > > shouldn't care that