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)
jtimon: because the signed ones require a key that is not public
so people can build the unsigned one, compare results, then the person with the key can produce the detached signatures
and then people can build the signed one from the earlier unsigned result plus downloaded detached signature
I am proud to work with people who come up with such slick procedures. :)
why do the signed ones require a key that's not public?
jtimon: signed in this case refers to the windows and apple code signing keys.
which are used to prevent ugly warning boxes on those OSes.
"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." …
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?
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.
rgrant: see RewindBlockIndex, in validation.cpp (assuming you're looking at master)
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)
sdaftuar: thx! it does use BLOCK_OPT_WITNESS, too. not sure how i missed that in my search.