📅 Original date posted:2015-08-13
📝 Original message:Very cool! This will certainly help make Lightning Network testable on
the main-chain and permit channels to remain open indefinitely. I'm
looking forward to it.
On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:
> // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
> // accept 5-byte bignums since any value greater than or
> // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
> // anyway. This limitation just happens to coincide with
> // CScriptNum's default 4-byte limit with an explicit sign
> // bit.
I haven't tested the details of this, but is there another bit available
for use in the future for the relative blockheight?
I strongly believe that Lightning needs mitigations for a systemic
supervillan attack which attemps to flood the network with transactions,
which can hypothetically be mitigated with something like a timestop
bit (as originally suggested by gmaxwell).
Summary: If a block is flagged as timestopped (whether automatically or
by vote or other mechanism), then an auxillary blockheigh is frozen and
does not increment. This auxillary blockheight is only used for
accounting in timestopped height computation (and isn't used for
anything else). So as the real blockheight increments, the auxillary
blockheight can sometimes stop and stay the same. If a transaction has a
timestop bit enabled, then the transaction's OP_CSV relative height is
dependent upon the auxillary height, not the real block height. This
allows for a large backlog of transactions which must occur before a
particular (relative) block height to enter into the blockchain.
I'm not sure if it's out of scope, but it could make sense to consider
the possibility for additional state(s) with relative height computation
today. Ideally, there'd be some kind of "version" byte which can be
recontextualized into something later, but I don't know how that could
cleanly fit into the data structure/code.
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-07 15:46:48
in reply to nevent1q…zuj6
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-07 15:46:48Event JSON
{
"id": "4bc9791d4567ad50f1c947aa39d7ac7c63815a3b2d179497737e8c86e68072e1",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686152808,
"kind": 1,
"tags": [
[
"e",
"6086ec24c7436956a4324b488abdb6aa06edbf1e682d11a0a5b70b6f8e62e6f3",
"",
"root"
],
[
"e",
"11041f8b5e03369f4a3d0f1857ad1623e3815f63332c60448abc95d3363f8395",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2015-08-13\n📝 Original message:Very cool! This will certainly help make Lightning Network testable on\nthe main-chain and permit channels to remain open indefinitely. I'm\nlooking forward to it.\n\nOn Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:\n\u003e // Note that unlike CHECKLOCKTIMEVERIFY we do not need to\n\u003e // accept 5-byte bignums since any value greater than or\n\u003e // equal to SEQUENCE_THRESHOLD (= 1 \u003c\u003c 31) will be rejected\n\u003e // anyway. This limitation just happens to coincide with\n\u003e // CScriptNum's default 4-byte limit with an explicit sign\n\u003e // bit.\n\nI haven't tested the details of this, but is there another bit available\nfor use in the future for the relative blockheight?\n\nI strongly believe that Lightning needs mitigations for a systemic\nsupervillan attack which attemps to flood the network with transactions,\nwhich can hypothetically be mitigated with something like a timestop\nbit (as originally suggested by gmaxwell).\n\nSummary: If a block is flagged as timestopped (whether automatically or\nby vote or other mechanism), then an auxillary blockheigh is frozen and\ndoes not increment. This auxillary blockheight is only used for\naccounting in timestopped height computation (and isn't used for\nanything else). So as the real blockheight increments, the auxillary\nblockheight can sometimes stop and stay the same. If a transaction has a\ntimestop bit enabled, then the transaction's OP_CSV relative height is\ndependent upon the auxillary height, not the real block height. This\nallows for a large backlog of transactions which must occur before a\nparticular (relative) block height to enter into the blockchain.\n\nI'm not sure if it's out of scope, but it could make sense to consider\nthe possibility for additional state(s) with relative height computation\ntoday. Ideally, there'd be some kind of \"version\" byte which can be\nrecontextualized into something later, but I don't know how that could\ncleanly fit into the data structure/code.\n\n-- \nJoseph Poon",
"sig": "e89dcc949b645e0931f83a05d8d19d94c67bdee58773597ea3b3f5d1c80f643b6d56e6988808b92941ede2e22afef357377390840c426aef7ac320a92466482c"
}