< 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>
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.
< 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
< 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
< 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
< 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
< 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>
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
< 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?