Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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 and Bob can do something on the WJT blockchain at this stage. What will happen if they publish txs simultaneously?
> For example, Alice publishes WJT tx while Bob publishes the tx closing the channel.

I am uncertain what you refer to by the "WJT payment channel".
What I am proposing here is there is a single funding transaction that will output to a modified HTLC where hashlock is Alice+Bob while Timelock is Bob, spending inputs from both Alice (10,000 WJT) and Bob (1,000,000 WJT).

So let me rephrase the nearest question as I understand it:

* What happens when Alice broadcasts the funding tx at the same time as Bob double-spends his 1,000,000 WJT input?

As both transactions spend the same input (the 1,000,000 WJT from Bob) then what happens depends on the miners.
The miners decide which transaction is valid and gets confirmed onchain.

That is the reason why we need large timeouts in the HTLC constructions: we need to give enough time, not only to react to transactions being published, but also to have transactions become deeply confirmed.
Otherwise we could have made the timelocks so small as to be practically worthless as an option.

>
> Second, will the concurrent txs introduce some attacks?  I guess concurrent-while-conflicting txs lead to highly unpredictable behaviours.
> For example, Alice or Bob uses high tx fee to bribe miners to accept her/his tx, in order to gain some advantage on the concurrent txs?
> Also, the “whale transaction” works here. Will this introduce some double-spending variants?

Yes, that is why Alice and Bob need to wait for deep confirmations of the transactions involved.
Once deeply confirmed, they now know which way the protocol went and can safely perform the next step (or abort the protocol).

>
> Third, assume Bob doesn’t wait any more and closes the channel. In this case, Bob cannot get the premium.
> This is not consistent with the original American Call Option, in which Bob should still get the premium.

It does not matter, because Bob doing so *prevents* the option.

Think of it this way:

Suppose we were to meet face-to-face, in order for you to sell me an options contract.
Now, suppose I agree to buy the options contract.
But, while filling up the paperwork, you change your mind.

Until the paperwork is properly filled up, the option does not exist.
Thus, until the paperwork is properly filled,, the option is not exerciseable (and I should not pay anything to you since you did not push through with completing the option).

This is similar in effect.


>
> To conclude, I find this protocol highly depends on the implementation of the payment channel as well as the expertise of participants (Alice and Bob) c.f. relatively low usability.
> We may need a suitable payment channel implementation here. What’s your opinion on the payment channel suitable for this scenario?

Any payment channel has the problem of non-cooperation by the other side.
I already mentioned this before.
Again, this is always an issue regardless of the existence or non-existence of an `OP_LOOKUP_OUTPUT`: you have to execute onchain activity anyway in order to enforce anything offchain in case of non-cooperation, and adding in the possibility of various attacks makes it more likely that non-cooperation occurs.
It is the main reason why I think it is difficult to make Lightning support multiple currencies on the same network.

Usability can always be improved by proper software design; you do not worry about what voltage levels need to be transmitted over the wires in order to transmit your email to me, yet you probably consider your email client quite usable.

Regards,
ZmnSCPxj