Btc Drak [ARCHIVE] on Nostr: π Original date posted:2015-09-18 π Original message:On Fri, Sep 18, 2015 at ...
π
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>
π 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>