< 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
< 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
< 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 ?
< 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...
< 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)
< 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