< Arvidt>
Is it on purpose, that the SHA256SUMs file in https://bitcoincore.org/bin/bitcoin-core-0.17.0/test.rc4/ is now named SHA256SUMS instead of SHA256SUMS.asc like it used to be named in the past? Because I have a download script and that looks for the file SHA256SUMS.asc to verfiy the download and the script does fail now because of missing signature file.
< wumpus>
without libc you cannot expect any binaries for linux to work, I doubt something like flatpak or appimage would help
< wumpus>
Arvidt: uhm, no, that's not on purpose, looks like I didn't upload the signed asc
< wumpus>
Arvidt: thanks for the reminder
< Arvidt>
wumpus: OK maybe there is missing a release algorithm documentation to be able to cleanly reproduce/make a release, to prevent something is forgotten/mistaken like in this case?
< wumpus>
Arvidt: should be fixed now
< Arvidt>
In the file there are signatures for bitcoin-0.10.4rc1 !
< wumpus>
right. now it has the correct ones.
< provoostenator>
cfields: will sign as soon as I remember what the "please run gbuild --upgrade" error was about again...
< Arvidt>
wumpus: Issue is fixed now, download could be verified as usual.
< promag>
jnewbery: do you think BitcoinTestFramework should be used/extended to support bitcoin-wallet-tool tests?
< jnewbery>
promag: I'd say it's probably better to keep them separate if possible. Take a look at the bitcoin-tx tests in test/util. Tests for bitcoin-wallet-tool should probably go in there.
< wumpus>
I agree
< wumpus>
although, in this case you might need bitcoind to create/populate the wallet in the first place
< wumpus>
so it integrates somewhat more closely with the existing tests that bitcoin-tx which is an independend utility
< wumpus>
and as soon as you need bitcoind and RPC, integrating it into the test framework makes much more sense
< wumpus>
otherwise you'll end up duplicating functionality
< wumpus>
promag isn't even here is he
< promag>
wumpus: jnewbery: sorry, catching up
< promag>
to test against running nodes I'm extending BitcoinTestFramework
< promag>
bbl
< wumpus>
* [new tag] v0.14.3 -> v0.14.3
< midnightmagic>
\o/
< jnewbery>
wumpus: promag: yes, that makes sense. If you need a bitcoind to create the wallet, then it makes sense to incorporate the tests into the functional test framework
< jnewbery>
(although I am a little concerned about the tendency for the functional test framework to keep on expanding forever)
< wumpus>
I'm more concerned with adding more utilities to bitcoin core than the test framework expanding to test them
< wumpus>
at least the tests should skip if built without the utility, I suppose
< MarcoFalke>
We can always try to refactor it later if it becomes an issue. Refactoring solves all issues I heard.
< wumpus>
heh
< wumpus>
that explains the large amount of refactoring...
< MarcoFalke>
meeting in 3?
< luke-jr>
no, 2
< sipa>
no, 1
< luke-jr>
I see you were just waiting for the minute to change for posting that!
< sipa>
actually, no, i just switched to this terminal when the clock was already ":59"
< luke-jr>
:p
< MarcoFalke>
0
< sdaftuar>
hi
< * luke-jr>
pokes wumpus
< jonasschnelli>
hi
< luke-jr>
don't make us off-by-one!
< MarcoFalke>
off-by-negative-one
< luke-jr>
:x
< MarcoFalke>
topic proposals:
< MarcoFalke>
short topic: Delete 0.10.* executables from bitcoincore.org
< MarcoFalke>
short topic: Add GitHub pull request template
< sipa>
wumpus: ^
< MarcoFalke>
But I think first topic is 0.17.0?
< achow101>
hi
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 20 19:02:24 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< MarcoFalke>
I think anyone can be the host that knows the commands for the meeting bot?
< MarcoFalke>
ah
< wumpus>
#topic 0.17.0
< meshcollider>
Hi
< MarcoFalke>
I think two of the issues in the milestone are just release-notes related
< wumpus>
anything specific you want to discuss about it?
< wumpus>
correct, the only real still-open issue is achow101 's PR
< gmaxwell>
I think we should probably just get 0.17 out soon, and even slip the PSBT fix to 0.17.1 to be done soon after.
< wumpus>
yes,agree
< gmaxwell>
it's unfortunately that PSBT is hobbled in 0.17, but considering bugfix upgrades we'll be better off not delaying due to a new feature that is kinda expiremental in any case... and probably has other bugs.
< promag>
hi
< sipa>
i'm not sure it's a very common workflow that triggers (importing a p2sh-segwit address without known pubkey, and then trying to sign on an offline system)
< sipa>
it just happened to be the first thing i tried
< gmaxwell>
I think it's like _the_ obvious workflow... if you happen to be using embedded segwit. :P
< wumpus>
so, all in all it depends on why people want to upgrade to 0.17.0
< gmaxwell>
Can we provide workaround instructions that have people import the redeemscript?
< luke-jr>
we just released 0.16.3; is there a reason to rush 0.17 now?
< wumpus>
if a properly working PSBT is very important, we should delay the release for it
< luke-jr>
people who really want it can always use a rc
< sipa>
gmaxwell: or another roundtrip; i'll write up a workaround
< gmaxwell>
luke-jr: It's 0.1 higher.
< wumpus>
if PSBT is seen as an curious experimental feature, then not so much
< gmaxwell>
Since PSBT is new I don't think it's important if it works at all.
< wumpus>
I don't have a clear perspective on that
< sipa>
gmaxwell: it's 0.7 higher :)
< sdaftuar>
gmaxwell: i agree with that
< morcos>
i also would rather document the shortcomings of PSBT and proceed with the release.
< achow101>
I think it is fine to release as is and do the fix for .1 later
< wumpus>
don't really want complaints like 'so you released 0.17.0 but it's useless as the PSBT we've been waiting for is useless'
< gmaxwell>
I think cosmically PSBT is important, but it's fine if we get it after another month delay or what not.. and it's not broken completely, there is a workaround, and that issue only applies to p2sh-segwit.
< achow101>
this is fairly edge case imo
< MarcoFalke>
so action: Merge release notes?
< wumpus>
but that's not the gut feeling I have about it, and I'm okay with tagging 0.17.0 final next week when no new problems come up
< gmaxwell>
It's also not the only shortcoming of PSBT as is... e.g. the txou-scan + spend workflow is kind of a mess for non-segwit outputs as I was lamenting in here a few weeks ago. (not as easily fixed)
< promag>
make it experimental like scantxoutset?
< wumpus>
right, PSBT is bound to have more problems that will come up when other users start using it
< gmaxwell>
I don't think it needs to be marked more expiremental.
< wumpus>
there will likely need to be a 0.17.1 for other reasons
< sipa>
i don't think we should be waving 'experimental' as a label as a way to avoid responsibility in creating decent interfaces
< wumpus>
we could disable it completely.
< sipa>
it's there to indicate that changes are possible in the future
< gmaxwell>
scantxoutset is marked expiremental in particular because the interface isn't stable.
< wumpus>
just disable the methods, make PSBT entirely miss 0.17.0
< sipa>
i think it's fine to release 0.17.0 as-is now
< wumpus>
but only if you think releasing as-is is "avoiding responsibility"
< gmaxwell>
wumpus: I don't see how doing that, in this case, would make anyone better off. I would agree if it was like "PSBT could surprise crash, or eat your coins" or whatnot.
< wumpus>
gmaxwell: it was because of sipa's working
< wumpus>
wording*
< luke-jr>
[19:10:32] <wumpus> just disable the methods, make PSBT entirely miss 0.17.0 <-- IMO better to just delay 0.17 a bit
< gmaxwell>
But in this case, it's just "this very specific sequence of actions in this specific use case just doesn't work"
< sipa>
wumpus: no, i'm just a bit annoyed with the "we could always mark things experimental!" response to things that don't work - not specific to this issue
< achow101>
I think 0.17 is fine to release as is
< sipa>
this is minor enough
< wumpus>
sipa: well it's quite common for software to have 'known issues' with releases
< morcos>
we have a precedent of release notes with a Known Bugs section
< promag>
luke-jr: remove features in RC?
< sipa>
wumpus: right, that's far more honest :)
< morcos>
damn i type too slow
< gmaxwell>
yea, for this it's fine.
< wumpus>
at some point ,a release needs to be cut, in spite of everything
< luke-jr>
promag: not necessarily in general, but in this specific case
< gmaxwell>
Sometimes a known issue is severe enough you need to disable the functionality, but not here. And expiremental isn't the right concept: it's not that PSBT is going to change its interface in an incompatible way, it just has some bugs.
< luke-jr>
promag: no reason to rush 0.17, and fixing it shouldn't delay long
< wumpus>
but I agree removing features should be left for when something is dangerously broken
< wumpus>
but the fact that this discussion keeps coming back indicates to me that most people just want 0.17.0 out, for other reasons than PSBT
< promag>
we want people to try it+, but in a responsible way, so experimental sounds fine to me
< gmaxwell>
For use we're using expiremental to get functionality out when the remaining issue is some debate (or incompleteness) in the interface, and where we figure people are better off having it, even if the interface isn't stable yet.
< sipa>
psbt is not experimental; its workflows or interfaces aren't changing, nor is there a security issue
< gmaxwell>
because we found that we were delaying good features because "interfaces-are-forever".
< wumpus>
right
< sipa>
there's just a bug that prevents it from working in an edge case that can be worked around, which will be fixed soon
< gmaxwell>
and 0.17 has a lot of fantastic improvements that people should get their hands on.
< earlz>
What's the best way to privately report a security problem in bitcoin core?
< promag>
sipa: experimental can also mean incomplete, or not entirely tested or finished?
< sipa>
earlz: security@bitcoincore.org
< wumpus>
earlz: gpg-signed mail to maintainers
< luke-jr>
gpg encrypted, not signed.
< sipa>
i care more about gpg-encrypted than signed :)
< MarcoFalke>
bitcoincore.org is mostly concerned about distributing working, tested and non-vulnerable software versions of Bitcoin Core. The site should not serve as an archive of binary blobs. Note that releases before 0.10.0 are already not offered as download on https://bitcoincore.org/bin/.
< wumpus>
yes, would rather move to an "old_dont_use" directory
< gmaxwell>
wumpus: it's really useful to have old executable archived somewhere. It's often hard to _build_ old versions because of @#$@ dependency changes.
< wumpus>
gmaxwell: I agree
< wumpus>
deleting isn't necssary, I think
< jonasschnelli>
Agree
< MarcoFalke>
Then, we should also put up the 0.8 and earlier versions?
< wumpus>
there was an rc for 0.10.4 at some point AFAIK that's why the directory exists
< MarcoFalke>
Ah
< gmaxwell>
in any case action is to move but don't delete old versions? and at least anything that isn't current with the current consensus rules?
< sdaftuar>
0.13 is past end-of-life, so i think it should be considered "old_dont_use" as well
< wumpus>
gmaxwell: yes I think so
< wumpus>
MarcoFalke: rcs for old releases used to be deleted because of disk space constraints on bitcoin.org, don't know if bitcoincore.org has the same problem
< gmaxwell>
sdaftuar: also old don't use due to not having the crash fix.
< wumpus>
isn't 0.14 the first release with the crash bug?
< MarcoFalke>
There are sometimes pull requests that do simple stylistic refactoring without obvious advantages to either users or developers. The GitHub pull request template would remind contributors that they need to provide clear rationale for these refactoring changes
< wumpus>
yes please
< jnewbery>
ACK
< sdaftuar>
+1
< jamesob>
+1. thoughts on test coverage requirements?
< cfields>
and a benchmark if it's intended to be an optimization
< MarcoFalke>
At least we have some monitoring to detect obvious slowdowns after merge
< gmaxwell>
See for example arvid's removal of INLINE that sipa commented on-- which actually seems to be okay, but its the sort of thing that could result in massive performance regressions.
< MarcoFalke>
Though, would be good to get the signal before merge
< wumpus>
gmaxwell: yes...
< gmaxwell>
MarcoFalke: yes, but it looks like it wasn't running very frequently which also makes it hard to tell which commit(s) did it.
< gmaxwell>
so perhaps my concern is best fixed by just improving the monitoring.
< MarcoFalke>
It runs about once a day, but we had some downtime last month
< wumpus>
that's another cleanup I really don't care for, for what it's worth
< jamesob>
gmaxwell: bitcoinperf shouldn't be down that long again
< gmaxwell>
OKAY
< gmaxwell>
Would it be possible to get it to run on each PR merge even if it falls behind?
< MarcoFalke>
The basic stuff for sure
< jamesob>
that's a lotta compute, but it's something I'm thinking about - and will have time to work on after the next month or so
< MarcoFalke>
IBD is the hardest
< wumpus>
could at least check whether cpp/h files were changed !
< gmaxwell>
I think it's silly for us to be bound on compute.
< wumpus>
it seems completely unnecessary to run it after a documentation change
< sdaftuar>
gmaxwell: agreed
< gmaxwell>
indeed, skipping pointless changes is good... but ultimately if we need a rack of computers to keep up with it, we should be able to get that.
< wumpus>
no one is stopping anyone from doing that, no :)
< sipa>
consistent performance numbers do need identical hardware etc
< wumpus>
could even run it on PRs
< sipa>
if you want to parallellize
< wumpus>
yes
< gmaxwell>
In absence of someone doing it we probably shouldn't just keep a commit flux that we can't adequately test though, and checking for perf regressions is part of it.
< wumpus>
it's kind of more expensive than what travis does, VMs would be useless for this
< gmaxwell>
indeed.
< wumpus>
in any case, I'm all for discouraging useless refactoring changes
< wumpus>
it sometimes feels like I'm the only person pushing back against them
< jonasschnelli>
no.. i'm with you
< wumpus>
any other topics?
< wumpus>
if not, I'm going to close the meeting and go to bed, need to get up very early tomorrow for my flight
< cfields>
I'm back full-time, still catching up. Please ping me if you have anything that was waiting for me or that I should get to quickly.
< sipa>
wumpus: safe travels
< wumpus>
cfields: welcome back !
< jonasschnelli>
cfields: great to hear!
< wumpus>
sipa: thank you
< promag>
cheers
< MarcoFalke>
safe travels!
< luke-jr>
cfields: I think I have at least one PR wumpus wanted you to look at, but no rush
< MarcoFalke>
proposed action: end meeting
< promag>
regarding practicalswift (are you here?), I think he should build something like bitcoinacks.com
< sipa>
ack
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 20 19:39:35 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< promag>
jnewbery: should I open a PR to discuss the wallet tool test?
< provoostenator>
Argh, timezones, sorry I missed the party/meeting.
< jnewbery>
promag: I think you could just oen a PR for a test for bitcoin-wallet-tool, including the commit from 13926. I expect any test would be merged as part of the original PR, but discussion of the tests can be in your new PR.
< promag>
yap
< luke-jr>
(I wish I could suggest new tools just get a new repo of their own, but I think in this case it's not practical :x )
< wumpus>
indeed, that's not practical in this case, the whole point in this case is to share the low-level code with the wallet
< wumpus>
and it makes sense to ship it, every database worth its salt also comes with at least one recovery tool
< luke-jr>
I wonder if the gitian sigs still match
< jcorgan>
provoostenator: if you set the timezone for the meeting to Reykjavik it will always be correct. I think that's the only country that uses GMT all year.
< sipa>
(nit: Reykjavik is not a country)
< jcorgan>
sure, sure
< provoostenator>
jcorgan: my calender worked fine, I just ignored it
< luke-jr>
some calendar won't let you just set UTC?
< jcorgan>
heh
< jcorgan>
i don't think google does
< sipa>
luke-jr: google calendar
< provoostenator>
Can we get signed binaries for 0.15.2?
< clarkmoody>
exit
< treyzania>
nice
< michagogo>
Um, I'm looking at a `git diff v0.14.2..v0.14.3`
< michagogo>
This version seems to introduce a whole bunch of typos o_O