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.
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
ChannelProposedMsgit creates signatures for theRatchetRound1TxandSettleOnlyWithHostTxand sends them to host. Guest does not check whetherEscrowAccount,GuestRatchetAccountandHostRatchetAccountare 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 ofEscrowAccount,GuestRatchetAccountandHostRatchetAccountbut 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
SettleWithHostTxand sending three signatures ofSettleWithHostTxalong withChannelProposedMsg– one signature created with the secret key ofEscrowAccount, one with the secret key ofHostRatchetAccountand one with the secret key ofGuestRatchetAccount.2.
The protocol rests on the assumption that
FinalityDelayis enough time for one party to successfully submit an up to dateRatchetTxwhen the counterparty submits an outdatedRatchtedTx. This requires that the maxtime of aRatchetTxis at leastFinalityDelaylarger than the maxtime of the precedingRatchetTx. However, this currently only holds if thePaymentTimebetween consecutive payments is at leastFinalityDelay. I guess that this is not desirable as it prevents payments at frequent intervals.3.
During payment, if sender receives
PaymentProposeMsgin statePaymentProposedand sender’s attempted payment was lower (i.e, it is about to transition into stateAwaitingPaymentMerge), then it should not increment itsRoundNumber(contrary to what is written in section "Conflict Resolution"). Reason: the validation of the nextPaymentProposeMsgwill fail and theRoundNumberwill be incremented by one upon receiving the nextPaymentProposeMsganyway (according to the description in section "Accepting payment").4.
What is the reason that
RoundSequenceNumberisBaseSequenceNumber + RoundNumber * 4instead of justBaseSequenceNumber + RoundNumber * 3which seems to be enough? This is not motivated sufficiently in the specification. EvenBaseSequenceNumber + RoundNumber * 2would 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.