--- Log opened Wed Aug 14 00:00:22 2024
00:58 -!- sipa [~pw@user/sipa] has quit [Ping timeout: 244 seconds]
00:59 -!- sipa [~pw@user/sipa] has joined ##miniscript
00:59 -!- mode/##miniscript [+o sipa] by ChanServ
01:07 < darosior> Upgrading to 12.2 from 11.0, it seems the compiler is now significantly slower?
01:22 -!- Netsplit *.net <-> *.split quits: Earnestly, troglodito, FelixWeis__, stevenroose, katsu, DeanGuss, stickies-v
01:34 -!- Netsplit over, joins: stickies-v, DeanGuss, Earnestly, FelixWeis__, katsu, stevenroose, troglodito
02:09 < darosior> My descriptors unit tests in Liana went from running in 5s to running in >4m
02:37 < futurechimp> andytoshi I have tried putting an `after + 1` into the locktime (no joy). The forking idea is a good one, I'll have a crack at that
03:18 < futurechimp> Aha. The match at the `_satisfy` step is `Witness::Impossible`.
03:18 < futurechimp> Aha. The match at the `_satisfy` step is `Witness::Impossible`
03:19 < futurechimp> The input in question is:
03:19 < futurechimp> ```
03:19 < futurechimp> Input { non_witness_utxo: None, witness_utxo: Some(TxOut { value: 1000 SAT, script_pubkey: Script(OP_0 OP_PUSHBYTES_32 71474071e942320344bbcf8dda02343fbf1b9f93735b067d7c489fe2df966934) }), partial_sigs: {PublicKey { compressed: true, inner:
03:19 < futurechimp> PublicKey(f85b14f5e0819da95cf1aa6bfea7ab9e9cf83756ba3f23ffc7bd5aa6d32fc6e7e2144494e3906bcef95dc2796b6f7174b192ac4a85e95bcd51c59581a8f2b360) }: Signature { signature: 3044022022585027585d35be0f7924c12b681f80e0a6033f2e3fe1eaeb7bbc01dfa28d340220665aa2815a0857eb6e31d36610ed7bf6fc3c04069850f9cff2e5dab21bc3eb03, sighash_type: All }}, sighash_type: None,
03:19 < futurechimp> redeem_script: None, witness_script: Some(Script(OP_PUSHBYTES_33 02e7c62fd3a65abdc7ff233fba5637f89c9eaba7fe6baaf15ca99d81e0f5145bf8 OP_CHECKSIGVERIFY OP_PUSHBYTES_3 e80114 OP_CLTV)), bip32_derivation: {PublicKey(f85b14f5e0819da95cf1aa6bfea7ab9e9cf83756ba3f23ffc7bd5aa6d32fc6e7e2144494e3906bcef95dc2796b6f7174b192ac4a85e95bcd51c59581a8f2b360):
03:19 < futurechimp> (d5b22af2, )}, final_script_sig: None, final_script_witness: None, ripemd160_preimages: {}, sha256_preimages: {}, hash160_preimages: {}, hash256_preimages: {}, tap_key_sig: None, tap_script_sigs: {}, tap_scripts: {}, tap_key_origins: {}, tap_internal_key: None, tap_merkle_root: None, proprietary: {}, unknown: {} }```
03:19 < futurechimp> ```
03:19 < futurechimp> Input { non_witness_utxo: None, witness_utxo: Some(TxOut { value: 1000 SAT, script_pubkey: Script(OP_0 OP_PUSHBYTES_32 71474071e942320344bbcf8dda02343fbf1b9f93735b067d7c489fe2df966934) }), partial_sigs: {PublicKey { compressed: true, inner:
03:19 < futurechimp> PublicKey(f85b14f5e0819da95cf1aa6bfea7ab9e9cf83756ba3f23ffc7bd5aa6d32fc6e7e2144494e3906bcef95dc2796b6f7174b192ac4a85e95bcd51c59581a8f2b360) }: Signature { signature: 3044022022585027585d35be0f7924c12b681f80e0a6033f2e3fe1eaeb7bbc01dfa28d340220665aa2815a0857eb6e31d36610ed7bf6fc3c04069850f9cff2e5dab21bc3eb03, sighash_type: All }}, sighash_type: None,
03:19 < futurechimp> redeem_script: None, witness_script: Some(Script(OP_PUSHBYTES_33 02e7c62fd3a65abdc7ff233fba5637f89c9eaba7fe6baaf15ca99d81e0f5145bf8 OP_CHECKSIGVERIFY OP_PUSHBYTES_3 e80114 OP_CLTV)), bip32_derivation: {PublicKey(f85b14f5e0819da95cf1aa6bfea7ab9e9cf83756ba3f23ffc7bd5aa6d32fc6e7e2144494e3906bcef95dc2796b6f7174b192ac4a85e95bcd51c59581a8f2b360):
03:19 < futurechimp> (d5b22af2, )}, final_script_sig: None, final_script_witness: None, ripemd160_preimages: {}, sha256_preimages: {}, hash160_preimages: {}, hash256_preimages: {}, tap_key_sig: None, tap_script_sigs: {}, tap_scripts: {}, tap_key_origins: {}, tap_internal_key: None, tap_merkle_root: None, proprietary: {}, unknown: {} }
03:19 < futurechimp> ```
03:20 < futurechimp> Whoops, a bit out of practice with IRC, sorry. I need to re-install xchat I think :)
03:27 < futurechimp> So, `Witness::Impossible` has the docs string `No third party can produce a satisfaction without private key` , `Witness Impossible`
04:21 < futurechimp> https://github.com/rust-bitcoin/rust-miniscript/blob/master/src/miniscript/satisfy.rs#L1271 is where the `Impossible` gets returned.
04:50 < futurechimp> Tracing the problem through.
04:50 < futurechimp> I am attempting to satisfy an expression which has a timelock. In miniscript's internals, this comes out as: `after(AbsLockTime(1311208 blocks))`
04:50 < futurechimp> That gets evaluated inside the match at https://github.com/rust-bitcoin/rust-miniscript/blob/master/src/miniscript/satisfy.rs#L1271
04:50 < futurechimp> ```
04:50 < futurechimp> Terminal::After(t) => {
04:51 < futurechimp>                 let (stack, absolute_timelock) = if stfr.check_after(t.into()) {
04:51 < futurechimp>                     (Witness::empty(), Some(t))
04:51 < futurechimp>                 } else if root_has_sig {
04:51 < futurechimp>                     // If the root terminal has signature, the
04:51 < futurechimp>                     // signature covers the nLockTime and nSequence
04:51 < futurechimp>                     // values. The sender of the transaction should
04:51 < futurechimp>                     // take care that it signs the value such that the
04:51 < futurechimp>                     // timelock is not met
04:51 < futurechimp>                     (Witness::Impossible, None)
04:51 < futurechimp>                 } else {
04:51 < futurechimp>                     (Witness::Unavailable, None)
04:51 < futurechimp>                 };
04:51 < futurechimp>                 Satisfaction { stack, has_sig: false, relative_timelock: None, absolute_timelock }
04:51 < futurechimp> ```
04:51 < futurechimp>     /// `true` if satisfactions cannot be created by any 3rd party
04:51 < futurechimp>     /// who has not yet seen a satisfaction. (Hash preimages and
04:51 < futurechimp>     /// signature checks are safe; timelocks are not.) Affects
04:51 < futurechimp>     /// malleability.
04:51 < futurechimp> ```
04:55 < futurechimp> So the malleability is `safe` because the root of the transaction is signed and has a timelock (?) And this causes `Witness::Impossible` to be returned?
04:56 < futurechimp> I have a feeling that I have signed something wrongly in some dumb way, but I am not too sure how.
05:06 < futurechimp> Thinking about transaction malleability, and (if I'm right) the fact that OP_CLTV transactions are resistance against malleability problems wrt segwit (which this one is), my speculation is that `safe` is a way for miniscript to keep track of the fact that this particular transaction is `safe`, because it is (a) signed and (b) not a legacy
05:06 < futurechimp> transaction.
05:07 < futurechimp> What I don't understand is why my "safe" transaction is always then marked `Witness::Impossible`.
05:17 < futurechimp> What is also strange is that it says "timelocks are not [safe]" in those comments. So why is my timelock marked "safe"?
05:20 < futurechimp> The comment on `else if root_has_sig` seems to suggest (maybe?) that signing the root terminal is a bad idea?
05:20 < futurechimp> "If the root terminal has signature, the signature covers the nLockTime and nSequence values. The sender of the transaction should take care that it signs the value such that the timelock is not met."
05:21 < futurechimp> I think the root of my problem is that I don't understand what the second sentence means.
05:26 < futurechimp> I'm signing using Miniscript's `psbt.sighash_msg()` and the `bitcoin 0.32` crate's `SighashCache`: https://gist.github.com/futurechimp/d799a2279ff87772e0bdf3ade6cd71af#file-main-rs-L131
06:03 < andytoshi> futurechimp: can you print the descriptor (the output from policy.compile)
06:03 < andytoshi> the rules for and(pk,after) should be really simple and you shouldn't need to think about "safe" branches or anything
06:05 < andytoshi> in the first line that you posted `let (stack, absolute_timelock) = if stfr.check_after(t.into())` ... that if should come out to `true` 
06:05 < andytoshi> and then the function will return `(Witness::empty(), Some(t))` and you don't need to think about this
06:19 -!- futurechimp [~futurechi@davehry.plus.com] has quit [Quit: Client closed]
06:34 -!- futurechimp [~futurechi@davehry.plus.com] has joined ##miniscript
06:35 < futurechimp> I seem to have disconnected, hopefully that went through, but just in case: `compiled_vault_policy: and_v(v:pk(02e7c62fd3a65abdc7ff233fba5637f89c9eaba7fe6baaf15ca99d81e0f5145bf8),after(1311208))`
06:36 < futurechimp> Good point about that `let (stack, absolute_timelock)`, let me see what's in `stfr.check_after(t.into())`
06:39 < futurechimp> `t: 1311208`
06:39 < futurechimp> `stfr.check_after(t.into()): false`
06:40 < futurechimp> Ah yes I ran across this earlier, this seemed weird to me:
06:40 < futurechimp> ```
06:40 < futurechimp>     /// Assert whether an absolute locktime is satisfied
06:40 < futurechimp>     fn check_after(&self, _: absolute::LockTime) -> bool {
06:40 < futurechimp>         false
06:40 < futurechimp>     }
06:40 < futurechimp> ```
06:41 < futurechimp> Is `check_after` really supposed to be hardcoded to `false`?
06:42 < futurechimp> I'm at 12.0.0 tag in my rust-miniscript
06:42 < futurechimp> the head of `master` is the same
06:53 < futurechimp> It is the same (hardcoded to `false`) in 11.0.0, doesn't exist in 10.0.0 as there was no `plan` module in that version.
06:58 < futurechimp> Actually the `check_after` in 10.0.0 is also hardcoded to `false`, but it is in satisfy.rs
07:21 < futurechimp> whoops, that might just be the default trait implementation, which the editor takes me to
07:22  * futurechimp goes into the penalty box and feels shame
07:28 < futurechimp> The actual `check_after` in use fails here:
07:28 < futurechimp> `if !self.psbt.unsigned_tx.input[self.index].enables_lock_time() { return false;}`
07:29 < futurechimp> Where `pub fn enables_lock_time(&self) -> bool { self.sequence != Sequence::MAX }`
07:29 < futurechimp> `
07:32 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
07:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined ##miniscript
07:56 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
08:20 -!- futurechimp [~futurechi@davehry.plus.com] has quit [Quit: Client closed]
09:17 -!- futurechimp [~futurechi@davehry.plus.com] has joined ##miniscript
09:28 -!- futurechimp [~futurechi@davehry.plus.com] has quit [Quit: Leaving.]
09:29 -!- futurechimp [~futurechi@davehry.plus.com] has joined ##miniscript
12:17 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
12:18 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
15:40 < andytoshi> futurechimp: yes, any satisfiers that don't know about locktimes hardcode the checks to "false"
15:40 < andytoshi> you are supposed to use one that's locktime-aware (as you are, in PSBT) if you want locktimes to work
15:41 < andytoshi> futurechimp: oh, there you go. it looks like your transaction is disabling locktimes by setting the sequence number to 0xffffffff. see BIP 65 https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
15:42 < andytoshi> futurechimp: this is totally "your fault", but could you file an issue about this? we really should figure out how to return useful error information here
15:42 < andytoshi> because there is no way in hell anyone can be expected to get from "could not satisfy" to "the sequence number was set to disable locktimes"
15:43 < andytoshi> I think that in our satisfaction errors we should have some sort of hinting mechanism
19:11 -!- achow101_ [~achow101@user/achow101] has quit [Ping timeout: 255 seconds]
19:12 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
19:18 -!- achow101 [~achow101@user/achow101] has quit [Ping timeout: 252 seconds]
19:19 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
19:26 -!- achow101 [~achow101@user/achow101] has quit [Read error: Connection reset by peer]
19:41 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
20:04 -!- lbia [~lbia@user/lbia] has quit [Ping timeout: 260 seconds]
20:07 -!- lbia [~lbia@user/lbia] has joined ##miniscript
--- Log closed Thu Aug 15 00:00:23 2024