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