--- Log opened Wed Feb 01 00:00:32 2023
05:22 < andytoshi> sipa: so, instagibbs was bugging me about the hash opcodes and i think maybe there's a dumb inefficiency here (though i'm unsure that we can fix it now without breaking miniscript, which i don't think we can do anymore without a 2.0 or something)
05:22 < andytoshi> in particular, our hash construction is SIZE <32> EQUALVERIFY SHA256 <h> EQUAL (and essentially the same for all hashes)
05:23 <@sipa> yeah
05:23 < andytoshi> one sec, i might be being stupid here :)
05:24 < andytoshi> i had thought, in the case that we v-wrap this, the EQV becomes EQUALVERIFY and then the SIZE check isn't needed anymore
05:24 < andytoshi> but the size check is on the *input* to the hash, not the *output*
05:24 < andytoshi> yeah never mind
05:25 < andytoshi> but my thought was, we could make the hash construction always be SHA256 <h> EQV .. and then if you wanted a non-V form you could wrap it with j, which would take exactly as many bytes as the existing thing
05:25 < andytoshi> so you'd get an improvement in the V case but no chaneg in the non-V case
05:25 < andytoshi> but i'm worng
05:25 < andytoshi> so never mind :P
05:27 < andytoshi> now i'm remembering ... the SIZE <32> EQV thing is there to ensure that hash preimages are always exactly 32 bytes, for the purpose of avoiding attacks on cross-chain swaps where you make your preimage so long that one blockchain will accept it but not the other
05:27 < andytoshi> instagibbs: ^ that is the purpose of the SIZE 32 EQV check
05:27 <@sipa> indeed!
05:31 < andytoshi> instagibbs: if you're feeling generous maybe you could PR to sipa's miniscript site adding a note explaining this ... because this one is a bit of an oddball and if you think of miniscript as purely a bitcoin thing then the size check is not actually necessary
05:31 < andytoshi> but we explicitly imagined the hashcheck as being there for atomic swaps, and we wanted to make sure it was secure for that purpose
05:31 < darosior> +1 for a note i had to explain it to benma last week
05:32 < darosior> And had to dig through the logs to find another rationale than "avoid largely increasing the max potential witness size" :)
05:32 < andytoshi> at the time, we did not think LN would ever bother with miniscript because miniscript was less efficient than the existing HTLC construction. so the only use for hashlocks was atomic swaps
05:33 < andytoshi> now i'm kinda curious ... if we took the minisrcipt HTLC construction (which i forget the details of) and removed the SIZE 32 EQV from it, would it be even smaller?
05:35 < andytoshi> ah! yes it is ... and in fact this is on sipa's site
05:35 < andytoshi> as an "example policy"
05:35 < andytoshi> so there's an interesting question .. do we want to add a "unsafe hashlock" (i think adding fragments is fine and non-breaking) for this purpose
05:36 < andytoshi> my guess is no, since LN is now going to taproot and PTLCs and doesn't care about hashlocks anymore
05:36 < andytoshi> instagibbs: ^
05:36 <@sipa> yeah, we can
05:36 < darosior> So by standardness the maximum invalid preimage one could use to try to increase the spend transaction size (could be useful for pinning) would in fact be 80 (100 for P2WSH). So i think it's not really a concern there.
06:31 < instagibbs> nice thanks
06:31 < instagibbs> andytoshi, PTLCs arent imminent yet, they require path-wide adoption
06:34 < instagibbs> it also matters I think in that an attacker could claim an HTLC that has a too-large-for-standardness preimage, but then you are unable to claim the incoming without miner help(I think)
06:43 < instagibbs> in other words, I think the size check is crucial for any serious usage
07:03 < darosior> instagibbs: you can always do that though? Make the preimage path unspendable i mean. The `SIZE 32 EQV` check doesn't prevent it
07:04 < darosior> It's just that since you choose it for your own spending path you are shooting yourself in the foot
07:04 < instagibbs> it's fine if it's invalid along whole path, atomically speaking 
07:04 < instagibbs> if you forward an HTLC, the receiver has mining buddies, gets it mined, you are left hanging with incoming
07:06 < instagibbs> standardness/private relay vs cross-chain
07:09 < darosior> Hmm right
07:11 < darosior> instagibbs: well today's scripts would be vulnerable to that already https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
07:11 < darosior> But i guess if you have a channel with a malicious partner that has some hashrate at his disposal there are 99 other ways you can get attacked already so...
07:12 < instagibbs> I think that weird swap area checks for size 32? Honestly it's hard to read, haha
07:12 < instagibbs> I last carefully read these BOLTs like 10 months ago
07:13 < instagibbs> pretty sure it's if size 32 -> preimage, else, it's timeout sig (veerying a bit off topic I suspect)
07:13 < darosior> Oh right nevermind i didn't read it carefully
07:14 -!- roze_paul [~quassel@142.243.254.224] has joined ##miniscript
07:14 -!- roze_paul [~quassel@142.243.254.224] has quit [Client Quit]
07:14 < darosior> Yeah, sorry for the OT
07:21 < instagibbs> more on-topic is a very cute hack to save 1 WU if you're using a sig+1 block csv timeouts that isn't miniscript compatible: https://github.com/lightning/bolts/pull/995#discussion_r1091181989
08:14 -!- roze_paul [~quassel@142.243.254.224] has joined ##miniscript
09:05 < andytoshi> that's a cool observation about standardness limits vs consensus limits
09:05 < andytoshi> so even on bitcoin the check is necessary
09:05 < andytoshi> we should definitely write that down lol, i'm not gonna remember it
09:08 < instagibbs> I sent up a PR to sipa's repo to add some brief text but maybe being super explicit is better
11:11 -!- roze_paul [~quassel@142.243.254.224] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:32 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
11:36 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
11:40 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
12:20 -!- jon_atack [~jonatack@user/jonatack] has joined ##miniscript
13:16 -!- alanturing [~alanturin@50.229.26.248] has joined ##miniscript
13:18 -!- alanturing [~alanturin@50.229.26.248] has quit [Remote host closed the connection]
18:13 -!- scg [~scg@161.132.197.96] has joined ##miniscript
21:23 -!- achow101 [~achow101@user/achow101] has quit [Ping timeout: 255 seconds]
21:33 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
--- Log closed Thu Feb 02 00:00:32 2023