< ElePHPhant>
jonasschnelli: But those *notify things make it much snappier.
< ElePHPhant>
Must take a walk to avoid going insane.
< ElePHPhant>
Will come back soon.
< provoostenator>
ElePHPhant jonasschnelli: related #15382 adds boost process as a dependency, which gives us more flexility on how to execute commands.
< sipa>
seems there is a fix in that stackexchange answer too; seems like a no-brainer to apply it, but it'll need developing on windows to champion it
< sipa>
(even if just to know that it works)
< ElePHPhant>
sipa: Any chance you could file the issue for me? So it's done right?
< cfields>
wumpus: fyi, I'll be away and unable to sign releases Friday-Tuesday. Headed to Boston to sign the docs for our new place there :)
< instagibbs>
anyone know why data carrier outputs have to be push-only in relay policy?
< instagibbs>
seems wasteful for no reason
< harding>
waxwing: I think it's just talking about when you have fewer than the needed number of signatures. E.g., you need 2 signatures but you call signrawtransactionwithprivatekey (or whatever untweetable name it has) with only one key. You'll get your input transaction returned back to you with the push of just that single signature in it and an "incomplete" flag in a separate field.
< harding>
waxwing: I don't think it means partial in the sense of less-than-one signatures.
< harding>
instagibbs: maybe to avoid people putting CHECKSIG-type opcodes in there that would count towards the block's sigop limit even though we know they'd never be evaluated (and that counting sigops in scriptPubKeys is wrong)?
< instagibbs>
harding, ehhh just count those then :) (good point regardless)
< instagibbs>
it would also mess with the "virtual size" right?
< waxwing>
harding, makes sense thanks. i always end up looking up the difference between witnessscript and scriptwitness hence i end up there, the question was only tangential :)
< dongcarl>
w/re #15717, I wish to stop confusing the poor man. I think we should make it a shared library dependency just as we do with `miniupnp`, in that case, we should not submit any more reviews on the subtree-d code which should be removed and make it clear that we really need is another depends package.
< dongcarl>
My reading of #11902 was that we'll keep uPNP as an option that's off by default, and introduce NAT-PMP as ON by default, which I'm not sure how I feel about. wumpus perhaps you can enlighten me?
< gmaxwell>
dongcarl: do you think wumpus is your shrink? you appear to be asking him to advise you on your feelings. :)
< dongcarl>
Hahahaha well... I guess more concretely I'm asking for any info I might be missing :-)
< gmaxwell>
miniupnp library is a security disaster-- adhoc xml parsing using lulzical pointer frobbing, nothing has changed about that AFAIK.
< * dongcarl>
adds lulzical pointer frobber to his list of insults
< gmaxwell>
And thats pretty bad since by its very nature its exposed to untrustworthy network inputs ... So we're unwilling to enable it by default because it continues to look like a timebomb.
< dongcarl>
that makes sense for sure
< gmaxwell>
(Ideally we'd replace the library with something that isn't so terror inducing, but at least when we looked before there wasn't anything.. in part because upnp is an awful spec...)
< dongcarl>
So given that NAT-PMP is a much simpler protocol that's harder to footgun, we can enable it by default, because if someone's got a NAT-PMP server on their gateway they're most likely okay with auto-port forwarding?
< gmaxwell>
dongcarl: the on/off by default dosn't have anything to do with being okay with port forwarding.
< gmaxwell>
It's entirely because of the multiple past RCE bugs in that particular library and the codebase that looks like it'll have more in the future.
< dongcarl>
gmaxwell: Okay, so should NAT-PMP be on by default or no?
< gmaxwell>
Yes
< gmaxwell>
dongcarl: it should be on by default, unless turned off-- and solf-set off by discover being off (either directly off, or indirectly off via listen off)