📅 Original date posted:2019-12-18
📝 Original message:
Hi ZmnSCPxj and Aj,
Thanks for starting this discussion ZmnSCPxj. Although transactions with
relative lock times are easily distinguishable today, couldn't this
situation be improved? Even just a few wallets changing their behaviour to
set relative time locks on normal payments would weaken the heuristic. From
a design perspective it feels like leaving the improvement vector open
would be better.
Aj's model of scriptless lightning is more or less what I had in my mind
(but with much better detail). On the question of "script based payment
points" or "fully scriptless": Why not just do both?
Since the tapscript version is faster to the "irrevocably committed" state,
you first do that so you can forward the payment as fast as possible. Now
that both parties have a commitment tx with a tapscript PTLC, they can (in
no hurry) sign the scriptless spending transactions from the PTLC output. I
think once they have signatures on their scriptless PTLC transactions they
can forget all the tapscript data (to minimize the data they have to store
per commitment tx).
> But with taproot you can have a script path as well, so you could have a
> script:
> A CHECKSIGVERIFY B CHECKSIG
> and supply a partial signature:
> R+X,s,X where s = r + H(R+X,A,m)*a
> to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
> log of X, and of course they can sign with B at any time. This is only
> half a round trip, and can be done at the same time as sending the "I
> want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
> spend. It's an extra signature on the sender's side and an extra
verification
> on the receiver's side, but I think it works out fine.
This is exactly how I thought the "script based payment point" would work
where you just replace the hashing with an CHECKSIG and an adaptor sig.
Like Z, I don't see how you can get away with just that though. I think you
need to do a full tapscript PTLC and revocation (1.5 round trips) before
you can forward a payment.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/b966b7d5/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:57:44
in reply to nevent1q…hjlk
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:57:44Event JSON
{
"id": "b19036c90f770ac6b4409854cc14fc7b8913d34fa3f776d260df0b99c5a642d6",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315464,
"kind": 1,
"tags": [
[
"e",
"38fb650ed77ac532241d05a44756544075d642e1b79abb819c1094f0e73bdf30",
"",
"root"
],
[
"e",
"ba411ab2ef2e3b7eab48dc96aa7fed923320c677256ea794126544c580567f39",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-12-18\n📝 Original message:\nHi ZmnSCPxj and Aj,\n\nThanks for starting this discussion ZmnSCPxj. Although transactions with\nrelative lock times are easily distinguishable today, couldn't this\nsituation be improved? Even just a few wallets changing their behaviour to\nset relative time locks on normal payments would weaken the heuristic. From\na design perspective it feels like leaving the improvement vector open\nwould be better.\n\nAj's model of scriptless lightning is more or less what I had in my mind\n(but with much better detail). On the question of \"script based payment\npoints\" or \"fully scriptless\": Why not just do both?\n\nSince the tapscript version is faster to the \"irrevocably committed\" state,\nyou first do that so you can forward the payment as fast as possible. Now\nthat both parties have a commitment tx with a tapscript PTLC, they can (in\nno hurry) sign the scriptless spending transactions from the PTLC output. I\nthink once they have signatures on their scriptless PTLC transactions they\ncan forget all the tapscript data (to minimize the data they have to store\nper commitment tx).\n\n\u003e But with taproot you can have a script path as well, so you could have a\n\u003e script:\n\n\u003e A CHECKSIGVERIFY B CHECKSIG\n\n\u003e and supply a partial signature:\n\n\u003e R+X,s,X where s = r + H(R+X,A,m)*a\n\n\u003e to allow them to satisfy \"A CHECKSIGVERIFY\" if they know the discrete\n\u003e log of X, and of course they can sign with B at any time. This is only\n\u003e half a round trip, and can be done at the same time as sending the \"I\n\u003e want to do a PTLC for X\" message to setup the (ultimately cheaper) MuSig\n\u003e spend. It's an extra signature on the sender's side and an extra\nverification\n\u003e on the receiver's side, but I think it works out fine.\n\nThis is exactly how I thought the \"script based payment point\" would work\nwhere you just replace the hashing with an CHECKSIG and an adaptor sig.\nLike Z, I don't see how you can get away with just that though. I think you\nneed to do a full tapscript PTLC and revocation (1.5 round trips) before\nyou can forward a payment.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/b966b7d5/attachment-0001.html\u003e",
"sig": "83c39d13a34cfab1e800b3fe2e75d4609dffd6a6a3c8f56991fc9a0d77723619988b84524f8b3e64bb5c7c6341628fe5b114159bd51b8e469a0f2dbe153e5b78"
}