rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2021-01-14 📝 Original message:Good Morning Kevin, > Inputs (mainly for pre-signed Tx): > ================================== > Problem: Poisoned inputs are a major risk for HW as they don't know the UTXO set. While this can be exploited for fee > attacks, it is a bigger threat to pre-signed transactions protocols. Once any input of a (pre-signed)transaction is > spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense > mechanism, spending any input would mean incapacitating the entire defense mechanism. > Proposed improvement: for protocols that requires it, keeping track of inputs already signed once would be extremely > helpful. Going further, most of these protocols require to follow a specific signing order (typically the "clawback" > first, then the regular spend path) so adding a way to check that a "clawback" has been signed first, with the same > input, would be very helpful. All of this on the dev > ice itself. This requires the hardware device to maintain some state in order to remember that the clawback has been signed before. My post on HW devices for Lightning (which you already linked) contains a suggestion to use a Merklized persistent data structure to maintain state for the hardware device, with a majority of the state storage on the trust-minimized software. The primary issue here is that we have a base assumption that the hardware wallet cannot be sophisticated enough to have Internet access; "do not enter seed words on an online device", as the typical advice goes. Most clawback transactions are time-based, and *must* be broadcast at a particular blockheight. Yet if the hardware wallet cannot be an online device, then it cannot know the current blockheight is now at a time when the clawback transaction *must* be broadcast. Thus, the hardware must always tr\*st the software to actually perform the clawback in that case. In protocols where clawbacks are at all necessary, often the counterparty can have an advantage / can steal if the clawback is not broadcast in a timely manner, thus the software that is corrupted by the counterparty can be corrupted to simply not broadcast the clawback. If the software on an online device cannot be tr\*sted (which is the model that hardware wallets use) then the software cannot be tr\*sted to provide correct information on the current blockheight to the offline hardware device, and cannot be tr\*sted to use clawback transactions. It seems to me that we cannot use the same model of "do not enter seed words on an online device" for any protocol with a time-based clawback component (and honestly there seems to be no clawback mechanism that is not time-based). Ultimately, I consider the blockchain as a proof of time passing, and as the blockchain is an online structure, we can only get at that proof by going online and actively searching for the block tip. Yet going online increases our attack surface. Regards, ZmnSCPxj