< achow101> sipa: last time I read through the base 64 stuff, I thought it dropped the padding before decoding
< achow101> I could be remembering incorrectly
< fanquake> Currently 7 sigs each for macOS and win signed sigs
< MarcoFalke> PSA: The hacktoberfest is going on again this year, so if anyone has programming tasks that could be solved by non-core devs, please file an issue and ask for the hacktoberfest issue label
< MarcoFalke> There will probably be a rush of whitespace fixes in the coming weeks and it would be nice if we could direct these contributors to do something useful instead.
< instagibbs> thoughts on what the wallet should do if it doesn't know the size of the change output future spending size? Turn off bnb for coin selection?
< sipa> instagibbs: or exclude from automatic coin selection?
< instagibbs> fundrawtransaction, or siblings, where you can specify output address, is the situation, to be clear
< instagibbs> output change address*
< sipa> oh, right
< instagibbs> if you do this to say a multisig you wallet doesn't own all the keys to, you assert
< instagibbs> it underflows, then nBytes is too big :)
< wumpus> phantomcircuit: stuck at 'done loading' tends to mean that it's validating a backlog blocks in the background, check debug.log
< wumpus> phantomcircuit: there's some interplay with cs_main locking that causes the GUI to be stuck at that point
< wumpus> I think it was fixed at some point, but might have come back... ideally, it would not show 'Done loading' before it gets its initial information from the core
< wumpus> (would be easier to do if the GUI didn't do potentially blocking calls to the core in the main loop)
< wumpus> fanquake: okay, I'll try to upload the binaries and do the rest of the release process today
< harding> wumpus: https://github.com/bitcoin-core/bitcoincore.org/pull/613 is ready for merge when you want to make the announcement. (I can merge too, if you want.)
< wumpus> harding: thank you !!!
< warren> FYI https://status.linuxfoundation.org/incidents/dfgswmqj3wyx The mailing list server suffered data corruption, restored from backups and brought back online yesterday. Could somebody please check the recent archive history for missing posts? I don't know how old the backups were.
< e4xit> harding: exerpt: "We're pleased the release of Bitcoin Core 0.17" -- to announce?
< harding> e4xit: indeed, thanks. Will push a fix momentarily.
< e4xit> :)
< fanquake> wumpus \o/
< wumpus> harding: e4xit: whoops
< wumpus> well time for one of those typo PR I guess…
< harding> Fixed now on the live site. I need to add previewing excerpts to my proofreading checklist; I forget because they're aren't shown on the actual page I'm editing (not that looking at them guarantees I'll notice the typos).
< wumpus> well don't blame yourself, we should have started reviewing it sooner
< wumpus> we also didn't get the magnet link
< wumpus> I'll file a PR
< harding> wumpus: sorry, and thanks. I'll merge that now.
< wumpus> my own fault for merging it too soon
< hebasto> wumpus: please remove 'temporary file' note from https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md
< harding> wumpus: definitely shared fault on that one. I should've copy/pasted my usual release checklist that mentions these things.
< wumpus> hebasto: right
< harding> wumpus: you create the .torrent file yourself? That is, it's not something that's created by gitian that I could access a day or two before the release so that we don't have to make that last minute edit?
< wumpus> harding: I currently create it manually using transmission-gtk; not sure if torrent files are deterministic but I think the biggest obstacle is: the torrent includes the signed SHA256SUMS.asc, we won't have that two days before the release
< harding> Ah, indeed. Oh, well then. We still usually need to update the date anyway.
< wumpus> yes, we'll just need to keep this in mind for the release checklist
< wumpus> I'll add it to mine too
< wumpus> on the old bitcoin.org server there was a script that automatically generated the .torrent when all the files are in place; but I don't think that helps much, compared to uploading the torrent along with the rest of the files
< wumpus> I *guess* I could sign the SHA256SUMS.asc, then generate a .torrent, as soon as I did final codesigned gitian build for a release, then upload the torrent without the actual .asc so it doesn't actually get seeded prematurely...
< wumpus> but thinking of it, that won't win much time either and complicates the process
< wumpus> 71kB release notes, gah, when I grew up computers didn't even have that much *memory*
< queip> Release.txt, lines 1000-1025 ... Please insert Disk #2. Not ready reading drive A. Abort, Retry, Fail? _
< gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
< wumpus> *please turn around the cassette tape*
< harding> The site build script could grab the .torrent file from the current release's directory and recreate the magnet URI automatically on each site rebuild, obliviating the technical need to manually paste it in. It looks pretty easy (although this exact code has some heavyweight dependencies I'd prefer to avoid): https://gist.github.com/Burgestrand/1733611
< sipa> wumpus: haahal, my first programming language was some version of gwbasic, which had 56 kB of space for variables + program code :)
< aj> harding: obviating. too much harry potter?
< aj> harding: (or too much mimblewimble?)
< harding> aj: probably! (Harry Potter; Mimblewimble hurts my brain.)
< wumpus> harding: that's a better idea, though yes it's unfortunate if it drags in all kinds of stuff for the web build
< queip> lol by accident discovered #2. Gavin suggesting BTC to be good store of value. muh narrative of that only recently thaw was added. gmaxwell
< gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
< wumpus> heh.
< wumpus> you could dig in the bitcoin talk forums and find layer after layer of the same kinds of discussions, going back to the beginning, repeated every time. Where did those 8 years go, suddenly...
< wumpus> sipa: good old x86 "tiny" memory model
< wumpus> harding: so from what I understand, it needs openssl only to compute a sha1 hash, and bencode to parse the torrent file and grab the info section and trackers
< wumpus> and the other dependencies such as cgi for URL-encoding and assorted utility things
< queip> do we need to rely on sha1 there?
< wumpus> your guess is as good as mine...
< queip> can't wait till Linus moves git over to sha2/sha3. Perhaps that should be written in his CoC.
< spinza> harding, wumpus -> make_magnet links: https://gist.github.com/spinza/bf2018a35b66b46f4ab6875fee44d32f
< wumpus> spinza: great! apparently it's simpler in python; though the website generation script is in ruby, so this will be harder to integrate, I guess