Date: Thu, 13 Aug 2015 16:42:13 -0700
From: Joseph Poon <joseph@lightning.network>
To: Btc Drak <btcdrak@gmail.com>
Message-ID: <20150813234213.GH2123@lightning.network>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
 relative locktime
Precedence: list

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