< meshcollider>
luke-jr: you already have #14532 on high-priority, are you sure you're allowed another ;)
< 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
< luke-jr>
meshcollider: probably not, forgot about that one XD
< luke-jr>
guess it will have to wait
< meshcollider>
instagibbs: what do you mean by "xpub byte prefix mismatch" in the descriptor import PR? Mismatch with what?
< sipa>
meshcollider: i assume if you try a testnet xpub on mainnet etc
< Ramis_>
Hello, nice to meet you all, i have a question, can someone tell me if i can change mycoin value from basecli ? i am learning tendermint so was wondering am i able to alter the value of my wallet without sending/receiving,without altering any file through the basecli command is it possible ?
< bitcoin-git>
[bitcoin] harding opened pull request #14688: Doc: update release notes for changes since 0.17.0 branch (master...2018-11-release-notes) https://github.com/bitcoin/bitcoin/pull/14688
< bitcoin-git>
[bitcoin] achow101 opened pull request #14689: Require a public key to be retrieved when signing a P2PKH input (master...fix-pkh-pubkeys) https://github.com/bitcoin/bitcoin/pull/14689
< achow101>
instagibbs: provoostenator: ^
< promag>
jonasschnelli: are you still working on #7949?
< bitcoin-git>
[bitcoin] conscott opened pull request #14691: Speedup feature_pruning test and refactor big transaction logic (master...2018_11_opreturn_splices) https://github.com/bitcoin/bitcoin/pull/14691
< provoostenator>
Drahbot says "The following sections might be updated with supplementary metadata" -> "No conflicts as of last run"
< provoostenator>
Maybe it should hold off on posting its first comment until there's something to say?
< bitcoin-git>
bitcoin/master fa4da3c MarcoFalke: [doc] conf: Remove deprecated options from docs, Other cleanup...
< bitcoin-git>
bitcoin/master e70a19e MarcoFalke: Merge #14684: [doc] conf: Remove deprecated options from docs, Other cleanup...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14684: [doc] conf: Remove deprecated options from docs, Other cleanup (master...Mf1609-trivialPre14) https://github.com/bitcoin/bitcoin/pull/14684
< esotericnonsense>
promag: hmm. it seems to me like what should probably happen is rip out zmq and replace it with that. it feels bizarre to have multiple notification mechanisms.
< esotericnonsense>
the 'subscribe/unsubscribe' layer also feels like perhaps making RPC more complex/stateful than it needs to be, if this is someone's specific use case can't they just do it?
< promag>
I don't think we should throw away zmq though
< esotericnonsense>
i'll be looking in to this stuff a bit in the next few days I think, but I suspect what I'll be doing is just using the existing mechanisms through a proxy
< esotericnonsense>
i.e. you have bitcoind <-> bitcoind-api-i-actually-want-for-my-program <-> consumer(s)
< esotericnonsense>
promag: neither do I, actually I think it should just go through zmq :P
< esotericnonsense>
(e.g. in the hashtx hashblock case - just write another thing that does it)
< sipa>
but ZMQ is unreliable?
< esotericnonsense>
lol
< * esotericnonsense>
has deja vu
< esotericnonsense>
i feel like the last time I was here something like a year ago we had the same discussion and sequence numbers and other solutions came up
< sipa>
hah
< esotericnonsense>
the whole thing very much feels like a "who actually wants to use this" thing
< esotericnonsense>
i.e. if you have a use case for it, implement it
< promag>
I just asked if jonasschnelli was planning to update his PR :P
< esotericnonsense>
hehe
< esotericnonsense>
if I actually get to the point of my RPC proxy being usable it might be informative, because it does look like at the moment I might end up just using every different RPC interface together and combining them all into a rest api
< esotericnonsense>
but I'm kind of lazy and would probably just hack around weirdnesses in bitcoind rather than fix them (because I don't actually know what a fix looks like for anyone other than me)
< ezzzy>
would you people suggest en.bitcoin.it or bitcoin.org as a reference for the protocol (for client implementors)?
< esotericnonsense>
ezzzy: for the p2p protocol I'd suggest the code itself since any re-implementation has a hard requirement of being bug-for-bug compatible
< sipa>
esotericnonsense: only if you reimplement consensus rules (which I'd advise against)
< sipa>
but implementing the P2P protocol... follow the bitcoin.org developer docs
< MarcoFalke>
[12:31] <provoostenator> Maybe it should hold off on posting its first comment until there's something to say?
< ezzzy>
this is for educational purposes so I'd like to reimplement the consensus rules too
< MarcoFalke>
I have the feeling this is going back and forth
< sipa>
ezzzy: what do you hope to learn? all the nitty details of exactly which opcode does what?
< MarcoFalke>
But since GitHub will update the most recently changed when someone edits a comment I think I can change it back to only create the comment when there is information
< sipa>
my personal belief is that contributing to an existing project is a far more useful learning experience
< MarcoFalke>
Also: 6:21 PM ( Time in Reykjavík, Iceland )
< instagibbs>
what is the meeting time again, in Reyk time
< ezzzy>
sipa: I think there's a lot to learn in the process since it involves cryptography, network protocols, p2p, databases, testing all of the above etc.
< sipa>
ezzzy: well, good luck :)
< ezzzy>
thx :)
< sipa>
instagibbs: so 7 pm UTC
< sipa>
is the meeting time always
< ezzzy>
do you suggest using testnet or is there better alternatives for testing new implementations?
< sipa>
ezzzy: off topic here, as this channel is about bitcoin core specifically, but you may find help on https://bitcoin.stackexchange.com
< ezzzy>
cool, thx
< MarcoFalke>
#14437 has some conflicts (none with high priority), so I'd like to merge it after maybe 1-2 more reviews before it gets stale again
< wumpus>
luke-jr achow101 phantomcircuit sipa ryanofsky currently have open PRs there
< provoostenator>
Some of the hardware wallet support would be nice to add, e.g. the overhaul PR by sipa.
< luke-jr>
well, I rebased rwconf (#11082), but now #14532 is in the way :x
< 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
< 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
< MarcoFalke>
Just to repeat my latest comment there: Many users already have bitcoind running and don't care about performance, so I don't see why we'd want to stop providing utility functions for them.
< MarcoFalke>
If we want to (in addition) provide a high-performance library or executable for those functions, that seems partly orthogonal. And maybe even out of scope for our project?
< wumpus>
achow101: it complicates bitcoind, more code to maintain, more API to support
< MarcoFalke>
achow101: Sure, but has a bit of maintanence overhead
< instagibbs>
are existing utils well-tested and used?
< provoostenator>
I agree that performance really isn't an issue for at least some users. There's a reason people run NodeJS :-)
< promag>
bitcoin-qt already exposes RPC functionality without network overhead
< wumpus>
more testing as well; API coverage is not free
< wumpus>
I don't think performance is the only consideration
< sipa>
wumpus: but what about code that we already have, which can be used to implement a useful function, but would require a lot of work to reimplement elsewhere?
< wumpus>
sipa: it removes the flexibility to change that code later I guess
< luke-jr>
preferably a separate repo entirely IMO
< sipa>
say, signing PSBT with a descriptor
< MarcoFalke>
Also, I guess there'd be design tradeoffs that make the library/executable usable by some and not by others, so maybe just too much to worry about for us?
< provoostenator>
I think there's two seperate questions: 1) do we want a sep. utility 2) do we want to deprecate / stop adding that stuff to the RPC
< sipa>
descriptors are a bitcoin core specific thing (at least for now), it would be trivial amount of code to implement given the existing infrastructure, but a lot of work to do elsewhere
< jnewbery>
I think having duplicate code that does basically the same thing can be problematic. We've already had issues where bitcoin-tx has fallen out of sync with the equivalent RPC methods.
< provoostenator>
I would say (1) would be nice in general, even in a seperate repo. I'm a bit reluctant about (2) for reasons Marco pointed to.
< wumpus>
I mean obviously the ship to have bitcoind be a minimal consensus node implementation sailed, but I'm not sure we should be tacking on more that *could* be implemented outside it and is independent on any node functionality
< MarcoFalke>
2) NACK on stop adding utility to RPC
< wumpus>
but I'm sure this is pointless for me to argue
< promag>
also nack 2
< wumpus>
so do whatever you want..
< phantomcircuit>
MarcoFalke, most of the utility like things can trivially be RPC and some utility binary
< MarcoFalke>
For 1) it is not even clear if it should be a util binary or a util library
< phantomcircuit>
it's quite a nuisance to implement lots of things as another project, if only because of serialization stuff
< provoostenator>
It would be good to have a _generic_ way to map utility functions to RPC functions, so that it's easy to keep well tested.
< luke-jr>
MarcoFalke: library + utility
< luke-jr>
MarcoFalke: see libbase58 for example
< provoostenator>
Right now every RPC is bespoke.
< esotericnonsense>
butting in. this is more of a wallet vs node implementation thing than a RPC vs node thing, right.
< sipa>
esotericnonsense: we're talking about RPCs that don't need a wallet or node/chainstate/blocks
< phantomcircuit>
esotericnonsense, there's lots of non-wallet utility rpc's
< MarcoFalke>
Neither wallet, nore node, since both have state. We are talking about stateless util functions
< esotericnonsense>
sure, i suppose what i'm saying is that they're more wallet-like than node-like (if they deal with transactions, signing, etc)
< sipa>
esotericnonsense: maybe
< wumpus>
maybe, but AFAIK they're also enabled with the wallet disabled
< wumpus>
always compiled in
< sipa>
decodescript is pretty independent of anything
< wumpus>
yes
< MarcoFalke>
say, decoding a transactions, has nothing to do with wallet imo
< esotericnonsense>
longer term if the wallet and node become more 'split out' then it seems like you're going to have a whole bunch of wallet rpc's build up over time that aren't relevant for the node, it seems unavoidable
< wumpus>
I don't think the current ones should be removed, but i'm not sure about adding new ones
< MarcoFalke>
We don't talk about keystore or "chainstore" rn
< sipa>
esotericnonsense: i really think you're talking about something else
< achow101>
I would rather that it not be separated into a separate repo. a big reason for me to have utility functions in core is that most of the framework for doing something is already there. in a separate repo, you have to reimplement stuff like serializations, etc. which is a major pain in the ass
< esotericnonsense>
(agree that decodescript doesn't really belong in either)
< wumpus>
achow101: if only those parts of core were available as a library heh...
< sipa>
i think that bitcoin core, for better or worse, implements certain featuresets - and it makes sense to implement those features completely, even if some are stateless
< sipa>
that doesn't mean we should add arbitrary utilities because they may be useful for something
< wumpus>
sometimes seems we're using RPC to compensate for the fact there's no library or API separation
< esotericnonsense>
i think provoostenator's point about RPC being non-automated is interesting
< esotericnonsense>
yes
< sipa>
i don't really care for decodescript being in our codebase really - it's trivial to do anywhere
< luke-jr>
bitcoin-cli add 1 2
< wumpus>
things that have no state don't need *remote* procedure calls
< esotericnonsense>
like effectively a lot of RPC's are just a wrapper over a raw function call, but with the "stable ABI" pushed outwards a bit
< sipa>
but signrawtransaction makes perfect sense, as we offer raw transaction functionality
< provoostenator>
luke-jr yes, so we can claim that Bitcoin Core is turning complete :-P
< instagibbs>
We already kind of have frozen random util addition, I think?
< sipa>
instagibbs: yes, there has been sort of a policy like that for a while
< phantomcircuit>
wumpus, we definitely use the rpc stuff to compensate for there not being a good library
< wumpus>
instagibbs: that was the idea! but recently a few new PRs have been opened in that regard which prompted this discussion
< luke-jr>
instagibbs: I thought so, but I think I've seen more going in since then -.-
< wumpus>
and apparently it's still controversial
< luke-jr>
maybe just saw PRs, perhaps not going in
< provoostenator>
Lots of folks us a microservices like architecture, wher eyou have bunch of applications on seperate servers talking to eachother. RPC is useful for that, but less so once there are enough libraries that can replace it.
< instagibbs>
luke-jr, for example? the ones I've suggested have gone nowhere :P
< instagibbs>
ah ok
< instagibbs>
fair enough
< provoostenator>
So I agree with wumpus that it's paritally a chicken egg thing
< wumpus>
provoostenator: that RPC is useful is not the discussion, does it need to be in bitcoin core!
< wumpus>
we can't add everything that is useful
< wumpus>
that's infinite scope creep
< provoostenator>
Of course
< sipa>
absolutely
< gwillen>
for utility stuff that doesn't go in bitcoin core, is there some way to make it available to end-users who are not developers?
< gwillen>
e.g. a library doesn't really help them
< luke-jr>
gwillen: can you give an example?
< wumpus>
gwillen: you could make your own RPC server, btcutilityd, or so
< gwillen>
unless there's a utility wrapper around it that also ships with core
< phantomcircuit>
gwillen, see bitcoin-tx
< wumpus>
it could be completely separate from bitcoin core
< wumpus>
as it shares not state
< esotericnonsense>
gwillen: it's sort of what I've been doing in my projects, but it's not public
< sipa>
gwillen: i think wumpus' argument is not having such things in our codebase entirely
< luke-jr>
gwillen: libraries should have wrappers for shell scripts to use them, but having trouble seeing a case where a real end user would need such things
< sipa>
not just not exposing it over RPC
< provoostenator>
Right, so a seperate utility repo could also include an RPC wrapper.
< esotericnonsense>
or rather, it's "public" as in it's OSS/free software, but it's not marketed or known or anything (I expect there's a lot of stuff out there like this)
< luke-jr>
if people really need RPC, let someone do a RPC-to-exec server :/
< wumpus>
I'm just trying to prevent the codebase complicating even more, I mean, I think we should focus on consensus issues in bitcoin core, it's hard enough
< luke-jr>
+1
< phantomcircuit>
wumpus, agreed
< phantomcircuit>
so anyways
< phantomcircuit>
sipa, suggest changing the GetRandBytes functions to GetWeakRandBytes to make it more obvious, maybe
< gwillen>
I don't think RPC is necessary for quick utilities with no state, but I do think commandline is necessary
< gwillen>
versus just a library
< sipa>
wumpus: so, just to gauge your opinion here, imagine we didn't have any raw transaction or PSBT functionality included, and it is being added now; would you argue for only having signrawtransactionwithwallet, but say signrawtransactionwithkey needs to be implemented elsewhere, even though it shares 95% of the code?
< provoostenator>
I thikn that's reasonable actually. Especially considering that the _wallet_ could also be split out at some distant future.
< luke-jr>
sipa: IMO, ideally we'd abstract that code into a library itself, and use it in Core
< wumpus>
sipa: sure, it's always possible to argue some grey area where it seems harmless to add because it's only a small difference, maybe that would be ok, just not complicated things that we don't use otherwise
< luke-jr>
or rather, use it in "wallet split out of Core"
< sipa>
luke-jr: agree, but that's a separate discussion
< provoostenator>
The number of RPC methods that would be left if we strip out utilities and the wallet would be nice and small.
< sipa>
wumpus: my point here is that the "feature creep" is in deciding whether to have raw transaction support or not; the fact that part of the necessary RPC calls happen to be stateless isn't
< wumpus>
I'm not arguing to remove the current ones or so, just prevent an onslaught of new ones
< sipa>
(this is also orthogonal to whether it should be implemented as RPC or separate utility; i'm just discussing having the functionality somewhere in our codebase)
< gwillen>
note also, as someone doing development on the GUI right now, that the GUI might reasonably need utilities that don't touch the wallet
< provoostenator>
(by strip out I just mean not adding more than we already have, only deprecating if they become a problem)
< gwillen>
unless the goal for the GUI also is to be functionally minimal, which I don't think i tis
< wumpus>
if only the GUI needs it, it could be a library at the GUI side
< luke-jr>
gwillen: I think the goal is to split the GUI out too, but in the meantime, I see your point
< wumpus>
so maybe it's better to discuss per PR
< sipa>
wumpus: say for example, if somewhere were to propose a set of RPCs just to do script debugging, fully stateless, I would nack that - there is no reason for that to be in core
< wumpus>
say, deriveaddress seems small and is only using what is already in the code base: #14667
< wumpus>
luke-jr: no, debugging does not belong in consensus
< sipa>
yeah i don't think we should have had decodescript
< luke-jr>
wumpus: I guess I just mean the hooks, which can't really be anywhere else
< wumpus>
it's also not difficult to implement on the application side, unlike the cryptography of deriving addresses
< sipa>
so that was on the topic of "whether something belongs in the codebase or not"; another question is, for the things that do, separate utility/library, or RPC, or both?
< luke-jr>
sipa: if it's being pulled in because it's tied to something that should be, then presumably that other thing is RPC already
< sipa>
luke-jr: that's fair
< luke-jr>
if it could be a separate utility/library, it wouldn't need to be in the codebase I guess
< luke-jr>
(but maybe it makes sense to do all 3?)
< MarcoFalke>
I think there is not too much cost in doing both (but currently we don't have a utility/library)
< luke-jr>
MarcoFalke: we do have bitcoin-tx
< wumpus>
sipa: ideally I'd prefer having a library, this more general and allows for implementing a RPC service that does the same, the other way is more limiting
< MarcoFalke>
luke-jr: that is not useful for general utility functions
< luke-jr>
MarcoFalke: even if we rename it?
< sipa>
luke-jr: i think tx is too specific
< sipa>
its arguments are all transformations on transactions
< MarcoFalke>
good luck renaming it, heh
< luke-jr>
I guess there's no real need to have just one tool
< wumpus>
the advantage of an executable is that it's separate
< luke-jr>
even for libraries, it makes sense to have different ones for substantially different tasks
< wumpus>
it's annoying to interface with in most languages, though :)
< sipa>
perhaps we should change topics, i need to go in 10-15 minutes
< wumpus>
also need to spawn a new process for every call
< phantomcircuit>
luke-jr, the openssl rng is already lol slow
< luke-jr>
(since we don't make them, so I guess new keys are only generated one at a time)
< wumpus>
does slowness matter for anywhere we need strong crypto?
< meshcollider>
This isn't actually going to slow things down is it, long term might even speed it up?
< wumpus>
I mean, now that key generation is HD
< luke-jr>
wumpus: my point is that key generation is not necessarily HD
< wumpus>
generating the initial seed isn't perf critical and certainly not high bandwidth
< wumpus>
is there anything besides that?
< sipa>
phantomcircuit: actually, GetWeakRandBytes is perhaps a bit confusing too; the data returned would be cryptographic strength, seeded by all available randomness sources - just not reseeded regularly
< luke-jr>
GetRandomStrengthRandBytes
< wumpus>
I guess the master key for the wallet; but that's als oa one-time thing
< meshcollider>
GetWeaklySeededRandBytes
< phantomcircuit>
luke-jr, by far the slowest thing about keygeneration is the ridiculous number of fsync calls from bdb
< sipa>
luke-jr: what phantomcircuit says ^
< sipa>
generating thousands of keys per second should be trivial
< phantomcircuit>
sipa, Strong/Mediocre/Weak
< phantomcircuit>
heh
< sipa>
phantomcircuit: i think two levels is sufficient :)
< sipa>
so ok, weak and strong :)
< phantomcircuit>
sipa, the distinction is really about things like vm state copies where we hope that /dev/random would know about that right?
< luke-jr>
was about to ask what the use case is for the middle level :P
< meshcollider>
If you take GitHub emoji reactions as comments it looks like there's a pretty good approval consensus anyway
< sipa>
phantomcircuit: so even weakrand in my suggestion would invoke high-accuracy timestamp (rdtsc etc), so it'd be highly unlikely that you get the same random numbers in two instances of a VM copy
< wumpus>
what if: if you need high speed key generation, switch to HD wallet
< wumpus>
if not, the current fallback is fine
< wumpus>
it will be slower but work
< kanzure>
timezones are difficult.
< sipa>
RNG is really not the bottleneck for key generation
< luke-jr>
wumpus: it sounds like it's a non-issue either way?
< meshcollider>
Yeah just wanted to check this date was sane to put on the website
< luke-jr>
most nodes are still using 0.15 :x
< MarcoFalke>
luke-jr: EOL would be august next year. Seems reasonable
< wumpus>
what is the proposed date?
< luke-jr>
yeah, hopefully it will change by then
< luke-jr>
2019-08-01
< phantomcircuit>
sipa, indeed
< achow101>
seems reasonable
< wumpus>
that seems.. far enough away
< meshcollider>
luke-jr: it's maintenance end now anyway
< meshcollider>
Ok that's all then, unless anyone disagrees :)
< luke-jr>
(correction: 0.16 is actually now the most-used branch, barely)
< wumpus>
yep, please do any ACKing in the PR
< wumpus>
any other topics?
< kanzure>
RPC is used by many companies as the only interface to bitcoin at all; not sure i understand the scope of discussion about moving RPC into another utility or project but yeah be careful i guess.
< meshcollider>
kanzure: only a few utility RPCs, not the whole thing ;)
< wumpus>
kanzure: the topic is not of moving any current RPCs away
< gwillen>
one possible alternative I can think of would be to give bitcoin-cli a way to talk to multiple backends
< gwillen>
then you can easily put utilities in a separate codebase
< luke-jr>
gwillen: it already can?
< gwillen>
without any user issues
< gwillen>
luke-jr: I mean something like dispatching based on which command it's given
< esotericnonsense>
hm. but isn't the issue the ongoing maintenance of ensuring RPC works (integrating it into the test suite etc)
< gwillen>
for a seamless experience
< luke-jr>
gwillen: ew :<
< wumpus>
kanzure: as far as I'm concerned the discussion is about the addition of new pure, utility-only RPCs, what is the crit to add them, or never do it? but removing the current ones is out of the question I think
< esotericnonsense>
i'm struggling to understand how seperating it makes it "simpler" if you keep the maintenance burden anyway
< kanzure>
something out of scope for bitcoind but exchanges and merchants could really benefit from tracking slightly more state on bitcoind end (like "updates since last sync"- specific to an external application which otherwise has to write their own since-last-sync tracking code etc)
< wumpus>
no way...
< kanzure>
wumpus: got it, understood. i didn't understand context. my apologies.
< kanzure>
wumpus: yeah i said it's out of scope :-)
< wumpus>
really, tracking consensus is hard enough, a REALLY hard problem
< wumpus>
I think there's too little respect for just how hard that is, even as a single concern, we can't pull in anything that is marginally useful to anyone else also
< jarthur>
I have to say that I don't have much use for a cryptocurrency node that isn't either A) a wallet, or B) providing other services with currency network functionality. If separating the concerns out still gives me those things as I need them, no complaints.
< esotericnonsense>
it sounds to me like provoostenator's idea of making RPC more 'automated' somehow would be useful; in the sense that you have a ton of functions that could just be exposed over rpc by like, function name or something, if they're stateless, without doing anything
< esotericnonsense>
and then it's "someone else's job" to maintain the bitcoin library to RPC shim which ensures RPC backward compatibility
< wumpus>
again, you're speaking of 'backward compatibility'
< wumpus>
there's no talk of dropping anything here
< wumpus>
the discussion was about adding...
< esotericnonsense>
wumpus: right, what I mean is that, when you add stuff, it's not a problem a priori, it becomes a problem because over time you're maintaining it
< phantomcircuit>
gwillen, please no
< esotericnonsense>
there is also the overhead of dealing with a PR, merging, rebasing, basically actually doing the work
< wumpus>
going to close the meeting we're out of topics
< kanzure>
esotericnonsense: i would phrase that as automatically generated bindings
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Nov 8 19:55:01 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< esotericnonsense>
which seems to be solved if the person in control of maintaining that 'library-RPC' interface is an external party
< esotericnonsense>
anyway, yeah, i'm kind of external in this, just musing... sorry
< wumpus>
yes, don't put it on my plate and I'm happy
< meshcollider>
Time to add an RPC maintainer too ;)
< wumpus>
meshcollider: are you interested?
< luke-jr>
lol
< instagibbs>
RPC Tsar
< meshcollider>
That was partly a joke but does the RPC really need its own maintainer?
< wumpus>
nothing 'needs', but could if someone was interested in taking that up
< wumpus>
we can really use any help at this point
< meshcollider>
Well I'm always happy to help, I thought the wallet maintainer was more needed than other random parts of the code though
< wumpus>
well if you want to be wallet maintainer that's great too ;)
< meshcollider>
Haha oh no ;)
< wumpus>
nah seriously just pick what part you're interested in
< meshcollider>
Speaking of which though, in seriousness, that discussion has been going on for months now with no result. What would it take to actually learn to fill that role?
< luke-jr>
meshcollider: I would guess making an explicit effort to review <topic> PRs and move them forward
< wumpus>
you can be maintainer of any part you're interested in by actively reviewing PRs in that area and getting involved there
< wumpus>
it doesn't have to be the wallet, that's just the running joke because it turns out to be really hard to find a maintainer for that :)
< meshcollider>
Because the wallet is still quite a mixture of things, e.g. coin selection is quite different to the key stuff
< meshcollider>
To be comfortable with it all at a deep enough level seems hard lol
< sipa>
sorry, had to run
< wumpus>
I'm not sure what a 'deep enough level' is here though
< meshcollider>
Neither am I ;)
< meshcollider>
I guess it feels like to be a good maintainer of an aspect, you should be an expert in that aspect's code
< luke-jr>
probably comes naturally with time reviewing everything going into it
< wumpus>
well you need to be an expert compared to new people contributing to it at least, you don't need to know everything, you don't have to take decisions without other people's input
< instagibbs>
wumpus doesn't have to know literally everything to be overall maintainer; you need to digest discussions, prod, etc
< wumpus>
exactly.
< meshcollider>
Both very good points lol
< meshcollider>
Hmm well I guess it is something I can work towards in the meantime :)
< instagibbs>
I bet if you just fake it you'll make it eventually
< meshcollider>
Hahaha your support is much appreciated greg
< bitcoin-git>
[bitcoin] DrahtBot closed pull request #9298: [Wallet] use CHDPubKey, don't store child priv keys in db, derive on the fly (master...2016/12/hd_no_priv) https://github.com/bitcoin/bitcoin/pull/9298
< meshcollider>
Is this a new drahtbot feature ^
< MarcoFalke>
Old feature, but I only run it manually every couple of weeks
< esotericnonsense>
hm. sorry if this isn't really a 'core-dev' question but i'm having shower thoughts of a kind...