< GitHub188> [bitcoin] cbarcenas opened pull request #8560: Trivial: Fix two VarInt examples in serialize.h (master...fix_varint_examples) https://github.com/bitcoin/bitcoin/pull/8560
< kanzure> a toy demo for finding most recent common blockhash between two data stores (one being a hypothetical bitcoind) (rpc calls not implemented) https://gist.github.com/kanzure/2fa531afaf03fddd6568eb0212ac8c4c
< kanzure> i was wondering about making this a patch for bitcoind itself- perhaps storing some external application synchronization state and letting bitcoind manage that based on reorgs and known time since last query from some authorized application. easier to manage chain diffs from the perspective of bitcoind. and probably application authors aren't going to bother doing this right anyway...
< kanzure> (whereas application authors might be more likely to write code to handle an explicit "here's the exact bundle of block differences not yet consumed" data dump)
< GitHub129> [bitcoin] rebroad opened pull request #8561: Show "end" instead of many zros when getheaders request received with… (master...LessGetheadersZeros) https://github.com/bitcoin/bitcoin/pull/8561
< timothy> hi, I'm changing the build procedure of official archlinux packages to use git tag directly instead of downloading the linux tar with the source code
< timothy> with the check of tag signature ofc
< timothy> any comments against that?
< sipa> arch builds from source on install?
< timothy> no, I build packages signed with my signature
< timothy> but user can choose to build the package by itself
< sipa> ok, and this applies only in case they choose to build from source?
< timothy> also when I build from source
< timothy> binary packages on archlinux are signed by my gpg key
< sipa> timothy: i don't think it matters much. git tags are only on sha1 hashes, though, which may not be considered sufficiently secure in the future
< timothy> builds are made by using git too
< timothy> so if someone inject malware in git repository gitian doesn't help
< sipa> fair enough
< sipa> though we would detect different binaries through gitian... unless everyone got a version with modified history
< sipa> so actually, i think that downloading the source tarball is stronger, if you verify multiple gitian signatures
< sipa> which is nontrivial, i guess
< MarcoFalke> It should be mentioned that a lot of people mistake the tarball on the GitHub as something that can be verified
< btcdrak> there doesnt seem to be a way to turn those off :(
< MarcoFalke> But I am not aware of disabling those
< MarcoFalke> jup
< btcdrak> we should ask Github about it
< btcdrak> timothy: you should build from the gitian tarballs at least
< btcdrak> wumpus do you upload the tar sources too?
< MarcoFalke> We could upload wumpus' sig.asc to the github releases and link to the site where we place the gitian binaries
< timothy> MarcoFalke: I'm using git clone + git verify-tag ofc
< btcdrak> wumpus: also remember to include the hashes in your release announcement going forward so that information can be widely distributed.
< timothy> yes, I'm still waiting for 0.13.0 tarballs :p
< btcdrak> Starting today the bitcoincore.org merges will be git signed. (I have been lazy in this respect). I ask the other maintainers to do so also.
< warren> btcdrak: easier to force it if you have the web server update only to signed commits?
< btcdrak> if/when we do our own hosting
< btcdrak> I'll turn off the merge button on the repository at least
< btcdrak> oh they dont have that feature. I must be misremembering
< warren> github is so convenient they make people forget the "distributed" part.
< GitHub129> [bitcoin] ajtowns opened pull request #8563: Add configure check for -latomic (master...autoconf-latomic) https://github.com/bitcoin/bitcoin/pull/8563
< * jonasschnelli> stabs berkleyDb
< GitHub107> [bitcoin] jonasschnelli opened pull request #8564: [Wallet] remove unused code/conditions in ReadAtCursor (master...2016/08/bdb_abstraction_1) https://github.com/bitcoin/bitcoin/pull/8564
< * btcdrak> calls an ambulance
< kanzure> need something?
< sipa> ?
< wumpus> because of the heat wave?
< GitHub113> [bitcoin] roques opened pull request #8565: .gitignore TAGS and emacs lock files (master...gitignore) https://github.com/bitcoin/bitcoin/pull/8565
< btcdrak> "14:26 — jonasschnelli stabs berkleyDb"
< kanzure> man, i was about to schedule an airdrop of paramedics to you
< wumpus> noooo don't add your personal gitignores into the project
< sipa> i just flew from london to frankfurt
< wumpus> why do people keep doing that
< sipa> i did not see any clouds
< sipa> for the entire flight
< sipa> crazy
< wumpus> crazy indeed
< waxwing> open the window?
< wumpus> during a flight?
< sipa> no clouds in london on itself is oretty remarkable already :)
< juscamarena> There's always the emergency escape "window" ;)
< sipa> there are a few changes that i don't think were considered for inclusion in the release notes... not sure they're important enough, or just forgotten: wallet encryption no longer relies on OpenSSL, debug symbol binaries are now separately downloadable, removal of no-fee send option in gui
< wumpus> well the last one clearly affect users, and may have been useful to include
< wumpus> the debug symbols are not downloadable, they're just generated by gitian
< sipa> oh, ok
< wumpus> that they are generated deterministically is useful for doing eg. addrtoline on stack traces in bug reports
< wumpus> no longer using OpenSSL may make some people happy I suppose :)
< wumpus> (only for random number generation now...)
< sipa> and payment protocol
< MarcoFalke> Well, let's hope that people no longer use the GUI to send no-fee txes
< MarcoFalke> So no one will notice, if above statement holds
< instagibbs> supporting "no fee" from GUI just gives plenty of work helping people get stuff unstuck
< wumpus> wasn't the no-fee option moved to coin control?
< wumpus> or really removed
< wumpus> I don't remember
< wumpus> payment protocol *needs* TLS, we're not going to do without OpenSSL there
< wumpus> well it would be possible to use PolarSSL
< wumpus> AFAIK qt can use that as drop-in replacement
< wumpus> not that I'm sure why it would be better
< wumpus> and libressl
< instagibbs> \o/ congrats
< sipa> w00t
< wumpus> sounds good to me
< MarcoFalke> This helps to make clear that the zip and tarballs are "not official" but provided by GitHub
< wumpus> right
< wumpus> and would point people to actual executables
< wumpus> is it possible to add text there? I've never been in that interface I think
< MarcoFalke> Jup, you can add anything
< MarcoFalke> Even the binaries
< MarcoFalke> But I would advise against adding anything but text
< MarcoFalke> "Anyone" can change it anytime.
< wumpus> yes I wouldn't want to add the binaries there, that's just confusing, especially as the source tarballs don't match our gitian-generated oens
< GitHub48> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/9358893518a19f38eab9186c768ad81c7a2f9cec
< GitHub48> bitcoin/master 9358893 Wladimir J. van der Laan: doc: Add historical release notes for 0.12.1 0.13.0
< wumpus> woohoo \o/ congrats everyone
< wumpus> on to 0.13.1
< wumpus> bleh, having trouble with updating bitcoin.org https://github.com/bitcoin-dot-org/bitcoin.org/pull/1348
< timothy> should I enable zeromq?
< wumpus> are you planning to use it?
< btcdrak> wumpus: check your email please
< otium> To all the Core-dev
< otium> thank you for the great work and for our Bitcoin that you are nursing for all of us
< otium> I believe we are numerous QUIET watchers who are supporting all of you
< otium> Thanks !
< luke-jr> petertodd: re your ACP-by-default PR: wouldn't this enable someone to add garbage inputs (spending, for example, the 0-value p2pool anyone-can-spend UTXOs) to high-fee transactions, avoiding reducing the fee enough to allow RBF by the original tx? (anyone else find themselves doing attack scenarios like this in dreams? O.o)
< wumpus> thanks otium
< instagibbs> luke-jr, might be a standard rule that all the ACP inputs have to increase the feerate of the transaction?
< instagibbs> (I haven't thought this through)
< instagibbs> that immediately rules out 0-value by definition, for one
< luke-jr> instagibbs: the spam input wouldn't necessarily be ACP, and in any case you'd see the spam-malleated version first
< instagibbs> luke-jr, well, if my premise was correct the latter part wouldn't "matter", but my premise is wrong it seems
< michagogo> 18:47:51 <GitHub48> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/9358893518a19f38eab9186c768ad81c7a2f9cec 18:47:51 <GitHub48> bitcoin/master 9358893 Wladimir J. van der Laan: doc: Add historical release notes for 0.12.1 0.13.0
< michagogo> Backport that commit to 0.13?
< michagogo> (Maybe also 0.12, if we think there's a chance there'll be a .2?)
< michagogo> Well, "backport"
< wumpus> possibly
< wumpus> I'm still fighting the bitcoin.org release announcement here https://github.com/bitcoin-dot-org/bitcoin.org/pull/1348
< wumpus> there is an error in the html generated from the md, but it doesn't tell where or the context
< wumpus> I thought I'd try to bisect it, divide up the page until I've found the part of the page where it happens but the check is so slow that that's pointless
< btcdrak> ping harding
< wumpus> also can't run the tests locally, something about "Your Ruby version is 2.3.1, but your Gemfile specified 2.0.0
< wumpus> "
< wumpus> fuck ruby, really
< kanzure> use rbenv
< kanzure> or rvm
< wumpus> can anyone that is able to run those scripts send me the malformed html file? thanks
< kanzure> you can use after_failure in the travis-ci yaml file to upload or store files from a failed build
< wumpus> good idea, or just cat the thing into the travis log
< kanzure> hah.
< luke-jr> wumpus: btw, the ann ML email doesn't verify either (not even the text/plain one)
< wumpus> it does verify here before sending
< wumpus> not sure what I'm doing wrong
< wumpus> getting kind of annoyed by this, nothing is working as it should
< luke-jr> the ML is doing some kind of changes, adding a footer at least; that's outside the signature, but who knows what else it's touching
< sipa> sigh
< wumpus> maybe MLs are unsuited for sending signed messages
< wumpus> next time i'll just upload the .asc file and send a link...
< luke-jr> probably. but this is a private ML, so it should be possible to configure it to just send like a regular PGP-signed email..
< luke-jr> I would think anyway
< wumpus> possible, but I don't have time to look into that stuff really
< wumpus> there's tons of subtle changes that can invalidate a gpg signature
< Lauda> Compact blocks is enabled by default in 0.13.0?
< wumpus> I spent multiple days in that rabbit hole once
< instagibbs> Lauda, yes
< Lauda> I see, time to update then. Thanks!
< wumpus> man it's 2016 and even basic shit like that isn't working
< wumpus> stuff like that was working better in the 90's
< luke-jr> FWIW, my BFGMiner announce list on nongnu.org works fine for PGP
< wumpus> maybe I'm just getting too old
< sipa> who manages the bitcoin-dev list, actually?
< sipa> maybe it is a particular setting
< wumpus> if only the mailing list sent me my own message, I could compare
< luke-jr> bitcoin core ML is different from bitcoin-dev; I imagine btcdrak manages it
< TD-Linux> enigmail correctly detects the part of the message that is signed
< luke-jr> wumpus: I'll forward it
< wumpus> oh wait you mean the notification list? I should have that one, I have a test message
< wumpus> TD-Linux: that's the one from bitcoin-dev?
< TD-Linux> yes
< luke-jr> wumpus: yes
< TD-Linux> actually no, it's bitcoin-core-dev. I haven't gotten the bitcoin-dev one yet
< wumpus> ok, so that one works, that's good to hear. There was already a complainer about that too, but he had the digest mode, so probably that messed up the message
< luke-jr> https://lists.gnu.org/mailman/listinfo/bfgminer-announce says it uses Mailman 2.1.21, so that's a known-usable ML sw
< wumpus> bitcoin-core-dev is the same host and software as bitcoin-dev
< achow101> Copying the text from the bitcoin-dev mailing list archive verifies fine
< instagibbs> yeah i did archive myself
< TD-Linux> it looks like I only got one of the two messages. does mailman deduplicate magically?
< kanzure> mail clients sometimes deduplicate on their own
< wumpus> this is the diff between the mail I sent and the one I received from bitcoin-announce: https://gist.github.com/laanwj/3807c6024c6c28ae06e567a63045fb25
< wumpus> I don't see any difference between the green and red lines
< wumpus> maybe I should open the diff in a hex editor...
< wumpus> 2d 20 20 at the beginning of a line becomes 2d a0 20
< wumpus> wow
< wumpus> oh wait no, 2d is the '-'. No, 20 20 at the beginning of a line becomes c2 a0 20
< wumpus> it's doing unicode magic!
< sipa> unicode magic... we should call that unicornde
< wumpus> lol sipa :D
< wumpus> so it looks like spaces are converted into non-breaking spaces
< wumpus> that could be an option
< sipa> solution: use non-breaking spaces in the announcement email!
< sipa> so which of the two lists does this?
< luke-jr> sipa: the announcement ML on bitcoincore.org
< luke-jr> hmm, I need an announce ML for Knots too. :x
< btcdrak> luke-jr: bitcoin-core-dev mailing list is another LF managed list.
< luke-jr> btcdrak: I'm aware, but that's not the list with the problem
< btcdrak> verifying by copy paste from the ML archive works fine https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000018.html
< sipa> luke-jr: i'm confused
< luke-jr> btcdrak: the problem is the https://bitcoincore.org/en/list/announcements/join/
< btcdrak> luke-jr: oh. sorry I didnt understand. what happened?
< btcdrak> oh i see, it doesnt verify. Weird, the last ones did.
< luke-jr> btcdrak: it modified the message invalidating the PGP sig
< btcdrak> wumpus: I see what happened, I think you might have pasted it in the HTML window, so if you view the message original source there are HTML entities /tags all over the pace
< btcdrak> place*
< wumpus> after undoing the substititions (d.replace(b'\xc2\xa0',b'\x20')) it still does't pass, it also converts \#7840 on line 288 to #7840
< wumpus> btcdrak: I'm checking the text/plain attachment, not the html one, that's hopeless I'd fathom
< btcdrak> let me login and make a test with the test list
< btcdrak> sec
< sipa> i wonder whether we shouldn't link to the gitian build results in announcement emails
< sipa> it's probably not something every user should be confronted with, but i do think it is important to make this part of our process visible
< wumpus> I'm fine with that
< wumpus> I've added the hashes on recommendation of btcdrak, I'm fine with adding even more stuff next time
< btcdrak> and hopefully we'll have the verification too then as well.
< btcdrak> wumpus: pm
< sipa> btcdrak: not for 0.13.1 :)
< MarcoFalke> wumpus: Fingers crossed: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1349
< wumpus> gah I had just found out how to inject a cat into the right place into the makefile
< wumpus> but thanks :)
< wumpus> hope it solves it
< wumpus> it passes with "sed 's/\xc2\xa0/ /g' /tmp/test | sed 's/^ #7840/ \\#7840/g' |gpg"
< wumpus> where /tmp/test is the exported text/plain message
< wumpus> so we should probably publish a validation FAQ for wumpus' botched gpg messages
< gmaxwell> I was about to report that the list message doesn't verify.
< Arichy> Glad to hear that You are aware of the email signature problem. Same here with Claws Mail 3.11.1 . And I am wondering why the Email is not signed with the release signing key. I had to google the email signing key....
< wumpus> I should just give up trying to send GPG signed messages
< gmaxwell> Arichy: because the release signing key is kept offline and only used for release signing, presumably.
< wumpus> gmaxwell: the announce-list right? bitcoin-dev and bitcoin-core-dev messages should pass
< wumpus> I don't sign mails with a release-signing key
< wumpus> that's not what it's for
< wumpus> it only signs SHA256SUMS.asc files, if you want more of it, I' msorry to disappoint you
< kanzure> presumably the release signing key is only for release signing
< kanzure> announcement emails should probably not be signed by a release key
< wumpus> yes, trange uh
< kanzure> (instead signed by some other key)
< wumpus> although how kanzure words it does make sense
< gmaxwell> wumpus: yes.
< wumpus> gmaxwell: next time I'll convert spaces to non-breaking spaces first and it should work
< kanzure> oh this was email client fault?
< gmaxwell> wumpus: though if the content isn't plain ascii that might cause other mangling elsewhere.
< wumpus> (assuming there's no \# in the release notes)
< wumpus> kanzure: no, the client is not at fault, the list that failed to pass it through un-mangled has a web interface, the two lists I sent to with mutt did fine
< wumpus> gmaxwell: oh yes it may mangle it in another stage, fun!
< kanzure> oh. i'm not aware of a web interface for sending email to -announce.
< Arichy> @kanzure Makes sense regarding security to keep the release signing keys seperate, only from a user point of view, with the publicity about checking sigs, I thout ok let's import wumpus' key but that was the wrong one, and after googeling the missing one, that failed :-(
< wumpus> unicornde indeed
< sipa> wumpus: solution: next time just post a link to the bitcoin-core-dev LM archove page for the announcement mail :)
< kanzure> Arichy: one might think this is a feature not a bug of the release process- that users can recognize verification failure.
< sipa> Arichy: i'm happy to see that therr are people who take that suggestion to verify signatures seriously
< wumpus> sipa: heh, yes posting a link is probably the best idea, maybe it'll even be let through unmangled if signed
< gmaxwell> Arichy: it's signed with the same key as last release.
< wumpus> oh wait signing a link makes no sense
< Arichy> @gmaxwell I had an old other wumpus key that had expired a year ago or so, I deleted that. Maybe last time I was not so aware of checking the sigs
< btcdrak> gmaxwell: we've found the issue and workaround for the announce list
< wumpus> Arichy: I've signed the release signing key with my main key. There is no 'old wumpus key', I have a personal key, which I've used for years, and a release sigining key
< gmaxwell> Arichy: it's probably the same key but you needed to fetch an updated expiration.
< gmaxwell> Arichy: it's good practice to set keys to expire to force people to potentially go fetch a revocation.
< wumpus> I only have those two: any other keys on GPG keyservers, if they exist, are false
< Arichy> @gmaxwell I am very surprised of that! Did not know about something like that
< gmaxwell> and then periodically update the expire if the key is still not believed to be compromised.
< Arichy> [little bit offensive] If I would be the NSA or the Zhōnghuá Rénmín Gònghéguó Guójiā Ānquánbù , I would keep this Email and PGP crap forever
< MarcoFalke> Error: Start tag a seen but an element of the same type was already open
< MarcoFalke> ull/7762"><a href="https://github.com/bitcoin/bitcoin/pull/7762">#7762<
< wumpus> my main key has fingerprint 71A3 B167 3540 5025 D447 E8F2 7481 0B01 2346 C9A6, the release signing key is 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964
< luke-jr> also, expiration means it self-"revokes" if you lose the private key ;)
< wumpus> not that you should believe that coming from somone pretending to be wumpus on IRC
< wumpus> or something
< MarcoFalke> Maybe the hash tag before 7762?
< wumpus> oh my cat worked
< wumpus> <a href="https://github.com/bitcoin/bitcoin/pull/7762"><a href="https://github.com/bitcoin/bitcoin/pull/7762">#7762</a></a> yes that definitely doesn't look like standards-compliant HTML
< Arichy> @sipa Glad to get positive feedback :-)
< wumpus> though I'm sure internet explorer would just accept it...
< gmaxwell> nested links.
< GitHub149> [bitcoin] roques closed pull request #8565: .gitignore TAGS and emacs lock files (master...gitignore) https://github.com/bitcoin/bitcoin/pull/8565
< MarcoFalke> They call it Edge, now
< wumpus> I've factored the # out of the [], let's see if that does it
< wumpus> MarcoFalke: if it was that simple, I'm fairly sure that windows 10 has both IE and Edge
< GitHub45> [bitcoin] MarcoFalke closed pull request #8527: Take minRelayTxFee into account in FEEFILTER messages (master...clampfeefilter) https://github.com/bitcoin/bitcoin/pull/8527
< PatBoy> can i ask a question n the spec of 0.13.0 here ? or just developement ? (sry to ask)
< luke-jr> PatBoy: #bitcoin
< PatBoy> okk thx
< PatBoy> sry
< MarcoFalke> wumpus: Passed!1!!
< wumpus> whooooo
< wumpus> thanks, going to clean up that pull
< Chris_Stewart_5> Is the 'flags' hex representation right for this documentation on the bitcoin developer reference wrt to merkle blocks?
< Chris_Stewart_5> in the hex dump part
< Chris_Stewart_5> wouldn't it be 'd1' instead of '1d'?
< sipa> Chris_Stewart_5: no, in a hex dump you put the more significant of the 2 characters for a byte first
< GitHub47> [bitcoin] achow101 opened pull request #8566: Easy to use gitian building script (master...gitian-build-script) https://github.com/bitcoin/bitcoin/pull/8566
< Chris_Stewart_5> sipa: Just to be clear though, on the wire would it look like 'd1'?
< sipa> Chris_Stewart_5: who knows
< sipa> Chris_Stewart_5: it depends on the transmission technology
< sipa> from the application perspective, the wire contains bytes
< sipa> not individual bits
< sipa> and the wire will contain the byte commonly referred to as 1d
< Chris_Stewart_5> I guess what I am getting at is it serialized differently for a hex dump compared to what it would be serialized for and sent over the network?
< Chris_Stewart_5> For instance if you called HexStr on it would be d1 correct?
< sipa> ffs no
< sipa> no
< sipa> it would be 1d
< GitHub90> [bitcoin] djpnewton opened pull request #8567: Add default port numbers to REST doc (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8567