1 2016-08-23 00:56:39	0|GitHub188|[13bitcoin] 15cbarcenas opened pull request #8560: Trivial: Fix two VarInt examples in serialize.h (06master...06fix_varint_examples) 02https://github.com/bitcoin/bitcoin/pull/8560
  2 2016-08-23 03:46:31	0|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
  3 2016-08-23 03:46:35	0|kanzure|this is re: https://botbot.me/freenode/bitcoin-core-dev/2016-04-28/?msg=65077020&page=3
  4 2016-08-23 03:47:37	0|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...
  5 2016-08-23 03:48:36	0|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)
  6 2016-08-23 06:11:26	0|GitHub129|[13bitcoin] 15rebroad opened pull request #8561: Show "end" instead of many zros when getheaders request received with… (06master...06LessGetheadersZeros) 02https://github.com/bitcoin/bitcoin/pull/8561
  7 2016-08-23 09:57:52	0|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
  8 2016-08-23 09:58:07	0|timothy|with the check of tag signature ofc
  9 2016-08-23 09:58:18	0|timothy|any comments against that?
 10 2016-08-23 10:02:53	0|sipa|arch builds from source on install?
 11 2016-08-23 10:03:12	0|timothy|no, I build packages signed with my signature
 12 2016-08-23 10:03:22	0|timothy|but user can choose to build the package by itself
 13 2016-08-23 10:14:53	0|sipa|ok, and this applies only in case they choose to build from source?
 14 2016-08-23 10:17:41	0|timothy|also when I build from source
 15 2016-08-23 10:17:58	0|timothy|binary packages on archlinux are signed by my gpg key
 16 2016-08-23 10:24:34	0|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
 17 2016-08-23 10:25:09	0|timothy|builds are made by using git too
 18 2016-08-23 10:25:21	0|timothy|so if someone inject malware in git repository gitian doesn't help
 19 2016-08-23 10:26:57	0|sipa|fair enough
 20 2016-08-23 10:27:31	0|sipa|though we would detect different binaries through gitian... unless everyone got a version with modified history
 21 2016-08-23 10:28:10	0|sipa|so actually, i think that downloading the source tarball is stronger, if you verify multiple gitian signatures
 22 2016-08-23 10:28:19	0|sipa|which is nontrivial, i guess
 23 2016-08-23 10:39:06	0|MarcoFalke|It should be mentioned that a lot of people mistake the tarball on the GitHub as something that can be verified
 24 2016-08-23 10:39:08	0|MarcoFalke|link: https://github.com/bitcoin/bitcoin/releases/tag/v0.13.0
 25 2016-08-23 10:39:31	0|btcdrak|there doesnt seem to be a way to turn those off :(
 26 2016-08-23 10:39:35	0|MarcoFalke|But I am not aware of disabling those
 27 2016-08-23 10:39:40	0|MarcoFalke|jup
 28 2016-08-23 10:39:41	0|btcdrak|we should ask Github about it
 29 2016-08-23 10:40:10	0|btcdrak|timothy: you should build from the gitian tarballs at least
 30 2016-08-23 10:40:30	0|btcdrak|wumpus do you upload the tar sources too?
 31 2016-08-23 10:41:31	0|MarcoFalke|We could upload wumpus' sig.asc to the github releases and link to the site where we place the gitian binaries
 32 2016-08-23 10:42:14	0|timothy|MarcoFalke: I'm using git clone + git verify-tag ofc
 33 2016-08-23 10:42:18	0|MarcoFalke|btcdrak: yes https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc3/
 34 2016-08-23 10:43:14	0|btcdrak|wumpus: also remember to include the hashes in your release announcement going forward so that information can be widely distributed.
 35 2016-08-23 10:44:25	0|timothy|yes, I'm still waiting for 0.13.0 tarballs :p
 36 2016-08-23 10:47:44	0|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.
 37 2016-08-23 10:57:17	0|warren|btcdrak: easier to force it if you have the web server update only to signed commits?
 38 2016-08-23 10:57:48	0|btcdrak|if/when we do our own hosting
 39 2016-08-23 10:58:06	0|btcdrak|I'll turn off the merge button on the repository at least
 40 2016-08-23 11:01:03	0|btcdrak|oh they dont have that feature. I must be misremembering
 41 2016-08-23 11:01:41	0|warren|github is so convenient they make people forget the "distributed" part.
 42 2016-08-23 11:22:29	0|GitHub129|[13bitcoin] 15ajtowns opened pull request #8563: Add configure check for -latomic (06master...06autoconf-latomic) 02https://github.com/bitcoin/bitcoin/pull/8563
 43 2016-08-23 13:41:25	0|GitHub107|[13bitcoin] 15jonasschnelli opened pull request #8564: [Wallet] remove unused code/conditions in ReadAtCursor (06master...062016/08/bdb_abstraction_1) 02https://github.com/bitcoin/bitcoin/pull/8564
 44 2016-08-23 13:55:37	0|kanzure|need something?
 45 2016-08-23 13:56:11	0|sipa|?
 46 2016-08-23 13:56:31	0|wumpus|because of the heat wave?
 47 2016-08-23 13:56:48	0|GitHub113|[13bitcoin] 15roques opened pull request #8565: .gitignore TAGS and emacs lock files (06master...06gitignore) 02https://github.com/bitcoin/bitcoin/pull/8565
 48 2016-08-23 13:57:18	0|btcdrak|"14:26 — jonasschnelli stabs berkleyDb"
 49 2016-08-23 13:57:38	0|kanzure|man, i was about to schedule an airdrop of paramedics to you
 50 2016-08-23 13:57:43	0|wumpus|noooo don't add your personal gitignores into the project
 51 2016-08-23 13:57:51	0|sipa|i just flew from london to frankfurt
 52 2016-08-23 13:57:51	0|wumpus|why do people keep doing that
 53 2016-08-23 13:57:56	0|sipa|i did not see any clouds
 54 2016-08-23 13:58:01	0|sipa|for the entire flight
 55 2016-08-23 13:58:03	0|sipa|crazy
 56 2016-08-23 13:58:07	0|wumpus|crazy indeed
 57 2016-08-23 14:06:12	0|waxwing|open the window?
 58 2016-08-23 14:06:35	0|wumpus|during a flight?
 59 2016-08-23 14:07:16	0|sipa|no clouds in london on itself is oretty remarkable already :)
 60 2016-08-23 14:07:21	0|juscamarena|There's always the emergency escape "window" ;)
 61 2016-08-23 14:47:29	0|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
 62 2016-08-23 14:54:56	0|wumpus|well the last one clearly affect users, and may have been useful to include
 63 2016-08-23 14:55:11	0|wumpus|the debug symbols are not downloadable, they're just generated by gitian
 64 2016-08-23 14:55:20	0|sipa|oh, ok
 65 2016-08-23 14:55:45	0|wumpus|that they are generated deterministically is useful for doing eg. addrtoline on stack traces in bug reports
 66 2016-08-23 14:56:28	0|wumpus|no longer using OpenSSL may make some people happy I suppose :)
 67 2016-08-23 14:56:41	0|wumpus|(only for random number generation now...)
 68 2016-08-23 14:57:56	0|sipa|and payment protocol
 69 2016-08-23 14:58:34	0|MarcoFalke|Well, let's hope that people no longer use the GUI to send no-fee txes
 70 2016-08-23 14:58:57	0|MarcoFalke|So no one will notice, if above statement holds
 71 2016-08-23 14:59:52	0|instagibbs|supporting "no fee" from GUI just gives plenty of work helping people get stuff unstuck
 72 2016-08-23 15:00:11	0|wumpus|wasn't the no-fee option moved to coin control?
 73 2016-08-23 15:00:14	0|wumpus|or really removed
 74 2016-08-23 15:00:16	0|wumpus|I don't remember
 75 2016-08-23 15:00:30	0|wumpus|payment protocol *needs* TLS, we're not going to do without OpenSSL there
 76 2016-08-23 15:00:51	0|wumpus|well it would be possible to use PolarSSL
 77 2016-08-23 15:01:16	0|wumpus|AFAIK qt can use that as drop-in replacement
 78 2016-08-23 15:02:12	0|wumpus|not that I'm sure why it would be better
 79 2016-08-23 15:06:50	0|wumpus|and libressl
 80 2016-08-23 15:24:42	0|instagibbs|\o/ congrats
 81 2016-08-23 15:28:19	0|sipa|w00t
 82 2016-08-23 15:32:00	0|MarcoFalke|wumpus: What about adding a link to https://bitcoin.org/bin/bitcoin-core-0.13.0/ on the tag ( https://github.com/bitcoin/bitcoin/releases/new?tag=v0.13.0 )
 83 2016-08-23 15:32:31	0|wumpus|sounds good to me
 84 2016-08-23 15:33:13	0|MarcoFalke|This helps to make clear that the zip and tarballs are "not official" but provided by GitHub
 85 2016-08-23 15:33:28	0|wumpus|right
 86 2016-08-23 15:33:34	0|wumpus|and would point people to actual executables
 87 2016-08-23 15:33:57	0|wumpus|is it possible to add text there? I've never been in that interface I think
 88 2016-08-23 15:41:52	0|MarcoFalke|Jup, you can add anything
 89 2016-08-23 15:41:55	0|MarcoFalke|Even the binaries
 90 2016-08-23 15:42:05	0|MarcoFalke|But I would advise against adding anything but text
 91 2016-08-23 15:42:35	0|MarcoFalke|"Anyone" can change it anytime.
 92 2016-08-23 15:42:43	0|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
 93 2016-08-23 15:47:49	0|GitHub48|13bitcoin/06master 149358893 15Wladimir J. van der Laan: doc: Add historical release notes for 0.12.1 0.13.0
 94 2016-08-23 15:47:49	0|GitHub48|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/9358893518a19f38eab9186c768ad81c7a2f9cec
 95 2016-08-23 16:06:28	0|wumpus|woohoo \o/ congrats everyone
 96 2016-08-23 16:06:34	0|wumpus|on to 0.13.1
 97 2016-08-23 16:07:30	0|wumpus|bleh, having trouble with updating bitcoin.org https://github.com/bitcoin-dot-org/bitcoin.org/pull/1348
 98 2016-08-23 16:08:41	0|timothy|should I enable zeromq?
 99 2016-08-23 16:11:16	0|wumpus|are you planning to use it?
