📅 Original date posted:2022-03-06
📝 Original message:Good morning Chris,
> >On the other hand, the above, where the oracle determines *when* the fund can be spent, can also be implemented by a simple 2-of-3, and called an "escrow".
>
> I think something that is underappreciated by protocol developers is the fact that multisig requires interactiveness at settlement time. The multisig escrow provider needs to know the exact details about the bitcoin transaction and needs to issue a signature (gotta sign the outpoints, the fee, the payout addresses etc).
>
> With PTLCs that isn't the case, and thus gives a UX improvement for Alice & Bob that are using the escrow provider. The oracle (or escrow) just issues attestations. Bob or Alice take those attestations and complete the adaptor signature. Instead of a bi-directional communication requirement (the oracle working with Bob or Alice to build the bitcoin tx) at settlement time there is only unidirectional communication required. Non-interactive settlement is one of the big selling points of DLC style applications IMO.
>
> One of the unfortunate things about LN is the interactiveness requirements are very high, which makes developing applications hard (especially mobile applications). I don't think this solves lightning's problems, but it is a worthy goal to reduce interactiveness requirements with new bitcoin applications to give better UX.
Good point.
I should note that 2-of-3 contracts are *not* transportable over LN, but PTLCs *are* transportable.
So the idea still has merit for LN, as a replacement for 2-fo-3 escrows.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 23:05:10
in reply to nevent1q…zqts
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:05:10Event JSON
{
"id": "66ef52459619930a6063111c26ba8dc45c6ddf7247cfc7acc2785560cff017cd",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179110,
"kind": 1,
"tags": [
[
"e",
"4e296de6791e419fed77f6e3cdc93ce4cb4937b7488ba08e14a5b71934bcf305",
"",
"root"
],
[
"e",
"e45937fce1b134d53b7dcf8c9ba70037c93cc2970e90279d6614e2a4016fd4c0",
"",
"reply"
],
[
"p",
"e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817"
]
],
"content": "📅 Original date posted:2022-03-06\n📝 Original message:Good morning Chris,\n\n\u003e \u003eOn the other hand, the above, where the oracle determines *when* the fund can be spent, can also be implemented by a simple 2-of-3, and called an \"escrow\".\n\u003e\n\u003e I think something that is underappreciated by protocol developers is the fact that multisig requires interactiveness at settlement time. The multisig escrow provider needs to know the exact details about the bitcoin transaction and needs to issue a signature (gotta sign the outpoints, the fee, the payout addresses etc).\n\u003e\n\u003e With PTLCs that isn't the case, and thus gives a UX improvement for Alice \u0026 Bob that are using the escrow provider. The oracle (or escrow) just issues attestations. Bob or Alice take those attestations and complete the adaptor signature. Instead of a bi-directional communication requirement (the oracle working with Bob or Alice to build the bitcoin tx) at settlement time there is only unidirectional communication required. Non-interactive settlement is one of the big selling points of DLC style applications IMO.\n\u003e\n\u003e One of the unfortunate things about LN is the interactiveness requirements are very high, which makes developing applications hard (especially mobile applications). I don't think this solves lightning's problems, but it is a worthy goal to reduce interactiveness requirements with new bitcoin applications to give better UX.\n\nGood point.\n\nI should note that 2-of-3 contracts are *not* transportable over LN, but PTLCs *are* transportable.\nSo the idea still has merit for LN, as a replacement for 2-fo-3 escrows.\n\nRegards,\nZmnSCPxj",
"sig": "3274384b21c627e884948ea3117432dd57534b9b069660d85b7d73059fc450933663e5df750b9c40d01b6063e5b6c36a845676f5a3916a5b0f1429c6dd55c8c6"
}