< esotericnonsense> is it expected behaviour that repeated calls to fundrawtransaction will result in new change addresses being used even if the set of inputs is identical?
< sipa> define "set of inputs is identical" ?
< sipa> ah, you're calling fundrawtransaction with the same input multiple times?
< esotericnonsense> yes, basically it'll use the exact same coins as inputs each time (unless the algo was non-deterministic, why wouldn't it)
< sipa> yes, those change addresses are marked in use by the fundrawtransaction RPC, regardless of whether the resulting transaction is broadcast or not
< esotericnonsense> and then just burn through change addresses
< esotericnonsense> hm. okay. I guess I need to getnewaddress and handle that manually.
< sipa> use getrawchangeaddress instead
< esotericnonsense> aha.
< esotericnonsense> so you end up with a workflow a bit like this then; getrawchangeaddress (store this in a DB or whatever); do a bunch of fundrawtransactions with that change address; once you're happy, do "ismine" checks (e.g. look at getaddressinfo, listreceivedbyaddress) immediately prior to signing
< sipa> or you can use PSBT
< esotericnonsense> it seems that PSBT doesn't really add anything for the single-signature case
< sipa> decodepsbt will tell you the fee explicitly, for example
< sipa> something that decoderawtransaction can't do
< sipa> but fair, its advantages are more relevant in multiparty or at least multi-device settings
< esotericnonsense> yeah, though maybe it makes sense to just use it, walletcreatefundedpsbt seems to do basically what I'm after in one step
< esotericnonsense> i'm just trying to avoid reinventing the wheel since it feels like holding this change address around is a bit silly; I almost want a transaction that has a dummy change address in it that's invalid but otherwise would have the same fee, so that bitcoind could just swap out the dummy for a real change address immediately prior to signing, then there's no external state
< bitcoin-git> [bitcoin] qubenix opened pull request #14729: correct -onion default to -proxy behavior (master...qubenix-proxyfix) https://github.com/bitcoin/bitcoin/pull/14729
< jkjk> hi
< sipa> hi
< gmaxwell> hi
< gmaxwell> is it time for the new midnight meeting?
< gwillen> gmaxwell: it seems like midnightmagic would need to moderate, for reasons of nominative determinism
< esotericnonsense> sipa: thanks for the help earlier. i have it working now (ignoring the change address issues). think i'll deal with that later on since i don't care about bloating a testnet wallet
< promag> does appveyor merges with master before build and test?
< cjd> Does anybody happen to know what was the largest (in number of bytes) transaction ever created ?
< cjd> oh wow, thank you
< bitcoin-git> [bitcoin] dongcarl opened pull request #14731: Improve scripted-diff developer docs (master...patch-4) https://github.com/bitcoin/bitcoin/pull/14731
< promag> hebasto: thanks, I wonder if it's possible to rebase with a different branch
< esotericnonsense> sipa: in case you were interested, the results of the psbt stuff from yesterday...
< esotericnonsense> (the gray box is a javascript QR scanner)\
< esotericnonsense> so this is all self hosted using bitcoind rpc, very much testnet stuff atm though
< promag> "omg send"? :D
< esotericnonsense> the gray box is using decodepsbt
< esotericnonsense> promag: i have a really bad habit of using stupid names for everything all over my code
< promag> lgtm :D
< esotericnonsense> not "unsensible variable names", but rather stuff like panic!("omg it's all gone terribly wrong NOOOOOOOOOO")
< instagibbs> in functional tests how do i set up nodes with no connections to peers?
< instagibbs> got it, override setup_network
< MarcoFalke> 6:59 PM
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Nov 15 19:00:04 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
< provoostenator> hi
< meshcollider> hi
< promag> hi
< kanzure> hi.
< wumpus> proposed topics?
< wumpus> #topic high priority for review
< sipa> hi.
< phantomcircuit> hi
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 current high priority PRs are by luke-jr promag achow101 phantomcircuit sipa
< meshcollider> Maybe #14552
< wumpus> anything to add or remove for this week?
< gribble> https://github.com/bitcoin/bitcoin/issues/14552 | wallet: detecting duplicate wallet by comparing the db filename. by ken2812221 · Pull Request #14552 · bitcoin/bitcoin · GitHub
< instagibbs> hi
< wumpus> meshcollider: added
< meshcollider> Thanks
< promag> regarding #14670, it is possible to have appveyor rebase on that instead of master?
< gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
< wumpus> luke-jr: please rebase #14532
< gribble> https://github.com/bitcoin/bitcoin/issues/14532 | Never bind INADDR_ANY by default, and warn when doing so explicitly by luke-jr · Pull Request #14532 · bitcoin/bitcoin · GitHub
< wumpus> (should be a small change)
< provoostenator> I like to nominate #11082
< gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< promag> I saw several connection problems in some PR's in appveyor and I think 14670 fixes that
< provoostenator> Since I have PR that depends on that.
< wumpus> provoostenator: I don't know anything about appveyor
< MarcoFalke> promag: You'd have to fixup the appveyor yaml, I'd presume
< wumpus> provoostenator: luke-jr already has a PR
< wumpus> really, let's try to get the INADDR_ANY in, it's silly that it takes so long
< wumpus> it's an important security issue in a way
< wumpus> buut I'm fine with adding the _rw one as well if others agree...
< promag> MarcoFalke: you mean manually rebase? because from https://www.appveyor.com/docs/appveyor-yml/ I don't see that's possible out of the box
< MarcoFalke> Git should be installed on the machine, so you could do "git fetch https://github.com/promag/bitcoin branch && git merge FETCH_HEAD" before compiling?
< promag> MarcoFalke: do you think that could go to master temporally?
< provoostenator> wumpus: I'm fine with waiting until this more urgent PR is done, I'll try to help with review
< sipa> i think merging it is preferable
< sipa> (after review, of course)
< wumpus> merging it is certainly preferable, if we can be confident of it
< promag> ok then
< phantomcircuit> wumpus, im reviewing that one now
< MarcoFalke> phantomcircuit: Thx
< wumpus> it's the so-manieth time that particular part of the code was fixed, so I certainly understand people are a bit skeptical, you'll need very good tests
< phantomcircuit> the IsBindAny looks wrong actually...
< phantomcircuit> unless GetByte does some magic
< wumpus> let's review in the PR :)
< wumpus> any other topics?
< phantomcircuit> true sorry
< sipa> short reminder: wallet meeting tomorrow, same time
< wumpus> #action wallet meeting tomorrow, same time (friday 19:00 UTC)
< wumpus> this is a short meeting I suppose!
< sipa> seems so
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Nov 15 19:19:58 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< meshcollider> Very short :)
< provoostenator> Sorry, a bit distracted by a certain fork.
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/e74649e95122...384967f311b4
< bitcoin-git> bitcoin/master 7c5bc2a practicalswift: miner: Default to DEFAULT_BLOCK_MIN_TX_FEE if unable to parse -blockmintxfee
< bitcoin-git> bitcoin/master 145fe95 practicalswift: tests: Check return value of ParseParameters(...)
< bitcoin-git> bitcoin/master 579497e practicalswift: tests: Explicitly ignore the return value of DecodeBase58(...)
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13815: util: Add [[nodiscard]] to all {Decode,Parse}[...](...) functions returning bool (master...check-return-values-from-parse) https://github.com/bitcoin/bitcoin/pull/13815
< phantomcircuit> sipa, had any issues with the poll server?
< sipa> phantomcircuit: no
< sipa> currently running with 160 connections
< phantomcircuit> sipa, do we have anything that will exercise the performance?
< phantomcircuit> like try to do ibd or something
< phantomcircuit> but x100 nodes
< sipa> jamesob: ^
< stevenroose> who is maintaining the gnusha.org logs? Are they open to adding more channels? We were thinging we'd love one for #rust-bitcoin
< stevenroose> dongcarl: ^ there, I asked ;)
< luke-jr> wumpus: unable to do so at the moment, and too tied up with other work to fix :/
< dongcarl> stevenroose: ah, I got the answer, it's kanzure
< luke-jr> re bitcoin_rw, reminder that things *don't* have to be high-prio for review, to be reviewed
< stevenroose> dongcarl: ah oops
< Vita> Zk proof of identity + POS or PoW with a hashing/staking hardcap.
< Vita> 1 - Prevents recentralization
< Vita> 2 - Allows and motivates scalability (implement a variable cap with formula Cap(throughput))
< sipa> Vita: #bitcoin-wizards or so, off topic here
< Vita> 3 - Conserves security
< phantomcircuit> sipa, is there a sorted_vector class i can just use?
< phantomcircuit> i dont think the performance gain is worth making the code more complex
< phantomcircuit> the only real solution to it is ultimately to register for and release events
< sipa> just add stuff to a vector, and call std::sort(v.begin(), v.end()); before returning it
< phantomcircuit> (which would make a switch to libevent easier)
< phantomcircuit> but that's way harder to get right
< sipa> but a wrapper would be neat, which exposes an efficient find
< sipa> like frozenset in python
< phantomcircuit> hmm i guess that cant have duplicated entries either so it doesn't need to check for inclusion first
< sipa> indeed
< sipa> phantomcircuit: i think it's not worth the code complexity in your PR though
< phantomcircuit> with ~100 connections SocketEvents is using 15x the cpu time though
< phantomcircuit> so im not sure any change to the select set logic is worth it
< sipa> 15x compared to what?
< phantomcircuit> sipa, compared to GenerateSelectSets
< phantomcircuit> sipa, im not sure how to make the socketevents method faster without having duplicate pollfd entries
< phantomcircuit> which seem to cause problems (at least on os x)
< sipa> phantomcircuit: how does allowing duplicates make it faster?
< phantomcircuit> sipa, currently i have a map and that needs to be converted to a vector for the actual poll() call
< phantomcircuit> the map lookup/change is slower than the vector push_back
< bitcoin-git> [bitcoin] zallarak opened pull request #14733: p2p: allow p2ptimeout to be configurable, speed up slow test (master...p2ptimeout) https://github.com/bitcoin/bitcoin/pull/14733
< phantomcircuit> there's some optimization i can do but i doubt it'll have a huge impact
< sipa> phantomcircuit: can you show me the code you have with the map?
< sipa> phantomcircuit: start by using an unordered_map ?
< phantomcircuit> sipa, will do
< phantomcircuit> i guess i'll do the rest to one sec
< phantomcircuit> sipa, actually the other one is super annoying
< phantomcircuit> setting the fd and the events bitfield that way does two lookups when i only have to do one
< sipa> phantomcircuit: do you hate template magic?
< sipa> we could make GenerateSelectSets a templated function that takes as input a callback for each thing to listen to, which will be different for the select and the poll based implementation
< sipa> and by using a template that won't be a runtime function pointer, but an inlinable piece of code