# Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

```Good morning Alejandro,

I was about to ask Christian this myself.```
```
There is another technique:

Use a sequence of `nSequence`d transactions off-chain.  For example, to get an
2-bit counter, you would have:

funding -> kickoff -> bit1 -> bit0

Only funding is onchain.  kickoff, bit1, and bit0 transactions are all kept
offchain.  We start a unilateral close by broadcasting kickoff, then wait for
bit1 to become valid and broadcast then, then wait for bit0 to become valid and

There are two versions of the bit1 and bit0 transactions.  Each bit position,
you have a high `nSequence` to represent the binary 0, and a low `nSequence`
value to represent the binary 1.

Then to increment your counter, you replace bit0.  If it has a high `nSequence`
you replace it with a new bit0 transaction with the low `nSequence` (equivalent
to flipping the bit).  If it is already the low `nSequence` (i.e. logically it
is value 1) then we "carry" it by replacing the next higher bit, then replacing
the current bit with the high `nSequence` (equivalent to propagating the carry
and flipping the bit).  Thus it is equivalent to binary incrementation.

It is safe to re-use the high `nSequence` on a lower bit if some higher bit in
the offchain transactions uses the low `nSequence` value, since that higher bit
dominates over the rest of the chain.

This is basically just the "invalidation tree" concept brought to its logical
conclusion.  We could use trinary or quaternary or more, but that limits the
`nSequence` we can use (we do not want to use too large a high `nSequence`
value as that increases wait times), so there is some balancing involved in the
various parameters (number of digits, radix of counter).

To get a 32-bit counter for a maximum of 4,294,967,296 updates transactions in
sequence, we need 33 transactions in sequence kept off-chain.  When one party
disappears, we are forced to feed the 33 transactions one-by-one into the
blockchain.  If we use 4 blocks for high `nSequence` (bit 0) and 0 blocks for
low `nSequence` (bit 1) then at worst case lockup time for unilateral close is
128 blocks.

Note that all transactions are kept offchain: we never re-point a refund
transaction as you describe in your "(b)".  Thus we only waste blockchain space
if we are forced into a unilateral close.  Normal operation, we simply keep all
transactions offchain and only touch the chain on unilateral or bilateral close.

The big drawback is the large number of transactions in sequence in a
unilateral close.  In a bilateral close we collapse all transactions into a
single bilateral refund.  I suppose it is hopeful to consider that unilateral
closes should be very rare.

So, Christian, it still seems that techniques that reduce total wait times in a
unilateral close have the drawback of increasing the number of transactions in
sequence in a unilateral close.  It still seems Poon-Dryja, is superior in that
total wait time is easily user-selectable and unilateral closes only have two
transactions in sequence.  For low number of updates, we can consider having a
tiny "counter" (possibly a quaternary counter) that itself terminates in
multiple Poon-Dryja channels, which I believe is what the
Burchert-Decker-Wattenhofer channel factories do.

Regards,
ZmnSCPxj

​Sent with ProtonMail Secure Email.​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On April 11, 2018 4:43 PM, Alejandro Ranchal Pedrosa
<alejandro.ranchal_pedr...@etu.upmc.fr> wrote:

> Hi Christian,
>
> > That's not as bad a tradeoff as people usually interpret, the DMC
> >
> > construction has parameters that allow tweaking the number of
> >
> > invalidations, and with parameters similar to LN we can have 1.4 billion
> >
> > updates. Which is years of operation without need to
> >
> > re-anchor. In addition penaltyless invalidation has a number of
> >
>
> As far as I understand, long-lasting DMCs require either:
>
>     (a) an initial Refund transaction with a very distant relative
>
> locktime
>
>     (b) periodic updates in the form of a Refund transaction pointing
>
> to a new Refund transaction resetting initial the locktime, instead of
>
> actually refunding.
>
>     For an extreme case of (a), if one party goes unresponsive and
>
> decides not to sign new commitments then the counterparty in the DMC
>
> will have its funds locked for a significant amount of time, without
>
> penalising the unresponsive party. In the extreme case of (b), either if
>
> as a result of a malicious, unresponsive, or honest participant, each
>
> new refund transaction that resets the refunds may end up hitting the
>
> blockchain, which means the worst-case utility of the channel itself
>
> decreasing due to accumulative blockchain fees. Is this the trade-off
>
> you speak of? if so, can you point at any resource where this trade-off
>
> is tackled to get worst-case utility similar to that of LN channels?
>
> Best,
>
> Alejandro.
>
> Lightning-dev mailing list
>
> Lightning-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
```