📅 Original date posted:2015-07-05
📝 Original message:I would say yes. Just putting a locktime in transaction may help against
fee sniping, even in transactions that are allowed to be mined at the same
time as some of their dependencies?
On Jul 5, 2015 6:17 PM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
> Can you construct an example? Are there use cases where there is a need
> for an enforced lock time in a transaction with inputs that are not
> confirmed at the time the lock time expires?
> On Jul 5, 2015 8:00 AM, "Tom Harding" <tomh at thinlink.com> wrote:
>
>> BIP 68 uses nSequence to specify relative locktime, but nSequence also
>> continues to condition the transaction-level locktime.
>>
>> This dual effect will prevent a transaction from having an effective
>> nLocktime without also requiring at least one of its inputs to be mined
>> at least one block (or one second) ahead of its parent.
>>
>> The fix is to shift the semantics so that nSequence = MAX_INT - 1
>> specifies 0 relative locktime, rather than 1. This change will also
>> preserve the semantics of transactions that have already been created
>> with the specific nSequence value MAX_INT - 1 (for example all
>> transactions created by the bitcoin core wallet starting in 0.11).
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/f360820c/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:41:43
in reply to nevent1q…cakq
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:41:43Event JSON
{
"id": "5ae7c9fa8b6f0bc6959e8a6d0bed0fa12a7ddc7ea0db822a21eaba7c46312c79",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152503,
"kind": 1,
"tags": [
[
"e",
"a9a9aca60fe5ebc109f9ba65c6e1110ae9ec6ca7ce05bca568532288913e8719",
"",
"root"
],
[
"e",
"272da1d1b96c5b1f7f3ecad76f09a37e8e8c0b97b3ef386e96e0fd94d2d13329",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-07-05\n📝 Original message:I would say yes. Just putting a locktime in transaction may help against\nfee sniping, even in transactions that are allowed to be mined at the same\ntime as some of their dependencies?\nOn Jul 5, 2015 6:17 PM, \"Mark Friedenbach\" \u003cmark at friedenbach.org\u003e wrote:\n\n\u003e Can you construct an example? Are there use cases where there is a need\n\u003e for an enforced lock time in a transaction with inputs that are not\n\u003e confirmed at the time the lock time expires?\n\u003e On Jul 5, 2015 8:00 AM, \"Tom Harding\" \u003ctomh at thinlink.com\u003e wrote:\n\u003e\n\u003e\u003e BIP 68 uses nSequence to specify relative locktime, but nSequence also\n\u003e\u003e continues to condition the transaction-level locktime.\n\u003e\u003e\n\u003e\u003e This dual effect will prevent a transaction from having an effective\n\u003e\u003e nLocktime without also requiring at least one of its inputs to be mined\n\u003e\u003e at least one block (or one second) ahead of its parent.\n\u003e\u003e\n\u003e\u003e The fix is to shift the semantics so that nSequence = MAX_INT - 1\n\u003e\u003e specifies 0 relative locktime, rather than 1. This change will also\n\u003e\u003e preserve the semantics of transactions that have already been created\n\u003e\u003e with the specific nSequence value MAX_INT - 1 (for example all\n\u003e\u003e transactions created by the bitcoin core wallet starting in 0.11).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/f360820c/attachment.html\u003e",
"sig": "663cc238bd67dd4b852b31ec344e3c5f191119f1160a73c6a805c4a36c6c1419b3a7eb518670870a043350ae274123801665d0e17132f701d20a238a54e560fd"
}