Jonas Nick [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-11 📝 Original message: > hashing out old ideas ...

📅 Original date posted:2019-10-11
📝 Original message:
> 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
> things of any cool application using this line of thought (or really
> anything cool with payment points :P).
>
> Idea 1: "MultiSignature" Lightning Contracts
> I mean "MultiSignature" here only in the sense that m-of-n parties must
> agree to the payment in order for it to happen, no actual signatures are
> used. A "MultiSignature" contract is simply a bunch of ANDs and ORs! For
> example a 2-of-3 multisig between parties A, B, and C can be represented as
> (A AND B) OR (B AND C) OR (C AND A). As such, if some seller has a point S
> and three parties have points A, B, and C where a certain payment must go
> through if any two of them think it should, then the payment point used for
> the payment should be S + KE(A + B, B + C, C + A). We add S to this point
> so that the scalar, s, can act as proof of payment. And that's it! I
> haven't thought long enough to come up with any situation where this might
> be useful but hoping someone who reads this will!
>
> Idea 2: DLCs Routed over Lightning
> Say that some DLC oracle will either broadcast s_A or s_B whose public
> points are S_A and S_B (which can be computed from public information as
> per the DLC scheme). Then say that Alice and Bob enter into a contract
> under which Alice wins some amount if s_A is broadcasted and Bob if s_B is
> broadcasted. Say Alice has a point A and Bob has a point B. They each send
> the other a payment with the amount that party must receive if they win
> with the payment point A + S_A for Bob's payment to Alice and B + S_B for
> Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice
> gets paid (and Bob gets proof of payment a, which is the scalar to A),
> otherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as
> PoP). An interesting note is that under this scheme neither party is forced
> to pay extra on-chain fees in the case of a counter-party who doesn't
> cooperate whilst in the wrong.
> One wrinkle with this scheme is that setup isn't trustless. Although it is
> generally true that one party must sign the funding transaction for a DLC
> before the other party for on-chain DLCs, at least there is the mitigation
> that when your counter-party goes silent, you can move your input funds
> invalidating the funding transaction you signed (at a cost because fees).
> So what can we do here to ensure that both payments are setup at the same
> time in the case that Alice and Bob don't trust each other?
> Say that although they don't trust each other, they're both willing to
> trust some escrow entity who generates some point E for their payment.
> Alice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes
> A + S_A + E. The escrow now waits to hear from Alice and Bob that they have
> incoming payments setup and only once both of them attest to this (using
> signatures, for example) does the escrow release the scalar to E to them
> both. The escrow can also have a timeout at which it will never reveal the
> scalar to E: forcing both parties to commit to the contract well before the
> DLC event. In this way, trust has been moved from counter-party to
> trustworthy (hopefully) escrow in such a way that the Escrow learns nothing
> about the contract itself (other than that there is one of some kind).
> I believe that this scheme can be extended to more events through the use
> of multiple payments being setup (usually in both directions) but this
> seems complicated and I've rambled for long enough. One last note is that
> DLC oracles can be composed in the usual way under this scheme (by
> addition) and potentially even threshold multi-oracles can be supported in
> this way, although this would require the oracles to attest to some shared
> key's points with other oracles which isn't necessarily optimal.
>
> Best,
> Nadav
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>