From ZmnSCPxj at protonmail.com Fri Oct 25 10:05:48 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 25 Oct 2019 10:05:48 +0000 Subject: [Lightning-dev] Make Me An Offer: Next Level Invoicing In-Reply-To: References: Message-ID: Good morning CJP, > In my view, a transaction is not a line, it's a circle. I strongly agree to this. Indeed, in a full-blown economy running completely on Lightning Network, we may very well "never" settle onchain, instead simply draining then refilling our channels as we swap so-caled "real-world" assets around --- the closing of the Lightning circle. > Bitcoins go from > payer to payee over the Lightning network, and whatever > assets/goods/services are paid for go from payee to payer - this closes > the circle. Transactions on all hops of the circle should be atomic. > Between Lightning hops this is realized with HTLCs. For the payer-payee > hop this is generally not possible, as non-cryptographic things > generally don't allow you to construct HTLCs on them. A sealed box that can only be opened by inputting the preimage of a hash could work: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001688.html Of course, as a cross-asset swap, this is susceptible to the well-known premium-free American Call Option problem --- eh who cares, it is not as if the price of real-world goods changes that fast. > --->8--- > > The state updating mechanism and its properties require special > attention. I think the purpose of the channel is to aid in conflict > resolution - it should provide evidence of what is agreed between both > parties. There is nothing in an old state that makes it inherently > invalid: in fact, at some point in the past it was valid. The only thing > that makes it invalid is the presence of a later version. To reveal the > truth in conflict resolution, it is necessary that > > (1) the latest state is revealed > > (2) it is clear that this latest state is more recent than all other > states that are revealed > > I hope that (1) is likely incentive-wise: typically, incentives of the > parties are each other's opposite, so either one party has an interest > in revealing an update, or the other party has. I haven't worked out > this thought very rigorously though. If you allow a timeout to show a later state before finalizing the most recent published state, much like Decker-Russell-Osuntokun or Poon-Dryja unilateral closes, then I see no issue. > > I think a bit of cryptography can help with (2). One idea is to include > sequence numbers in states, another is to include the hash of the > previous state. Either way, the possibility remains (cryptographically, > maybe not incentive-wise) to mess up the evidence by "forking" the > channel: making multiple state updates that have the same parent state. > This may be resolved semantically, with rules like "if A unilaterally > makes a fork, and both sides are revealed, B may choose which side of > the fork is to be considered valid". In this particular case, as long as the overall state is signed by both counterparties, then it is immaterial whether there is a cryptographic protection against forking or not. As long as the other side refuses to fork when one side attempts it, then forking is not possible as it requires both counterparties to sign off on it. Of course, they can rewrite history if they should like to do so, but it would have to be done bilaterally, and if we use sequence numbers (which are probably what we should prefer rather than hash-of-previous, so that if the non-latest state is published, we can show the latest state without having to reveal all intervening states), then they would have to make artificially large sequence number. > > Some advanced ideas > > - Contracts between three or more parties. > - Merging and joining of contracts in state updates > Merging and joining is difficult. Consider the difficulties we have been having in designing a good splice-in facility, while a splice-out facility can be done much more easily. Since the real world is subservient to the Bitcoin world, we should probably expect to find similar difficulties with merging and joining of contracts. Regards, ZmnSCPxj