100 2016-08-23 16:14:30	0|btcdrak|wumpus: check your email please
101 2016-08-23 16:29:27	0|otium|thank you for the great work and for our Bitcoin that you are nursing for all of us
102 2016-08-23 16:29:27	0|otium|To all the Core-dev
103 2016-08-23 16:29:28	0|otium|I believe we are numerous QUIET watchers who are supporting all of you
104 2016-08-23 16:29:28	0|otium|Thanks !
105 2016-08-23 17:04:40	0|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)
106 2016-08-23 17:05:16	0|wumpus|thanks otium
107 2016-08-23 17:10:18	0|instagibbs|luke-jr, might be a standard rule that all the ACP inputs have to increase the feerate of the transaction?
108 2016-08-23 17:10:35	0|instagibbs|(I haven't thought this through)
109 2016-08-23 17:11:02	0|instagibbs|that immediately rules out 0-value by definition, for one
110 2016-08-23 17:14:36	0|luke-jr|instagibbs: the spam input wouldn't necessarily be ACP, and in any case you'd see the spam-malleated version first
111 2016-08-23 17:15:29	0|instagibbs|luke-jr, well, if my premise was correct the latter part wouldn't "matter", but my premise is wrong it seems
112 2016-08-23 17:26:12	0|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
113 2016-08-23 17:26:22	0|michagogo|Backport that commit to 0.13?
114 2016-08-23 17:26:43	0|michagogo|(Maybe also 0.12, if we think there's a chance there'll be a .2?)
115 2016-08-23 17:27:06	0|michagogo|Well, "backport"
116 2016-08-23 17:27:19	0|wumpus|possibly
117 2016-08-23 17:27:34	0|wumpus|I'm still fighting the bitcoin.org release announcement here https://github.com/bitcoin-dot-org/bitcoin.org/pull/1348
118 2016-08-23 17:28:20	0|wumpus|there is an error in the html generated from the md, but it doesn't tell where or the context
119 2016-08-23 17:28:52	0|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
120 2016-08-23 17:29:10	0|btcdrak|ping harding
121 2016-08-23 17:29:19	0|wumpus|"
122 2016-08-23 17:29:19	0|wumpus|also can't run the tests locally, something about "Your Ruby version is 2.3.1, but your Gemfile specified 2.0.0
123 2016-08-23 17:29:22	0|wumpus|fuck ruby, really
124 2016-08-23 17:31:50	0|kanzure|use rbenv
125 2016-08-23 17:31:54	0|kanzure|or rvm
126 2016-08-23 17:33:53	0|wumpus|can anyone that is able to run those scripts send me the malformed html file? thanks
127 2016-08-23 17:35:17	0|kanzure|you can use after_failure in the travis-ci yaml file to upload or store files from a failed build
128 2016-08-23 17:36:50	0|wumpus|good idea, or just cat the thing into the travis log
129 2016-08-23 17:37:11	0|kanzure|hah.
130 2016-08-23 17:38:29	0|luke-jr|wumpus: btw, the ann ML email doesn't verify either (not even the text/plain one)
131 2016-08-23 17:38:46	0|wumpus|it does verify here before sending
132 2016-08-23 17:39:18	0|wumpus|not sure what I'm doing wrong
133 2016-08-23 17:39:30	0|wumpus|getting kind of annoyed by this, nothing is working as it should
134 2016-08-23 17:39:31	0|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
135 2016-08-23 17:39:43	0|sipa|sigh
136 2016-08-23 17:40:35	0|wumpus|maybe MLs are unsuited for sending signed messages
137 2016-08-23 17:40:50	0|wumpus|next time i'll just upload the .asc file and send a link...
138 2016-08-23 17:41:05	0|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..
139 2016-08-23 17:41:18	0|luke-jr|I would think anyway
140 2016-08-23 17:41:23	0|wumpus|possible, but I don't have time to look into that stuff really
141 2016-08-23 17:42:03	0|wumpus|there's tons of subtle changes that can invalidate a gpg signature
142 2016-08-23 17:42:08	0|Lauda|Compact blocks is enabled by default in 0.13.0?
143 2016-08-23 17:42:14	0|wumpus|I spent multiple days in that rabbit hole once
144 2016-08-23 17:42:15	0|instagibbs|Lauda, yes
145 2016-08-23 17:42:27	0|Lauda|I see, time to update then. Thanks!
146 2016-08-23 17:42:33	0|wumpus|man it's 2016 and even basic shit like that isn't working
147 2016-08-23 17:42:57	0|wumpus|stuff like that was working better in the 90's
148 2016-08-23 17:42:59	0|luke-jr|FWIW, my BFGMiner announce list on nongnu.org works fine for PGP
149 2016-08-23 17:43:07	0|wumpus|maybe I'm just getting too old
150 2016-08-23 17:43:19	0|sipa|who manages the bitcoin-dev list, actually?
151 2016-08-23 17:43:55	0|sipa|maybe it is a particular setting
152 2016-08-23 17:44:12	0|luke-jr|bitcoin core ML is different from bitcoin-dev; I imagine btcdrak manages it
153 2016-08-23 17:44:12	0|wumpus|if only the mailing list sent me my own message, I could compare
154 2016-08-23 17:44:16	0|TD-Linux|enigmail correctly detects the part of the message that is signed
155 2016-08-23 17:44:26	0|luke-jr|wumpus: I'll forward it
156 2016-08-23 17:44:44	0|wumpus|oh wait you mean the notification list? I should have that one, I have a test message
157 2016-08-23 17:44:58	0|wumpus|TD-Linux: that's the one from bitcoin-dev?
158 2016-08-23 17:45:19	0|TD-Linux|yes
159 2016-08-23 17:45:20	0|luke-jr|wumpus: yes
160 2016-08-23 17:46:01	0|TD-Linux|actually no, it's bitcoin-core-dev. I haven't gotten the bitcoin-dev one yet
161 2016-08-23 17:46:03	0|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
162 2016-08-23 17:46:32	0|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
163 2016-08-23 17:47:04	0|wumpus|bitcoin-core-dev is the same host and software as bitcoin-dev
164 2016-08-23 17:47:21	0|achow101|Copying the text from the bitcoin-dev mailing list archive verifies fine
165 2016-08-23 17:47:37	0|instagibbs|yeah i did archive myself
166 2016-08-23 17:49:06	0|TD-Linux|it looks like I only got one of the two messages. does mailman deduplicate magically?
167 2016-08-23 17:50:17	0|kanzure|mail clients sometimes deduplicate on their own
168 2016-08-23 17:52:02	0|wumpus|this is the diff between the mail I sent and the one I received from bitcoin-announce: https://gist.github.com/laanwj/3807c6024c6c28ae06e567a63045fb25
169 2016-08-23 17:52:09	0|wumpus|I don't see any difference between the green and red lines
170 2016-08-23 17:52:16	0|wumpus|maybe I should open the diff in a hex editor...
171 2016-08-23 17:53:43	0|wumpus|2d 20 20 at the beginning of a  line becomes 2d a0 20
172 2016-08-23 17:53:44	0|wumpus|wow
173 2016-08-23 17:54:51	0|wumpus|oh wait no, 2d is the '-'. No, 20 20 at the beginning of a line becomes c2 a0 20
174 2016-08-23 17:55:05	0|wumpus|it's doing unicode magic!
175 2016-08-23 17:56:10	0|sipa|unicode magic... we should call that unicornde
176 2016-08-23 17:56:16	0|wumpus|lol sipa :D
177 2016-08-23 18:00:28	0|wumpus|so it looks like spaces are converted into non-breaking spaces
178 2016-08-23 18:00:42	0|wumpus|that could be an option
179 2016-08-23 18:00:55	0|sipa|solution: use non-breaking spaces in the announcement email!
180 2016-08-23 18:01:08	0|sipa|so which of the two lists does this?
181 2016-08-23 18:02:30	0|luke-jr|sipa: the announcement ML on bitcoincore.org
182 2016-08-23 18:03:28	0|luke-jr|hmm, I need an announce ML for Knots too. :x
183 2016-08-23 18:04:45	0|btcdrak|luke-jr: bitcoin-core-dev mailing list is another LF managed list.
184 2016-08-23 18:05:01	0|luke-jr|btcdrak: I'm aware, but that's not the list with the problem
185 2016-08-23 18:05:41	0|btcdrak|verifying by copy paste from the ML archive works fine https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000018.html
186 2016-08-23 18:05:57	0|sipa|luke-jr: i'm confused
187 2016-08-23 18:06:01	0|luke-jr|btcdrak: the problem is the https://bitcoincore.org/en/list/announcements/join/
188 2016-08-23 18:06:35	0|btcdrak|luke-jr: oh. sorry I didnt understand. what happened?
189 2016-08-23 18:07:26	0|btcdrak|oh i see, it doesnt verify. Weird, the last ones did.
190 2016-08-23 18:07:30	0|luke-jr|btcdrak: it modified the message invalidating the PGP sig
191 2016-08-23 18:08:59	0|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
192 2016-08-23 18:09:02	0|btcdrak|place*
193 2016-08-23 18:09:15	0|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
194 2016-08-23 18:09:23	0|btcdrak|e.g https://i.imgur.com/oAzcLYb.png
195 2016-08-23 18:11:29	0|wumpus|btcdrak: I'm checking the text/plain attachment, not the html one, that's hopeless I'd fathom
196 2016-08-23 18:12:04	0|btcdrak|let me login and make a test with the test list
197 2016-08-23 18:12:05	0|btcdrak|sec
198 2016-08-23 18:13:36	0|sipa|i wonder whether we shouldn't link to the gitian build results in announcement emails
199 2016-08-23 18:14:10	0|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
200 2016-08-23 18:14:25	0|wumpus|I'm fine with that
201 2016-08-23 18:14:43	0|wumpus|I've added the hashes on recommendation of btcdrak, I'm fine with adding even more stuff next time
202 2016-08-23 18:15:09	0|btcdrak|and hopefully we'll have the verification too then as well.
203 2016-08-23 18:15:13	0|btcdrak|wumpus: pm
204 2016-08-23 18:17:02	0|sipa|btcdrak: not for 0.13.1 :)
205 2016-08-23 18:18:09	0|MarcoFalke|wumpus: Fingers crossed: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1349
206 2016-08-23 18:20:23	0|wumpus|gah I had just found out how to inject a cat into the right place into the makefile
207 2016-08-23 18:20:28	0|wumpus|but thanks :)
208 2016-08-23 18:20:32	0|wumpus|hope it solves it
209 2016-08-23 18:34:15	0|wumpus|it passes with "sed 's/\xc2\xa0/ /g' /tmp/test | sed 's/^  #7840/  \\#7840/g' |gpg"
210 2016-08-23 18:34:24	0|wumpus|where /tmp/test is the exported text/plain message
211 2016-08-23 18:34:50	0|wumpus|so we should probably publish a validation FAQ for wumpus' botched gpg messages
212 2016-08-23 18:36:21	0|gmaxwell|I was about to report that the list message doesn't verify.
213 2016-08-23 18:37:38	0|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....
214 2016-08-23 18:37:59	0|wumpus|I should just give up trying to send GPG signed messages
215 2016-08-23 18:39:00	0|gmaxwell|Arichy: because the release signing key is kept offline and only used for release signing, presumably.
216 2016-08-23 18:39:02	0|wumpus|gmaxwell: the announce-list right? bitcoin-dev and bitcoin-core-dev messages should pass
217 2016-08-23 18:39:13	0|wumpus|I don't sign mails with a release-signing key
218 2016-08-23 18:39:17	0|wumpus|that's not what it's for
219 2016-08-23 18:39:35	0|wumpus|it only signs SHA256SUMS.asc files, if you want more of it, I' msorry to disappoint you
220 2016-08-23 18:40:02	0|kanzure|presumably the release signing key is only for release signing
221 2016-08-23 18:40:11	0|kanzure|announcement emails should probably not be signed by a release key
222 2016-08-23 18:40:14	0|wumpus|yes, trange uh
223 2016-08-23 18:40:16	0|kanzure|(instead signed by some other key)
224 2016-08-23 18:40:26	0|wumpus|although how kanzure words it does make sense
225 2016-08-23 18:40:28	0|gmaxwell|wumpus: yes.
226 2016-08-23 18:40:50	0|wumpus|gmaxwell: next time I'll convert spaces to non-breaking spaces first and it should work
227 2016-08-23 18:41:02	0|kanzure|oh this was email client fault?
228 2016-08-23 18:41:08	0|gmaxwell|wumpus: though if the content isn't plain ascii that might cause other mangling elsewhere.
229 2016-08-23 18:41:12	0|wumpus|(assuming there's no \# in the release notes)
230 2016-08-23 18:41:54	0|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
231 2016-08-23 18:42:15	0|wumpus|gmaxwell: oh yes it may mangle it in another stage, fun!
232 2016-08-23 18:42:18	0|kanzure|oh.  i'm not aware of a web interface for sending email to -announce.
233 2016-08-23 18:42:24	0|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 :-(
234 2016-08-23 18:42:26	0|wumpus|unicornde indeed
235 2016-08-23 18:42:54	0|sipa|wumpus: solution: next time just post a link to the bitcoin-core-dev LM archove page for the announcement mail :)
236 2016-08-23 18:43:07	0|kanzure|Arichy: one might think this is a feature not a bug of the release process- that users can recognize verification failure.
237 2016-08-23 18:43:25	0|sipa|Arichy: i'm happy to see that therr are people who take that suggestion to verify signatures seriously
238 2016-08-23 18:43:53	0|wumpus|sipa: heh, yes posting a link is probably the best idea, maybe it'll even be let through unmangled if signed
239 2016-08-23 18:44:01	0|gmaxwell|Arichy: it's signed with the same key as last release.
240 2016-08-23 18:44:11	0|wumpus|oh wait signing a link makes no sense
241 2016-08-23 18:46:04	0|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
242 2016-08-23 18:46:23	0|btcdrak|gmaxwell: we've found the issue and workaround for the announce list
243 2016-08-23 18:46:42	0|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
244 2016-08-23 18:47:07	0|gmaxwell|Arichy: it's probably the same key but you needed to fetch an updated expiration.
245 2016-08-23 18:47:40	0|gmaxwell|Arichy: it's good practice to set keys to expire to force people to potentially go fetch a revocation.
246 2016-08-23 18:47:49	0|wumpus|I only have those two: any other keys on GPG keyservers, if they exist, are false
247 2016-08-23 18:47:51	0|Arichy|@gmaxwell I am very surprised of that! Did not know about something like that
248 2016-08-23 18:48:05	0|gmaxwell|and then periodically update the expire if the key is still not believed to be compromised.
249 2016-08-23 18:49:24	0|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
250 2016-08-23 18:49:46	0|MarcoFalke|Error: Start tag a seen but an element of the same type was already open
251 2016-08-23 18:49:51	0|MarcoFalke|ull/7762"><a href="https://github.com/bitcoin/bitcoin/pull/7762">#7762<
252 2016-08-23 18:49:57	0|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
253 2016-08-23 18:50:09	0|luke-jr|also, expiration means it self-"revokes" if you lose the private key ;)
254 2016-08-23 18:50:11	0|wumpus|not that you should believe that coming from somone pretending to be wumpus on IRC
255 2016-08-23 18:50:13	0|wumpus|or something
256 2016-08-23 18:50:31	0|MarcoFalke|Maybe the hash tag before 7762?
257 2016-08-23 18:51:18	0|wumpus|oh my cat worked
258 2016-08-23 18:52:25	0|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
259 2016-08-23 18:53:09	0|Arichy|@sipa Glad to get positive feedback :-)
260 2016-08-23 18:53:18	0|wumpus|though I'm sure internet explorer would just accept it...
261 2016-08-23 18:53:19	0|gmaxwell|nested links.
262 2016-08-23 18:54:21	0|GitHub149|[13bitcoin] 15roques closed pull request #8565: .gitignore TAGS and emacs lock files (06master...06gitignore) 02https://github.com/bitcoin/bitcoin/pull/8565
263 2016-08-23 18:54:24	0|MarcoFalke|They call it Edge, now
264 2016-08-23 18:55:14	0|wumpus|I've factored the # out of the [], let's see if that does it
265 2016-08-23 18:55:50	0|wumpus|MarcoFalke: if it was that simple, I'm fairly sure that windows 10 has both IE and Edge
266 2016-08-23 18:57:50	0|GitHub45|[13bitcoin] 15MarcoFalke closed pull request #8527: Take minRelayTxFee into account in FEEFILTER messages (06master...06clampfeefilter) 02https://github.com/bitcoin/bitcoin/pull/8527
267 2016-08-23 19:06:02	0|PatBoy|can i ask a question n the spec of 0.13.0 here ? or just developement ? (sry to ask)
268 2016-08-23 19:06:17	0|luke-jr|PatBoy: #bitcoin
269 2016-08-23 19:06:32	0|PatBoy|okk thx
270 2016-08-23 19:06:34	0|PatBoy|sry
271 2016-08-23 19:12:02	0|MarcoFalke|wumpus: Passed!1!!
272 2016-08-23 19:12:07	0|wumpus|whooooo
273 2016-08-23 19:12:22	0|wumpus|thanks, going to clean up that pull
274 2016-08-23 19:58:29	0|Chris_Stewart_5|Is the 'flags' hex representation right for this documentation on the bitcoin developer reference wrt to merkle blocks?
275 2016-08-23 19:58:31	0|Chris_Stewart_5|https://bitcoin.org/en/developer-reference#merkleblock
276 2016-08-23 19:58:52	0|Chris_Stewart_5|in the hex dump part
277 2016-08-23 19:59:10	0|Chris_Stewart_5|wouldn't it be 'd1' instead of '1d'?
278 2016-08-23 20:02:55	0|sipa|Chris_Stewart_5: no, in a hex dump you put the more significant of the 2 characters for a byte first
279 2016-08-23 20:25:00	0|GitHub47|[13bitcoin] 15achow101 opened pull request #8566: Easy to use gitian building script (06master...06gitian-build-script) 02https://github.com/bitcoin/bitcoin/pull/8566
280 2016-08-23 20:25:13	0|Chris_Stewart_5|sipa: Just to be clear though, on the wire would it look like 'd1'?
281 2016-08-23 20:25:24	0|sipa|Chris_Stewart_5: who knows
282 2016-08-23 20:25:39	0|sipa|Chris_Stewart_5: it depends on the transmission technology
283 2016-08-23 20:26:00	0|sipa|from the application perspective, the wire contains bytes
284 2016-08-23 20:26:31	0|sipa|not individual bits
285 2016-08-23 20:26:50	0|sipa|and the wire will contain the byte commonly referred to as 1d
286 2016-08-23 20:27:04	0|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?
287 2016-08-23 20:27:16	0|Chris_Stewart_5|For instance if you called HexStr on it would be d1 correct?
288 2016-08-23 20:27:16	0|sipa|ffs no
289 2016-08-23 20:27:28	0|sipa|no
290 2016-08-23 20:27:33	0|sipa|it would be 1d
291 2016-08-23 20:43:34	0|GitHub90|[13bitcoin] 15djpnewton opened pull request #8567: Add default port numbers to REST doc (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8567