Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-03 📝 Original message: Good evening, > I didn't ...
📅 Original date posted:2019-12-03
📝 Original message:
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 <ZmnSCPxj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191202/00acdf73/attachment-0001.html>;
📝 Original message:
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 <ZmnSCPxj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191202/00acdf73/attachment-0001.html>;