Ohayou Hiroki-san,
I agree this possibility.
Of note is that this also helps support:
1. Cross-currency swaps without premium-free American Call Option.
Exchanges will demand for a premium to be paid for revelation of the second
preimage.
2. Non-custodial Escrow.
The second preimage is sh
Hi all,
I explained Stuckless Payments on the basis of PTLCs before and some people
understood that this is a proposal that can be accomplished after PTLCs are
introduced. But this can also be accomplished using HTLC variants that are
not compatible with BOLT 1.x HTLCs. For simplicity, I'd like to
Hi ZmnSCPxj and Bastien,
When I was putting together this proposal, I thought it would be difficult
for me to consider all the security and privacy issues. I am very glad that
you raised the possible issues.
> So my opinion, it is best to retain this property of "D does not know
payer A".
I agre
Good morning list,
> Another thought, is that this may also solve the "American Call Option"
> problem.
> In this case, the key at the final step is the sum of the payer key and the
> exchange key (`y0 + y1 + y2 + z` where payer knows `y0 + y1 + y2` and
> exchange knows `z`).
> Then intermedia
This is a very good proposal, thanks Hiroki for all those details it helped
me learn a lot.
If I'm not mistaken, https://eprint.iacr.org/2018/472.pdf has shown that we
MUST add another round
of communication if we want to avoid the wormhole attacks (and thus
decorrelate payments). While
I agree th
Good morning Hiroki,
Thank you for this.
It seems a good solution.
And, it seems, yet another reason to move to payment point / scalar from
payment hash / preimage.
As I understand it, the `y0+y1+...` sums are also the blinding tweaks used for
payment decorrelation.
My understanding, they will
Problem
===
With the current BOLT 1.x, there exists a theoretical possibility that
payments get stuck. In the actual network, this problem appears to be
significantly improved due to the maturity of each implementation and the
preventive ping-before-commitment_signed [
