< meshcollider>
Is anything in the share/certs/ directory actually relevant anymore? Seems pretty outdated
< achow101>
meshcollider: yes, that's information about the codesigning certs
< achow101>
the threat mitigation part is outdated I think because of the detached sigs thing. the codesigned binaries are now gitian built
< kallewoof>
Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with <height> <blockhash> OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match <blockhash>? (It would probably require that <height> was less than <current height> - 100 to avoid nasty double spends at reorgs...)
< kallewoof>
Actually, I don't think that would solve anything, since old UTXOs would still be replayed, just unspendable. Nevermind.
< achow101>
meshcollider: well I suppose the keys there are outdated as it looks like the codesigned stuff uses a more recent cert
< achow101>
cfields: would you mind updating that? or do you think it should be removed entirely?
< meshcollider>
achow101: yeah that's what I thought, this is stuff from 5 years ago
< achow101>
meshcollider: the keys there are expired too
< cfields>
achow101: yea, i think it can just be removed. The signing process is documented (and scripted)
< achow101>
cfields: where is it documented?
< cfields>
achow101: in the gitian build instructions
< achow101>
oh I see.
< achow101>
where is this script: detached-sig-create.sh?
< cfields>
I've helped a few other projects (litecoin, for ex), build using our process. The last one (i forget who, now) was able to sign without my assistance.
< cfields>
hmm, we have one for windows as of 0.15. surely i updated the instructions for it. Checking.
< cfields>
(the script/cert are in contrib/windeploy )
< achow101>
ah, I see it now.
< achow101>
missed that earlier
< achow101>
no certs for osx? (I don't see any in macdeploy)
< cfields>
well, there aren't instructions in that gitian doc like i thought there were. Will add.
< achow101>
the gitian doc has instructions for running the scripts
< achow101>
err the release process doc
< meshcollider>
cfields: might be in the release process doc
< cfields>
no, I got distracted from finishing the osx tool, so committed osx certs can't be used yet
< cfields>
ah, maybe that's it
< cfields>
anyway, gitian spits out "*unsigned.tar.gz", which the signer just untars and runs ./detached-sig-create.sh. Very straigtforward.
< cfields>
but if it's not fully written up, I can do so
< cfields>
achow101: oh, sorry. portable tool. Works from Linux.
< achow101>
cfields: ah. ok. I figured it was probably also that it is open source
< cfields>
achow101: well most (all?) of osx userspace is open-source. It's just a tangled web.
< luke-jr>
cfields: pretty sure the GUI stuff isn't?
< cfields>
luke-jr: that would make sense
< meshcollider>
luke-jr: that can't even be considered until SPV mode is added though right, no way android is going to run Qt with even a pruned blockchain and full UTXO set lol
< achow101>
meshcollider: it can run bitcoind
< achow101>
look up ABCore
< achow101>
and android devices (smartphones in general) are getting more powerful and have more ram
< cfields>
meshcollider: no reason why it should be less performant than gnu/linux on an arm machine
< meshcollider>
hmm that's true, I've just never even considered trying to run a full node on a smartphone
< meshcollider>
that's an interesting idea
< esotericnonsense>
my smartphone is multiple years old and is more powerful than many machines i've synced a node from
< esotericnonsense>
much better than a raspberry pi anyway :)\
< sdfgsdfg_>
ohio, how much until LN is tested on mainnet ?
< kallewoof>
Someone wrote a post about that on reddit. One of the devs said two weeks I think. (LN is actually not bitcoin core, but a separate client entirely.)
< ossifrage>
The 'reindexing blocks on disk...' progress bar flaps around quite a bit, not exactly a stable progress bar
< wumpus>
at least better than not showing progress at all
< ossifrage>
wumpus, yeah it just was flapping between "5 year" and "3 years" behind, which is a bit extreme
< gmaxwell>
huh....
< gmaxwell>
it shouldn't do that
< ossifrage>
I restarted the node with txindex=1
< ossifrage>
I set dbcache to 4096
< wumpus>
I expect there to be larger variance in the beginning, once it gets to the blocks that are actually filled, it's probably more stable
< ossifrage>
I thought the estimate was just based on block count not transaction count?
< sipa>
no, it's based on transaction count
< ossifrage>
Now it is flapping + 1 year
< wumpus>
I've never seen it flapping here, though I must say I haven't ever paid close attention to it, after all it's hardly something you can wait for to complete :)
< ossifrage>
Maybe it is specific to reindexing with txindex=1... Oddly it doesn't seem to be io bound or cpu bound (none of the threads consume 100% cpu). Lock contention? Or maybe blocking on fsync()?
< wumpus>
that's just in the beginning, it will get cpu bound soon enough
< gmaxwell>
if its flaping then it doesn't work like I understood...
< ossifrage>
Both the bar and the text are flapping but the "Progress x%" is counting up smoothly (that must be just block height?)
< wumpus>
before it gets to the blocks that require serious validation I expect it's mostly waiting for i/o latency (reading blocks from disk, updating db), interspersed with a bit of cpu use
< wumpus>
I don't think it has used block height as a progress measure in the UI since 0.5.x or so
< wumpus>
block height is pretty useless for that because it starts off really fast and then slows down more and more
< sipa>
meetung?
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 21 19:00:26 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
I don't think we made much progress on review, this week (me included)
< BlueMatt>
no, we (or at least I) did not :(
< sipa>
regarding that: i've seen several reports of people wondering what happened because getinfo doesn't work... i guess they went from 0.14 to 0.5.99 and never saw the deprecation
< gmaxwell>
Well they shouldn't run 0.5, that would be bad.
< wumpus>
added 10871
< BlueMatt>
heh, so, what, when a new release is announced they just build master? :(
< luke-jr>
Maybe `bitcoin-cli getinfo` should print a message informing the user about the new RPCs, like we did when bitcoind client got deprecated
< gmaxwell>
BlueMatt: some people do that.
< wumpus>
luke-jr: also thought about that
< BlueMatt>
gmaxwell: wat
< luke-jr>
lol
< wumpus>
luke-jr: it should at least print a deprecated message
< sipa>
BlueMatt: gmaxwell is joking about my typo (0.5 instead of 0.15)
< BlueMatt>
gmaxwell: so...what you're saying is we should start using a "develop" branch with master pointing to released versions?
< BlueMatt>
sipa: i figured......
< wumpus>
luke-jr: instead of just about a missing call, as if it's never existed
< sipa>
i like the approach being used for the estimatefee deprecation
< luke-jr>
BlueMatt: github lets you change the default branch, so we could just make it the latest stable branch
< goatpig>
dont poeple typically pull tags, not just the head of a branch (in this case master)
< wumpus>
BlueMatt: or we can just change the github default branch to something else, you know
< luke-jr>
problem is, it's also the default for PRs…
< BlueMatt>
wumpus: yea, possible
< sipa>
where it disappears, but you have a cmdline switch to re-enable
< BlueMatt>
I mean really not joking there that's a serious issue
< wumpus>
but yes, PRs also go there by default, whichi s kinda annoying
< BlueMatt>
people building master right after release is usually bad cause we merge lots of fun stuff on master right after release :/
< achow101>
topic suggestion: deprecation stuff a la #11031
< BlueMatt>
luke-jr: I'd expect there to be ~0 on mainnet aside from some developer test nodes, fwiw
< achow101>
I think that we might run into a problem where people just have -deprecatedrpc (or whatever it is called) and enable all deprecated behavior until it disappears
< BlueMatt>
achow101: thats fine, at least they were made to type "I know this is going away soon"
< BlueMatt>
so they cant show up and complain that its gone
< cfields>
jnewbery: i like it (better than an rpc arg, on second thought), though the name could use some bikeshedding :(
< jonasschnelli>
luke-jr: my crawler counts 2496
< jonasschnelli>
oh.. no .99,.. sry
< wumpus>
I also prefer command line arg to rpc arg
< wumpus>
it's enough to type it once
< jnewbery>
achow101: it's designed such that the user needs to include `-enablerpcmethod=<method1> -enablerpcmethod=<method2> ...` to avoid the problem of a user just setting `-enablealldepractedrpcmethods` and forgetting
< jnewbery>
cfields: yes, name could probably be improved
< gmaxwell>
yea, don't have a deprecatedall, it needs to be specific.
< wumpus>
the purpose is just to signal, not to overburden a user with extra work updating their client applications (apart from getting rid of using the RPC call in the first place)
< meshcollider>
hmm yeah "-enablerpcmethod=" should probably have the word "deprecated" in it
< wumpus>
yes
< achow101>
I propose calling it -enableddeprecatedrpc
< jonasschnelli>
ack
< wumpus>
otherwise it sounds more like a silly security feature
< achow101>
although maybe enabled may not necessarily be the best word for that since we have PRCs that themselves are not deprecated but have deprecated output fields and only the deprecated output fields would show if that option is set
< luke-jr>
thought: should rpcuser auth always throw RPC_METHOD_DEPRECATED? if so, how does the user bypass it?
< morcos>
-deprecatedrpc is good enough
< luke-jr>
maybe -enabledeprecated= would be better
< wumpus>
morcos: yes!
< morcos>
in a light pink
< gmaxwell>
-backwardscompatibilitylaunchcode=0xdeadbeef234828429342893429 < that could trigger fields that are going away. :P
< wumpus>
hehehe
< gmaxwell>
(and you need to read the release notes to get the launch code)
< gmaxwell>
(or source)
< jnewbery>
ok, -deprecatedrpc it is
< wumpus>
release notes scavenger hunt
< cfields>
gmaxwell: where the launchcode is the git commit, so it changes every day until release
< cfields>
jnewbery: ack
< gmaxwell>
well the idea there was that each depricated feature would have its own code. So you'd look up the code and specify it.
< luke-jr>
gmaxwell: too strong for mere deprecation IMO
< gmaxwell>
luke-jr: yes, though it solved the how about deprecated fields case.
< luke-jr>
something like that feels more like to allow changing consensus-critical stuff
< achow101>
I suppose we can then put all of the deprecated account RPCs behind that argument
< cfields>
gmaxwell: you're deprecating me? :(
< wumpus>
yes
< luke-jr>
gmaxwell: how about if the "launch code" matches the method name for methods? :p
< luke-jr>
and "accounts" for accounts
< wumpus>
in the case of accounts it'd be a group not one single call
< luke-jr>
"rpcuser" for -rpcuser
< wumpus>
right
< luke-jr>
this code already fits that paradigm I think, except for the param name
< achow101>
luke-jr: doing that for rpcuser is going to annoy a lot of people
< luke-jr>
achow101: yes, that can be discussed separately; it was an example
< wumpus>
I think we should keep the discussion of what things to deprecate separate
< sipa>
agree
< achow101>
ok
< jonasschnelli>
removing the account support via -depracaterpc and positioned arguments seems pretty difficult and/or dangerous.
< jnewbery>
achow101: As long as you're happy with that I'll update 11031 with the new name so you can rebase your various RPC deprecation PRs on it
< luke-jr>
"rpc" probably shouldn't be in the arg name.
< jonasschnelli>
users may be confuse why account are deprecated but still work while -depacaterpc=accounts
< luke-jr>
-enabledeprecated seemed nicer IMO
< achow101>
jnewbery: I guess so. I haven't looked over 11031 in a while so I want to review it before rebasing
< wumpus>
jonasschnelli: it's just the account rpcs that are deprecated, accounts themselves will work as labels
< meshcollider>
jonasschnelli: are you suggesting disable the account system completely?
< meshcollider>
(without deprecation)
< jonasschnelli>
wumpus: yes. That makes sense.
< wumpus>
we'll not rip out the account arguments from any non-account RPC calls
< wumpus>
just that move etc are deprecated
< achow101>
topic suggestion: what to deprecate
< jonasschnelli>
But the transition of having a -enabledepracatedrpc= and not disabling the depracated account features seems not to be ideal.. although I guess it's okay
< wumpus>
I doubt there is any ideal way to deprecate a monster like the accounts feature, tbh
< luke-jr>
wumpus: getbalance <non-*> should fail too
< wumpus>
luke-jr: yes
< luke-jr>
jonasschnelli: no "rpc" :/
< wumpus>
do we have any more upbeat topic than deprecation?
< gmaxwell>
China blocking bitcoin?
< gmaxwell>
(not really)
< meshcollider>
segwit wallet support progress?
< gmaxwell>
That
< sipa>
i'll have a PR soon
< wumpus>
#topic segwit wallet support progress
< wumpus>
thanks
< sipa>
otherwise, review #11167
< gmaxwell>
sipa: Have you heard from thomasv about them blocking v>0
< gmaxwell>
There should be almost no GUI intersection, other than perhaps offering the default overrides in the gui.
< sipa>
yeah, i expect some expert mode setting to choose the address type - but otherwise it can just use the default
< gmaxwell>
oh right, point of use switching, sure.
< jonasschnelli>
sipa: yes. That is what I though...
< sipa>
not that much to say about the topic otherwise
< gmaxwell>
jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter. We need a monospace text entry field that can be told to underline characters or something like that.
< gmaxwell>
(not necessarily a 0.15.1 feature in any case)
< jonasschnelli>
Yes! I just wanted to write that
< gmaxwell>
well sipa's bip173 patch doesn't have the error finder in it.
< sipa>
i think there is another question, that ThomasV brought up yesterday
< sipa>
what to do with private key import/export for segwit addresses
< gmaxwell>
Though we've written one (a port of it to JS is on that demo page)... it deserves a nice gui handling though (even the js demo is kind of lame, in that it can't highlight inline)
< wumpus>
some importmulti ?
< achow101>
sipa: importmulti
< sipa>
importmulti can handle this natively
< wumpus>
ok, seems good enough for me then
< gmaxwell>
importmulti was my first thought too.
< achow101>
deprecate the other import* rpcs
< sipa>
but perhaps at least a warning for importprivkey / dumpprivkey is needed
< wumpus>
just highlight that the old import* rpcs don't work with segwit
< jonasschnelli>
sipa: yes. Or depracate?
< gmaxwell>
When we do the changes that split the key types later, we'll have more to think about. Right now any key is all keytypes.
< wumpus>
or deprecate them at some point, but not for a minor release
< sipa>
right
< gmaxwell>
we can announce an intent at any time. (I think we just did.)
< ThomasV>
importmulti does not seem as easy to use as a serialized format
< wumpus>
yes, intent+reason could be menitoned in the release notes
< sipa>
ThomasV: i consider that a feature :)
< gmaxwell>
ThomasV: because of versioning issues, we're not going to solve a new serialized format right now.
< jonasschnelli>
importmulti is a bit cumbersome to use,... but should the okay for an RPC layer
< wumpus>
importing keys in bitcoin core is considered advanced functionality anyhow
< sipa>
ThomasV: as said, i don't mind discussing a more convenient import format for some use case, but we're not going to solve that instantly
< jonasschnelli>
importaddress and key with the current rescan-everything approach must go away at some point anyways
< wumpus>
jonasschnelli: yeah... that too
< ThomasV>
gmaxwell: we were also considering an import format along the lines of bip124
< gmaxwell>
raw key handling frequently results in funds loss, even for advanced users too.. but I do think we should ultimately be embedding the required metadata to actually use a key. but it's not something we can really do right now.
< achow101>
the bech32-for-privkeys thing could be something for segwit only and have a the witness version number included in that?
< wumpus>
achow101: yes
< sipa>
achow101: yes, or no - i'm not sure
< gmaxwell>
achow101: witness version number isn't the right data.
< sipa>
i think we need a 'pure private key' format, which is just a key
< instagibbs>
doesn't tell you how it's being used, specifically
< sipa>
to minimize the data needed for backup
< wumpus>
more like a 'key use'
< gmaxwell>
it effectively needs to communicate the scriptpubkey (perhaps be template reference).
< sipa>
the associated addresses/chains/... can be stored separately
< jonasschnelli>
Not sure if we should really support exporting / importing private keys over an RPC layer in the long run
< luke-jr>
sipa: but if you're going for minimal, you'd backup the seed, not the keys?
< sipa>
jonasschnelli: yeah... that's a hard question
< gmaxwell>
sipa: still needs metadata.
< sipa>
gmaxwell: how so?
< wumpus>
right, you could backup the seed, and some metadata, no need to backup the keys themselves
< achow101>
<scriptpubkey>|<privkey(s)>
< gmaxwell>
I mean you need to know _what_ chains or key types are expected. Otherwise it's a lossy search problem to figure out what you should be actually getting.
< wumpus>
yes
< sipa>
gmaxwell: sure, but i think that can be separate
< sipa>
ideally, your wallet has 1 piece of actually secret data, and then a bunch of chains/addresses/scripts/... that use keys derived from that secret data
< gmaxwell>
it's critical data without which you can't recover the keys... and with which you can. (maybe you could bruteforce it out, under somewhat reasonble assumptions...)
< jonasschnelli>
Conceptual, we should work towards private key separation with a daemon (or agent) and core only deals with public keys. The private-keys agent/tool could still be in the repository (or different one)
< gmaxwell>
it's also potentially a rather small amount of data.
< sipa>
gmaxwell: an example i came up yesterday is CLTV scripts
< sipa>
there is no way you can enumerate all CLTV scripts from a particular seed
< gmaxwell>
no, indeed, but the inability to back up CLTV cleanly was one of the motivations for CSV.
< sipa>
but perhaps there is no need, if you have built-in backups of the chain data (which don't risk monetary loss), and a separate backup of the private key
< luke-jr>
so three levels of data really: the seed itself, the types/chains/etc, and the comments/labels
< sipa>
the private key in that case is just a piece of secret data, referred to by the chains
< gmaxwell>
asking people to handle two critical to maintain pieces of information instead of one would be unfortunate.
< gmaxwell>
(and by unfortunate I mean result in non-negligible funds loss in practice)
< luke-jr>
gmaxwell: maybe concatenate seed + types/chains/etc in practice
< sipa>
sure, for simple situations you can create a convenient format that handles both simultaneously
< gmaxwell>
sure. that would be okay to.
< wumpus>
you could encode it into one identifier somehow...
< wumpus>
sounds easy enough
< gmaxwell>
(re to both luke and sipa)
< sipa>
but i expect there to be cases where you really just want to backup a key, and will handle the metadata (which is too complicated) yourself
< gmaxwell>
the logical seperation sounds fine, but for at least the common case there should be some format for combined data.
< sipa>
sure
< morcos>
+1 for the common case combined format
< gmaxwell>
A possible metadata flag is 'external, good luck'. :)
< jonasschnelli>
X509
< sipa>
JSONx!!
< ThomasV>
lol
< * jonasschnelli>
*ducks*
< wumpus>
you could always back up the key and metadata separately, then combine them before importing, or have import accept multiple formats, this is just details
< gmaxwell>
Could just have a box where people can just type in x86 machine code and it will decode the result for you ... almost as flexible as x509.
< gmaxwell>
:-)
< luke-jr>
XD
< sipa>
ok, other topics?
< wumpus>
nice, though too easy to use, should be some ancient 8-bit assembly like z80 or 6502
< sipa>
INTERCAL
< luke-jr>
suggested topic: it would be really nice to get #7533 in, since it is a constant rebase hell otherwise; comments on how to improve the code quality (ugh, macros) appreciated
< gribble>
https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
< gmaxwell>
I've had to use 6502 assembly in the last couple years ... (for a mystery hunt puzzle)
< wumpus>
yeah
< wumpus>
gmaxwell: did you still manage to? :)
< gmaxwell>
other topics: did people see on the mailing list that there is a new Dandelion post?
< jnewbery>
wumpus: you suggested topic high-priority for review earlier. Did you want to discuss individual PRs or were you just asking if people had PRs they want added to the list?
< wumpus>
jnewbery: both is ok, though there are too many PRs on the list right now, would prefer some to be reviewed first - the point of it focusing review is lost if we just add all PRs in there :)
< gmaxwell>
I don't know that I have much to say, other that I thought it should get some attention (I know not everyone reads the list closely). I think this will be a good thing to implement and the people working on it are pretty eager.
< gmaxwell>
(and responsive)
< jnewbery>
wumpus: ok, tit-for-tat. I'll review a couple of those in the next week. Can you add #10740. I think it's ready for initial review
< wumpus>
thanks for mentioning it, I indeed missed it
< * BlueMatt>
is curious how this interacts with the questions about mempool sync
< BlueMatt>
though I havent read the dandelion stuff much
< wumpus>
jnewbery: ok added
< gmaxwell>
BlueMatt: externally to it. Basically it's a quiet forwarding thing that has little to no mempool interaction.
< jnewbery>
wumpus: thanks!
< gmaxwell>
BlueMatt: so that public distribution of transactions happens away from the source.
< BlueMatt>
gmaxwell: well based on the dandelion tl; dr i just got, it seems to me that dandelion is essentially the old mempool-sync proposal of "relay txn to only one, maybe two peers but then do sync of your mempool with your peers every so often to propagate things more fully"
< BlueMatt>
except they replace sync with "broadcast after a while"
< gmaxwell>
BlueMatt: kind of. it's not in your mempool though when it passes through in the one at a time propagation.
< sipa>
BlueMatt: but dandelion has rebroadcast too, which can't be avoided (if you dandelion-forwarded a TX, but don't see it N seconds later on the normal network, you yourself start broadcasting it normally)
< morcos>
sipa: why not dandelion it again?
< BlueMatt>
sipa: yes, I'm asking for comparison between dandelion and the old mempool-sync proposal of gmaxwell
< sipa>
morcos: the dandelion stem isn't expected to reach the entire network
< BlueMatt>
it sounds to me like the gmaxwell proposal is effeciely similar, though maybe dandelion pointed out (correctly, I suppose) that you want to not add it to your mempool until later to preserve privacy
< sipa>
so you still need something outside of dandelion-forward and mempool reconciliation
< gmaxwell>
Peer hands you a txn with a private flag. Assuming the txn is valid wrt your mempool, you set it aside and forward it on to a single other peer (determinstically selected based on the input peer). At random, you drop the private flag when you relay it with some fixed probablity. If the txn is offered by other peers you fetch it.
< gmaxwell>
If after a timeout you never see it from other peers you broadcast it yourself.. but that only happens if someone in the 'stem' path drops the ball.
< sipa>
BlueMatt: there seems to be some overlap, but i don't think dandelion+sync is a complete solution
< gmaxwell>
so it is similar to my relay improvement proposal, but the privacy requirements mean that it doesn't accomplish syncing itself.
< morcos>
sipa: hmm, i was just asking if you didn't see it, why you wouldn't repeat the whole process assuming the stem got cut somehwere, and hoping that you can get to the fluff on try 2. why fall back to old method
< BlueMatt>
wait, wait doesnt "(determinstically selected based on the input peer)" imply that you can still group transactions from a single source based on where you first saw them....sure where you first saw them wont be the guy who created it, but it'll still be the same for all txn from the same guy
< BlueMatt>
maybe I should shut up and go read it
< sipa>
morcos: the 'fluff' is just normal tx relay
< gmaxwell>
BlueMatt: so it is like my relay bandwidth improving proposal, without improving relay bandwidth. :P
< BlueMatt>
heh, yea, ok
< gmaxwell>
BlueMatt: only if you are inside the stem yourself. (this was a change their latest work makes)
< BlueMatt>
hmm, alright
< gmaxwell>
the tradeoff is that if you don't do the determinstic routing and the sender sends lots of txn you are certian to be in the stem for some of them.
< gmaxwell>
basically related to the guardnodes problem in tor.
< gmaxwell>
in any case, it would be good to have more critical eyes on their design. I've only just started thinking about the implications of the change to determinstic paths.
< sipa>
PLOINK
< wumpus>
yes, extrememly important for privacy to not make any mistakes here
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 21 20:00:18 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gmaxwell>
wumpus: At least the current behavior is weak enough that it would be hard to not make an improvement. :)
< BlueMatt>
hah, yea, that ^
< wumpus>
sure
< gmaxwell>
unrelated, my gpg encryption subkey expired a bit ago. I just replaced it with a newly generated one... with the rationale that its good to rotate such things, and unlike identity keys, easy to rotate them. I can still decrypt with the old one for now.
< wumpus>
your new key is on the keyserver?
< achow101>
does anyone know when verack was added to the protocol? It's not in the first version but I can't find any documentation about it
< wumpus>
apparently it is, refresh-key worked gpg: new subkeys: 1
< gmaxwell>
wumpus: yes. as of about the beginning of the meeting.
< jnewbery>
promag: because it's likely to take quite a bit of review and I'd like it in for 0.16. It will also provide a resolution to the keypool topup corner cases that prevented a full fix for that issue getting into v0.15.
< luke-jr>
#10615 and GUI support should go before 10740..
< gribble>
https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
< luke-jr>
far more important to be able to actually use it, than dynamic open/close
< promag>
luke-jr: no PR for GUI support right?
< luke-jr>
promag: no, because it's built on top of 10615
< luke-jr>
promag: the branch is named multiwallet_gui
< promag>
mind I take a look?
< promag>
so the concept is to have a combobox to choose the wallet in the mainwindow?
< luke-jr>
promag: yes, it works pretty well
< luke-jr>
been shipping it in Knots since 0.13 ;)
< luke-jr>
maybe I should open a PR so it at least has that
< promag>
does it restores the current wallet when it starts?
< luke-jr>
promag: no
< luke-jr>
maybe it should
< promag>
yeah, like the geometry stuff
< luke-jr>
promag_: not sure it makes sense for the wallet, since presumably you'd be using all the wallets (you don't reposition the GUI geometry normally)