ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2021-02-11 đź“ť Original message: Good morning Andres, > ...
đź“… Original date posted:2021-02-11
đź“ť Original message:
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).
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.
Regards,
ZmnSCPxj
>
> On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <ZmnSCPxj at 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
Published at
2023-06-09 13:01:59Event JSON
{
"id": "c443f4d04b06f1aa14a0c99f94b945b6e7f2a7840ca88ce01c674e0e2ff5c930",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315719,
"kind": 1,
"tags": [
[
"e",
"314d09df8983f36a6cfef295360e46d7142fc01ed765a13fbdab5e1db6b5c415",
"",
"root"
],
[
"e",
"375c211bb9aa242a5133a50bd4ddae87c2c4a7d26e4a84fd77681057e51e47b7",
"",
"reply"
],
[
"p",
"8e5fc86df9a80e0d9988200f4374243d6e385a112063ed34067efb4edf2d802b"
]
],
"content": "📅 Original date posted:2021-02-11\n📝 Original message:\nGood morning Andres,\n\n\u003e 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?\n\nCorrect.\nThough 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.\nWithout it, the counterparty takes on increased risk (which translate to larger exchange spread).\n\nIn 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.\nPresumably, 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.\n\n\u003e\n\u003e So are you saying that this is not doable without PTLCs (with simple HTLCs) unless it's done like suggested?\n\nYes, it is yet another reason we want PTLCs quickly.\n\nAn alternative would be to have dual-hash HTLCs, which would be helpful in other escrow-related cases including escrow-facilitated cross-currency swaps.\n\nRegards,\nZmnSCPxj\n\n\n\u003e\n\u003e On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e \u003e Good morning Nadav and Andres,\n\u003e \u003e\n\u003e \u003e Thank you for bringing up this topic again.\n\u003e \u003e\n\u003e \u003e Let me provide a new twist to this old idea.\n\u003e \u003e\n\u003e \u003e This is the entire logic of the contract to the seller:\n\u003e \u003e\n\u003e \u003e   SELLER \u0026\u0026 (BUYER || ESCROW)\n\u003e \u003e\n\u003e \u003e Now, a big issue is that simple `\u0026\u0026` is trivial for PTLCs, it is the `||` which is difficult and requires ECDH and proof that the ECDH was done correctly.\n\u003e \u003e\n\u003e \u003e But we can observe the De Morgan Theorem:\n\u003e \u003e\n\u003e \u003e   A || B \u003c=\u003e !(!A \u0026\u0026 !B)\n\u003e \u003e\n\u003e \u003e So how about we *invert* the logic?\n\u003e \u003e\n\u003e \u003e So what we do is, we make *two* payments of the same amount:\n\u003e \u003e\n\u003e \u003e * Seller -\u003e Buyer , claimable by BUYER \u0026\u0026 ESCROW key.\n\u003e \u003e * Buyer -\u003e Seller, claimable by SELLER key.\n\u003e \u003e\n\u003e \u003e So the ritual is this:\n\u003e \u003e\n\u003e \u003e * Seller -\u003e Buyer claimable by BUYER \u0026\u0026 ESCROW.\n\u003e \u003e * Buyer -\u003e Seller claimable by SELLER.\n\u003e \u003e * Seller hands over item.\n\u003e \u003e * Buyer judges whether to accept, or complain to Escrow.\n\u003e \u003e\n\u003e \u003e Now let us consider our cases:\n\u003e \u003e\n\u003e \u003e * Buyer is satisfied with the product.\n\u003e \u003e  * Buyer fails the Seller-\u003eBuyer payment after seller claims the Buyer-\u003eSeller payment, so Seller is paid and has no more obligations.\n\u003e \u003e * Buyer is dissastisfied and wants the Escrow to judge:\n\u003e \u003e  * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who then clawbacks the payment to the seller.\n\u003e \u003e  * Escrow judges Seller is right: Escrow deletes ESCROW privkey (\"not ESCROW\"), and the Seller-\u003eBuyer payment eventually times out, ending the obligation of the Seller.\n\u003e \u003e\n\u003e \u003e 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.\n\u003e \u003e 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).\n\u003e \u003e\n\u003e \u003e 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.\n\u003e \u003e It only just requires twice as much Bitcoins getting locked.\n\u003e \u003e\n\u003e \u003e Thoughts?\n\u003e \u003e\n\u003e \u003e Regards,\n\u003e \u003e ZmnSCPxj",
"sig": "d8c5a69299a68e96644ec148389c15a54bfe08d5d7747770b286568d613f38d85acd5ed00935d9403b003855d30aa043234c8b6df18119c0e238ec120872367f"
}