1 2017-01-27 00:13:20	0|jtimon|another question about gitian, why are there signed and unsigned builds for win and osx in https://github.com/bitcoin-core/gitian.sigs ? (according to the guide it seems I should build and sign the unsigned ones)
  2 2017-01-27 00:13:53	0|sipa|jtimon: because the signed ones require a key that is not public
  3 2017-01-27 00:14:13	0|sipa|so people can build the unsigned one, compare results, then the person with the key can produce the detached signatures
  4 2017-01-27 00:14:28	0|sipa|and then people can build the signed one from the earlier unsigned result plus downloaded detached signature
  5 2017-01-27 00:15:43	0|gmaxwell|I am proud to work with people who come up with such slick procedures. :)
  6 2017-01-27 00:16:44	0|jtimon|why do the signed ones require a key that's not public?
  7 2017-01-27 00:17:38	0|gmaxwell|jtimon: signed in this case refers to the windows and apple code signing keys.
  8 2017-01-27 00:17:48	0|gmaxwell|which are used to prevent ugly warning boxes on those OSes.
  9 2017-01-27 00:18:00	0|gmaxwell|to anyone who pays the piper. :P
 10 2017-01-27 00:18:03	0|jtimon|ohh, right
 11 2017-01-27 00:20:38	0|jtimon|I'm having problems building osx, I think I did all well, https://0bin.net/paste/U+Sqgot+Xk0VO-kL#cQl5R4xNHgCBRNxC5IoHZd7aW-dPJKTNO2ghEPVm0rz
 12 2017-01-27 00:21:22	0|sipa|jtimon: you don't have the MacOSX SDK
 13 2017-01-27 00:21:27	0|sipa|tar: MacOSX10.11.sdk.tar.gz: Cannot stat: No such file or directory
 14 2017-01-27 00:22:15	0|jtimon|oh, I thought it would download it by itself or something, I see
 15 2017-01-27 00:22:54	0|sipa|no, it can't, license issues
 16 2017-01-27 00:23:11	0|sipa|you need to register for an mac developer account, i think
 17 2017-01-27 00:23:38	0|jtimon|I see, thanks again
 18 2017-01-27 00:54:31	0|michagogo|Yep
 19 2017-01-27 00:54:44	0|michagogo|You need to log into developer.apple.com
 20 2017-01-27 00:54:59	0|michagogo|(You don't need the $99 membership, a free account is enough)
 21 2017-01-27 00:55:28	0|michagogo|Then you need to download Xcode, and pull out the SDK directory from within that
 22 2017-01-27 00:55:53	0|michagogo|Unfortunately that can only be done (as of the last I heard) on a Mac
 23 2017-01-27 00:57:47	0|luke-jr|michagogo: I posted some doc to the git repo with non-Mac instructions IIRC
 24 2017-01-27 00:58:08	0|michagogo|Oh, really?
 25 2017-01-27 00:58:47	0|sipa|luke-jr: is it included in the bitcoin repo?
 26 2017-01-27 00:58:50	0|sipa|+core
 27 2017-01-27 00:59:12	0|luke-jr|https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.md
 28 2017-01-27 00:59:14	0|luke-jr|sipa: yes ^
 29 2017-01-27 00:59:23	0|luke-jr|"Alternatively, you can use 7zip and SleuthKit to extract the files one by one. The script contrib/macdeploy/extract-osx-sdk.sh automates this. First ensure the dmg file is in the current directory, and then run the script. You may wish to delete the intermediate 5.hfs file and MacOSX10.11.sdk (the directory) when you've confirmed the extraction succeeded." …
 30 2017-01-27 01:00:00	0|michagogo|Ah, yes
 31 2017-01-27 01:00:01	0|michagogo|https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/extract-osx-sdk.sh
 32 2017-01-27 01:00:04	0|michagogo|Nice!
 33 2017-01-27 01:01:34	0|michagogo|August?
 34 2017-01-27 01:01:35	0|sipa|luke-jr: ok, thanks
 35 2017-01-27 01:01:41	0|michagogo|Wow, I've been out of the loop for a long time.
 36 2017-01-27 01:01:49	0|sipa|luke-jr: i remember you finding this, but i wasn't aware it actually got pred
 37 2017-01-27 01:08:45	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9642: [Hardfork] Safe block size limit (06master...06bip-blksize) 02https://github.com/bitcoin/bitcoin/pull/9642
 38 2017-01-27 08:18:26	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9643: [refactor] Remove using namespace <xxx> from wallet/ & util* (06master...06no-using-namespace-wallet-util) 02https://github.com/bitcoin/bitcoin/pull/9643
 39 2017-01-27 09:09:57	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9644: [refactor] Remove using namespace <xxx> from src/ (06master...06no-using-namespace-src) 02https://github.com/bitcoin/bitcoin/pull/9644
 40 2017-01-27 09:23:06	0|Eliel_|25
 41 2017-01-27 10:34:52	0|rgrant|can someone point me at the function that backfills local blockchain blocks to include witness data if user upgrades to a segwit full node after segwit activation?
 42 2017-01-27 10:53:45	0|rgrant|it looks like BLOCK_OPT_WITNESS stores some activation data for the block, but it also looks like this is not queried to see if backfill is necessary.  i could also use some help tracking down what happens if a segwit-capable node only finds itself connected to non-segwit nodes while receiving a block.
 43 2017-01-27 13:17:59	0|sdaftuar|rgrant: see RewindBlockIndex, in validation.cpp (assuming you're looking at master)
 44 2017-01-27 13:28:00	0|sdaftuar|rgrant: after segwit activates, segwit-capable nodes will only attempt to download blocks from segwit-capable peers (which is why 0.13.1 introduced outbound peering logic that would specifically seek out segwit-capable peers)
 45 2017-01-27 13:47:45	0|rgrant|sdaftuar: thx!  it does use BLOCK_OPT_WITNESS, too.  not sure how i missed that in my search.
 46 2017-01-27 15:18:01	0|bitcoin-git|13bitcoin/06master 1404b8773 15Jonas Schnelli: [Qt] fix transaction details output-index to reflect vout index
 47 2017-01-27 15:18:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9b4d2673b775...d9e4d1d9fbd9
 48 2017-01-27 15:18:02	0|bitcoin-git|13bitcoin/06master 14d9e4d1d 15Wladimir J. van der Laan: Merge #9637: [Qt] fix transaction details output-index to reflect vout index...
 49 2017-01-27 15:18:21	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9637: [Qt] fix transaction details output-index to reflect vout index (06master...062017/01/qt_vout) 02https://github.com/bitcoin/bitcoin/pull/9637
 50 2017-01-27 15:33:40	0|bitcoin-git|13bitcoin/06master 14fab035f 15MarcoFalke: qa: Actually test assertions in pruning.py...
 51 2017-01-27 15:33:40	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d9e4d1d9fbd9...a7ea2f8fdbe9
 52 2017-01-27 15:33:41	0|bitcoin-git|13bitcoin/06master 14a7ea2f8 15Wladimir J. van der Laan: Merge #9638: qa: Actually test assertions in pruning.py...
 53 2017-01-27 15:33:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9638: qa: Actually test assertions in pruning.py (06master...06Mf1701-qaPruning_try) 02https://github.com/bitcoin/bitcoin/pull/9638
 54 2017-01-27 20:07:04	0|luke-jr|is anyone else working on #9493? (I wish github let us self-assign stuff..)
 55 2017-01-27 20:07:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/9493 | event_set_mem_functions is not available on all libevents · Issue #9493 · bitcoin/bitcoin · GitHub
 56 2017-01-27 20:19:49	0|BlueMatt|luke-jr: looks like not? its either you or cfields probably
 57 2017-01-27 20:20:23	0|cfields|luke-jr: last i looked you had a fix for it?
 58 2017-01-27 20:21:34	0|cfields|yea, i assumed that define was all it took. If there's more to it, i'm happy to take a look
 59 2017-01-27 20:32:12	0|luke-jr|it's probably not difficult, just didn't want to step on any toes
 60 2017-01-27 20:33:13	0|luke-jr|just gotta figure out how to indicate a skipped test I guess
 61 2017-01-27 22:07:48	0|BlueMatt|cfields: what do you want to do about hSocket?
 62 2017-01-27 22:08:02	0|cfields|BlueMatt: races, you mean?
 63 2017-01-27 22:08:05	0|BlueMatt|yes
 64 2017-01-27 22:08:13	0|BlueMatt|well "races"
 65 2017-01-27 22:08:17	0|BlueMatt|not that they actually are, but....
 66 2017-01-27 22:08:30	0|cfields|well, concurrent access
 67 2017-01-27 22:09:30	0|cfields|BlueMatt: going forward, it'll all be contained to one thread. So again, it's just a matter of what we do for 0.14
 68 2017-01-27 22:09:46	0|BlueMatt|it will?
 69 2017-01-27 22:09:52	0|BlueMatt|oh, you mean CloseSocketDisconnect will be? yea, ok
 70 2017-01-27 22:09:52	0|cfields|sec, taking a look. iirc it's mostly just disconnection that's problematic?
 71 2017-01-27 22:10:06	0|BlueMatt|its entirely only CloseSocketDisconnect thats problematic, iirc
 72 2017-01-27 22:11:23	0|cfields|oh, and optimistic sends
 73 2017-01-27 22:13:46	0|cfields|BlueMatt: with my async refactors, CloseSocketDisconnect always happens on the sockethandler thread, the others just set fDisconnect
 74 2017-01-27 22:14:09	0|BlueMatt|yea, ok, that sounds like what we /should/ do....but what about 0.14?
 75 2017-01-27 22:14:10	0|cfields|i wonder if we could do a simplified version of that for 0.14
 76 2017-01-27 22:14:15	0|BlueMatt|I havent looked, can we do that easily in 14?
 77 2017-01-27 22:15:39	0|cfields|uhmm, just looking at it quickly, it seems so
 78 2017-01-27 22:16:12	0|gmaxwell|if the behavior involved doesn't block, add a lock and move on.
 79 2017-01-27 22:16:46	0|BlueMatt|gmaxwell: might as well fix it right, though
 80 2017-01-27 22:18:35	0|cfields|BlueMatt: i think we'll still need a lock for the optimistic send :(
 81 2017-01-27 22:18:47	0|BlueMatt|oh valid point, yea, likely
 82 2017-01-27 22:19:04	0|BlueMatt|has anyone ever figured out how much optimistic send saves us?
 83 2017-01-27 22:19:19	0|BlueMatt|like, notifying the other thread and having it do the send is like a few extra syscalls
 84 2017-01-27 22:19:20	0|BlueMatt|so what
 85 2017-01-27 22:21:10	0|cfields|BlueMatt: i think the only downside is you can end up at the tail of the sendqueue for that loop as opposed to sending immediately
 86 2017-01-27 22:21:29	0|BlueMatt|"meh" ?
 87 2017-01-27 22:21:33	0|cfields|but with the locks cleaned up now, i doubt there's much consequence there
 88 2017-01-27 22:21:46	0|BlueMatt|oh, true, without the lock cleanups that would've been hell
 89 2017-01-27 22:21:55	0|cfields|BlueMatt: well i think that could've been substantial before, with a long hold on the send lock
 90 2017-01-27 22:21:59	0|BlueMatt|but, alright, lets call that a 0.15 optimization and just add a lock for 0.14?
 91 2017-01-27 22:22:34	0|cfields|BlueMatt: yes, afraid so :(
 92 2017-01-27 22:22:43	0|BlueMatt|ok, well shouldnt be a big deal
 93 2017-01-27 22:23:08	0|BlueMatt|if your send() is blocking, you have bigger problems :p
 94 2017-01-27 22:23:34	0|cfields|heh
 95 2017-01-27 22:23:53	0|cfields|true i suppose. Scope can basically be limited to send/recv/close, right?
 96 2017-01-27 22:24:06	0|BlueMatt|I'd hope so?
 97 2017-01-27 22:24:17	0|BlueMatt|I havent looked in a while
 98 2017-01-27 22:24:50	0|cfields|mm, worth looking at select/fd_set's safety guarantees
 99 2017-01-27 22:25:19	0|cfields|BlueMatt: heh, hint taken. I'll work up a patch for discussion.
100 2017-01-27 22:25:26	0|BlueMatt|are we close()ing in CloseSocketDisconnect, or just disconnect()?
101 2017-01-27 22:25:31	0|BlueMatt|sorry, wasnt a hint, just saying
102 2017-01-27 22:26:24	0|BlueMatt|oh, hum, we are
103 2017-01-27 22:26:26	0|BlueMatt|yea, that sucks
104 2017-01-27 22:26:33	0|cfields|close/closesocket
105 2017-01-27 22:28:02	0|BlueMatt|cfields: ouch, yea, then maybe we do need the full patch now, then
106 2017-01-27 22:28:16	0|BlueMatt|to avoid calling CloseSocketDisconnect on any thread but ThreadSocketHandler
107 2017-01-27 22:28:48	0|BlueMatt|hum...orrrr...no, because select will just return and we'll still get the lock when we recv or send?
108 2017-01-27 22:28:58	0|BlueMatt|i mean i guess it should be fine, but might prefer not to?
109 2017-01-27 22:40:15	0|cfields|BlueMatt: just for the sake of covering all angles... this concurrent access isn't new, right? much more likely maybe, but i'm pretty sure this has always been the case
110 2017-01-27 22:42:00	0|BlueMatt|yes, I believe this is very, very, very old
111 2017-01-27 22:42:12	0|BlueMatt|but havent gone back to make sure