Good morning,
>
> That is mostly due to the selection of 1 bit sequence diffs, the
>
> branching gives us a huge increase in the number of invalidations. The
>
> paper has the example of branching factor of 46, and a tree depth of 11,
>
> which results in 1.48e11 updates.
>From your descripti
ZmnSCPxj via Lightning-dev
writes:
> 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
>
>
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 tran
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 penal
ZmnSCPxj via Lightning-dev
writes:
> In a retaliation construction, if a party misbehaves, the other party gets
> the entire amount they are working on together, as disincentive for any party
> to cheat.
>
> That works for the two-party case A and B. If A cheats, B gets money.
>
> How do you ex
Good morning Alejandro,
There is no assumption involved, merely a large number of questions.
In a retaliation construction, if a party misbehaves, the other party gets the
entire amount they are working on together, as disincentive for any party to
cheat.
That works for the two-party case A an
Hello all,
Christian Decker pointed the following out
(source:https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000991.html):
>I'd also like to point out that the way we do state invalidations in
>Lightning is not really suited for multi-party negotiations beyond 2
>parties.
I'd also like to point out that the way we do state invalidations in
Lightning is not really suited for multi-party negotiations beyond 2
parties. The number of potential reactions to a party cheating grows
exponentially in the number of parties in the contract, which is the
reason the Channel Fact
Good morning Abhishek Sharma,
While the goal of the idea is good, can you provide more details on the Bitcoin
transactions? Presumably the on-chain anchor is a 3-of-3 multisig UTXO, what
is the transaction that spends that? What do Lightning commitment transactions
spend? Can you draw a grap
