19:01:49 <wumpus> #startmeeting
19:01:49 <lightningbot> Meeting started Thu Apr 12 19:01:49 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:49 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:04 <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
19:02:09 <promag> hi
19:02:12 <Randolf> Hello.
19:02:13 <achow101> hi
19:02:15 <sipa> hi
19:02:16 <jonasschnelli> hi
19:02:27 <kanzure> hi.
19:02:36 <cfields> hi
19:02:39 <meshcollider> hi
19:02:40 <wumpus> any proposed topics?
19:02:42 <luke-jr> o hai
19:02:59 <sipa> #12874 What to do with IsMine of bare multisig?
19:03:01 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
19:03:18 <wumpus> thanks
19:03:29 <jimpo> hi
19:03:29 <promag> dynamic wallet load/unload
19:03:37 <luke-jr> I don't know why we would *ever* accept bare multisig
19:03:41 <wumpus> let's start with "high priority for review" as usual
19:03:44 <wumpus> #topic high priority for review
19:03:55 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:04:14 <jimpo> Waiting on BlueMatt to rereview #11857 after revision
19:04:17 <wumpus> #11857 #12560 #11775
19:04:17 <BlueMatt> #11775 should probably removed and replaced with the forthcoming split of it into multiple pr's
19:04:18 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
19:04:23 <gribble> https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
19:04:28 <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
19:04:29 <BlueMatt> though the first few commits could still use eyeballs
19:04:29 <gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
19:04:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11775 | Move fee estimator into validationinterface/cscheduler thread by TheBlueMatt · Pull Request #11775 · bitcoin/bitcoin · GitHub
19:04:40 <sdaftuar> BlueMatt: i'll give you my comments after you split it :P
19:04:43 <BlueMatt> as for 11857, yes, thats my fault :/
19:05:17 <jtimon> hi
19:05:37 <jimpo> #12560 still has one unaddressed comment by me I think
19:05:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
19:05:40 <wumpus> BlueMatt: ok
19:05:41 <BlueMatt> as for 12560...why no reivew? :/
19:06:09 <wumpus> dunno github gives me the unicorn now
19:06:48 <Randolf> The "unicorn?"
19:06:48 <jtimon> I guess https://github.com/bitcoin/bitcoin/pull/10757 is not a priority, but review beg either way now that there's many people
19:06:59 <sipa> #10757
19:07:02 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
19:07:27 <wumpus> Randolf: the "This page is taking way too long to load." unicorn
19:07:43 <BlueMatt> lol, cancel meeting cause github broken?
19:07:54 <Randolf> wumpus:  I haven't seen that one yet.
19:07:58 <Randolf> That's hilarious.
19:07:58 <wumpus> looks like the bot still can use the API
19:08:05 <jtimon> works for me just fine...
19:08:24 <jtimon> I got a unicorn the other day though, I reloaded and it worked
19:08:55 <wumpus> usually it takes a few minutes and then it works again
19:09:10 <promag> jtimon: I'll take a look
19:09:19 <jtimon> promag: awesome, thanks
19:09:28 <wumpus> I'll add 10757
19:09:59 * Randolf wonders if "Unicorns" is going to be listed as one of the topics in the log afterwards
19:10:18 <achow101> i believe i addressed all comments for 12560, but i could have missed one or two
19:10:30 <jtimon> great, I had it kind of abandoned for some time but aj helped me with the tests and I got "unstuck"
19:11:10 <promag> I can also look 12560, at least code wise
19:11:10 <jimpo> achow101: I requested that HaveKey be moved out of the RPC file and into keystore
19:11:15 <jimpo> not sure if others agree
19:12:27 <wumpus> might want to discuss that outside the meeting?
19:12:41 <achow101> oh, I missed that comment
19:12:58 <jnewbery> hi
19:13:04 <plorark> hey
19:13:05 <plorark> omg
19:13:10 <plorark> I've found people alive
19:13:12 <jimpo> yeah, we can discuss offline (well, still online, but yeah)
19:13:31 <plorark> watshapenin
19:13:32 <wumpus> #topic What to do with IsMine of bare multisig? (sipa)
19:13:46 <sipa> hi
19:13:48 <wumpus> plorark: after the meeting please
19:13:50 <Randolf> plorark:  You've joined this channel during a meeting.
19:14:04 <plorark> omg sorry
19:14:05 <sipa> so currently (and since forever) we accept bare multisig outputs to us
19:14:25 <sipa> this is stupid, annoying, pointless, and hard to maintain
19:14:33 <achow101> are there any wallets that can even make bare multisig?
19:14:42 <sipa> BIP70, technically :)
19:14:48 <achow101> ew
19:14:52 <sipa> because it only works when you have all the public keys
19:15:00 <sipa> eh, all the private keys
19:15:12 <wumpus> sounds completely useless
19:15:12 <sipa> so generally i think this is a feature that nobody should ever want
19:15:19 <luke-jr> we don't act as BIP70 server ever though
19:15:26 <sipa> however, there may be existing outputs to it
19:15:33 <sipa> i don't know if this is the case or not
19:15:38 <jtimon> do people use bip70 ?
19:15:39 <sipa> but it sounds scary to just stop supporting it
19:15:47 <wumpus> so  that needs some chain analysis I suppose
19:15:55 <echeveria> bitpay uses bip70 exclusively.
19:16:06 <BlueMatt> sipa: we'd not "stop supporting it", you'd still be able to sign for them in rawtransaction rpcs
19:16:14 <BlueMatt> so write up a five-sentence release not and stop supporting it :p
19:16:20 * luke-jr wonders how much overhead there'd be to supporting it up to a certain height
19:16:24 <achow101> sipa: is it possible to just prevent new bare multisig?
19:16:25 <jtimon> sipa: perhaps deperecate it on the next release ?
19:16:25 <sipa> BlueMatt: i have no intention to stop supporting signing for it
19:16:29 <jtimon> echeveria: thanks
19:16:34 <BlueMatt> sipa: yes, thats my point
19:16:36 <sipa> this is just about IsMine
19:16:46 <wumpus> just stop supporting it for receiving to our wallet
19:16:58 <sipa> yes, that's the easy part
19:17:07 <jtimon> BlueMatt: sounds fair enough
19:17:08 <sipa> but what if there are existing outputs in people's wallet
19:17:09 <BlueMatt> I mean step back a minute, if we're still talking about doing another hd split to move to a address model instead of a pubkey model in the wallet, why not do it then
19:17:19 <BlueMatt> and keep doing the default-add of the scripts from the original keys?
19:17:28 <BlueMatt> incl all the stuff we support today
19:17:37 <sipa> BlueMatt: ah, because it's impossible to remain compatible with it in an address model
19:17:46 <jonasschnelli> if one has already detected bar multisig txns, they will not disappear (unless rescan)?
19:17:47 <sipa> (you get a cubic explosion of combinations)
19:17:58 <BlueMatt> I though we only supported about 4 different script types?
19:18:02 <instagibbs_> sipa: sorry give an example?
19:18:07 <BlueMatt> raw multisig, p2ph, p2pubkey, and...?
19:18:15 <achow101> isn't the plan to move to a script model?
19:18:20 <sipa> BlueMatt: yes, but raw multisig up to 3-of-3
19:18:30 <BlueMatt> ouch
19:18:31 <sipa> which means N^3 combinations if you have N private keys
19:18:32 <plorark> ehh... I know I was not supposed to interrupt the meeting, but it's pointless for me to wait if this is not the channel i'm looking for. Is altcoins development discussions allowed here?
19:18:39 <Randolf> I thought Multisig could support more than 3 signatures.
19:18:39 <sipa> plorark: no
19:18:44 <sipa> Randolf: not standard
19:18:50 <instagibbs_> plorark: no
19:18:55 <plorark> oh, ok, sorry
19:18:56 <plorark> see ya
19:18:59 <Randolf> plorark:  Join the ##altcoins channel.
19:19:01 <plorark> thx
19:19:10 <plorark> thx
19:19:10 <luke-jr> ##altcoin-dev *
19:19:12 <plorark> oops
19:19:19 <plorark> thx and bye
19:19:19 <BlueMatt> I mean, anyway, does it matter much? I'd default to "dont support with release notes indicating you can use signrawtransaction"
19:19:31 <sipa> so the #1 reason to fix this now is because I'd like to remain compatible with whatever the wallet already supports
19:19:34 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
19:19:35 <sipa> except for bare multisig
19:19:46 <BlueMatt> if we really care, add an option to include them when we move to address-based
19:19:51 <BlueMatt> with a note indicating it will eat all your memory
19:19:54 <Randolf> sipa:  Maintaining compatibility seems like a very good justification.
19:20:09 <sipa> BlueMatt: by default our keypool is 2000 keys
19:20:14 <sipa> the cube of that is 8 billion
19:20:15 <BlueMatt> yes, I know
19:20:19 <sipa> that's just not feasible
19:20:24 <jimpo> Is there a way to register bare multisigs as some sort of key-thing?
19:20:31 <BlueMatt> meh, so dont support it at all without manual key-adds, then
19:20:46 <BlueMatt> jimpo: you could register the scripts as watch only
19:20:49 <instagibbs_> jimpo: manual import isn't out of question i assume
19:20:49 <sipa> BlueMatt: that's what #12874 does!
19:20:51 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
19:20:52 <jimpo> So that IsMine is true only if you explicitly watch the script
19:21:05 <sipa> jimpo: yes, that is the PR i have open
19:21:07 <BlueMatt> sipa: I dont even think we need to match IsMine/accept them at that point
19:21:10 <jimpo> Oh, cool
19:21:13 <BlueMatt> sipa: would prefer we get rid of it completely
19:21:19 <BlueMatt> and just let people mark it watchonly
19:21:22 <sipa> i want to bring up is: is this overkill, and should we instead just remove it
19:21:22 <BlueMatt> then signrawtransaction it
19:21:31 <sipa> can you watchonly it?
19:21:40 <sipa> you can only watchonly addresses, not scripts, afaik
19:21:54 <sipa> ok i will investigate
19:21:55 <sdaftuar> importmulti lets you, i thought?
19:21:56 <instagibbs_> does it not sneak under redeemscript field or somesuch?
19:21:59 <jonasschnelli> just stop supporting it and mention it in the release notes... this seems safe and okay to me.
19:22:00 <instagibbs_> yeah check it out
19:22:45 <jimpo> sipa: Do you think there's a large burden to maintaining #12874?
19:22:46 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
19:23:13 <sipa> jimpo: no, but it'd be better not to
19:23:21 <jonasschnelli> bar-multisig use-cases are data-services only IMO... we could analyze the utxos first to get a idea about how many potentail users would be affected...
19:23:29 <jonasschnelli> but right,.. existing bare multisig wtx would not disapear, right?
19:23:47 <sipa> they would
19:23:57 <jonasschnelli> ah.. isMine(), right
19:24:20 <jonasschnelli> but we could detect that and warn
19:24:43 <jimpo> If there's not a big downside to #12874, I'd prefer that approach, but don't care much if it's deprecated
19:24:45 <gribble> https://github.com/bitcoin/bitcoin/issues/12874 | Only accept bare multisig outputs after addmultisigaddress by sipa · Pull Request #12874 · bitcoin/bitcoin · GitHub
19:25:24 <sipa> BlueMatt: it seems we can indeed watch scripts
19:25:35 <sipa> i think that's my preferred approach then
19:25:55 <sipa> remove support entirely and note a workaround for the highly unlikely case in the release notes
19:26:07 <BlueMatt> yes
19:26:07 <jonasschnelli> ack
19:26:08 <wumpus> yes
19:26:09 <BlueMatt> agreed
19:26:12 <sipa> end topic
19:26:28 <wumpus> #topic dynamic wallet load/unload (promag)
19:26:34 <Randolf> Ack.
19:26:50 <promag> not sure what you guys think
19:26:56 <instagibbs_> what's the controversy in this topic :)
19:27:01 <jonasschnelli> #10740
19:27:02 <sipa> it should happen, duh
19:27:04 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
19:27:06 <wumpus> seems like something we want to have at some point...
19:27:07 <promag> but I think luke agrees that wallet management should be with shared pointers
19:27:08 <sipa> how and when is another :)
19:27:26 <luke-jr> indeed, using names just asks for chaos with runtime-changing wallets
19:28:19 <promag> please read #11402 for some reasons to switch
19:28:20 <gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
19:28:54 <jonasschnelli> IMO 10740 can't create wallets, IMO first step would be to add a createwallet RPC call
19:29:21 <jonasschnelli> the whole creation/configuration setup if flawed since multiwallet
19:29:29 <jonasschnelli> stuff like -keypool should be per wallet
19:29:40 <jnewbery> jonasschnelli: you think createwallet should go in *before* load/unload?
19:29:43 <jonasschnelli> and persisted in the wallet file (as configuration section)
19:29:55 <jonasschnelli> jnewbery: not sure,.. just thinking
19:30:05 <jnewbery> seems reasonable to me
19:30:25 <jonasschnelli> createwallet could also *not* load the wallet in the first step (not ideal, but maybe reduces complexity)
19:30:25 <sipa> that seems strange... you could create a new wallet at run time but not use it?
19:30:41 <jonasschnelli> sipa: createwallet could also directly load/use the wallet
19:30:46 <jnewbery> I think createwallet would also load the new wallet, no?
19:30:48 <promag> create implies loading
19:30:52 <luke-jr> sipa: iow, 0 to 1 only.
19:31:06 <sipa> jonasschnelli: well then you need to have loading functionality first!
19:31:14 <sipa> and if you have it, why not expose it
19:31:53 <jonasschnelli> sipa: yes. That's a point.
19:31:54 <jnewbery> createwallet could also be done by bitcoin-wallet-tool
19:32:23 <jnewbery> (#8745)
19:32:25 <gribble> https://github.com/bitcoin/bitcoin/issues/8745 | [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" by jonasschnelli · Pull Request #8745 · bitcoin/bitcoin · GitHub
19:32:35 <jonasschnelli> Yes. Would be possible...
19:32:55 <jonasschnelli> I just think the create-during-startup approach is not good
19:33:06 <promag> also related #10973
19:33:07 <jnewbery> jonasschnelli: I agree
19:33:09 <gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
19:33:10 <sipa> jonasschnelli: agree
19:33:24 <jonasschnelli> And as a first step I though createwallet would make sense.. but not loading it seems after a strange use-case
19:33:29 <luke-jr> load -> create -> unload
19:33:33 <jonasschnelli> but a nice first code/impl. step
19:33:36 <luke-jr> unload is the complex part tbh
19:33:49 <jnewbery> luke-jr: agree
19:34:05 <jonasschnelli> Agree with luke-jr. Maybe split unload away from the existing PR jnewbery ?
19:34:12 <jnewbery> yes
19:34:28 <jnewbery> I intend to pick up 10740 again soon, rebase and rework it
19:34:39 <promag> consider the use case: 1) rpc rescan wallet 2) in parallel unload wallet - should 2) wait for 1) ?
19:34:57 <luke-jr> probably
19:35:01 <jonasschnelli> Great. Dynamic loading/creating is a nice feature that we probably want for 0.17!
19:35:30 <promag> luke-jr: and if the unload is from the UI?
19:35:57 <jnewbery> promag: do you consider 11402 a prereq for load/unload? What about just load?
19:36:01 <jonasschnelli> the wallet-tool is IMO orthogonal to wallet creation
19:36:13 <jonasschnelli> *via RPC
19:36:39 <luke-jr> promag: probably the same
19:36:43 <promag> jnewbery: IMHO for both
19:36:50 <jonasschnelli> RPC seems to be a must, wallet-tool can be a better place to create some sorts of wallets (or inspect it), .. like encrypted wallets
19:36:52 <luke-jr> promag: at least initially
19:37:40 <jnewbery> promag: want to rebase and put on high priority for review then, if you consider it a blocker?
19:37:50 <promag> luke-jr: my point is that it should not block, you request the unload and go on, when the wallet is not used anymore it gets unloaded
19:38:11 <jonasschnelli> #11402
19:38:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11402 | Use shared pointer for wallet instances by promag · Pull Request #11402 · bitcoin/bitcoin · GitHub
19:38:15 <luke-jr> promag: you mean leave the wallet loaded, but invisible? that seems worst outcome IMO
19:38:26 <luke-jr> user may unload and just shut off the PC
19:38:44 <wumpus> the unload should probably be in two stages: after requesting it, RPC and the GUI lose access to it. Then it waits for current operations tofinish. Then the thing really gets delted.
19:38:50 <luke-jr> yes
19:38:53 <promag> luke-jr: then the application will wait for wallets to unload
19:38:54 <jnewbery> I don't think we need to worry about unload at this stage. First step is add load functionality, then createwallet functionality
19:38:57 <luke-jr> and make it visible to the user in the meantime
19:39:06 <luke-jr> jnewbery: +1
19:39:17 <promag> wumpus: right, hence shared pointers
19:40:13 <wumpus> ok
19:40:19 <wumpus> any other topics? we've had the proposed ones
19:41:05 <luke-jr> gitian updates?
19:41:17 <luke-jr> seems we have at least a few things that need a newer VM
19:41:27 <luke-jr> not sure if there's anything to discuss tho
19:42:33 <wumpus> dunno if cfields is here, if not it makes little sense to discuss this I think
19:42:45 <cfields> sure
19:43:01 <wumpus> #topic gitian update
19:43:38 <wumpus> #12511 I guess
19:43:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
19:44:24 <wumpus> not sure what's there to discuss about it
19:44:53 <luke-jr> I guess we need a replacement for vmbuilder or something, since Canonical hasn't updated it to support anything recent :/
19:45:55 <cfields> ah, i didn't realize gitian couldn't handle it :(
19:46:02 <wumpus> debootstrap?
19:46:10 <luke-jr> debootstrap is a step in vmbuilder
19:46:47 <cfields> anyway, concept ack
19:47:36 <achow101> I'm considering adding docker support to gitian so we would use a default ubuntu docker image and then build from there
19:47:37 <wumpus> cool
19:48:20 <cfields> sgtm
19:48:25 <jcorgan> that would be nice
19:49:05 <wumpus> yes
19:49:18 <luke-jr> so KVM would no longer work?
19:49:45 <wumpus> heh if you make it work it will work
19:49:56 <luke-jr> Docker seems to just be a LXC wrapper
19:50:18 <achow101> Docker avoids all of the vm setup because someone else did that for us
19:50:21 <luke-jr> it's also x86-64 only
19:50:24 <wumpus> if vmbuilder or debootstrap does't work you could always manually install ubuntu to a base image I guess...
19:51:04 <jtimon> achow101: please, ping me for review if you do
19:51:07 <wumpus> but in my experience debootstrap works very well, though I've never used it for ubuntu on x86
19:51:19 <wumpus> I
19:52:12 <achow101> jtimon: sure
19:53:19 <wumpus> yes, I'm willing to test the docker stuff as well
19:53:39 <luke-jr> I suppose fixing vmbuilder might be not too unreasonable effort, maybe I will try that :/
19:53:49 <wumpus> though I agree iwht luke-jr it's not a long-term solution, can't be used from other platforms, though cfields is still working on his long-term solution I hope
19:54:28 <cfields> wumpus: yes, very much so.
19:54:55 <wumpus> great!
19:55:30 <wumpus> time to wrap up the meeting I think
19:55:39 <wumpus> unless someone has a quick topic
19:56:11 <wumpus> #endmeeting