19:00:01 <sipa> #startmeeting
19:00:01 <lightningbot> Meeting started Thu Jun 21 19:00:01 2018 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:01 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:08 <achow101> hi
19:00:13 <promag> hi
19:00:39 <meshcollider> Hi
19:00:45 <sipa> #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:00:52 <kanzure> hi.
19:00:57 <sipa> topics?
19:01:00 <kanzure> alert key
19:01:05 <kanzure> not priority tho
19:01:42 <instagibbs> hi
19:02:24 <sipa> okay, let's start with high-priority reviews
19:02:33 <sipa> #topic review blocks
19:02:34 <kanzure> also, bitcoin-dev mailing list hosting provider is migrating away from the email protocol, so the underlying host is going to probably switch soon (more details forthcoming)
19:03:16 <jnewbery> hi
19:03:26 <sipa> we have 3 open review blockers: #13062 #12196 #13425
19:03:29 <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
19:03:33 <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
19:03:37 <gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
19:03:44 <achow101> the merged ones should be removed from the list
19:04:00 <sipa> good point, will od
19:04:48 <sipa> done
19:04:55 <sipa> any proposals for others to add?
19:05:14 <promag> I'll update #13100 in the next couple of days, but would be nice to have it on high priority
19:05:16 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
19:05:37 <promag> it's the missing piece in the dyn multi wallet story
19:05:49 <sipa> promag: ping me when ready, i'll add it then
19:06:01 <promag> will do ty
19:06:13 <sipa> #topic alert key
19:06:15 <sipa> kanzure: ^
19:06:39 <kanzure> alert key system deprecated, topic has absolutely no impact on bitcoind itself AFAIK
19:06:50 <achow101> besides vulnerable versions
19:06:50 <kanzure> i recognize the request to perhaps wait for v0.13 end-of-life, would like to hear more comments about that
19:06:55 <sipa> absent any other topic proposals, i'm sure we can talk about it
19:07:04 <kanzure> i believe those vulnerabilities might not be public but whatever, yes those
19:07:36 <achow101> 0.13 is the first version to have the alert system gone. the final alert stuff was added in 0.14.
19:07:55 <kanzure> for context: i'm thinking of releasing the private key, would be nice to get that out there and remove that liability
19:07:56 <achow101> so waiting for 0.14 to be the oldest version in any form of support is good
19:08:01 <gmaxwell> Though it was default off since what.. 0.10.something ?
19:08:06 <luke-jr> if 0.13 doesn't have alert system at all, why wait for it to be EOL?
19:08:07 <achow101> 0.12
19:08:26 <meshcollider> Yeah doesn't seem much point waiting for 13 EOL
19:08:38 <meshcollider> 0.12 is already gone
19:08:59 <gmaxwell> There are two levels, off by default, and gone completely. 0.12 has it off by default and 0.13 gone completely?
19:09:04 <achow101> yes
19:09:18 <kanzure> i'm particularly interested in hearing from others who have good reason not to reveal the key.. in the year+ since this was announced i don't think much has been raised.
19:09:21 <gmaxwell> and 0.12 is not supported at all, so all supported versions have it gone completely.
19:09:37 <kanzure> i sent out an email to the mailing list a few days ago and i have heard back from exactly one person regarding a request for a final alert message to some other altcoin
19:09:50 <kanzure> so i think this stuff is good and dead at this point
19:09:54 <achow101> yes
19:10:07 <achow101> also, if someone needs a final alert, they can pull it from the current source code
19:10:07 <gmaxwell> So that sounds pretty good for a release now, unless pre-0.12 nodes are still popular, and I don't believe they are.
19:10:24 <achow101> I would assume that someone who has changed the alert format would also change the alert key
19:10:30 <kanzure> anyway, if anyone would like to send me name suggestions for someone to go talk to in private, i'm open to that, although i don't expect to hear from anyone
19:10:56 <gmaxwell> unfortunately, final alerts don't have the protective properties we believed they had.
19:11:03 <luke-jr> there's ~3% of the network on 0.12
19:11:12 <achow101> luke-jr: what about earlier?
19:11:12 <kanzure> was non-protection disclosed somewhere?
19:11:27 <sipa> bitnodes says around 300 ish 0.12 and below nodes, out of 9945
19:11:40 <luke-jr> achow101: 0.61% "other" versions, which includes everything before 0.12
19:11:52 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
19:11:56 <achow101> ok.. and they all probably have the final alert anyways
19:12:00 <luke-jr> sipa: bitnodes only shows listening
19:12:09 <sipa> luke-jr: i'm aware; just offering an extra data point
19:12:10 <luke-jr> although that's the same 3%
19:12:35 <luke-jr> gmaxwell: what was missing re protective properties?
19:13:02 <kanzure> also how do folks feel about the unmentioned (spamming) vulnerabilities related to this?
19:14:01 <gmaxwell> luke-jr: back when we first started talking about publishing it I was under the mistaken belief that a final alert basically disabled the alert code ... e.g. no more alert message processing, only relaying of the final alert.
19:14:24 <gmaxwell> so that a final alert would effectively also limit the usefulness of any alert dos attacks
19:14:30 <gmaxwell> But that isn't the case.
19:14:34 <achow101> kanzure: I think all of the vulns should be disclosed at the same time as the key
19:14:47 <kanzure> this sounds like the same one
19:14:49 <luke-jr> gmaxwell: that was also my impression
19:15:01 <gmaxwell> I doubt we know all the vulnerabilities. I know of at least two but I stopped looking.
19:15:12 <achow101> gmaxwell: I believe I know of three
19:15:26 <gmaxwell> Also depends on how you count. :)
19:15:29 <achow101> that too
19:15:46 <sipa> i tend to count using the ring of integers
19:16:22 <gmaxwell> in any case, the alert code didn't stand up to careful review and is somewhat exposed to malicious alerts.
19:16:35 <gmaxwell> But then again any code still with it is also exposed in other ways.
19:16:49 <BlueMatt> there's also limited utility to releasing the alert key
19:16:55 <kanzure> sounds like some forkcoin projects might have to deal with this if they haven't already, not just rely on the fantasy of a final alert that shuts down the alert system
19:16:58 <BlueMatt> aside from "one less thing to worry about"
19:17:33 <gmaxwell> kanzure: well if anything still had it, it would have been easy enough to fix.
19:17:49 <gmaxwell> (by basically adding an "if I have had a final alert, drop all new alert messages" line.
19:17:50 <jnewbery> I think 'one less thing to worry about' is good enough reason (also 'one less thing to discuss for the rest of our lives')
19:17:50 <gmaxwell> )
19:18:01 <kanzure> i was surprised by the one person that did message- didn't think he would have had something with the alert system :-)
19:18:08 <kanzure> and if he could make that kind of mistake, i'd imagine many others are making worse mistakes
19:18:22 <gmaxwell> I was more concerned about it a year ago when in a short periord we had multiple people crop up and propose using that stupid key as some centeralized controlled whatever.
19:18:36 <meshcollider> And it has been a couple of years since the deprecation was announced, it's not like fair warning wasn't given in any case
19:18:39 <achow101> kanzure: if the altcoins have better control of their alert key, publishing the bitcoin one and the related vulns shouldn't be a problem
19:18:45 <kanzure> #action collect vulnerability knowledge from achow101
19:19:03 <kanzure> achow101: ah interesting point. i was only thinking about the projects that copied the public key actually.
19:19:23 <gmaxwell> I had thought there were ~none, but it turns out prior searches were somewhat ineffective.
19:19:25 <achow101> kanzure: AFAICT, there aren't any projects using the bitcoin one
19:19:32 <gmaxwell> The litecoin alertkey is copied all over heck and back.
19:19:38 <achow101> Google and github search for the key itself has turned up nothing
19:19:40 <gmaxwell> achow101: there was at least one we missed.
19:19:52 <kanzure> achow101: there is at least one actually, and someone contacted me about it i think :-)
19:20:11 <achow101> it could be that they removed the alert system but still have legacy nodes?
19:20:40 <kanzure> unfortunately this person was also misinformed about the effects of the final alert message... in fact, i should go fix that misunderstanding.
19:20:46 <gmaxwell> In any case, I think there has been plenty of warning from the prior discussion.
19:21:07 <gmaxwell> kanzure: also I think our prior discussion made it pretty clear that the final alert turned out to not be so final.
19:21:21 <BlueMatt> at some point if you're so incompetent that you leave the alert key around for a while you've probably broken things in 10 other ways, honestly
19:21:26 <gmaxwell> (or rather there were DOS vulnerabilties that persisted in spite of it)
19:21:41 <kanzure> BlueMatt: yeah but i also somewhat have a duty to not inadvertedly break other people's broken systems just because they are stupid broken systems
19:21:46 <BlueMatt> I dont think we need to worry about other random crap
19:21:53 <meshcollider> Agreed, I think just a full post with all info, vulns and key would be best now to resolve this
19:21:57 <gmaxwell> the alert system was kinda cool, except for the bugs... and unclear security model, lack of multisig, etc. :P
19:22:04 <BlueMatt> more like worry about our own crap and make sure to sufficiently disclose, which clearly happened
19:22:20 <luke-jr> DoS is not a big deal IMO
19:22:25 <kanzure> sure. okay. let's move on.
19:22:31 <luke-jr> maybe the denial of service will prompt the user to upgrade ;)
19:22:36 <kanzure> i do have one other topic about bitcoin-dev mailing list
19:22:37 <gmaxwell> luke-jr: yes, assuming thats the worst of it.
19:22:59 <sipa> ok, let's switch topics
19:23:10 <gmaxwell> (I don't have any reason to assume it's worse than dos other than the fact that there were a bunch of DOS vulns that were unknown until I checked before publishing the key)
19:23:13 <sipa> #topic bitcoin-dev mailinglist
19:23:23 <kanzure> linuxfoundation is migrating away from the email protocol and will no longer be hosting the bitcoin-dev mailing list
19:23:40 <kanzure> there is a migration plan but it's under investigating still
19:23:42 <BlueMatt> what are the other 200 mailing lists on lists.linuxfoundation.org doing?
19:23:42 <kanzure> details are still forthcoming sorry i don't have anything specific at this time
19:23:52 <kanzure> will post to mailing list when i have more details about actual plan
19:24:01 <BlueMatt> errr, oh, actually there arent many
19:24:03 <kanzure> i believe the current plan is "give lists.linuxfoundation.org to osuosl"
19:24:22 <achow101> what does "migrating away from the email protocol" mean? are they just not doing mailing lists anymore?
19:24:27 <luke-jr> achow101: right
19:24:32 <kanzure> achow101: linuxfoundation no longer believes in email apparently
19:24:42 <kanzure> i don't know, man.
19:24:45 <meshcollider> lol
19:24:48 <gmaxwell> Is that like not believing in santa clause?
19:24:59 <kanzure> it's similar but not in the abstract
19:25:03 <gmaxwell> claus*
19:25:22 <sipa> How can you believe in the universe, if you don't even know if email is real?
19:25:36 <kanzure> i'll post more details once i have some, i'd prefer to get an email out to the mailing list before the migration happens since this is weird and unusual
19:25:41 <luke-jr> I guess if you disbelieve in email, it ceases to be real for you?
19:25:54 <gmaxwell> in any case, I can't say that I was completely happy with LF regardless.
19:26:05 <kanzure> my primary concern is about linkrot
19:26:16 <kanzure> they seem open to including some rewrite rules on their http server to fix some of the linkrot problem
19:26:23 <sipa> ... for now
19:26:39 <luke-jr> kanzure: if they're letting OSUOSL use the domain, wouldn't OSUOSL just be able to maintain the links?
19:26:54 <kanzure> and also, if the mailing list was to move away from lists.linuxfoundation.org as the domain, and MX records, then potential email delivery problems for the current subscribers
19:27:19 <kanzure> luke-jr: sipa notes that the relationship there might change over time
19:27:19 <sipa> are there any other topics?
19:27:27 <achow101> I'm already experiencing mail delivery problems, so....
19:27:40 <luke-jr> kanzure: nothing we can do can prevent that AFAIK
19:27:40 <sipa> (we can let this discussion continue if nothing else, but perhaps there are more development related topics)
19:27:45 <kanzure> oh yeah, achow101 has reported mail delivery and receipt problems for lists.linuxfoundation.org that i haven't been able to investigate
19:30:04 <aj> was there configuration / bitcon-rw.conf / ...? stuff to discuss? i think some got deferred from previous meetings
19:30:11 <achow101> topic suggestion: coin selection
19:30:21 <achow101> (again)
19:30:54 <sipa> aj: i'm not up to date with that discussion
19:31:00 <sipa> #topic coin selection
19:31:22 <achow101> I did a bunch of simulations of the srd fallback stuff
19:31:22 <achow101> https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c
19:31:37 <luke-jr> aj: yes, last time it was deferred cuz someone wasn't here
19:31:58 <achow101> there are two problems that I see with this strategy: change can be incredibly small and the mean number of utxos in the wallet is quite highg
19:33:04 <achow101> the question is whether we can accept these tradeoffs or whether we need to find a better algorithm
19:33:50 <sipa> it sounds concerning to me
19:34:03 <achow101> I agree, especially the small change
19:34:21 <achow101> we may have to keep MIN_CHANGE, but I don't really like having a fixed minimum change
19:34:39 <gmaxwell> is this code discarding sub fee change?
19:34:49 <sipa> yes
19:35:05 <sipa> you mean turning dust change into fee? yes
19:36:02 <gmaxwell> OKAY
19:36:28 <gmaxwell> So let me check my understanding of our understanding.
19:36:56 <gmaxwell> SRD is producing poor solutions in cases where the wallet has lots of small inputs?  And also tends to produce small change itself?
19:37:10 <sipa> tends to produce
19:37:53 <achow101> however it does help BnB find more exact matches
19:38:06 <gmaxwell> Yes, but probably other strategies could do that.
19:38:12 <sipa> but clearly not enough to compensate (as the total number of UTXOs grows)
19:38:21 <gmaxwell> e.g. current algo but with a min_change that is randomized more.
19:38:21 <luke-jr> aj: (do you have time to discuss rwconf stuff after the meeting if we run out of time during?)
19:38:24 <jtimon> sorry I'm late, https://github.com/bitcoin/bitcoin/pull/13311 is kind of blocking to me for the block signed testnets thing (assuming there's still interest in that) </offtopic>
19:39:03 <gmaxwell> IIRC there is nothing fundimental about SRD that makes it good for making BNB work better, but rather it was the first alternative murch tried there.
19:39:26 <aj> luke-jr: (yes, it's the start of my day here)
19:39:34 <sipa> well and in murch's simulations, SRD performed reasoably well, and was extremely simple
19:39:44 <sipa> though i guess we may be seeing different results now
19:39:53 <gmaxwell> So for example, current solver plus add a couple extra inputs at random probably also makes BNB work better than current alone.
19:40:45 <sipa> i'm wondering if instead of SRD, we shouldn't use a BNB algorithm with a very large target range, larger than minimal change
19:41:11 <Murch> And then allow it to create change outputs?
19:41:16 <sipa> Murch: indeed
19:41:33 <sipa> Murch: basically run BNB in a mode where it assumes change will be created anyway
19:41:40 <sipa> and then minimize waste for that
19:41:56 <sipa> have you considered such a strategy?
19:42:23 <gmaxwell> stratigies that minimize change values are bad for building a collection of coins that help BNB.
19:42:26 <Murch> I have thought a bit about it, but figured that it is computationally intensive for no good reason
19:42:38 <sipa> gmaxwell: minimizing change != minimizing waste
19:42:48 <gmaxwell> sipa: what is 'waste'?
19:43:12 <jonasschnelli> hi
19:43:14 <Murch> Also, then you're just minimizing the input set since everything produces change and thus all with the same count of inputs have the same waste value
19:43:23 <Murch> at least at higher fees
19:43:29 <achow101> gmaxwell: line 36 of src/wallet/coinselection.cpp
19:43:37 <sipa> gmaxwell: in this case, it means minimziing fees
19:43:50 <Murch> Maybe one could just do smallest first selection at the lowest fee range to auto-consolidate?
19:43:58 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/coinselection.cpp#L36L40
19:44:19 <gmaxwell> Murch: smallest first is pathalogical for wallets with tons of tiny inputs, unfortunately.
19:44:19 <sipa> we probably shouldn't do algorithm design in this meeting, but ideas for things to try may be useful
19:44:53 <Murch> Alright, maybe oldest first on the ones that are smaller than the target. ;)
19:44:56 <gmaxwell> we can't have undefended pathological behavior, since we can't assume the usage will be supervised.
19:45:08 <Murch> but it would have some sort of limit on transaction size
19:45:40 <luke-jr> might be interesting to have coin selection pay attention to feerate estimates. use more inputs when feerates are low, for example. just a thought
19:45:42 <gmaxwell> We could still have that mode, it would just have to be guarded by something that cuts off the pathalogical behavior.
19:45:55 <Murch> gmaxwell: If smallest first is only used at < 4 sats/byte, why not auto-consolidate up to e.g. 250 unspents?
19:46:00 <achow101> luke-jr: preferably the algorithm would be self adjusting to the feerates
19:46:01 <sipa> luke-jr: it does
19:46:09 <sipa> BNB at least does
19:46:20 <Murch> ofc it would mean that a cpfp would be extremely expensive should it become necessary
19:46:42 <Murch> luke-jr: the new fee estimation is already fee sensitive
19:46:49 <luke-jr> i c
19:46:52 <sipa> Murch: you mean coin selections
19:46:59 <sipa> i would hope that fee estimation is fee sensitive :p
19:47:00 <Murch> äh, I do
19:47:42 <jonasschnelli> I have two topic proposal... but I guess I'm too late: a) Multiwallet session persistence b) Bech32X
19:48:31 <achow101> perhaps this coin selection discussion would be better done in person with whiteboards
19:48:34 <sipa> yeah
19:48:40 <sipa> #topic multiwallet session persistence
19:48:43 <Murch> I'm game
19:48:45 <jonasschnelli> Okay...
19:48:55 <luke-jr> ok, so I guess rwconf waits until after meeting :x
19:49:00 <gmaxwell> achow101: that leaves out people who can't attend.
19:49:07 <jonasschnelli> I guess it's not ideal that loaded wallets need to be re-loaded after a Bitcoin-Core restart...
19:49:19 <jonasschnelli> especially in pruning mode
19:49:20 <sipa> luke-jr, aj: i can make it a topic; it wasn't clear if you wanted it here
19:49:26 <gmaxwell> jonasschnelli: so put them in the conf file?
19:49:33 <luke-jr> sipa: almost out of time anyway
19:49:35 <sipa> jonasschnelli: that sounds like something to address with rwconf
19:49:37 <jonasschnelli> gmaxwell: that works for static enviromnents...
19:49:50 <gmaxwell> jonasschnelli: not with rwconf.
19:49:54 <luke-jr> gmaxwell: maybe not easy for GUI users (yet; rwconf to the rescue? :P)
19:50:09 <jonasschnelli> rwconf would be indeed a solution, yes.
19:50:24 <sipa> it seems like the exact same problem as the one rwconf is intended to solve
19:50:37 <luke-jr> unless you wanted multiple different sessions, maybe?
19:50:56 <luke-jr> but I'm not sure there's a use case for that
19:51:43 <gmaxwell> seems out of scope to me.
19:51:46 <jonasschnelli> Okay guess rw/config solves this... so /topic
19:51:59 <sipa> #topic bech32x
19:52:17 <jonasschnelli> Bech32X has currently the distance 27 BCH with correction to 7 chars (thanks to sipa)
19:52:20 <jonasschnelli> The idea is now..
19:52:32 <jonasschnelli> to have three "levels" or correction..
19:52:58 <sipa> i'll gladly create code for that
19:53:08 <jonasschnelli> I'd like to hear if this a) is "easy" possible (three generators) and b) if the use case makse sense (selective correction robusntess)?
19:53:08 <sipa> i don't have strong opinions about usage
19:53:21 <gmaxwell> I don't understand
19:53:22 <gmaxwell> 12:52:32 < jonasschnelli> to have three "levels" or correction..
19:53:29 <jonasschnelli> 7 chars is still not much more then 5% correction for 512bit key material
19:53:47 <luke-jr> maybe correction level should be somehow defined as a % of the whole?
19:53:53 <gmaxwell> Oh you want multiple codes so for long key data it uses a stronger code?
19:53:57 <jonasschnelli> gmaxwell: a flexible checksum, either 7 chars or 14chars or 28 chars of correction
19:54:07 <sipa> gmaxwell: or that the user can choose how much correction information they want
19:54:13 <jonasschnelli> gmaxwell: either the length or the HRP does hint what code to use
19:54:14 <sipa> (QR codes have this, for example)
19:54:19 <jonasschnelli> Yes.
19:54:21 <gmaxwell> It can't be 'flexible' without hurting performance, but we could just have more or less.
19:54:27 <gmaxwell> through multiple codes.
19:54:43 <sipa> yeah, i'm sure he just means have 3 codes to choose from
19:54:49 <jonasschnelli> yes
19:54:54 <gmaxwell> But I think it is not good to make it generally user selectable. The user _generally_ has no way to make a useful decision.
19:55:13 <jonasschnelli> gmaxwell: Yes. I also thought this...
19:55:16 <luke-jr> user in this case being the software I think
19:55:19 <gmaxwell> But making the format support multiple codes seems okay to me though it might lower the odds that powerful fancy decoders get written, because it'll be more work.
19:55:24 <jonasschnelli> On the other hand, maxing on 5% correction may also be not ideal
19:55:47 <sipa> gmaxwell: we can make sure they use the same field and extension, so that the majority of the recovery code can be shared
19:55:58 <gmaxwell> There are certian improved properties we can get if we know a code will only be used for shorter vs longer data.
19:56:13 <sipa> gmaxwell: not much as these levels of corrections (too large search space)
19:56:37 <gmaxwell> so if the goal really was just to have multiple codes to have a certian percentage of correction that could perhaps be used.
19:57:06 <gmaxwell> sipa: well we can still search for codes with improved performance over modest (e.g. 50 char) windows, giving better burst error handling.
19:57:57 <sipa> we can even make the generators multiples of each other, so that a valid code according to one is also valid according to the "weaker" versions
19:58:08 <gmaxwell> in any case, I assume sipa would come up with the codes.. fewer levels is better than more...
19:58:09 <sipa> (or with a different offset, guarantee that this exactly never happens)
19:59:00 <gmaxwell> sipa: if you're going to abandon beyond bch performance the difference codes could just be punctures of a single bigger one.
19:59:20 <sipa> gmaxwell: right, i believe that's actually saying the same thing
19:59:57 <sipa> gmaxwell: also, for distance 15 there is nothing we can grind, not even for short lengths
20:00:09 <sipa> #endmeeting