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

2018-04-11 Thread Christian Decker
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:

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

2018-04-11 Thread ZmnSCPxj via Lightning-dev
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

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

2018-04-06 Thread Christian Decker
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

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

2018-04-05 Thread ZmnSCPxj via Lightning-dev
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

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

2018-04-02 Thread Alejandro Ranchal Pedrosa
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

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

2018-02-05 Thread Christian Decker
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

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

2018-02-04 Thread ZmnSCPxj via Lightning-dev
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