--- Log opened Tue Aug 30 00:00:05 2022
01:57 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
02:06 < salvatoshi> Hi all! I have a question about safely signing transactions (eg. with a hardware signer) with miniscript policies containing older/after.
02:06 < salvatoshi> The flow I have now for all policies is that once you register a certain policy on the device, you can sign a transaction with the usual flow and UX (with the only difference that the registered policy name is shown on-screen).
02:06 < salvatoshi> After that, the checks the app makes and the UX are exactly the same for any policy, regardless if multisig, miniscript, etc. (let's assume P2WSH, as there are the obvious technical differences with legacy/taproot, or P2WPKH/P2WSH). That is, the device only shows to the user all non-change outputs and amounts, and the fees.
02:07 < salvatoshi> Generally, that's ok, as the worst that can happen is that the user signs an invalid transaction (eg.: already spent, or with non-existing prevouts).
02:07 < salvatoshi> Because of my lack of confidence in understanding of OP_CSV and OP_CLTV, I want to reassure myself that's the case also in the presence of older/after in miniscript. Is it still always safe to sign, or could there be situations where not having the right values for nSequence or nLockTime could be bad for the user?
04:58 < darosior> salvatoshi: i believe it's safe in the same way as not checking prevouts exist. There are 3 possibilities. 1) the timelock value in the tx (nSeq or nLock) is not valid (disabled (*) or not of the same type as the value in the Script). In this case the transaction is necessarily invalid. 2) the timelock value in the tx is valid, but strictly
04:58 < darosior> inferior to the value in the Script. In this case the transaction is also always invalid. 3) happy case, you signed a valid transaction with satisfied timelocks.
04:58 < darosior> (*) Disabled could be through nSequence being set to final for absolute locktimes, or version being < 2 or disabled bit set  for relative locktimes
05:24 < salvatoshi> darosior: thanks a lot for confirming it! That's what I thought, but I couldn't reach peace of mind after reading BIP-68/BIP-112
05:25 < darosior> Talking about timelocks, you did implement sanity checks in the Ledger? Like even if i tried i wouldn't be able to register a descriptor with timelock mixes?
05:56 < salvatoshi> yes, I should have all the same sanity checks you have in IsSane, and copied all the tests as well (up to a few months ago, so I guess I might miss a few; I'll double check later).
06:11 < darosior> Cool :)
08:41 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 260 seconds]
09:04 -!- Durableerin [~durableer@5.226.139.233] has joined ##miniscript
09:13 -!- Durableerin [~durableer@5.226.139.233] has quit [Ping timeout: 255 seconds]
12:55 -!- Netsplit *.net <-> *.split quits: FelixWeis, sanket_cell, kalle, appservicebot, MatrixBot1, sandipndev, darosior, afilini, andytosh1, sebx2a,  (+5 more, use /NETSPLIT to show all of them)
12:56 -!- Netsplit over, joins: darosior, MatrixBot1, sanket1729, achow101, hugohn_, andytosh1, afilini, sanket_cell, appservicebot, sandipndev (+5 more)
12:59 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Ping timeout: 255 seconds]
12:59 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 255 seconds]
12:59 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Ping timeout: 255 seconds]
15:18 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
15:18 -!- sipa [~sipa@user/sipa] has joined ##miniscript
15:18 -!- mode/##miniscript [+o sipa] by ChanServ
15:28 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined ##miniscript
--- Log closed Wed Aug 31 00:00:05 2022