That is correct, the chain of noinput/anyprevout transactions is broken as soon as the signers are online and can interactively bind and sign without noinput/anyprevout.
Conner Fromknecht <conner@lightning.engineering> writes: > Good evening, > >> I didn't think this was the design. The update transaction can spend any > prior, with a fixed script, due to NOINPUT. > > From my reading of the final construction, each update transaction has a > unique script to bind settlement transactions to exactly one update. > >> My understanding is that this is not logically possible? > The update transaction has no fixed txid until it commits to a particular > output-to-be-spent, which is either the funding/kickoff txout, or a > lower-`nLockTime` update transaction output. >> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no > txid it can spend, if it is constrained to spend a particular update > transaction. > > This is also my understanding. Any presigned descendants of a NOINPUT txn > must also use NOINPUT as well. This chain must continue until a signer is > online to bind a txn to a confirmed input. The unique settlement keys thus > prevent rebinding of settlement txns since NOINPUT with a shared script > would be too liberal. > > Cheers, > Conner > > On Mon, Dec 2, 2019 at 18:55 ZmnSCPxj <zmnsc...@protonmail.com> wrote: > >> Good morning Rusty, >> >> > > Hi all, >> > > I recently revisited the eltoo paper and noticed some things related >> > > watchtowers that might affect channel construction. >> > > Due to NOINPUT, any update transaction can spend from any other, so >> > > in theory the tower only needs the most recent update txn to resolve >> > > any dispute. >> > > In order to spend, however, the tower must also produce a witness >> > > script which when hashed matches the witness program of the input. To >> > > ensure settlement txns can only spend from exactly one update txn, >> > > each update txn uses unique keys for the settlement clause, meaning >> > > that each state has a unique witness program. >> > >> > I didn't think this was the design. The update transaction can spend >> > any prior, with a fixed script, due to NOINPUT. >> > >> > The settlement transaction does not use NOINPUT, and thus can only >> > spend the matching update. >> >> My understanding is that this is not logically possible? >> The update transaction has no fixed txid until it commits to a particular >> output-to-be-spent, which is either the funding/kickoff txout, or a >> lower-`nLockTime` update transaction output. >> Thus a settlement transaction *must* use `NOINPUT` as well, as it has no >> txid it can spend, if it is constrained to spend a particular update >> transaction. >> >> Unless I misunderstand how update transactions work, or what settlement >> transactions are. >> >> Regards, >> ZmnSCPxj >> > -- > —Sent from my Spaceship > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
