1 2015-07-17 00:37:37 <justinnewton> I'm on the list at the linux foundation
  2 2015-07-17 06:53:18 <wumpus> cfields: any idea why Travis decided to rebuild everything, including depends, in this pull: https://github.com/bitcoin/bitcoin/pull/6442  (and then fails "Your test run exceeded 50 minutes.  One possible solution is to split up your test run.")
  3 2015-07-17 06:53:44 <wumpus> https://s3.amazonaws.com/archive.travis-ci.org/jobs/71114577/log.txt
  4 2015-07-17 07:01:37 <cfields> wumpus: running `casher fetch` took longer than 180 seconds and has been aborted
  5 2015-07-17 07:01:54 <cfields> cache failed to download so it had to build fresh
  6 2015-07-17 07:02:06 <wumpus> bleh, it happens a lot lately
  7 2015-07-17 07:02:33 <cfields> yea :\
  8 2015-07-17 07:02:40 <wumpus> could we just cancel the pull buld early if that happens?
  9 2015-07-17 07:03:17 <cfields> sf.net is just going to make it worse until they get it worked out
 10 2015-07-17 07:03:25 <cfields> hmm, maybe
 11 2015-07-17 07:03:42 <wumpus> as we know it will go over the limit anyway + extraneous full builds in pulls put a lot of load on the infrastructure
 12 2015-07-17 07:04:12 <wumpus> for main branch builds this is the right logic, of course
 13 2015-07-17 07:04:49 <cfields> yea
 14 2015-07-17 07:04:59 <cfields> i'll see if we can do that early abort
 15 2015-07-17 07:05:06 <wumpus> this is a sf.net issue?
 16 2015-07-17 07:05:14 <cfields> but also, i have a few things i've been working on/ thinking about to improve the situation
 17 2015-07-17 07:05:29 <cfields> no, simultaneous
 18 2015-07-17 07:06:00 <cfields> maybe they share the same root cause though. if aws is flaky, we're all doomed anyway :)
 19 2015-07-17 07:06:06 <wumpus> hehe
 20 2015-07-17 07:06:44 <cfields> i have some changes that make depends build in parallel
 21 2015-07-17 07:06:54 <cfields> should speed things up significantly
 22 2015-07-17 07:07:56 <wumpus> I thought the builds already used parallelism?
 23 2015-07-17 07:08:24 <cfields> individually, yes
 24 2015-07-17 07:09:17 <cfields> but there's no reason why boost and bdb can't be building at the same time (for ex)
 25 2015-07-17 07:11:12 <wumpus> but if they both use make-level parallelism, will there be an overall gain and not just a flurry of proceses stomping on the CPU? :)
 26 2015-07-17 07:11:35 <cfields> you'd think it wouldn't gain much, since they're individually parallel anyway. But i did it with another project at one point and it scaled impressively. There's lots of time spent on small setup tasks
 27 2015-07-17 07:11:41 <cfields> hehe, saw that coming :)
 28 2015-07-17 07:11:45 <wumpus> right
 29 2015-07-17 07:12:19 <wumpus> boost and bdb build very fast :D
 30 2015-07-17 07:12:30 <wumpus> qt is the culprit, it takes so much longer too build than anything else
 31 2015-07-17 07:13:52 <cfields> right. logically, we could just stash qt bins somewhere to avoid rebuilding it. But that's exactly what the cache does already. So any other attempt would likely be equally prone to failure. So i'm not sure it's worth adding another layer like that
 32 2015-07-17 07:14:28 <wumpus> agree on that -and more layers and more complexity makes it even harder to troubleshoot failures
 33 2015-07-17 07:15:17 <wumpus> it's just that *if* travis is going to fail anyway, failing fast is better than after 50 minutes :)
 34 2015-07-17 07:16:15 <cfields> agreed
 35 2015-07-17 07:17:52 <cfields> well, yes, we can certainly make it fail. only question is whether we can fail so that it's obviously a transient failure.
 36 2015-07-17 07:18:44 <cfields> i'll have a look first thing tomorrow. off to bed for now
 37 2015-07-17 07:19:05 <wumpus> that'd be an interesting feature for travis - assert an intermittent failure, so that it shows "there was a problem running the test"
 38 2015-07-17 07:19:27 <cfields> well it makes that distinction already
 39 2015-07-17 07:19:29 <wumpus> instead of a problem testing the code
 40 2015-07-17 07:19:30 <cfields> error != failure
 41 2015-07-17 07:19:34 <wumpus> ok
 42 2015-07-17 07:19:46 <wumpus> nn!
 43 2015-07-17 07:19:52 <cfields> just not sure if the script can trip the assertion
 44 2015-07-17 07:20:23 <cfields> btw, if sourceforge is causing a sea of red for travis, we could always just re-point those to bitcoincore.org instead
 45 2015-07-17 07:20:52 <cfields> given their momentum lately, that may be more stable in the long-run anyway :\
 46 2015-07-17 07:21:11 <wumpus> at a fallback to bitcoincore.org
 47 2015-07-17 07:21:15 <wumpus> at least
 48 2015-07-17 07:21:54 <wumpus> or, does travis have a way to host files locally?
 49 2015-07-17 07:22:05 <cfields> the issue is that sourceforge doesn't report a failure :(
 50 2015-07-17 07:22:06 <wumpus> that'd be even better, to avoid load on any upstream
 51 2015-07-17 07:23:02 <cfields> they happily serve a "200: file not found"
 52 2015-07-17 07:23:17 <wumpus> ...... *speechless*
 53 2015-07-17 07:23:20 <cfields> (snark is mine, but iirc it does return a 2xx along with an error html
 54 2015-07-17 07:23:21 <cfields> )
 55 2015-07-17 07:23:43 <wumpus> sf is broken in so many ways it's no longer even funny
 56 2015-07-17 07:24:45 <wumpus> thinking about it, they probably want to discourage automatic downloading by script, so that people see their ads
 57 2015-07-17 07:25:19 <wumpus> (and can accidentally click the big green 'give me malware!' button instead of the well hidden real download link)
 58 2015-07-17 07:25:40 <wumpus> anyhow, nn
 59 2015-07-17 07:26:08 <cfields> heh yep, same as last time:
 60 2015-07-17 07:26:19 <cfields> wget http://sourceforge.net/projects/boost/files/boost/1.58.0/boost_1_58_0.tar.gz
 61 2015-07-17 07:26:31 <cfields> HTTP request sent, awaiting response... 200 OK
 62 2015-07-17 07:26:31 <cfields> Length: 639 [text/html]
 63 2015-07-17 07:29:01 <cfields> ah yes, that actually works exactly how we want it to already
 64 2015-07-17 07:29:12 <cfields> (travis failure/error semantics, i mean)
 65 2015-07-17 07:29:14 <wumpus> nice!
 66 2015-07-17 07:29:31 <wumpus> (that's always so good to hear for a change :)
 67 2015-07-17 07:29:45 <cfields> heh
 68 2015-07-17 07:31:09 <cfields> if we return != 0 in before_script, it'll mark it as a build error and stop before running. So we just need to check for caching success and bail otherwise
 69 2015-07-17 07:31:13 <cfields> will do first thing tomorrow.
 70 2015-07-17 10:04:27 <ClockCat> hello
 71 2015-07-17 10:38:22 <wumpus> hello
 72 2015-07-17 11:00:31 <mjerr> Hey, just scrolled through the draft on lightning from rusty. How is using preimages more efficient over exchanging private keys?
 73 2015-07-17 11:32:29 <GreenIsMyPepper> mjerr: hash preimages are necessary due to malleability risks (in the script, each output state has only one signature required), multisig with hostile co-signers doesn't work without a full malleability fix since hostile parties may refuse to sign mutated parent transactions
 74 2015-07-17 11:36:40 <mjerr> so when I want to have a revokable output, I'll have the output script hash(you) and signature(me), and send you the transaction with my signature and a timelock?
 75 2015-07-17 11:37:16 <mjerr> such that you can fill the preimage
 76 2015-07-17 14:49:13 <cappu_> Hello , how does BIP approval work in practice? For example BIP 039 has be draft for some time seems like I cant rely up on it can I?
 77 2015-07-17 14:51:36 <wumpus> well it is draft until someone proposes on the mailing list to change the status, and there is general agreement. See BIP 0001 for the whole process.
 78 2015-07-17 14:52:33 <cappu_> wumpus: how long does these things take_
 79 2015-07-17 14:54:20 <wumpus> but the status shouldn't stop you from implementing it, BIP39 has been around for a long while, it's unlikely to change
 80 2015-07-17 14:54:47 <cappu_> wumpus: I see, right no I am just learning it thats why I am asking
 81 2015-07-17 16:28:18 <kanzure> what's a good max value for rpcthreads?
 82 2015-07-17 16:36:11 <wumpus> the maximum number of requests that you want to be able to have in flight at once. Setting it too high won't win you much because the amount of concurrency in handling RPC commands is fairly low.
 83 2015-07-17 16:36:38 <wumpus> usually the default of 4 should be enough
 84 2015-07-17 16:36:48 <kanzure> i think all of my rpc threads are getting locked
 85 2015-07-17 16:37:19 <wumpus> depending on the problem, it may be that your software implements rpc keepalive incorrectly, and holds up threads
 86 2015-07-17 16:37:24 <kanzure> i was using python-bitcoinlib's rpc client and made a keyboardinterrupt happen; now bitcoin-cli can't run "getinfo" and i get back in python land things like "http.client.CannotSendRequest: Request-sent"
 87 2015-07-17 16:38:07 <wumpus> what RPC command was it running? note that disconnecting won't break off very long commands
 88 2015-07-17 16:38:08 <kanzure> so, that sounds likely, but shouldn't bitcoind eventually trigger some rpc timeout perhaps?
 89 2015-07-17 16:38:25 <kanzure> actually it was a non-existing rpc command (i made a typo or something)
 90 2015-07-17 16:38:43 <wumpus> not as long as you're connected. When you have disconnected, it will abandon the connection as soon as it notices (eg stops executing the current command)
 91 2015-07-17 16:39:06 <kanzure> hm; maybe i have a pool of connections still open.
 92 2015-07-17 16:39:40 <kanzure> nope
 93 2015-07-17 16:40:32 <kanzure> so i think threads are still held up, regardless of my client's connection
 94 2015-07-17 16:42:25 <kanzure> hmm https://github.com/jgarzik/python-bitcoinrpc/pull/49
 95 2015-07-17 16:42:55 <kanzure> "Since 02d6ed6, any problem with the connection has been permanently fatal to all future requests." (of course, this is python-bitcoinrpc and not python-bitcoinlib)
 96 2015-07-17 16:43:15 <wumpus> that's strange - haven't heard that issue before, if you can reliably reproduce it please file an issue
 97 2015-07-17 16:43:56 <kanzure> Luke-Jr: any insigh
 98 2015-07-17 16:43:59 <kanzure> *insight?
 99 2015-07-17 16:47:05 <kanzure> hm well that seems to be unrelated, because the problem i experience is with bitcoind, even after i kill the rpc client connections
100 2015-07-17 16:49:56 <kanzure> weird, i may have lost my regtest blockchain by sigkilling bitcoind?
101 2015-07-17 16:50:41 <wumpus> what signal?
102 2015-07-17 16:51:33 <wumpus> signal 15 should result in a controlled shutdown, signal 9 could mean that things (esp block database / utxo updates) haven't been flushed to disk yet
103 2015-07-17 16:51:34 <kanzure> sigkill (9) (it wasn't responding to anything else)
104 2015-07-17 16:51:41 <kanzure> ok fair enough
105 2015-07-17 16:52:02 <kanzure> it was a small blockchain so maybe it had never been flushed to disk?
106 2015-07-17 16:52:16 <wumpus> it ideally shouldn't result in a corrupted database though, but it's possible for incomplete, which you'd normally not notice on the main chain as it will just fetch the blocks from someone else on next start
107 2015-07-17 16:53:03 <wumpus> yes
108 2015-07-17 17:40:56 <smaltaman13> sorry to be a pain guys, but would anyone have some testnet coin to spare. I need some for testing my code, and mining on testnet is pretty hard these days :p
109 2015-07-17 17:42:10 <gunnis> https://testnet.coinfaucet.eu/en/
110 2015-07-17 17:54:27 <cfields> wumpus: not as straightforward as i'd hoped: https://github.com/travis-ci/travis-ci/issues/4423
111 2015-07-17 17:54:35 <cfields> we'll see what they come back with
112 2015-07-17 18:37:50 <ali1234> i'm getting hundreds of "Peer x.x.x.x:55413/8333 unexpectedly shrunk window 2715312020:2715322628 (repaired)" - is this an attack?
113 2015-07-17 18:41:33 <smaltaman13> anyone know who this is on testnet? kind of a drag http://blockchains.io/btct/address/n4eY3qiP9pi32MWC6FcJFHciSsfNiYFYgR/
114 2015-07-17 18:43:29 <smaltaman13> seems like someone else noticed this guy
115 2015-07-17 18:43:30 <smaltaman13> https://www.reddit.com/r/Bitcoin/comments/3b50mo/p2pool_rogue_mining_on_testnet_explanation/csixu2e
116 2015-07-17 19:04:23 <kanzure> wumpus: i might have a set of steps for replicating my rpc thread failures. could you take a look at https://gist.github.com/kanzure/57f1b50cf7fb82cc5c1a before i submit a bug report? is this unexpected behavior.
117 2015-07-17 19:08:08 <wumpus> what exactly is the issue?
118 2015-07-17 19:09:07 <wumpus> you create one rpc thread, then "mine some blocks, but don't wait for it to finish mining", that holds up the RPC thread, so of course you have to wait before getinfo() will run
119 2015-07-17 19:10:09 <wumpus> oh it's the latter part that is weird
120 2015-07-17 19:10:51 <kanzure> heh
121 2015-07-17 19:10:57 <kanzure> yes, waiting for getinfo results is expected behavior
122 2015-07-17 19:11:16 <kanzure> gmaxwell commit message text seems relevant here,
123 2015-07-17 19:11:18 <kanzure> https://github.com/bitcoin/bitcoin/commit/16a5c18cea7330bd68dc9d2f768eb518af88795b
124 2015-07-17 19:11:22 <kanzure> https://github.com/bitcoin/bitcoin/commit/7d2cb485116636595250fce4ea4eab16a877479b
125 2015-07-17 19:12:25 <wumpus> so, does rpckeepalive=0 solve it?
126 2015-07-17 19:13:01 <kanzure> willtry1sec
127 2015-07-17 19:14:13 <kanzure> yes
128 2015-07-17 19:14:27 <kanzure> should i still submit a bug report? i don't see any examples of how to replicate the failure.
129 2015-07-17 19:14:33 <kanzure> seems like rpckeepalive=0 is some sort of tempfix
130 2015-07-17 19:19:50 <kanzure> i'm also not entirely convinced that this is a client library issue
131 2015-07-17 19:21:12 <wumpus> no, it could be an issue in the current http server as well, #5677 is going to solve these kind of issues
132 2015-07-17 19:21:53 <kanzure> ok i'll do a quick issue writeup then
133 2015-07-17 19:22:04 <wumpus> I think it's better to spent effort on that than try to fix the current mess
134 2015-07-17 19:22:54 <kanzure> sure. but i'm still going to report the problem and how to replicate it.
135 2015-07-17 19:22:59 <kanzure> so that others don't have to repeat my steps.
136 2015-07-17 19:23:07 <wumpus> for now, just use -rpckeepalive=0
137 2015-07-17 19:23:09 <wumpus> ok, right
138 2015-07-17 19:23:20 <kanzure> (you're free to close it, though, that's of course up to you or whoever)
139 2015-07-17 19:39:06 <wumpus> no, it's good to have it reported
140 2015-07-17 19:39:38 <kanzure> okay reported https://github.com/bitcoin/bitcoin/issues/6454
141 2015-07-17 19:44:52 <phantomcircuit> kanzure, -rcpthreads=1
142 2015-07-17 19:44:54 <phantomcircuit> dont do dat
143 2015-07-17 19:45:20 <phantomcircuit> there's something broken about the rpc threads if there is only 1
144 2015-07-17 19:45:29 <phantomcircuit> i couldn't ever figure out what though
145 2015-07-17 19:45:38 <phantomcircuit> because threads!
146 2015-07-17 19:45:40 <kanzure> that was only for replicating the problem
147 2015-07-17 19:45:58 <kanzure> setup is slightly more complex if you have the default setting
148 2015-07-17 19:47:29 <phantomcircuit> oh
149 2015-07-17 19:47:35 <phantomcircuit> all future rpc requests fail?
150 2015-07-17 19:47:44 <phantomcircuit> interesting
151 2015-07-17 19:47:46 <kanzure> well, i haven't let it run for days or something, but yes
152 2015-07-17 19:48:00 <phantomcircuit> it's probably deadlocked then
153 2015-07-17 19:48:10 <phantomcircuit> kanzure, have you tried enabling the lock debugging stuff
154 2015-07-17 19:48:21 <kanzure> nope i am not aware of lock debugging stuff
155 2015-07-17 19:51:55 <phantomcircuit> kanzure, ./configure CXXFLAGS="-DDEBUG_LOCKORDER -DDEBUG_LOCKCONTENTION -g -Og"
156 2015-07-17 19:52:26 <phantomcircuit> it'll (mostly) detect deadlocks
157 2015-07-17 19:53:00 <kanzure> how will it tell me about deadlocks?
158 2015-07-17 19:54:39 <wumpus> I don't think this is a deadlock, probably some other place it gets stuck either in boost::asio or getline or ... as said, time is probably better spent on rebasing #5677 than trying to fix the current mess
159 2015-07-17 19:56:15 <phantomcircuit> kanzure, prints stuff in the debug log
160 2015-07-17 19:56:21 <phantomcircuit> wumpus, hmm true
161 2015-07-17 19:56:47 <kanzure> wumpus: at least a docfix would be nice
162 2015-07-17 19:56:53 <kanzure> phantomcircuit: ah, okay
163 2015-07-17 19:58:05 <kanzure> actually a log message would be ideal
164 2015-07-17 19:58:14 <kanzure> "your rpc threads are dead, see you later"
165 2015-07-17 20:13:56 <phantomcircuit> kanzure, btw my "debug the things" flags
166 2015-07-17 20:14:19 <phantomcircuit> CXXFLAGS="-Wall -pedantic -Og -fstack-protector-all -D_FORTIFY_SOURCE=2 -ggdb3 -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -DDEBUG_LOCKORDER -DDEBUG_LOCKCONTENTION"
167 2015-07-17 20:14:46 <phantomcircuit> the GLIBCXX ones are annoying though cause you need to have boost built with them also
168 2015-07-17 20:15:16 <sipa> and, run that in valgrind for reducing processing to a speed at which you can follow the cpu instructions being executed indivudally?
169 2015-07-17 20:15:42 <phantomcircuit> sipa, i've not used valgrind in a long time
170 2015-07-17 20:16:03 <phantomcircuit> it's so slow to find anything you need to leave it running for a few days
171 2015-07-17 20:16:03 <sipa> you're missing out on the cutting edge of slowing down the speed of light
172 2015-07-17 20:16:27 <phantomcircuit> the pedantic flag fills your screen with warnings though
173 2015-07-17 20:17:30 <sipa> fun
174 2015-07-17 20:17:39 <midnightmagic> Uh. Why is the bitcoin-dev mailing list now sending out emails from "Name Lastname via bitcoin-dev" instead of actual names and emails?
175 2015-07-17 20:18:09 <phantomcircuit> midnightmagic, it's a DMARC fix
176 2015-07-17 20:18:59 <phantomcircuit> warren, ^ maybe you can shed some light
177 2015-07-17 20:19:25 <midnightmagic> phantomcircuit: most people aren't signing their names, or aren't pgp-signing their messages.
178 2015-07-17 20:19:49 <midnightmagic> wow that's really irritating lol
179 2015-07-17 20:19:54 <phantomcircuit> midnightmagic, jgarzik at least was having problems because of bitpay's strong DMARC policy
180 2015-07-17 20:19:58 <sipa> midnightmagic: how is that a problem?
181 2015-07-17 20:20:10 <sipa> message subjects are not part of what you sign
182 2015-07-17 20:20:14 <sipa> afaik
183 2015-07-17 20:20:27 <phantomcircuit> sipa, for pgp they're not, but the DKIM stuff it is
184 2015-07-17 20:20:37 <phantomcircuit> iirc you sign From/Subject/Body
185 2015-07-17 20:20:41 <phantomcircuit> maybe also Date
186 2015-07-17 20:21:01 <sipa> i'm a DKIM noob, not going to comment
187 2015-07-17 20:22:30 <midnightmagic> sipa: identity, trackable from-addresses, and email responses are all either less-possible or impossible now. I can't search for andrew karamoun. I have to search for his space-broken PGP key, I initially believe it's actually amiller (but only discover afterwards that it isn't)
188 2015-07-17 20:24:06 <midnightmagic> who wrote message ID CAL8tG=nr8DGG+xad9t8dwPLJQ=jdYtZ=CSziN8kM_BTqEtrADg@mail.gmail.com ? Beats me. If I want to know for sure, I have to gpg --recv-key and manually fiddle with his pgp key id.
189 2015-07-17 20:25:19 <midnightmagic> meanwhile I'm loosely thinking amiller's IQ dropped a dozen points.
190 2015-07-17 20:29:16 <midnightmagic> .. and how do I answer someone privately off-list? Did everyone agree they wanted their email addresses obscured? hey, rnicoll, what's your email address I want to answer you privately. Hopefully Google knows, or I know you're here on IRC, *and* you're active enough to answer me here.
191 2015-07-17 20:29:44 <rnicoll> midnightmagic, jrn@jrn.me.uk
192 2015-07-17 20:30:24 <midnightmagic> rnicoll: I'm glad you're active and we happen to share an IRC network. You didn't miss anything, I'm complaining about the new obscured from address on bitcoin-dev.
193 2015-07-17 20:30:29 <Luke-Jr> midnightmagic: considering emails can be spoofed, you couldn't know even if From was retained..
194 2015-07-17 20:30:41 <Luke-Jr> midnightmagic: also, when you go to reply, it puts the right email.
195 2015-07-17 20:30:42 <midnightmagic> Luke-Jr: It's a convenience. Now it is less convenient.
196 2015-07-17 20:31:13 <rnicoll> oh... I think generally more people are happier that their addresses are private, than want to be visible, sorry
197 2015-07-17 20:31:17 <amiller> midnightmagic, is this visible from the archives? i just noticed i'm not even signed up on the new linuxfoundation bitcoin-dev yet but the archives site looks fine
198 2015-07-17 20:31:25 <Luke-Jr> midnightmagic: my point is your argument makes no sense. you can't trust the new-style From, in the same way you can't trust the old-style From
199 2015-07-17 20:32:04 <midnightmagic> Luke-Jr: I can't trust anything, of course not. But now I have to modify my client to show me reply-to, and I have to do this every time I'm curious about whether "Andrew" is amiller or some other Karamoun guy.
200 2015-07-17 20:32:28 <Luke-Jr> rnicoll: they're not private
201 2015-07-17 20:33:27 <phantomcircuit> midnightmagic, the email is still there it's just "Replay-To" now
202 2015-07-17 20:33:51 <phantomcircuit> midnightmagic, unfortunately I dont believe that there's anyway to make the mailing list DMARC and PGP friendly simultaneously
203 2015-07-17 20:35:03 <Luke-Jr> phantomcircuit: this doesn't seem to break PGP
204 2015-07-17 20:35:41 <phantomcircuit> Luke-Jr, it doesn't but it does break some email clients that integrate pgp which try to use the From: field for display
205 2015-07-17 20:35:45 <Luke-Jr> http://luke.dashjr.org/tmp/screenshots/snapshot138.png
206 2015-07-17 20:36:00 <Luke-Jr> phantomcircuit: sounds like broken clients
207 2015-07-17 20:36:10 <midnightmagic> Fine, it's in Reply-To:. What the hell email client puts the Reply-To: in the message header window?
208 2015-07-17 20:36:38 <midnightmagic> And who gives a crap about DMARC if this is the result?
209 2015-07-17 20:37:19 <rnicoll> isn't DMARC handled on the receiving SMTP side, so... us if we want the messages delivered?
210 2015-07-17 20:38:15 <Luke-Jr> rnicoll: it only affects senders who use it I think
211 2015-07-17 20:38:29 <akrmn> midnightmagic: I am that Andrew. How did you get my last name? From checking my the email headers?
212 2015-07-17 20:38:38 <Luke-Jr> midnightmagic: frankly, I didn't even notice until you said something :x
213 2015-07-17 20:38:47 <akrmn> and what did I do wrong?
214 2015-07-17 20:39:21 <midnightmagic> akrmn: I did what I said, I grabbed your PGP key from pgp.mit.edu, and it has your name in it. You did absolutely nothing wrong. You just displayed an understanding which is different from what I expected from amiller, from whom I thought your message was.
215 2015-07-17 20:39:57 <akrmn> midnightmagic: Well there's many people with my first name
216 2015-07-17 20:40:11 <midnightmagic> akrmn: The mailing list rewrote your From: address and stuffed it into the Reply-To: address, and you didn't sign your email, or put your identity anywhere in the email body.
217 2015-07-17 20:40:35 <midnightmagic> akrmn: Indeed there is!
218 2015-07-17 20:40:48 <akrmn> midnightmagic: I don't sign my emails. I just put the PGP id in case someone wants to use it
219 2015-07-17 20:41:01 <midnightmagic> akrmn: Perfectly reasonable.
220 2015-07-17 20:41:02 <akrmn> if enough people get it, its good as a MIM prevention
221 2015-07-17 20:41:44 <akrmn> though my clock is messed up on the computer I sent the email with, that's all, didn't do anything else weird
222 2015-07-17 20:46:19 <midnightmagic> Luke-Jr: What, do you use mutt or something and ignore the From: address entirely? I thought you used kmail?
223 2015-07-17 20:46:46 <amiller> midnightmagic, are you talking about this message: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009460.html it shows okay on the archive maybe just not via email
224 2015-07-17 20:46:57 <Luke-Jr> midnightmagic: I do use KMail. I see only From until I reply.
225 2015-07-17 20:47:54 <midnightmagic> amiller: The actual email delivered to people has a From: address that says this: From: Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
226 2015-07-17 20:49:26 <midnightmagic> ehh whatever. I'll write a tiny script to un-munge it. As it is, the From: is a useless field right now.
227 2015-07-17 20:50:03 <Luke-Jr> midnightmagic: I think most people have a last name on their email
228 2015-07-17 20:50:14 <Luke-Jr> "Luke Dashjr" is pretty unambiguous
229 2015-07-17 20:50:34 <midnightmagic> Luke-Jr: Sure, and "Me via bitcoin-dev" is super helpful when browsing my message window.
230 2015-07-17 20:50:41 <akrmn> anyway, what I'm saying is nothing exotic, even the inventor of bittorrent, Bram Cohen would agree.
231 2015-07-17 20:50:45 <Luke-Jr> midnightmagic: yeah……
232 2015-07-17 20:51:22 <midnightmagic> akrmn: You did and said absolutely nothing wrong. I know I said it before, but I should say it again: seriously, you did absolutely nothing wrong.
233 2015-07-17 20:51:51 <midnightmagic> You were even polite and courteous, which is more than I can say for myself right now.
234 2015-07-17 20:52:20 <akrmn> midnightmagic: ok no problem
235 2015-07-17 20:59:08 <sipa> midnightmagic: where does it get the 'Me' ?
236 2015-07-17 21:07:38 <amiller> sipa, midnightmagic, the 'Me' seems like this guys self reported name: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009425.html
237 2015-07-17 21:08:23 <sipa> then i don't see the problem...
238 2015-07-17 21:11:47 <amiller> from my limited vantage point, i think the problem is that in mail delivered from bitcoin dev, the from field does not contain the *email address* of the sender, even though this address shows up in the archive.
239 2015-07-17 21:12:04 <ajweiss> later versions of mailman will only munge emails from people with domains that ask for strict dkim verification
240 2015-07-17 21:12:16 <ajweiss> it looks like the list is now munging all
241 2015-07-17 21:13:50 <amiller> ajweiss, so it is expected behavior to munge the address *when delivering* posts by email, even though they are shown on the archive?
242 2015-07-17 21:14:03 <ajweiss> yes.
243 2015-07-17 21:14:18 <akrmn> ya next time Ill send with "Andrew K" instead of just Andrew
244 2015-07-17 21:14:28 <ajweiss> mailman perturbs the messages which breaks dkim signatures
245 2015-07-17 21:15:14 <ajweiss> if someone sends from a domain with strict dkim turned on, many recipients will send the message to spam or trash because the signature validation failed
246 2015-07-17 21:16:18 <ajweiss> so instead the current hack is to rewrite the envelope so that the message is being sent from the list (ie: the list's domain now controls dkim validation) and to reset the reply-to to the original author
247 2015-07-17 21:17:06 <ajweiss> ideally, it would be running on more recent versions of mailman, that have the option to query dkim status of each sender and only munge messages for senders from domains that advertise that they want strict dkim validation
248 2015-07-17 21:17:21 <ajweiss> does that make sense?
249 2015-07-17 21:18:18 <sipa> at least it could keep the actual email address inside the from field, even if munged
250 2015-07-17 21:18:27 <sipa> instead of only keeping the name
251 2015-07-17 21:19:20 <ajweiss> i think if the from field doesn't match the envelope from, many clients suspect spam as well
252 2015-07-17 21:20:05 <ajweiss> it could just leave the full name intact in the from field, but it makes sense that it place some mark there that it has done something
253 2015-07-17 21:20:40 <ajweiss> ideally it would only happen for a few people, as strict dkim hasn't been rolled out by many people yet... for reasons like this...
254 2015-07-17 21:23:13 <Luke-Jr> "Me jimmyjack at gmail com" would work
255 2015-07-17 21:24:32 <mrkent> How is this approach for an escrow service? - Each user submits an xpub, for transactions between two users, escrow service creates a BIP44 wallet with 2 users' xpub + own escrow xpub. New addresses are used for further transactions between same pair of users.
256 2015-07-17 21:25:15 <Luke-Jr> mrkent: usually escrows are one-off things, but sure
257 2015-07-17 21:28:10 <mrkent> Luke-Jr: Any problems with using the same xpub for escrows with different users?
258 2015-07-17 21:28:33 <Luke-Jr> …
259 2015-07-17 21:29:13 <sipa> damn mcbooks with narcolepsia
260 2015-07-17 21:29:33 <Luke-Jr> lol
261 2015-07-17 21:33:05 <mrkent> Luke-Jr: sorry back
262 2015-07-17 21:33:29 <Luke-Jr> mrkent: if you use the same xpub, you get all the usual key reuse problems
263 2015-07-17 21:33:34 <sipa> mrkent: do different users learn eachother's xpub?
264 2015-07-17 21:33:37 <Luke-Jr> besides, there's no value in doing so
265 2015-07-17 21:33:59 <mrkent> sipa: no
266 2015-07-17 21:34:11 <sipa> then there is no problem afaict
267 2015-07-17 21:34:18 <amiller> midnightmagic, it looks like the sender's email address is in the 'reply-to' field
268 2015-07-17 21:34:36 <sipa> they give up their privacy to the escrow, but that's inevitable
269 2015-07-17 21:34:38 <Luke-Jr> wait, if users don't see each others' xpubs, then how would they verify the address they're paying to is legit?
270 2015-07-17 21:34:51 <sipa> it includes their own
271 2015-07-17 21:35:02 <Luke-Jr> but it could be their own + 2 escrow..
272 2015-07-17 21:35:08 <sipa> yup
273 2015-07-17 21:35:12 <Luke-Jr> hmm
274 2015-07-17 21:35:42 <sipa> seems to be a problem indeed
275 2015-07-17 21:35:58 <sipa> assuming the two users have a trusted communication channel in the first place
276 2015-07-17 21:36:06 <sipa> otherwise there is no solution to that problem at all
277 2015-07-17 21:36:30 <sipa> but if there is, they should be able to verify that the address they're getting indeed corresponds to what the other user gave them
278 2015-07-17 21:36:47 <sipa> an escrow that can MITM addresses isn't very useful
279 2015-07-17 23:18:42 <jcorgan> anyone hear an ETA when sourceforge will get unborked?
280 2015-07-17 23:19:12 <sipa> what borkedness are you referring to?
281 2015-07-17 23:19:35 <jcorgan> http://sourceforge.net/error-404.html
282 2015-07-17 23:20:43 <sipa> no clue
283 2015-07-17 23:20:46 <sipa> why do we care?
284 2015-07-17 23:26:53 <mrkent> sipa: If there's that little trust for the escrow, why use that escrow?
285 2015-07-17 23:28:49 <sipa> mrkent: in a bitcoin setting, you can have an escrow that can't steal your money
286 2015-07-17 23:28:59 <sipa> that's the whole purpose of the 2-of-3 setup
287 2015-07-17 23:29:20 <sipa> if you put the escrow in charge of relaying address information, you're giving them the ability to steal again
288 2015-07-17 23:29:35 <sipa> so you could just as well use a fully trusted escrow, without any multisig
289 2015-07-17 23:35:45 <mrkent> sipa: Okay so in a scenario where shopper is buying an item from merchant and needs escrow, how does he find an escrow that isn't colluding with the merchant?
290 2015-07-17 23:36:19 <sipa> use one with a good reputaton?
291 2015-07-17 23:36:24 <sipa> there is no solution to this
292 2015-07-17 23:36:33 <mrkent> Okay cool
293 2015-07-17 23:36:54 <sipa> but in multisig setting, colluding with the other partner reduces to normal payment security
294 2015-07-17 23:37:08 <sipa> in a normal trusted escrow, the escrow can run off with the money
295 2015-07-17 23:38:23 <sipa> hmm, that's a bad formulation
296 2015-07-17 23:38:36 <mrkent> In the scenario I described, the escrow would have to be trusted to be relaying the right addresses
297 2015-07-17 23:38:38 <sipa> in a multisig setting, the worst the escrow can do is collude with the receiver
298 2015-07-17 23:38:54 <sipa> if you need to trust the escrow to relay the right addresses, you don't need multisig
299 2015-07-17 23:38:59 <sipa> it offers 0 benefit in that case
300 2015-07-17 23:39:14 <sipa> as all the multisig protects against is avoiding that the escrow steals the money
301 2015-07-17 23:41:43 <mrkent> sipa: so to properly gain value, the place (website or w/e) you buy stuff would have to be different than the place you find escrow?
302 2015-07-17 23:41:59 <sipa> it's not about gaining value
303 2015-07-17 23:42:13 <sipa> it's about preventing vectors of attack
304 2015-07-17 23:43:08 <sipa> there's no point in having a complex escrow if it can just steal the funds
305 2015-07-17 23:43:19 <sipa> as the whole complexity was there to prevent the escrow from stealing the funds
306 2015-07-17 23:44:00 <Luke-Jr> complexity != value :P
307 2015-07-17 23:44:17 <mrkent> preventing attack = value
308 2015-07-17 23:44:34 <sipa> you don't prevent an attack by trusting them to not attack!
309 2015-07-17 23:44:53 <BlueMatt> sourceforge hacked again or boost changing out files without a version bump? https://travis-ci.org/bitcoin/bitcoin/jobs/71501457#L1348
310 2015-07-17 23:45:08 <sipa> just use a normal escrow in that case, which gives you a simple address, you send them the money, and they decide whether refund you or send the money to the destination
311 2015-07-17 23:45:16 <sipa> there is no difference in security
312 2015-07-17 23:46:11 <dgenr8> -salvagewallet started breaking on a lock failure for me in master
313 2015-07-17 23:47:07 <cfields> BlueMatt: sourceforge is down again
314 2015-07-17 23:47:17 <BlueMatt> fun
315 2015-07-17 23:47:51 <sipa> BlueMatt: it's fetching http://sourceforge.net/ ...
316 2015-07-17 23:48:12 <BlueMatt> so?
317 2015-07-17 23:48:14 <BlueMatt> its checking hash
318 2015-07-17 23:48:24 <BlueMatt> sf mirrors are only http, last I heard
319 2015-07-17 23:48:28 <BlueMatt> though that was a long time ago
320 2015-07-17 23:48:57 <sipa> i mean
321 2015-07-17 23:49:00 <sipa> that's the full URL
322 2015-07-17 23:49:03 <cfields> sipa: sf is doing all kinds of wonky things. I think what you're seeing is just wget reporting redirects weirdly.
323 2015-07-17 23:49:16 <sipa> yes, that's my guess
324 2015-07-17 23:49:22 <cfields> sipa: give it a go yourself: wget http://sourceforge.net/projects/boost/files/boost/1.58.0/boost_1_58_0.tar.gz
325 2015-07-17 23:49:30 <cfields> it just gives you an html file
326 2015-07-17 23:49:38 <sipa> fun times
327 2015-07-17 23:50:13 <mrkent> sipa: okay so you'd have to get the address straight from the merchant, that is used as a part of the multisig contract, as the ultimate output destination?
328 2015-07-17 23:50:24 <sipa> mrkent: yup
329 2015-07-17 23:50:47 <sipa> or use signed payment requests, forwarded by the escrow
330 2015-07-17 23:50:56 <sipa> verified by the customer
331 2015-07-17 23:51:42 <mrkent> i see
332 2015-07-17 23:55:54 <mrkent> sipa: by signed payment request, you mean signed by the private key associated with the address that the shopper got straight from merchant, correct?
333 2015-07-17 23:56:06 <sipa> mrkent: i mean BIP70
334 2015-07-17 23:56:17 <mrkent> oh