< bitcoin-git>
[bitcoin] fanquake reopened pull request #13503: Document FreeBSD quirk. Fix FreeBSD build: Cast to int to allow std::min to work under FreeBSD. (master...document-freebsd-quirk) https://github.com/bitcoin/bitcoin/pull/13503
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13512: [qa] mininode: Expose connection state through is_connected (master...Mf1806-qaMininodeState) https://github.com/bitcoin/bitcoin/pull/13512
< skeees>
pierre_rochard: looks like bitcoinacks might not update when labels get removed from a pr
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #13515: travis: Enable Qt build for Windows and 32-bit Linux (master...travis_qt) https://github.com/bitcoin/bitcoin/pull/13515
< wumpus>
I won't be able to attend tonight's meeting, can someone else chair this time please?
< jonasschnelli>
wumpus: I'm also not sure if I make it on time... so happy if sipa, MarcoFalke or someone else takes the chair
< Guest37145>
bitcoin to rise $8230 2.35am EST tomorrow
< Guest37145>
dgdsgd
< Guest37145>
sgd
< Guest37145>
sg
< Guest37145>
dsg
< Guest37145>
d
< Guest37145>
g
< Guest37145>
dsg
< Guest37145>
dg
< Guest37145>
dsg
< Guest37145>
d
< Guest37145>
g
< Guest37145>
dg
< Guest37145>
d
< Guest37145>
gd
< Guest37145>
g
< Guest37145>
dsg
< Guest37145>
gds
< pierre_rochard>
skeees: ouch, I'll fix asap
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13517: qa: Remove need to handle the network thread in tests (master...Mf1806-qaAsyncIo) https://github.com/bitcoin/bitcoin/pull/13517
< sipa>
okay, let's start with high-priority reviews
< sipa>
#topic review blocks
< 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)
< jnewbery>
hi
< sipa>
we have 3 open review blockers: #13062 #12196 #13425
< 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
< achow101>
the merged ones should be removed from the list
< sipa>
good point, will od
< sipa>
done
< sipa>
any proposals for others to add?
< promag>
I'll update #13100 in the next couple of days, but would be nice to have it on high priority
< promag>
it's the missing piece in the dyn multi wallet story
< sipa>
promag: ping me when ready, i'll add it then
< promag>
will do ty
< sipa>
#topic alert key
< sipa>
kanzure: ^
< kanzure>
alert key system deprecated, topic has absolutely no impact on bitcoind itself AFAIK
< achow101>
besides vulnerable versions
< kanzure>
i recognize the request to perhaps wait for v0.13 end-of-life, would like to hear more comments about that
< sipa>
absent any other topic proposals, i'm sure we can talk about it
< kanzure>
i believe those vulnerabilities might not be public but whatever, yes those
< achow101>
0.13 is the first version to have the alert system gone. the final alert stuff was added in 0.14.
< kanzure>
for context: i'm thinking of releasing the private key, would be nice to get that out there and remove that liability
< achow101>
so waiting for 0.14 to be the oldest version in any form of support is good
< gmaxwell>
Though it was default off since what.. 0.10.something ?
< luke-jr>
if 0.13 doesn't have alert system at all, why wait for it to be EOL?
< achow101>
0.12
< meshcollider>
Yeah doesn't seem much point waiting for 13 EOL
< meshcollider>
0.12 is already gone
< gmaxwell>
There are two levels, off by default, and gone completely. 0.12 has it off by default and 0.13 gone completely?
< achow101>
yes
< 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.
< gmaxwell>
and 0.12 is not supported at all, so all supported versions have it gone completely.
< 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
< kanzure>
so i think this stuff is good and dead at this point
< achow101>
yes
< achow101>
also, if someone needs a final alert, they can pull it from the current source code
< 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.
< achow101>
I would assume that someone who has changed the alert format would also change the alert key
< 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
< gmaxwell>
unfortunately, final alerts don't have the protective properties we believed they had.
< luke-jr>
there's ~3% of the network on 0.12
< achow101>
luke-jr: what about earlier?
< kanzure>
was non-protection disclosed somewhere?
< sipa>
bitnodes says around 300 ish 0.12 and below nodes, out of 9945
< luke-jr>
achow101: 0.61% "other" versions, which includes everything before 0.12
< achow101>
ok.. and they all probably have the final alert anyways
< luke-jr>
sipa: bitnodes only shows listening
< luke-jr>
although that's the same 3%
< sipa>
luke-jr: i'm aware; just offering an extra data point
< luke-jr>
gmaxwell: what was missing re protective properties?
< kanzure>
also how do folks feel about the unmentioned (spamming) vulnerabilities related to this?
< 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.
< gmaxwell>
so that a final alert would effectively also limit the usefulness of any alert dos attacks
< gmaxwell>
But that isn't the case.
< achow101>
kanzure: I think all of the vulns should be disclosed at the same time as the key
< kanzure>
this sounds like the same one
< luke-jr>
gmaxwell: that was also my impression
< gmaxwell>
I doubt we know all the vulnerabilities. I know of at least two but I stopped looking.
< achow101>
gmaxwell: I believe I know of three
< gmaxwell>
Also depends on how you count. :)
< achow101>
that too
< sipa>
i tend to count using the ring of integers
< gmaxwell>
in any case, the alert code didn't stand up to careful review and is somewhat exposed to malicious alerts.
< gmaxwell>
But then again any code still with it is also exposed in other ways.
< BlueMatt>
there's also limited utility to releasing the alert key
< 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
< BlueMatt>
aside from "one less thing to worry about"
< gmaxwell>
kanzure: well if anything still had it, it would have been easy enough to fix.
< gmaxwell>
(by basically adding an "if I have had a final alert, drop all new alert messages" line.
< 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')
< gmaxwell>
)
< kanzure>
i was surprised by the one person that did message- didn't think he would have had something with the alert system :-)
< kanzure>
and if he could make that kind of mistake, i'd imagine many others are making worse mistakes
< 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.
< 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
< 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
< kanzure>
#action collect vulnerability knowledge from achow101
< kanzure>
achow101: ah interesting point. i was only thinking about the projects that copied the public key actually.
< gmaxwell>
I had thought there were ~none, but it turns out prior searches were somewhat ineffective.
< achow101>
kanzure: AFAICT, there aren't any projects using the bitcoin one
< gmaxwell>
The litecoin alertkey is copied all over heck and back.
< achow101>
Google and github search for the key itself has turned up nothing
< gmaxwell>
achow101: there was at least one we missed.
< kanzure>
achow101: there is at least one actually, and someone contacted me about it i think :-)
< achow101>
it could be that they removed the alert system but still have legacy nodes?
< kanzure>
unfortunately this person was also misinformed about the effects of the final alert message... in fact, i should go fix that misunderstanding.
< gmaxwell>
In any case, I think there has been plenty of warning from the prior discussion.
< gmaxwell>
kanzure: also I think our prior discussion made it pretty clear that the final alert turned out to not be so final.
< 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
< gmaxwell>
(or rather there were DOS vulnerabilties that persisted in spite of it)
< 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
< BlueMatt>
I dont think we need to worry about other random crap
< meshcollider>
Agreed, I think just a full post with all info, vulns and key would be best now to resolve this
< gmaxwell>
the alert system was kinda cool, except for the bugs... and unclear security model, lack of multisig, etc. :P
< BlueMatt>
more like worry about our own crap and make sure to sufficiently disclose, which clearly happened
< luke-jr>
DoS is not a big deal IMO
< kanzure>
sure. okay. let's move on.
< luke-jr>
maybe the denial of service will prompt the user to upgrade ;)
< kanzure>
i do have one other topic about bitcoin-dev mailing list
< gmaxwell>
luke-jr: yes, assuming thats the worst of it.
< sipa>
ok, let's switch topics
< 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)
< sipa>
#topic bitcoin-dev mailinglist
< kanzure>
linuxfoundation is migrating away from the email protocol and will no longer be hosting the bitcoin-dev mailing list
< kanzure>
there is a migration plan but it's under investigating still
< kanzure>
details are still forthcoming sorry i don't have anything specific at this time
< BlueMatt>
what are the other 200 mailing lists on lists.linuxfoundation.org doing?
< kanzure>
will post to mailing list when i have more details about actual plan
< BlueMatt>
errr, oh, actually there arent many
< kanzure>
i believe the current plan is "give lists.linuxfoundation.org to osuosl"
< achow101>
what does "migrating away from the email protocol" mean? are they just not doing mailing lists anymore?
< luke-jr>
achow101: right
< kanzure>
achow101: linuxfoundation no longer believes in email apparently
< kanzure>
i don't know, man.
< meshcollider>
lol
< gmaxwell>
Is that like not believing in santa clause?
< kanzure>
it's similar but not in the abstract
< gmaxwell>
claus*
< sipa>
How can you believe in the universe, if you don't even know if email is real?
< 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
< luke-jr>
I guess if you disbelieve in email, it ceases to be real for you?
< gmaxwell>
in any case, I can't say that I was completely happy with LF regardless.
< kanzure>
my primary concern is about linkrot
< kanzure>
they seem open to including some rewrite rules on their http server to fix some of the linkrot problem
< sipa>
... for now
< luke-jr>
kanzure: if they're letting OSUOSL use the domain, wouldn't OSUOSL just be able to maintain the links?
< 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
< kanzure>
luke-jr: sipa notes that the relationship there might change over time
< sipa>
are there any other topics?
< achow101>
I'm already experiencing mail delivery problems, so....
< luke-jr>
kanzure: nothing we can do can prevent that AFAIK
< sipa>
(we can let this discussion continue if nothing else, but perhaps there are more development related topics)
< kanzure>
oh yeah, achow101 has reported mail delivery and receipt problems for lists.linuxfoundation.org that i haven't been able to investigate
< aj>
was there configuration / bitcon-rw.conf / ...? stuff to discuss? i think some got deferred from previous meetings
< achow101>
topic suggestion: coin selection
< achow101>
(again)
< sipa>
aj: i'm not up to date with that discussion
< sipa>
#topic coin selection
< achow101>
I did a bunch of simulations of the srd fallback stuff
< luke-jr>
aj: yes, last time it was deferred cuz someone wasn't here
< 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
< achow101>
the question is whether we can accept these tradeoffs or whether we need to find a better algorithm
< sipa>
it sounds concerning to me
< achow101>
I agree, especially the small change
< achow101>
we may have to keep MIN_CHANGE, but I don't really like having a fixed minimum change
< gmaxwell>
is this code discarding sub fee change?
< sipa>
yes
< sipa>
you mean turning dust change into fee? yes
< gmaxwell>
OKAY
< gmaxwell>
So let me check my understanding of our understanding.
< gmaxwell>
SRD is producing poor solutions in cases where the wallet has lots of small inputs? And also tends to produce small change itself?
< sipa>
tends to produce
< achow101>
however it does help BnB find more exact matches
< gmaxwell>
Yes, but probably other strategies could do that.
< sipa>
but clearly not enough to compensate (as the total number of UTXOs grows)
< luke-jr>
aj: (do you have time to discuss rwconf stuff after the meeting if we run out of time during?)
< gmaxwell>
e.g. current algo but with a min_change that is randomized more.
< 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>
< 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.
< aj>
luke-jr: (yes, it's the start of my day here)
< sipa>
well and in murch's simulations, SRD performed reasoably well, and was extremely simple
< sipa>
though i guess we may be seeing different results now
< gmaxwell>
So for example, current solver plus add a couple extra inputs at random probably also makes BNB work better than current alone.
< 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
< Murch>
And then allow it to create change outputs?
< sipa>
Murch: indeed
< sipa>
Murch: basically run BNB in a mode where it assumes change will be created anyway
< sipa>
and then minimize waste for that
< sipa>
have you considered such a strategy?
< gmaxwell>
stratigies that minimize change values are bad for building a collection of coins that help BNB.
< Murch>
I have thought a bit about it, but figured that it is computationally intensive for no good reason
< 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
< Murch>
at least at higher fees
< achow101>
gmaxwell: line 36 of src/wallet/coinselection.cpp
< sipa>
gmaxwell: in this case, it means minimziing fees
< Murch>
Maybe one could just do smallest first selection at the lowest fee range to auto-consolidate?
< gmaxwell>
Murch: smallest first is pathalogical for wallets with tons of tiny inputs, unfortunately.
< sipa>
we probably shouldn't do algorithm design in this meeting, but ideas for things to try may be useful
< Murch>
Alright, maybe oldest first on the ones that are smaller than the target. ;)
< gmaxwell>
we can't have undefended pathological behavior, since we can't assume the usage will be supervised.
< Murch>
but it would have some sort of limit on transaction size
< 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
< gmaxwell>
We could still have that mode, it would just have to be guarded by something that cuts off the pathalogical behavior.
< Murch>
gmaxwell: If smallest first is only used at < 4 sats/byte, why not auto-consolidate up to e.g. 250 unspents?
< achow101>
luke-jr: preferably the algorithm would be self adjusting to the feerates
< sipa>
luke-jr: it does
< sipa>
BNB at least does
< Murch>
ofc it would mean that a cpfp would be extremely expensive should it become necessary
< Murch>
luke-jr: the new fee estimation is already fee sensitive
< luke-jr>
i c
< sipa>
Murch: you mean coin selections
< sipa>
i would hope that fee estimation is fee sensitive :p
< Murch>
äh, I do
< jonasschnelli>
I have two topic proposal... but I guess I'm too late: a) Multiwallet session persistence b) Bech32X
< achow101>
perhaps this coin selection discussion would be better done in person with whiteboards
< sipa>
yeah
< sipa>
#topic multiwallet session persistence
< Murch>
I'm game
< jonasschnelli>
Okay...
< luke-jr>
ok, so I guess rwconf waits until after meeting :x
< gmaxwell>
achow101: that leaves out people who can't attend.
< jonasschnelli>
I guess it's not ideal that loaded wallets need to be re-loaded after a Bitcoin-Core restart...
< jonasschnelli>
especially in pruning mode
< sipa>
luke-jr, aj: i can make it a topic; it wasn't clear if you wanted it here
< gmaxwell>
jonasschnelli: so put them in the conf file?
< luke-jr>
sipa: almost out of time anyway
< sipa>
jonasschnelli: that sounds like something to address with rwconf
< jonasschnelli>
gmaxwell: that works for static enviromnents...
< gmaxwell>
jonasschnelli: not with rwconf.
< luke-jr>
gmaxwell: maybe not easy for GUI users (yet; rwconf to the rescue? :P)
< jonasschnelli>
rwconf would be indeed a solution, yes.
< sipa>
it seems like the exact same problem as the one rwconf is intended to solve
< luke-jr>
unless you wanted multiple different sessions, maybe?
< luke-jr>
but I'm not sure there's a use case for that
< gmaxwell>
seems out of scope to me.
< jonasschnelli>
Okay guess rw/config solves this... so /topic
< sipa>
#topic bech32x
< jonasschnelli>
Bech32X has currently the distance 27 BCH with correction to 7 chars (thanks to sipa)
< jonasschnelli>
The idea is now..
< jonasschnelli>
to have three "levels" or correction..
< sipa>
i'll gladly create code for that
< 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)?
< sipa>
i don't have strong opinions about usage
< gmaxwell>
I don't understand
< gmaxwell>
12:52:32 < jonasschnelli> to have three "levels" or correction..
< jonasschnelli>
7 chars is still not much more then 5% correction for 512bit key material
< luke-jr>
maybe correction level should be somehow defined as a % of the whole?
< gmaxwell>
Oh you want multiple codes so for long key data it uses a stronger code?
< jonasschnelli>
gmaxwell: a flexible checksum, either 7 chars or 14chars or 28 chars of correction
< sipa>
gmaxwell: or that the user can choose how much correction information they want
< jonasschnelli>
gmaxwell: either the length or the HRP does hint what code to use
< sipa>
(QR codes have this, for example)
< jonasschnelli>
Yes.
< gmaxwell>
It can't be 'flexible' without hurting performance, but we could just have more or less.
< gmaxwell>
through multiple codes.
< sipa>
yeah, i'm sure he just means have 3 codes to choose from
< jonasschnelli>
yes
< 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.
< jonasschnelli>
gmaxwell: Yes. I also thought this...
< luke-jr>
user in this case being the software I think
< 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.
< jonasschnelli>
On the other hand, maxing on 5% correction may also be not ideal
< sipa>
gmaxwell: we can make sure they use the same field and extension, so that the majority of the recovery code can be shared
< gmaxwell>
There are certian improved properties we can get if we know a code will only be used for shorter vs longer data.
< sipa>
gmaxwell: not much as these levels of corrections (too large search space)
< gmaxwell>
so if the goal really was just to have multiple codes to have a certian percentage of correction that could perhaps be used.
< gmaxwell>
sipa: well we can still search for codes with improved performance over modest (e.g. 50 char) windows, giving better burst error handling.
< 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
< gmaxwell>
in any case, I assume sipa would come up with the codes.. fewer levels is better than more...
< sipa>
(or with a different offset, guarantee that this exactly never happens)
< gmaxwell>
sipa: if you're going to abandon beyond bch performance the difference codes could just be punctures of a single bigger one.
< sipa>
gmaxwell: right, i believe that's actually saying the same thing
< sipa>
gmaxwell: also, for distance 15 there is nothing we can grind, not even for short lengths
< sipa>
#endmeeting
< lightningbot>
Meeting ended Thu Jun 21 20:00:09 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< aj>
luke-jr: yeah. the separate maps for cmdline and config were to preserve the flipped ordering behaviour
< luke-jr>
aj: do you have any objections to reverting it back to a single-value map + multi-value map?
< luke-jr>
(thereby resolving the ordering stuff at startup, rathre than runtime)
< sipa>
i think AddArg should get a flag indicating whether the option is single-value or multi-value, so that repeated arguments can be dealt with at parsing time
< * sipa>
afk
< luke-jr>
sipa: IMO that makes sense, but best as a separate PR
< aj>
luke-jr: i don't think that quite works with prioritising the network stuff; ie atm it's "cmdline, [regtest], plainconfig"; but if you populate a single map with override first, then see a plain config option, then see regtest.foo=bah, you can't decide whether to drop the old entry or preserve it
< luke-jr>
hmm
< aj>
luke-jr: long term i like (an approach like) meshcollider's arg rework stuff