> hashing out old ideas in public like an out-of-the-loop person
Being fully in-the-loop literally seems undesirable anyway. As the scriptless
scripts space gets bigger, I invite everyone to consider contributing to the
scriptless scripts repo at
https://github.com/ElementsProject/scriptless-scripts. This allows to have the
ideas at one place, improve them over time and standardize on terminology and
notation. In particular, the escrow idea seems quite established and would be a
nice to have written down comprehensively along with it's shortcomings.
> OR is harder
Unless you have additional requirements OR is simpler because it just means
creating and revealing the key to the other party. In your exmple "(A AND B) OR
(B AND C) OR (C AND A)", A and B can generate each generate their key and add
it. Then they each split their key into two shares, one is created by adding a
random scalar, the other by subtracting the same random scalar. They each
encrypt their first share to B and the second share to C. They do the same for
C and A. The receivers must check that they've received valid shares, i.e.
their shares sum up to the secret to the A + B key. That's not very efficient
because it requires a lot of communication, but I don't know of a better scheme
for general disjunctive normal forms like that and this helps as a mental
model. Any policy consisting of ANDs and ORs policy can be written in
disjunctive normal form and can therefore be constructed similar to above
example.
On 10/9/19 11:42 PM, Nadav Kohen wrote:
> Hi list,
>
> I'm back again with another idea about Payment Points and fun things to do
> with them! Hopefully this time I'm not entirely just hashing out old ideas
> in public like an out-of-the-loop person :)
>
> *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which
> we can compose to make cool lightning contracts like Multisig, Escrow, and
> DLCs*
>
> So when looking at the following (likely incomplete) list of things you can
> do with payment points:
>
> 1) Payment De-correlation
> 2) "Stuckless" Payments
> 3) High AMP
> 4) Selling Signatures
> 5) Selling Pedersen De-commitment
> 6) Escrow Contracts
>
> I started of trying to classify what kind of thing these new features are
> in hopes of coming across new ones. The first three I clumped into a group
> I called "Payment point addition allows us to do cool things while
> maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I
> called "Commitment applications where point is public". But ZmnSCPxj's
> proposal for lightning escrow contracts (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html)
> struck me as something different that might somehow be made more general.
>
> Essentially the idea is to use the point S + ECDH(B, E) where S is the
> seller's point, B is the buyer's point and E is the escrow's point. This
> means that the scalar can be discovered by the seller in collaboration with
> the buyer or the escrow, that is, S AND (B OR E). I propose that under
> certain circumstances (such as the parties involved being able to
> interact), this can be generalized to have payments conditioned on
> arbitrary AND/OR circuits.
>
> I believe that AND is very straightforward as you simply take two
> conditions A and B and add them together to get a point that requires both
> of their scalars are discoverable (except maybe under certain bad
> circumstances that can be avoided where like B = C - A, this must be
> guarded against).
>
> OR is harder but I think that it can be achieved in the two party case by
> ECDH and in the n-party case by multi-party key exchanges (which I know
> pretty much nothing about other than that they exist). Given some key
> exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n)
> should result in a number known only to those who know any scalar a_1, ...,
> a_n and no one else. Assuming this exists and we can manage to trustlessly
> (in some possibly stretched sense of the word) compute shared keys
> (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our
> payment condition contract.
>
> To restate the escrow contract idea in this setting, the payment is
> conditioned on S + KE(B, E). Important to note is that not all parties must
> know about the details of the payment itself: the Escrow in this example
> knows nothing about this payment (other than that some payment exists)
> unless there is a dispute.
>
> Lastly, note that contracts following this scheme look indistinguishable to
> normal payments on the network, and are fully compatible with High AMPs
> since we can simply take the payment point specified by our contract and
> add that point to each partial payment point.
>
> Well this is all nice in theory, but is there anything that will actually
> come out of this thinking? I'll detail the two things I've thought of so
> far for which I'd love critique! I'd also love to hear if anyone else
>
