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:
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
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
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
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
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
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