Possible weaknesses of the specification

[TorstenStueber]

I have a few more question/remarks. I don't know whether this is the right place for this, so appologize.

1.

During channel opening when guest processes the ChannelProposedMsg it creates signatures for the RatchetRound1Tx and SettleOnlyWithHostTx and sends them to host. Guest does not check whether EscrowAccount, GuestRatchetAccount and HostRatchetAccount are owned by host. What if they are actually owned by guest (unknowingly in this situation)? This is not enough yet for host to actually get the funds out of EscrowAccount, GuestRatchetAccount and HostRatchetAccount but is certainly a first step in a possible attack and weakens guest's position.

Host should prove to guest that it is the owner of these three accounts, e.g., by creating SettleWithHostTx and sending three signatures of SettleWithHostTx along with ChannelProposedMsg – one signature created with the secret key of EscrowAccount, one with the secret key of HostRatchetAccount and one with the secret key of GuestRatchetAccount.

2.

The protocol rests on the assumption that FinalityDelay is enough time for one party to successfully submit an up to date RatchetTx when the counterparty submits an outdated RatchtedTx. This requires that the maxtime of a RatchetTx is at least FinalityDelay larger than the maxtime of the preceding RatchetTx. However, this currently only holds if the PaymentTime between consecutive payments is at least FinalityDelay. I guess that this is not desirable as it prevents payments at frequent intervals.

3.

During payment, if sender receives PaymentProposeMsg in state PaymentProposed and sender’s attempted payment was lower (i.e, it is about to transition into state AwaitingPaymentMerge), then it should not increment its RoundNumber (contrary to what is written in section "Conflict Resolution"). Reason: the validation of the next PaymentProposeMsg will fail and the RoundNumber will be incremented by one upon receiving the next PaymentProposeMsg anyway (according to the description in section "Accepting payment").

4.

What is the reason that RoundSequenceNumber is BaseSequenceNumber + RoundNumber * 4 instead of just BaseSequenceNumber + RoundNumber * 3 which seems to be enough? This is not motivated sufficiently in the specification. Even BaseSequenceNumber + RoundNumber * 2 would be enough if host accepts that guest is able to drain all funds out of the escrow account if the host accout does not exist anymore when submitting the settlement transactions – this is what host can similarly already do if the guest account does not exist anymore when submitting the settlement transactions.

[evgeniy-scherbina]

2.

This requires that the maxtime of a RatchetTx is at least FinalityDelay larger than the maxtime of the preceding RatchetTx.

It seems to me it doesn't require this condition, because Maxtime for RatchetTx is PaymentTime + FinalityDelay + MaxRoundDuration and anyway after MaxRoundDuration time party should either force close channel or make next off-chain payment thus increase Maxtime of latest RatchetTx.

Is it correct or I missed something?