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