📅 Original date posted:2015-09-18
📝 Original message:Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:
> It can be implemented by a "treat like Coinbase" flag in the
> UTXO set, set when the output is created.
I think this is the cleanest way to implement the maturity requirement.
I understand why we need maturity, However, requiring 100 block maturity
will unfortunately make the system much less appealing since the
recipient may not like it. A fill-or-kill tx may still be used as the
initial funding tx to the Lightning Network, as long as the counterparty
is willing to take the extra risk.
Actually, a fill-or-kill tx is slight safer than a coinbase tx,
depending on the difference between the absolute kill time and actual
confirmation time. In a re-org, an orphaned coinbase tx is permanently
invalidated and has no hope to be included again. However, an orphaned
fill-or-kill tx may still be confirmed by another miner. If there is
still a few days until the absolute kill time, a fill-or-kill tx is
basically as safe as a normal tx.
With possibility of re-org and unpredictable block interval in mind,
height-based fill-or-kill is not very useful since it is difficult for
users to determine the actual kill time. If we could abolish the idea of
height-based fill-or-kill, the resolution of time-based fill-or-kill
might be improved.
------------------------------------
Chun Wang 於 2015-09-17 18:33 寫到:
> We are currently using nLockTime for share info and nSequence for
> extranonce2. I have carefully reviewed the reference implementation of
> BIP68 and it should be compatible, but this proposal may break the
> implementation unless it does not affect coinbase transactions.
>
The fill-or-kill system is totally optional, using a bit flag in tx
nVersion to indicate. Everything should be fine unless you are also
messing with the nVersion
-------------------------------------
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
-------------------------------------
I made a mistake in this example:
> A user wants his tx get confirmed in the block 630000, the first block
> with reward below 10BTC. He is willing to pay high fee but don't want
> it gets into another block. He will set nLockTime2 = 210,000 and
> nKillTime = 0
The correct nLockTime2 for this example should be 210000/4 = 52500
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:40:45
in reply to nevent1q…30zh
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:40:45Event JSON
{
"id": "32692936b397809ce477bb7b1a4051d8f6a93387adbf7d8748b4cf2a640afcaf",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159645,
"kind": 1,
"tags": [
[
"e",
"d245f3cd2427d9c30e488b3eacebf2ae42b122d633366f33db323c8696dd9375",
"",
"root"
],
[
"e",
"396bd514776d0b3947979d1ed53fc77e8b4e9ea377022d36dce96164a474a422",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:\n\n\u003e It can be implemented by a \"treat like Coinbase\" flag in the\n\u003e UTXO set, set when the output is created.\n\nI think this is the cleanest way to implement the maturity requirement. \nI understand why we need maturity, However, requiring 100 block maturity \nwill unfortunately make the system much less appealing since the \nrecipient may not like it. A fill-or-kill tx may still be used as the \ninitial funding tx to the Lightning Network, as long as the counterparty \nis willing to take the extra risk.\n\nActually, a fill-or-kill tx is slight safer than a coinbase tx, \ndepending on the difference between the absolute kill time and actual \nconfirmation time. In a re-org, an orphaned coinbase tx is permanently \ninvalidated and has no hope to be included again. However, an orphaned \nfill-or-kill tx may still be confirmed by another miner. If there is \nstill a few days until the absolute kill time, a fill-or-kill tx is \nbasically as safe as a normal tx.\n\nWith possibility of re-org and unpredictable block interval in mind, \nheight-based fill-or-kill is not very useful since it is difficult for \nusers to determine the actual kill time. If we could abolish the idea of \nheight-based fill-or-kill, the resolution of time-based fill-or-kill \nmight be improved.\n\n\n------------------------------------\n\nChun Wang 於 2015-09-17 18:33 寫到:\n\u003e We are currently using nLockTime for share info and nSequence for\n\u003e extranonce2. I have carefully reviewed the reference implementation of\n\u003e BIP68 and it should be compatible, but this proposal may break the\n\u003e implementation unless it does not affect coinbase transactions.\n\u003e \n\nThe fill-or-kill system is totally optional, using a bit flag in tx \nnVersion to indicate. Everything should be fine unless you are also \nmessing with the nVersion\n\n\n-------------------------------------\n\nBtc Drak 於 2015-09-17 15:12 寫到:\n\u003e Forgive me if I have missed the exact use-case, but this seems overly\n\u003e complex. Surely fill-or-kill refers to getting a transaction confirmed\n\u003e within a few confirms or to drop the tx from the mempool so it wont be\n\u003e considered for inclusion anymore. As such, you could just repurpose a\n\u003e small range of nLocktime such that a TX will be accepted into mempool\n\u003e for a specific period before expiring.\n\nWhat I'm describing is to implement fill-or-kill as consensus rule. \nCertainly, we could implement it at the P2P network level: everything is \nthe same as I described, but the nLockTime2 and nKillTime are for \nreference only and tx validity depends only on the nLockTime. Benevolent \nminers should drop the tx after the suggested kill time but there is no \nguarantee\n\n\n-------------------------------------\n\nI made a mistake in this example:\n\n\u003e A user wants his tx get confirmed in the block 630000, the first block\n\u003e with reward below 10BTC. He is willing to pay high fee but don't want\n\u003e it gets into another block. He will set nLockTime2 = 210,000 and\n\u003e nKillTime = 0\n\nThe correct nLockTime2 for this example should be 210000/4 = 52500",
"sig": "3d95f94de1e8275879eb11cdf5c183402f00bca352f0bba0c920c62bcb78f70a6d07d79e701df85e90d1e21adb8f7d444ab0a00b27c91c3bc41e394a8f0eebd4"
}