📅 Original date posted:2015-09-18
📝 Original message:On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Btc Drak 於 2015-09-17 15:12 寫到:
>
>> Forgive me if I have missed the exact use-case, but this seems overly
>> complex. Surely fill-or-kill refers to getting a transaction confirmed
>> within a few confirms or to drop the tx from the mempool so it wont be
>> considered for inclusion anymore. As such, you could just repurpose a
>> small range of nLocktime such that a TX will be accepted into mempool
>> for a specific period before expiring.
>>
>
> What I'm describing is to implement fill-or-kill as consensus rule.
> Certainly, we could implement it at the P2P network level: everything is
> the same as I described, but the nLockTime2 and nKillTime are for reference
> only and tx validity depends only on the nLockTime. Benevolent miners
> should drop the tx after the suggested kill time but there is no guarantee
>
Sure, you can make the scheme I describe consensus based by adding the rule
tx is not valid to mine after expiry: this still keeps the simplicity I
described.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/d28eff3f/attachment-0001.html>;
Btc Drak [ARCHIVE] /
npub1lh…zg7ed
2023-06-07 17:40:45
in reply to nevent1q…77zn
Author Public Key
npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7edSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:40:45Event JSON
{
"id": "aac6443c5e5a13fbd4e31f2a07bebb7ec67643290f94fb733183110caa1999f1",
"pubkey": "fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83",
"created_at": 1686159645,
"kind": 1,
"tags": [
[
"e",
"d245f3cd2427d9c30e488b3eacebf2ae42b122d633366f33db323c8696dd9375",
"",
"root"
],
[
"e",
"32692936b397809ce477bb7b1a4051d8f6a93387adbf7d8748b4cf2a640afcaf",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Btc Drak 於 2015-09-17 15:12 寫到:\n\u003e\n\u003e\u003e Forgive me if I have missed the exact use-case, but this seems overly\n\u003e\u003e complex. Surely fill-or-kill refers to getting a transaction confirmed\n\u003e\u003e within a few confirms or to drop the tx from the mempool so it wont be\n\u003e\u003e considered for inclusion anymore. As such, you could just repurpose a\n\u003e\u003e small range of nLocktime such that a TX will be accepted into mempool\n\u003e\u003e for a specific period before expiring.\n\u003e\u003e\n\u003e\n\u003e What I'm describing is to implement fill-or-kill as consensus rule.\n\u003e Certainly, we could implement it at the P2P network level: everything is\n\u003e the same as I described, but the nLockTime2 and nKillTime are for reference\n\u003e only and tx validity depends only on the nLockTime. Benevolent miners\n\u003e should drop the tx after the suggested kill time but there is no guarantee\n\u003e\n\nSure, you can make the scheme I describe consensus based by adding the rule\ntx is not valid to mine after expiry: this still keeps the simplicity I\ndescribed.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/d28eff3f/attachment-0001.html\u003e",
"sig": "069473e757ffacb7a83fc233ef31073ffd5ed92aa91f4a6c8b24334257a29aedfc38242a6fc399b33e4491febf50b253466f6e3f724d30ca3688fe0dc849f725"
}