Hi Micheal (and all),
> Perhaps we need another moderator or two for the lightning-dev mailing list?
> There are already a lot of emails on the bitcoin-dev mailing list and so
> despite my views on the trend of Bitcoin and Lightning discussion becoming
> increasingly intertwined it probably mak
Proposal Summary
The following proposal is intended to adapt the existing PTLC protocol into
Payment Route Reservation[1] flow. Modifying the original PTLC protocol
slightly, we get support for reusable static invoices with atomic proof of
payment and payer proofs, that don't
Hi Bastien,
In general, 0-conf is only safe when WE are the only contributor to
the channel, otherwise the peer could double spend us.
The problem you seem to be describing is that we might double-spend
ourselves if we don't lock our 0-conf UTXOs at some point. I propose
that we DO lock our UTXO
Hi everyone,
I was chatting with Tony Giorgio the other day and he made me aware of a
potential griefing attack that is possible today on LSPs that provide
Just-In-Time channels.
The attack is very simple, when the LSP receives the payment and then opens a
0-conf channel to the client, the cli
Hi benthecarman,
> the LSP can give the funding transaction signed using adaptor sigs to the
> client and the client can then decrypt the signatures and broadcast the
> transaction. Then the LSP can find the transaction in the mempool and extract
> the secret they need to claim the payment
Wha
Good morning benthecarman and SomberNight,
As noted by SomberNight, PTLCs does not quite fix this, as the client can still
wait out the inbound PTLC of the LSP and force the LSP to perform an onchain
action to ensure it does not give a channel for free.
Another wrinkle here is that the LSP can
Good morning Matt, and t-bast,
Your proposal basically means "do not dual-fund 0-conf".
You might as well use the much simpler openv1 flow in that case, just because
it is simpler.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, May 9th, 20
