Hello Runchao and ZmnSCPxj,
I think we can simplify the explanation here by not using joint signatures
and payment channel like constructions. ZmnSCPxj's more complex
construction could be more dynamic and practical in some settings but at
least for me it gets in the way of capturing how this rela
Hi ZmnSCPxj,
Thanks for your explanation. It’s comprehensive.
I think our disagreement is on the step 6.
In step 6,
- Alice can publish or withhold the WJT tx
- Bob can wait or unilaterally close the WJT payment channel
I see the following things:
First, both Alice and Bob can do something on
Good morning Runchao,
> Thanks for your explanation. It’s comprehensive.
>
> I think our disagreement is on the step 6.
> In step 6,
>
> - Alice can publish or withhold the WJT tx
> - Bob can wait or unilaterally close the WJT payment channel
>
> I see the following things:
>
> First, both Alice a
Good morning Runchao,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, August 12, 2019 11:19 AM, Runchao Han wrote:
> Good morning ZmnSCPxj,
>
> Sorry for the ambiguity of my last email. It was Sunday and I wrote it in 1
> min on my bed. Let me elaborate what we
Good morning ZmnSCPxj,
Sorry for the ambiguity of my last email. It was Sunday and I wrote it in 1 min
on my bed. Let me elaborate what we are thinking of here.
## Analysis on the protocol from Fournier et al.
In this protocol, Bob participates in the swap following the steps below:
1. Alice
If I remember it right, Alice first signs the WJT transaction, sends it to
Bob, then Bob signs it and makes this transaction valid.
If so, there are two problems.
First, Bob gets the valid tx first, and he can choose not to send it to
Alice.
Second, even if Bob honestly sends Alice this tx, Alice
Good morning Runchao,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, August 10, 2019 1:44 PM, Runchao Han
wrote:
> Hi ZmnSCPxj,
>
> Thanks for your reply.
>
> I agree with your opinions about OP_LOOKUP_OUTPUT.
> Indeed, the pruning mechanism renders this op
Hi ZmnSCPxj,
Thanks for your reply.
I agree with your opinions about OP_LOOKUP_OUTPUT.
Indeed, the pruning mechanism renders this opcode unrealistic for some nodes.
Also, the execution of OP_LOOKUP_OUTPUT depends on the time of verifying this
tx.
However, I’m concerning of some security issue
Good morning Haoyu LIN et al.,
> We have investigated this problem in very detail. We analysed how profitable
> the arbitrage can be given the default timelock setting (24/48 hrs). Our
> result shows that the profit can be approximately 1% ~ 2.3%, which is
> non-negligible compared with 0.3% f
