19:02:03 #startmeeting 19:02:03 Meeting started Thu Jul 19 19:02:03 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:06 hi 19:02:20 #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:22 hi. 19:02:26 hu 19:02:29 hi 19:02:32 hi 19:02:35 ho 19:03:00 PSA: 0.16.2rc2 executables have been uploaded today and announcement sent 19:03:25 thanks wumpus 19:03:54 any topics? I think main priority is to review feature PRs that need to go in before the feature freeze - which was postponed to the 23th 19:04:03 4 days and ticking... 19:04:05 although we maerged a view 19:04:15 few* 19:04:15 last chance to vote on scheduling if you haven't already. Poll closes at the end of the meeting 19:04:25 cfields: I voted 19:04:25 I'd like to see #9662 merged... 19:04:32 https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub 19:04:32 (has >5 acks) 19:04:42 wumpus: thanks :) 19:04:49 jonasschnelli: let's do it then 19:05:09 topic suggestion: exposing coin selection (or other possibly more internal things) as rpcs 19:05:21 #9502 has also a couple of acks and waits for a final review from cfields 19:05:24 https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub 19:05:29 (was originally tagged for 0.17) 19:05:37 i also want to bring up #13697 which changes the API for scantxoutset 19:05:40 https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub 19:05:44 Topic Suggestion: Hi everyone, I propose moving the bitcoin-seeder from sipa's private GitHub (https://github.com/sipa/bitcoin-seeder) to the bitcoin-core GitHub organisation (https://github.com/bitcoin-core). (if this is on-topic) 19:05:53 jonasschnelli: oh! sorry, will take a look right after the meeting 19:06:00 thanks cfields 19:06:10 I think sipas 13697 should be added to the high prio list 19:06:11 Nice, though it would be nice if a followup PR made disable_private_keys positional, then we'll see if that part makes it into 0.17 19:06:20 non-positional 19:06:22 (since it's an API thing) 19:06:26 if it doesn't go into 0.17, it'll either need to be an addition rather than a replacement, or we need to mark the API experimental (which may be a good idea regardless) 19:06:48 I think it's more relevant right now to tag things for 0.17 instead of adding them to the high-priority list 19:06:59 Or that, yes. 19:07:10 everything that needs to go into 0.17 is high-priority by definition 19:07:20 in general I think it's a sensible default policy to mark new APIs as experimental 19:07:25 (although some things are taggd 0.17 that shouldn't be,I tihnk) 19:07:34 what about #13666 ? 19:07:37 https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub 19:07:52 What's in a number? 19:08:01 13 and 666, can't beat those odds 19:08:17 niice 19:08:35 it was completely planned, obviously 19:08:40 Could #13426 be tagged for 0.17? 19:08:42 https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Add u8path and u8string to fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 19:08:45 in some timezones it was also opened on friday the 13th 19:09:03 oh, no 19:09:20 I hope no black cat was sitting on the keyboard during coding 19:09:20 ken2812221_: done 19:09:32 thanks 19:09:50 if it is a bugfix it can also go in after the feature freeze 19:10:01 tagged 13666 13426 and 13697 with 0.17 19:10:06 absolutely 19:10:34 12 PRs tagged 0.17 :o 19:10:44 * sipa fires up the review engine 19:10:44 #13712 is a bug fix for 0.17 too 19:10:46 https://github.com/bitcoin/bitcoin/issues/13712 | wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation. by practicalswift · Pull Request #13712 · bitcoin/bitcoin · GitHub 19:10:53 Looks like #8469 won't make it for 0.17. I guess untag would make sense 19:10:56 https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub 19:11:08 jonasschnelli: yes will remove that one 19:11:41 Also #13617 (I like, but to wip-ish for the timing of 0.17) 19:11:43 https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub 19:11:53 and added 13712 19:12:22 jonasschnelli: ok 19:13:01 jonasschnelli: if 13617 isn't ready in time (I don't see why it wouldn't, though), we can always bump the requirement and leave the stale code for later removal 19:13:15 #13617 19:13:18 https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub 19:13:56 Oh. Right... it's not a feature... agree with cfields 19:14:08 re-add it then? 19:14:20 Yes. I'll do it. Sry for the confusion 19:15:00 no problem 19:15:11 #topic exposing coin selection on RPC (achow101) 19:15:22 What does that mean precisely? 19:15:51 this came up in a discussion with some companies about coin selection. basically, some are interested in using core's coin selection (or someone elses) instead of having to implement/roll their own 19:15:54 I'd say listunspent+raw transactions API 19:16:14 currently if they wanted to use core's coin selection, the utxos need to be in the wallet, i.e. the addresses and possibly keys need to be in the wallet 19:16:17 fundrawtransaction? 19:16:17 that is not ideal for them 19:16:17 achow101: hmm,... is RPC the right interface for that?` 19:16:28 i suggested to achow101 that a library might be a better way of doing so 19:16:31 but again what does that mean. like isn't fun-draw-transaction that? 19:16:31 Right.. what wumpus said 19:16:39 the idea was then to have an rpc call where the utxos are provided and coin selection is operated on those utxos 19:16:46 gmaxwell: they don't want to use the wallet; they just want to be able to run coin selection 19:16:51 you can import utxos into the wallet with importprunedfunds 19:16:53 wumpus: fundrawtransaction requires the wallet 19:17:03 achow101: using private key disabled dynamic wallet in conjunction with fundraw seems very efficient 19:17:08 I am doubtful that it is worth our effort in maintaining a stable interface for such a thing. 19:17:11 wumpus: that's probably slow with hundreds of thousands of utxos 19:17:11 meh, RPC is not a good place for pure utility functions 19:17:26 if it doesn't need the wallet nor core state, why have it on *remote* procedure call? 19:17:26 E.g. kallewoof's recent grouping PR would have obliterated the interface for coin selection. 19:17:53 it just creates a central point of faliure for no good reason 19:18:03 a library indeed sounds like a better idea 19:18:04 Agree with wumpus. 19:18:27 I know a library would be cumbersome to implement (compared to RPC),... but that is a weak argument IMO 19:18:27 RPC is not a good way to do code sharing 19:18:39 it sounded like people really like RPC interfaces over libraries though, for reason i have difficulty comprehending 19:18:52 a library is probably better, but the issue with libraries is that they all use different languages. so a different library for each language would need to be created 19:18:54 but one possibility would be to have a separate binary with utility functions, that exposes an RPC 19:19:00 its just the webby world. 19:19:03 I don't get it 19:19:06 and they seemed to like rpcs where things are easily dropped in 19:19:08 I don't want to debate this madness 19:19:12 achow101: C(++) is callable from every language.... :P 19:19:21 Wild though: provide a cli tool? 19:19:22 [13bitcoin] 15masonicboom opened pull request #13717: docs: Link to python style guidelines from developer notes (06master...06link-to-python-style-guidelines-from-dev-notes) 02https://github.com/bitcoin/bitcoin/pull/13717 19:19:25 (well C is, C++ via making a C interface. :) ) 19:19:27 *thought 19:19:28 jonasschnelli: slow 19:19:41 but in any case, if you have a library you can also wrap that to present an RPC. 19:19:44 (a library & a CLI tool for the lazy people) 19:19:51 cli also a 'remote' call, though it invokes a new process for every call! 19:19:57 but it has the same issues with (de)serialization 19:20:06 But the argument I was making above is also an argument against a library: pressure to maintain a stable interface to this would be harmful to the project. 19:20:20 right 19:20:24 indeed... if performance is the goal, a library is probably the right choice. 19:20:26 i think coin selection is relatively well encapsulated 19:20:46 i also don't see how kallewoof's groupings would break the API 19:20:47 sipa: I just gave an example where recent changes changed the API substantailly. 19:21:05 Both BNB and kallewoof changed arguments to every entry point. 19:21:18 to be honest I think this is not a concern for our project 19:21:21 gmaxwell: but the interface exposed to the callers did not 19:21:26 so? overall it takes a list of UTXOs and gives a subset back 19:21:41 some other people want a coin selection algorithm for their own purposes 19:21:58 gmaxwell: only things within selectcoins changed, and an rpc would effectively only expose selectcoins 19:22:00 it's fine, they can make a library out of it themselves 19:22:05 it's more tightly coupled than "list of UTXOs" ... e.g. it needs fees, signature sizes. 19:22:09 the code is open source 19:22:52 I mean if someone can jigger things around to make it seperable and they find that useful, fantastic. 19:22:57 wumpus: sure the code is open source, but it is not something that can easily be taken out and dropped into something else. 19:23:05 But I don't want to hear "we can't implement privacy feature X because it'll break an interface" 19:23:05 for the consensus code I see a strong reason to provide it as a library: it is *important* that everyone uses the same consensus code 19:23:08 wumpus: I think what they want is something maintained by the same people 19:23:22 jonasschnelli: the same people might not agree with that, who asks them?! 19:23:37 perhaps they should contribute to making the wallet code better so they don't have to write their own. :P 19:23:39 they might want the whole world to be maintained by the same people 19:23:52 heh... 19:24:38 gmaxwell: right, exactly 19:25:24 the general feeling was that they wanted core to be more modular so that they can pick and choose specific internal components to use in their software 19:25:44 also more generally that there was some sort of "canonical" libraries for things instead of everyone implementing their own thing 19:26:00 but making internal interfaces stable does restrict future flexibilty, as gmaxwell says 19:26:11 it's already hard enough to change the RPC interface 19:26:54 I understand the desire for that, bt puttingn that all on our plate is unreasonable 19:27:00 as well as centralization 19:27:58 it's not how things can work in a project like this, the same group providing canonical implementations for everything 19:28:10 right 19:28:21 suggested topic: next Core dev tech meetup 19:28:45 wumpus: there is some benefit to making the Core coin selection algorithm more generally usable though 19:29:15 jnewbery: people that want that, can work on that, the code is open source, they can make a library out of it 19:29:16 eg if we think it's good and reduces UTXO bloat, having more people using it is a benefit 19:29:35 if it turns out to be feasible enough then core can start using that library too 19:29:43 that's a two-step process, though 19:29:52 i think the first step for this is something we're doing anyway; making the code itself more encapsulated 19:29:53 Agree with wumpus: I guess its a one-day job to extract the coin selection code and create a library out of it... 19:30:01 no it's not 19:30:05 The burden is the maintenance... 19:30:08 it's currently split between wallet code and coinselection 19:30:12 jonasschnelli: I doubt it's that easy 19:30:13 and that's improving 19:30:13 [13bitcoin] 15masonicboom opened pull request #13718: docs: Specify preferred Python string formatting technique (06master...06python-string-format-guideline) 02https://github.com/bitcoin/bitcoin/pull/13718 19:30:19 yes, agree that anyone can work on it. I think it's a legitimate thing to bring up in a core meeting though 19:31:00 i think it's great to hear there is interest in code we're writing 19:31:10 sipa: +1 19:31:16 sipa: so in as far as that helps our own maintainability of the walletcode, that's a good thing 19:31:58 wumpus: perhaps once the code is sufficiently encapsulated, someone else can librarify that and maintain it 19:32:07 right 19:33:12 #topic #13697 which changes the API for scantxoutset 19:33:15 https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub 19:33:16 (sipa) 19:33:41 first of all, this is part of a bigger effort to combine keys and scripts and chains into one concept 19:34:14 there's a mini language to specify (sets of) scriptPubKeys, so i'd very much first want to hear comments on that language 19:34:27 yes that is very neat 19:34:58 https://github.com/sipa/bitcoin/blob/895a46d83550838a8170ccba075367232eabbd8c/src/script/descriptor.h#L9L68 19:35:22 I really like it. Will review and test it asap! 19:36:00 the other question is scantxoutset experimental or not, and with descriptor support in 0.17 or not 19:36:03 What is the difference between the FlatSigningProvider and the dummysigner? 19:36:24 dummysignatureprovider doesn't provide anything 19:36:39 flatisigningprovider takes its information from flat maps 19:36:53 I see 19:37:00 I think scantxout should be marked experimental 19:37:05 Agree 19:37:14 Also with 13697... 19:37:18 agree 19:37:22 Helps us to do unplaned API changed 19:37:34 *changes 19:37:35 right 19:37:49 i plan to write a longer explanation in doc/descriptors.md or so 19:38:11 cool 19:38:21 thanks for working on this sipa 19:38:23 one of the future ideas is a PSBT standalone binary that can sign/update using descriptors 19:38:34 should these be a BIP? seems potentially useful outside Core 19:38:45 luke-jr: potentially yes, but not in first instance 19:38:53 i expect that this will evolve rather quickly 19:39:11 BIP drafts can evolve :p 19:39:22 maybe at some point, but as this doesn't touch consensus or P2P it'd be an advisory BIP at most, and it's not required to do it first 19:39:34 luke-jr: let's just leave it up to sipa 19:39:35 also, the part that actually needs interoperability is PSBT; descripors are just how we (or at least i hope) represent our knowledge 19:40:00 compability would certainly be useful too, but i'd rather take some time to see how things evolve 19:40:23 otherwise i fear we'll have something with a dozen optional parts all implemented by different subsets of software 19:40:34 yes 19:41:28 #topic bitcoin-seeder under bitcoin-core GitHub organisation (lclc) 19:41:49 lclc: no problem as far as I'm concerned, but i'm not sure it's the right message 19:41:52 Seems unnecessary. 19:42:03 I though because there are a few open issues and simple PRs for bitcoin-seeder and it might would make sense that several Bitcoin maintainers have merge rights. 19:42:04 there are other pieces of seeder software out there too, and having variety is a good thing here 19:42:16 should we put bfgminer, knots, kallewoof's script debugger stuff, etc under bitcoin-core too? :p 19:42:21 I know there are several seeder implementations but it appears to be the most used one. And since getting new node IPs by DNS is the default way to bootstrap a node in Core I think it makes sense to have one implementation in the bitcoin-core org. 19:42:29 luke-jr: if they want 19:42:43 wumpus: what sipa said - it sends the wrong msg IMO 19:43:09 yes, to be clear I don't think it's necessary 19:43:20 Another approach could be for sipa to give more people access to that repo? 19:43:22 No strong opinion... but slighly prefere to have it under the bitcoin-core repository 19:43:23 although maybe it would make sense for knots, but that would probably just be a mess on github 19:43:32 provoostenator: +1 19:43:40 to sipa giving access as desired 19:43:41 provoostenator: i'm fine with that! 19:43:51 as I said before with the library stuff, I think it's more robust to spread projects around instead of create the illusion that they're all maintained by the same 'team' 19:43:53 Or create an ad hoc organization "Sipa's DNS Seed maintainer club" 19:43:59 so agree with you on that luke-jr 19:44:09 there's no reason to turn access to tht eCore github repo ainto an actual position 19:44:13 forgive the typos 19:45:11 That's also fine with me 19:45:14 topic suggestion: moving away from bitcoin.org more 19:46:02 I (and others) just have a few simple PRs open (and open PRs feels like potential outstanding work in the future :D), so a few more maintainers (maybe jonasschnelli ?) would be good 19:46:06 #topic moving away from bitcoin.org more (achow101) 19:46:12 not sure there's anything further we can do in terms of oving away..? 19:46:18 we still link to bitcoin.org for things like downloads 19:46:20 achow101: moving what, excatly? executables have been moved 19:46:22 should probably change those 19:46:24 I'm pretty familiar with the seeder code and happy to co-maintain it 19:46:26 achow101: where? 19:46:27 achow101: where? 19:46:31 in the readme 19:46:36 I don't think we link to bitcoin.org for downloads any more 19:46:46 at least in the release mail I link to bitcoincore.org nowadays 19:47:13 suggested topic: next Core dev tech meetup :) 19:47:15 For more information, as well as an immediately useable, binary version of 19:47:15 And there's guiconstants.h: QAPP_ORG_DOMAIN "bitcoin.org" 19:47:18 the Bitcoin Core software, see https://bitcoin.org/en/download 19:47:19 Open a PR to remove that link from the readme. I will happily ACK 19:47:21 bitcoin.org could increase distance further, but someone needs to do that work, and people whined when they tried, so I think it's stuck 19:47:29 I think the link to bitcoin.org is only for the *general* descriptoin of bitcoin 19:47:35 that certainly would be confusing to make bitcoincore.or 19:47:39 moneyball: yep 19:47:43 wumpus: see quote above 19:47:46 provoostenator: oh yeah, that was an issue for distro stuff somewhere IIRC 19:47:54 sipa: oh yes that should go 19:48:03 ack on that in any case 19:48:06 provoostenator: don't change that! it determines the settings path 19:48:08 provoostenator: might want to make it something generic though, not Core-specific 19:48:23 I was thinking that it may not be appropriate to make release posts on bitcoin.org, at least not before they go up on bitcoincore.or 19:48:52 wumpus: I think it's used outside settings too, but maybe best to just leave it alone 19:48:58 as in we should simply take the bitcoin.org steps out of our release process and if someone wants to do them later, then that's fine 19:49:04 perhaps a comment explaining it's for compatibility, nothing more 19:49:14 luke-jr: possibly, but at the least it loses the qsettings, that's also why it's not "Bitcoin core" named there yet 19:49:31 achow101: would that really make anything better? 19:49:43 achow101: are you seriously suggesting I should no longer update bitcoin.org and upload binaries there? 19:49:55 yes 19:50:17 wumpus: are you aware of the recent events on bitcoin.org? 19:50:36 Well, I think technically he's suggesting not having that be part of the documented process, but you can do whatever you want. 19:50:42 acvaguely 19:51:05 Cobra wanted to make Knots the "default" on bitcoin.org a while back; we could encourage that, or (probably better) encourage not having a "default" 19:51:06 so I think this will effectively reduce the number of downloads 19:51:28 I don't care though, I don't want to be involved in political stuff at all, I' kind of burned out on that 19:51:34 wumpus: Core doesn't have a problem wth getting users atm 19:51:36 I think we should only publish binaries via bitcoincore.org and should not actively push it to other websites... 19:51:47 >99% of the network runs Core 19:51:47 It's gives a wrong sense of project coupling 19:51:48 there's ongoing work to move all of the bitcoin core stuff from bitcoin.org to bitcoincore.org 19:52:21 maybe the developer documentation too 19:52:33 if people are running/updating Core simply because it's on bitcoin.org, that is kind of a systemic risk we should address if possible 19:52:48 (and making it harder to "just run bitcoin.org" seems a step in that direction) 19:53:33 #topic next coredev tech meeting (moneyball) 19:54:03 Hi, I wanted to let people know I've volunteered to organize the next Core Dev Tech meetup 19:54:18 The current thinking is to have it in Tokyo in October after Scaling Bitcoin 19:54:22 thanks 19:54:24 Oct 8-10 19:54:27 thanks moneyball 19:54:30 yes, awesome! 19:54:35 moneyball: please update https://github.com/coredev-tech 19:54:37 Awesome indeed 19:54:39 thanks moneyball :) 19:54:58 And to organize it in a similar fashion as the last one in NYC 19:55:20 Cory put me in touch with the Digital Garage guys and they will be able to help quite a bit, similar to last year's Tokyo meetup 19:55:21 nice 19:55:50 I plan to send out a survey to collect some feedback 19:56:07 If anyone has specific ideas or suggestions please feel free to contact me 19:56:59 Nothing more from me about the topic now 19:57:04 side note: anime meetup after on Oct 11 if anyone's interested https://docs.google.com/document/d/1CWLhg8u9pfNWSVjgiPYt0V5ZIOQFSCIYYdSvzHaqOpQ/edit?usp=sharing 19:57:41 thanks moneyball for organising! 19:57:55 You're welcome happy to help! 19:58:18 yes, thanks moneyball! Looking forward to it :) 19:59:27 #endmeeting