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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
