{"type":"rich","version":"1.0","title":"Conner Fromknecht [ARCHIVE] wrote","author_name":"Conner Fromknecht [ARCHIVE] (npub1za…uua2a)","author_url":"https://yabu.me/npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2a","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-12-03\n📝 Original message:\nGood evening,\n\n\u003e I didn't think this was the design.  The update transaction can spend any\nprior, with a fixed script, due to NOINPUT.\n\n\u003eFrom my reading of the final construction, each update transaction has a\nunique script to bind settlement transactions to exactly one update.\n\n\u003e My understanding is that this is not logically possible?\nThe update transaction has no fixed txid until it commits to a particular\noutput-to-be-spent, which is either the funding/kickoff txout, or a\nlower-`nLockTime` update transaction output.\n\u003e Thus a settlement transaction *must* use `NOINPUT` as well, as it has no\ntxid it can spend, if it is constrained to spend a particular update\ntransaction.\n\nThis is also my understanding. Any presigned descendants of a NOINPUT txn\nmust also use NOINPUT as well. This chain must continue until a signer is\nonline to bind a txn to a confirmed input. The unique settlement keys thus\nprevent rebinding of settlement txns since NOINPUT with a shared script\nwould be too liberal.\n\nCheers,\nConner\n\nOn Mon, Dec 2, 2019 at 18:55 ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Rusty,\n\u003e\n\u003e \u003e \u003e Hi all,\n\u003e \u003e \u003e I recently revisited the eltoo paper and noticed some things related\n\u003e \u003e \u003e watchtowers that might affect channel construction.\n\u003e \u003e \u003e Due to NOINPUT, any update transaction can spend from any other, so\n\u003e \u003e \u003e in theory the tower only needs the most recent update txn to resolve\n\u003e \u003e \u003e any dispute.\n\u003e \u003e \u003e In order to spend, however, the tower must also produce a witness\n\u003e \u003e \u003e script which when hashed matches the witness program of the input. To\n\u003e \u003e \u003e ensure settlement txns can only spend from exactly one update txn,\n\u003e \u003e \u003e each update txn uses unique keys for the settlement clause, meaning\n\u003e \u003e \u003e that each state has a unique witness program.\n\u003e \u003e\n\u003e \u003e I didn't think this was the design. The update transaction can spend\n\u003e \u003e any prior, with a fixed script, due to NOINPUT.\n\u003e \u003e\n\u003e \u003e The settlement transaction does not use NOINPUT, and thus can only\n\u003e \u003e spend the matching update.\n\u003e\n\u003e My understanding is that this is not logically possible?\n\u003e The update transaction has no fixed txid until it commits to a particular\n\u003e output-to-be-spent, which is either the funding/kickoff txout, or a\n\u003e lower-`nLockTime` update transaction output.\n\u003e Thus a settlement transaction *must* use `NOINPUT` as well, as it has no\n\u003e txid it can spend, if it is constrained to spend a particular update\n\u003e transaction.\n\u003e\n\u003e Unless I misunderstand how update transactions work, or what settlement\n\u003e transactions are.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-- \n—Sent from my Spaceship\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191202/00acdf73/attachment-0001.html\u003e"}