< 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)
< sipa>
jtimon: because the signed ones require a key that is not public
< sipa>
so people can build the unsigned one, compare results, then the person with the key can produce the detached signatures
< sipa>
and then people can build the signed one from the earlier unsigned result plus downloaded detached signature
< gmaxwell>
I am proud to work with people who come up with such slick procedures. :)
< jtimon>
why do the signed ones require a key that's not public?
< gmaxwell>
jtimon: signed in this case refers to the windows and apple code signing keys.
< gmaxwell>
which are used to prevent ugly warning boxes on those OSes.
< 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." …
< bitcoin-git>
[bitcoin] kallewoof opened pull request #9643: [refactor] Remove using namespace <xxx> from wallet/ & util* (master...no-using-namespace-wallet-util) https://github.com/bitcoin/bitcoin/pull/9643
< bitcoin-git>
[bitcoin] kallewoof opened pull request #9644: [refactor] Remove using namespace <xxx> from src/ (master...no-using-namespace-src) https://github.com/bitcoin/bitcoin/pull/9644
< Eliel_>
25
< 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?
< 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.
< sdaftuar>
rgrant: see RewindBlockIndex, in validation.cpp (assuming you're looking at master)
< 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)
< rgrant>
sdaftuar: thx! it does use BLOCK_OPT_WITNESS, too. not sure how i missed that in my search.
< BlueMatt>
luke-jr: looks like not? its either you or cfields probably
< cfields>
luke-jr: last i looked you had a fix for it?
< cfields>
yea, i assumed that define was all it took. If there's more to it, i'm happy to take a look
< luke-jr>
it's probably not difficult, just didn't want to step on any toes
< luke-jr>
just gotta figure out how to indicate a skipped test I guess
< BlueMatt>
cfields: what do you want to do about hSocket?
< cfields>
BlueMatt: races, you mean?
< BlueMatt>
yes
< BlueMatt>
well "races"
< BlueMatt>
not that they actually are, but....
< cfields>
well, concurrent access
< 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
< BlueMatt>
it will?
< cfields>
sec, taking a look. iirc it's mostly just disconnection that's problematic?
< BlueMatt>
oh, you mean CloseSocketDisconnect will be? yea, ok
< BlueMatt>
its entirely only CloseSocketDisconnect thats problematic, iirc
< cfields>
oh, and optimistic sends
< cfields>
BlueMatt: with my async refactors, CloseSocketDisconnect always happens on the sockethandler thread, the others just set fDisconnect
< BlueMatt>
yea, ok, that sounds like what we /should/ do....but what about 0.14?
< cfields>
i wonder if we could do a simplified version of that for 0.14
< BlueMatt>
I havent looked, can we do that easily in 14?
< cfields>
uhmm, just looking at it quickly, it seems so
< gmaxwell>
if the behavior involved doesn't block, add a lock and move on.
< BlueMatt>
gmaxwell: might as well fix it right, though
< cfields>
BlueMatt: i think we'll still need a lock for the optimistic send :(
< BlueMatt>
oh valid point, yea, likely
< BlueMatt>
has anyone ever figured out how much optimistic send saves us?
< BlueMatt>
like, notifying the other thread and having it do the send is like a few extra syscalls
< BlueMatt>
so what
< 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
< BlueMatt>
"meh" ?
< cfields>
but with the locks cleaned up now, i doubt there's much consequence there
< BlueMatt>
oh, true, without the lock cleanups that would've been hell
< cfields>
BlueMatt: well i think that could've been substantial before, with a long hold on the send lock
< BlueMatt>
but, alright, lets call that a 0.15 optimization and just add a lock for 0.14?
< cfields>
BlueMatt: yes, afraid so :(
< BlueMatt>
ok, well shouldnt be a big deal
< BlueMatt>
if your send() is blocking, you have bigger problems :p
< cfields>
heh
< cfields>
true i suppose. Scope can basically be limited to send/recv/close, right?
< BlueMatt>
I'd hope so?
< BlueMatt>
I havent looked in a while
< cfields>
mm, worth looking at select/fd_set's safety guarantees
< cfields>
BlueMatt: heh, hint taken. I'll work up a patch for discussion.
< BlueMatt>
are we close()ing in CloseSocketDisconnect, or just disconnect()?
< BlueMatt>
sorry, wasnt a hint, just saying
< BlueMatt>
oh, hum, we are
< BlueMatt>
yea, that sucks
< cfields>
close/closesocket
< BlueMatt>
cfields: ouch, yea, then maybe we do need the full patch now, then
< BlueMatt>
to avoid calling CloseSocketDisconnect on any thread but ThreadSocketHandler
< BlueMatt>
hum...orrrr...no, because select will just return and we'll still get the lock when we recv or send?
< BlueMatt>
i mean i guess it should be fine, but might prefer not to?
< 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
< BlueMatt>
yes, I believe this is very, very, very old