📅 Original date posted:2015-10-03
📝 Original message:BIP68 allows per-input locktime, though I don't know how this could be
useful.
BIP68 and BIP112 are mostly ready. If we try to reimplement
relative-locktime without using nSequence, we may need to wait for
another year for deployment.
A compromise is to make BIP68 optional, indicated by a bit in tx
nVersion, as I suggested earlier (1). This will allow deploying
relative-locktime without further delay while not permanently limiting
future upgrades.
(1)
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
Peter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到:
> BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
> which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
> However, CSV does define behavior for the previously undefined
> nSequence
> field, which is the only "free-form" field we currently have in the
> transaction serialization format that can be used for future upgrades -
> we should justify this new behavior carefully as it limits our options
> in the future. Adding new fields to the serialization format is very
> difficult, due to the very broad system-wide impact of the hard-fork
> required to do so.
>
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
>
> 2) Additionally to RCLTV, we need to implement this via nSequence
>
> To show we need RCLTV BIP112 provides the example "Escrow with
> Timeout",
> which is a need that was brought up by GreenAddress, among others; I
> don't think we have an issue there, though getting more examples would
> be a good thing. (the CLTV BIP describes seven use cases, and one
> additional future use-case)
>
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone. There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel. That example alone I don't think
> justifies a fairly complex soft-fork that limits future upgrades; we
> need more justification.
>
> So, what else can the community come up with? nSequence itself exists
> because of a failed feature that turned out to not work as intended;
> it'd be a shame to make that kind of mistake again, so let's get our
> semantics and use-cases in the BIPs and documented before we deploy.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 19:42:24
in reply to nevent1q…6qpp
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 19:42:24Event JSON
{
"id": "4655652b0bc32aafea2d1d3679f63b39100daf5067f3e674a1ab40c2ff500fac",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159744,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"88b7dd63e8954f826017e8f2fd0b41ec2d1bad325765f172a69856a5ac03a09e",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-10-03\n📝 Original message:BIP68 allows per-input locktime, though I don't know how this could be \nuseful.\n\nBIP68 and BIP112 are mostly ready. If we try to reimplement \nrelative-locktime without using nSequence, we may need to wait for \nanother year for deployment.\n\nA compromise is to make BIP68 optional, indicated by a bit in tx \nnVersion, as I suggested earlier (1). This will allow deploying \nrelative-locktime without further delay while not permanently limiting \nfuture upgrades.\n\n(1) \nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html\n\nPeter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到:\n\u003e BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,\n\u003e which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.\n\u003e However, CSV does define behavior for the previously undefined \n\u003e nSequence\n\u003e field, which is the only \"free-form\" field we currently have in the\n\u003e transaction serialization format that can be used for future upgrades -\n\u003e we should justify this new behavior carefully as it limits our options\n\u003e in the future. Adding new fields to the serialization format is very\n\u003e difficult, due to the very broad system-wide impact of the hard-fork\n\u003e required to do so.\n\u003e \n\u003e So we need to make the case for two main things:\n\u003e \n\u003e 1) We have applications that need a relative (instead of absolute CLTV)\n\u003e \n\u003e 2) Additionally to RCLTV, we need to implement this via nSequence\n\u003e \n\u003e To show we need RCLTV BIP112 provides the example \"Escrow with \n\u003e Timeout\",\n\u003e which is a need that was brought up by GreenAddress, among others; I\n\u003e don't think we have an issue there, though getting more examples would\n\u003e be a good thing. (the CLTV BIP describes seven use cases, and one\n\u003e additional future use-case)\n\u003e \n\u003e However I don't think we've done a good job showing why we need to\n\u003e implement this feature via nSequence. BIP68 describes the new nSequence\n\u003e semantics, and gives the rational for them as being a\n\u003e \"Consensus-enforced tx replacement\" mechanism, with a bidirectional\n\u003e payment channel as an example of this in action. However, the\n\u003e bidirectional payment channel concept itself can be easily implemented\n\u003e with CLTV alone. There is a small drawback in that the initial\n\u003e transaction could be delayed, reducing the overall time the channel\n\u003e exists, but the protocol already assumes that transactions can be\n\u003e reliably confirmed within a day - significantly less than the proposed\n\u003e 30 days duration of the channel. That example alone I don't think\n\u003e justifies a fairly complex soft-fork that limits future upgrades; we\n\u003e need more justification.\n\u003e \n\u003e So, what else can the community come up with? nSequence itself exists\n\u003e because of a failed feature that turned out to not work as intended;\n\u003e it'd be a shame to make that kind of mistake again, so let's get our\n\u003e semantics and use-cases in the BIPs and documented before we deploy.\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",
"sig": "c10650d2f47b31f214ee54a68eb7cbc32eaffe1a47b836996f8659308a2547b5a836c87f3491d1c1c9376d58de00fb2288d2bcb30d9c7acf274c794045bf7ce7"
}