BIP Draft: Anti-Fee-Sniping with LockTime

[nervana21]

Specifies the nLockTime anti-fee-sniping behavior that Bitcoin Core and Electrum already implement. BIP326 assumes these rules as the baseline and uses nSequence instead for some taproot spends. The nLockTime path itself was never specified.

Discussed on bitcoindev
https://gnusha.org/pi/bitcoindev/wWGWjMw9TI22vp4VzCm4xJJS3IGA1UhndMKynUkB04BqeoRjhe-QbDbJU-GMQq0nnOnXuB__u8KcdIcxU5i8Cy9pbTbtJ7Hi583FzLVojek=@pm.me/

[murchandamus]

Thanks for your submission. I like the idea to document Anti-Fee-Sniping as a BIP. This document is a good start, but it still feels a bit rough on the edges.

In some places you give advice that could be interpreted as implementation instructions in other sections than the Specification. Please make it clear whether these are implementation instructions or optional suggestions. If they are normative, they should appear in the Specification. If they are optional suggestions they should be more clearly introduced as such.

It’s a bit unclear whether you are going for an Informational BIP that describes a design issue, or a Specification BIP that tries to describe a feature in a way that it can be implemented. At times you describe behavior exhibited by existing implementations, but then you also seem to try to comprehensively describe how to implement the feature. If you are going for an Informational BIP, you may focus on the benefit of anti-fee-sniping, suggest that wallet implementers lock transactions to the chaintip and cut the specification back to some general implementation advice. If you are going for a Specification BIP, you would double-down on your Specification and Pseudocode by making sure that the Specification is comprehensive and precise enough that projects can implement the feature from reading the Specification section.

[murchandamus]

Please add a link to the discussion on the mailing list. Since this proposal supersedes BIP326 in one aspect, please add the corresponding “Replaces” header:

Suggested change

	License: CC0-1.0
	License: CC0-1.0
	Discussion: link to mailing list thread
	Replaces: 326

[nervana21]

Okay, I've added the mailing list discussion link.

IIUC correctly, "Replaces: 326" would mean that this BIP "succeeds, supersedes, or renders obsolete" BIP326, but isn't BIP326 is still needed to refer to the nSequence-based anti-fee-sniping?

[nervana21]

Thanks for the feedback @murchandamus! I will address your concerns and post an updated draft asap

[nervana21]

If you are going for a Specification BIP, you would double-down on your Specification and Pseudocode by making sure that the Specification is comprehensive and precise enough that projects can implement the feature from reading the Specification section.

Ok, I think it's best to be a Specification as opposed to Informational BIP. I've updated the style to reflect that everywhere appropriate.

[nervana21]

Rebased off master and updated draft to address detailed feedback from @murchandamus