< ElePHPhant> Can somebody please take a look at this question posted in 2014 which still applies today in 2019 for the latest stable Bitcoin Core on Windows? https://bitcoin.stackexchange.com/questions/23999/blocknotify-walletnotify-but-without-the-console-window
< ElePHPhant> This bug/issue/mistake/whatever-it-is is preventing me from running my Bitcoin payment system properly.
< jonasschnelli> I think wallet notify should finally be replaced with something more flexible...
< jonasschnelli> #13262 was my attempt
< gribble> https://github.com/bitcoin/bitcoin/issues/13262 | Wallet/RPC: Add listsincetx method with a stateless (server-side) long polling option by jonasschnelli · Pull Request #13262 · bitcoin/bitcoin · GitHub
< jonasschnelli> That PR includes a python scripts that demonstrate the push function
< jonasschnelli> (with pure RPC usage)
< jonasschnelli> Since its stateless and similar to "listsinceblock",... missing transactions is really hard
< ElePHPhant> jonasschnelli: Well, I use the notify things purely to know *when* to immediately do the normal polling of data from the API.
< ElePHPhant> jonasschnelli: It's done regularly anyway.
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/15382 | [util] add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
< provoostenator> The PR lists some alternative dependencies too. Maybe that can solve the Windows thing, but I have no idea.
< provoostenator> (I solved all my Windows problems 10+ years ago)
< sipa> provoostenator: by not using it anymore?
< ElePHPhant> Back.
< ElePHPhant> jonasschnelli: What happened to your suggestion?
< ElePHPhant> jonasschnelli: And will my bug be officially filed somehow now that I've reported it?
< sipa> ElePHPhant: not if you don't file it
< 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?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15868: rpc: Add have_pruned to getblockchaininfo (master...1904-rpcPruned) https://github.com/bitcoin/bitcoin/pull/15868
< ElePHPhant> Sigh... I guess not...
< ElePHPhant> I created an issue myself now...
< waxwing> can i ask what the "traditional partial signatures format" referred to on this line is? https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.h#L131
< 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 :)
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #15858: Faster tests with topological mempool rpc sync 🚀 (master...1904-qaSync) https://github.com/bitcoin/bitcoin/pull/15858
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/15717 | Changes to support NAT-PMP by MishraShivendra · Pull Request #15717 · bitcoin/bitcoin · GitHub
< 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?
< gribble> https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
< 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)
< dongcarl> gmaxwell: Roger
< gmaxwell> soft*
< bitcoin-git> [bitcoin] hebasto opened pull request #15886: qt, wallet: Revamp SendConfirmationDialog (master...20190424-send-confirmation-dialog) https://github.com/bitcoin/bitcoin/pull/15886
< bitcoin-git> [bitcoin] hebasto opened pull request #15887: docs: Align code example style with clang-format (master...20190424-coding-style) https://github.com/bitcoin/bitcoin/pull/15887