There’s another potential partial solution here if we can create some
cryptographic protocol for atomically swapping information. This would be used
to swap the final HTLC sig for the hash preimage, preventing the optionality
issue. This idea was inspired by a paper called “Timed Commitments” by
Hello ZmnSCPxj,
> Do you mean, that if you make a swap on Lightning, which *might* be a
Bitcoin-to-WJT American Call Option, I will refuse to forward until I also
get something that is a WJT-to-Bitcoin call option, similar to a butterfly
spread?
> That implies that in the "normal", non-American-ca
Nadav,
This is an interesting proposal, but because this still requires the
customer to trust the merchant, I am concerned that it adds complexity
without any meaningful guarantee to the customer. Perhaps it makes sense to
at least include some extension field here that allows the merchant to
incl
Chris,
Thanks for that explanation. I could see how this makes sense for
lightweight data payloads because it reduces the round trip count, but I
agree with ZmnSCPxj that this could pose a DoS risk for larger data
payloads. This DoS risk is even more magnified for ZKCPs.
I would guess that APIs s
