Hey ZmnSCPxj, On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
> Good morning Andres, > > > This looks cool but would hinder UX too much for certain scenarios: e.g. > if the escrow in place is part of a bitcoin exchange, then you require the > bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new > users (which could maybe only have fiat). Am I right? > > Correct. > Though note that existing systems like Bisq, to my knowledge, have the > same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to > offer as stake that can be revoked in case they attempt to defraud the > counterparty. > Without it, the counterparty takes on increased risk (which translate to > larger exchange spread). > Yeah I understand Bisq's model. However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl, localbitcoins, localcryptos... > > In any case, once you have that initial stake, you can then keep > increasing your ability to provide stake so as to relieve your > counterparties of risk and have them offer better exchange rates, so it is > "only" an issue for initial onboarding. > Presumably, in the later stable state, parents will provide children the > initial stake needed for them to start transacting over such a system, just > as they already provide their children with other "initial stakes" > (education, food, shelter, etc.) anyway. > > > > > So are you saying that this is not doable without PTLCs (with simple > HTLCs) unless it's done like suggested? > > Yes, it is yet another reason we want PTLCs quickly. > > An alternative would be to have dual-hash HTLCs, which would be helpful in > other escrow-related cases including escrow-facilitated cross-currency > swaps. > Is there any disadvantage about using dual-hash HTLCs? Is it supported by the current LN spec? > > Regards, > ZmnSCPxj > > > > > > On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <zmnsc...@protonmail.com> wrote: > > > > > Good morning Nadav and Andres, > > > > > > Thank you for bringing up this topic again. > > > > > > Let me provide a new twist to this old idea. > > > > > > This is the entire logic of the contract to the seller: > > > > > > SELLER && (BUYER || ESCROW) > > > > > > Now, a big issue is that simple `&&` is trivial for PTLCs, it is the > `||` which is difficult and requires ECDH and proof that the ECDH was done > correctly. > > > > > > But we can observe the De Morgan Theorem: > > > > > > A || B <=> !(!A && !B) > > > > > > So how about we *invert* the logic? > > > > > > So what we do is, we make *two* payments of the same amount: > > > > > > * Seller -> Buyer , claimable by BUYER && ESCROW key. > > > * Buyer -> Seller, claimable by SELLER key. > > > > > > So the ritual is this: > > > > > > * Seller -> Buyer claimable by BUYER && ESCROW. > > > * Buyer -> Seller claimable by SELLER. > > > * Seller hands over item. > > > * Buyer judges whether to accept, or complain to Escrow. > > > > > > Now let us consider our cases: > > > > > > * Buyer is satisfied with the product. > > > * Buyer fails the Seller->Buyer payment after seller claims the > Buyer->Seller payment, so Seller is paid and has no more obligations. > > > * Buyer is dissastisfied and wants the Escrow to judge: > > > * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, > who then clawbacks the payment to the seller. > > > * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not > ESCROW"), and the Seller->Buyer payment eventually times out, ending the > obligation of the Seller. > > > > > > The "reverse" payment is effectively the inversion of logic by the De > Morgan theorem, and the "normal case" (buyer ultimately pays seller) has > the Escrow not revealing the privkey. > > > In addition, in the case where Buyer is satisfied (i.e. both Buyer and > Seller agree the trade is beneficial) the Escrow is never involved (the > Escrow might have a timeout for the temporary ESCROW keypair, which it will > eventually delete; since all payments on LN need a timeout anyway, this is > fine) and thus does not know about the trade, except that some trade was > requested (since it must provide a temporary ESCROW pubkey). > > > > > > This even provides a simple BUYER + ESCROW keypair that gives the > seller a proof-of-refund, and of course the simple SELLER gives the buyer a > proof-of-payment as well. > > > It only just requires twice as much Bitcoins getting locked. > > > > > > Thoughts? > > > > > > Regards, > > > ZmnSCPxj > > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev