--- Log opened Mon Aug 01 00:00:37 2022
09:55 -!- afilini [~afilini@2001:bc8:1828:245::2] has joined ##miniscript
09:55 < afilini> andytoshi: sanket1729: would you be against a pr that bumps the signature weight in `max_satisfaction_weigh` to account for non-grinded signatures (high-r) ?
09:56 < andytoshi> high-r is (nearly) free and is done in Core .. i'd rather avoid deviating from core, especially in a negative direction, if we can
09:57 < andytoshi> OTOH i don't care too much about being suboptimal with ECDSA anymore :)
09:57 < afilini> currently the docs says "Assumes all ec-signatures are 73 bytes, including push opcode and sighash suffix.", so it essentially assumes all signatures are low-s and low-r. in theory the worst case is actually 74 bytes for segwit (if i recall correctly high-s signatures are forbidden by consensus) and 75 for legacy (because low-s is just a standardness rule)
09:57 < andytoshi> i think that's all correct
09:57 <@sipa> I don't think high-s is forbidden by consensus. It's nonstandard, though.
09:59 < afilini> yeah the problem arises when you can't control the code of the signer, maybe for hardware devices/hsms
10:00 < andytoshi> yeah, that sounds totally reasonable to me
10:00 < andytoshi> sanket1729: thoughts?
10:00 < afilini> there's been a bit of discussion here if you are interested: https://github.com/bitcoindevkit/bdk/issues/695
10:00 <@sipa> Assuming low-s is reasonable in miniscript. Assuming low-r sounds like it may need to be configurable, or use the conservative option of assuming high-r.
10:01 < andytoshi> i think early on i'd considered adding an API that would let you specify reduced signature sizes for smart signers (e.g. i sometimes sign txes on my laptop which could easily grind off several bytes from ECDSA sigs) but the API complexity seemed too high for something so niche
10:01 < andytoshi> and given that, we ought to be maximally conservative
10:01 -!- meshcollider [meshcollid@jujube.rpblc.net] has quit [Ping timeout: 272 seconds]
10:01 < afilini> if it was easier to do we could do it ourselves in bdk, but it's not trivial to figure out how many signatures can end up in a scriptsig/witness in the worst case (to account for the extra potential weight)
10:02 <@sipa> It wouldn't be impossible to just add a way to specify this to descriptors.
10:02 <@sipa> Some kind of flag on key expressions to indicate whether low-r may be assumed for its corresponding signatures.
10:02 < andytoshi> true -- though for ECDSA/legacy it's maybe not worth the hassle
10:02 <@sipa> yes, indeed
10:03 < afilini> sipa: yeah my argument is that a method called `max_satisfaction_weight()` implemented on a descriptor should return the absolute worst case possible
10:03 < andytoshi> afilini: after thinking about it a couple minutes, concept ACK from me on adding a byte to rust-minisript's weight estimation
10:03 < andytoshi> separately i would kinda like a way to estimate costs for grinded sigs .. but i don't feel as strongly as i used to
10:04 < afilini> in theory that's high-s + high-r, though maybe as you said low-s signatures have been around for so long that we can ignore that case
10:04 < andytoshi> (i used to work on liquid's signing logic, where we have 11 sigs all being produced on reasonably strong hardware, so potentially big savings ... but i've moved away from that stuff lately)
10:04 <@sipa> Miniscript already assumes "well-established" standardness rules in its design for way more than this.
10:04 <@sipa> I don't think assuming low-s is a problem at all.
10:05 < andytoshi> yeah, low-s sigs are (usually) just as big as high-s ones IIRC
10:05 < afilini> sipa: yes, makes sense
10:05 < andytoshi> it's just that high-s is _always_ 32 bytes for s, while low-s sometimes is less
10:05 < afilini> i used this as a reference which actually says they can be larger: https://b10c.me/blog/006-evolution-of-the-bitcoin-signature-length/
10:05 <@sipa> andytoshi: high-s adds 1 byte compared to low-s. high-r adds 1 byte compared to low-r.
10:06 <@sipa> https://bitcoin.stackexchange.com/questions/112662/what-is-the-probability-of-an-ecdsa-signature-being-less-than-71-bytes
10:07 <@sipa> afilini: low-r low-s ECDSA signatures are (max, and almost always) 72 bytes. Add a sighash byte, 73. Add a push opcode, 74.
10:07 < andytoshi> ah right! because DER encodes our (unsigned) values as signed ones, so a high 1 bit forces an extra 0 byte
10:07 <@sipa> andytoshi: exactly
10:46 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript
--- Log closed Tue Aug 02 00:00:39 2022