Signature weight should be estimated at 73 based on BOLT-3 #1783
Conversation
lightning/src/ln/channel.rs
Outdated
| @@ -1676,7 +1676,7 @@ impl<Signer: Sign> Channel<Signer> { | |||
| 1 + // witness element count | |||
| 4 + // 4 element lengths (2 sigs, multisig dummy, and witness script) | |||
| self.get_funding_redeemscript().len() as u64 + // funding witness script | |||
| 2*(1 + 71); // two signatures + sighash type flags | |||
| 2*(1 + 71 + 1); // two signatures + sighash type flags + sig lengths | |||
There was a problem hiding this comment.
The length is accounted for two lines up. The reason for the difference is that signatures are variable length.
There was a problem hiding this comment.
ah, I see. so my comment is wrong, but the change is correct, right?
There was a problem hiding this comment.
i.e. it should be 2*(1 + 72)
devrandom
force-pushed
the
2022-10-sig-weight
branch
from
72c819c to
837c568
Compare
Codecov ReportBase: 90.69% // Head: 90.71% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1783 +/- ##
==========================================
+ Coverage 90.69% 90.71% +0.01%
==========================================
Files 87 87
Lines 47045 47045
Branches 47045 47045
==========================================
+ Hits 42669 42677 +8
+ Misses 4376 4368 -8
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
I believe this is wrong, going from https://bitcoin.stackexchange.com/questions/77191/what-is-the-maximum-size-of-a-der-encoded-ecdsa-signature/77192#77192 The DER encoding has 6 bytes of headers, plus the sighash type byte makes 7. Then we have max 33 bytes for R and 32 bytes for low-S. The lengths are included two lines up. That gives us 72 bytes plus the length. Note that the answer there was trying to give an absolute, absolute maximum and answer based on someone thinking the number was very high. In practice we can't use high-S anyway. Interestingly, because the shutdown negotiation uses absolute fees, not fee rates, I don't believe this can cause us to disagree with our peer, but I may be wrong about this. |
|
So this is not a protocol level issue, because the fees for mutual-close are negotiated as total fees rather than feerate. The only real concern is that we would have an unrelayable tx, or that fee negotiations will fail, right? Looking at the actual difference between 72 and 73 - it's all about low-S, and BOLT-3 in general doesn't assume it. Wouldn't it be a bit strange to not assume low-S for other tx types, but assume it for mutual-close? |
|
or another way to look at it - is BOLT-3 wrong to not assume low-S for everything? |
I think this makes sense. Even though it's just standardness, we kind of do need everything to relay in Lightning so we should always be using low-S. Maybe warrants opening an issue. |
|
Submitted lightning/bolts#1034 |
Indeed, an unrelayable tx would be the issue.
Yep, and high-S would be unrelayable, for other reasons :) I believe this can be closed here? |
No description provided.