Transcript for #bitcoin-dev 2017/07/27

00:11 Chicago volure, Have a start by consuming the BIP9, BIP91 and BIP141 material at
00:13 volure Thanks :)
00:17 Chicago volure, What you learn is that BIP9 is the legacy method for implementing a soft fork using block version bits and that the original Segwit proposal on BIP141 was using it -- and then later when you get a bit deeper into things; what you'll find about BIP91 is that is a 51% attack by mining operators to reject blocks which do not contain a specific bit enabled in the version field -- effectively using their majority to advance the BIP141
00:17 Chicago proposal despite its original 95% signaling requirement.
00:30 volure I see.
00:32 volure So does that mean that 51% of the mining community would have to go rogue and install a version that specifically blocked BIP141 or is this something that could happen just by not upgrading to the latest version.
00:35 Chicago volure, Their segsignal version of Core v0.14.2 which has the BIP91 support will effectively operate the same as Core v0.14.2 with the exception of producing blocks which have the block version 4 bit enabled so that BIP91 could have been activated and (now) enforced. Basically, there wouldn't be a problem until if and when the majority mining operators decide to stop making BIP91 blocks before BIP141
00:35 volure sorry. Specifically blocked BIP 91....
00:35 Chicago gets activated and enforced on the Main network.
00:36 volure But that would be an intentional process needing 51% support of miners.
00:36 Chicago So during the interim, users on Core v0.14.2 will be able to complete block verification on both BIP91 and !BIP91 blocks (is compatible).
00:37 volure Is there a window where that would no longer be a threat ?
00:39 Chicago volure, no promises of course -- but generally accepted philosophy is that when the BIP141 enforcement happens sometime after the first week of August, then the Bitcoin chain on the main network will have achieved its scaling goal with Segwit. --- After that point of things get wonky and majority mining operators choose to follow different consensus rules -- there will have to be decisions made to be able to ensure blocks are generated on
00:39 Chicago schedule with the target.
00:40 Chicago For the time being, it is rational to run a segsignal node so that we're relaying blocks which will lead to BIP141 activation/enforcement.
00:40 volure I guess what I am getting at is. If this is a conscious decision that 51% of the community has to make or if this is something that could organically happen within the network just by late adoption.
00:42 volure I have this interest because I am running a full node myself. And I dont want to unintentionally/unwittingly aid in the split
00:42 Chicago depends which potential fork / threat you're referring to really -- there is more than one activist group seeking to change consensus rules and fork the Main chain
00:43 volure haha. I guess that is true enough.
00:44 Chicago Like I said, a segsignal node makes sense until BIP141 gets enforced on the Main chain.
00:45 volure is there something special that needs to be setup for a segsignal node ?
00:46 Chicago It builds just like the Core wallet and AFAIK from running one here, no additional changes are required. The way I'm doing it is described here:
02:05 melik hey midnightmagic you around ?
02:06 midnightmagic melik: Yes, sir.
02:06 melik i had a question about the release process
02:07 melik and noticed that you participate in the gitian builds
02:07 melik so you'd probably know :P
02:08 melik Only once the Windows/OS X builds each have 3 matching signatures may they be signed with their respective release keys.
02:09 melik is this process automated? (the detached-sig creation/signing)
02:09 melik or ergh specifically here: Detached signatures will then be committed to the bitcoin-detached-sigs repository, which can be combined with the unsigned apps to create signed binaries.
02:10 melik how are the 'detached' signatures created ?
02:16 melik midnightmagic: i'll be back, sorry gotta run
02:16 melik emergency
02:17 midnightmagic melik: The detached-sig process is done by one of the release types who controls the "official" keys. The binary signatures (separate from the gitian sigs) are then separated from the original bins, and provided for us gitian builders in a separate tarball.
02:17 midnightmagic melik.. argh
04:10 Mad7Scientist Feature request: add an option to warn the user when a the number of bitcoins which are not backed up exceeds the amount set by the user. The user can manually mark when a wallet.dat is backed up or if it is backed up through the application it will be marked as backed up. For instance, if the maximum non backed up is set to .5 BTC, then if a user backs up his wallet then sends 2 BTC somewhere and it was drawn from a 3BTC
04:10 Mad7Scientist transaction, that sends 1 BTC back home and now 1 BTC is not backed up in the wallet and the user is notified.
07:10 melik midnightmagic: im back :) if youre still around
07:29 midnightmagic melik: hello
07:29 melik midnightmagic: sorry, about askign a question and running off
07:29 melik so basically the codesigner carries the secret official keys
07:30 melik and he just verifies that there were builds from multiple people and that their checksums all match
07:30 midnightmagic melik: The detached-sig process is done by one of the release types who controls the "official" keys. The binary signatures (separate from the gitian sigs) are then separated from the original bins, and provided for us gitian builders in a separate tarball. They maintain build purity by ensuring that we can not only build the binaries themselves, but also use the detached signatures and combine
07:30 melik then he signs them and releases the signed signatures
07:30 midnightmagic them with the code in a non-modifying way, ensuring that both pre-signature, and post-signature, we have the same binaries as everyone else doing the gitian signatures.
07:30 midnightmagic melik: In this way, the *signed* binaries are entirely irrelevant.
07:31 midnightmagic melik: No. The *signature* process can be done by anybody, due to the distribution of trust out to the gitian builds and builders.
07:32 midnightmagic melik: You could even do a gitian build, and then take the detached signatures, satisfy yourself that the process of combining signature with the gitian build is safely done in a non-code-modifying way, and arrive at exactly the files that are them distributed to the public via
07:33 melik i get it, but i
07:33 melik i'm still not understanding where the detached signatures come from :(
07:35 midnightmagic melik: I think cfields.. or someone.. signs the built binaries with a code-signing key. On OS/X for example, it's just a developer account with Apple. I don't know what's what with Windows. Xcode allows you to use an active developer key to perform a binary signature process.
07:35 midnightmagic melik: The code-signing key and the process of signing code (on OS/X) is pretty much just clicking a menu item in Xcode. Or.. I guess however cfields does it. There's also a command-line for it.
07:36 midnightmagic melik: The point is, all of that is irrelevant. The signed code just means the bin can run without a warning on OS/X -- same as every other signed binary.
07:38 melik midnightmagic: cool, makes sense
07:39 melik i thought that piece was dependant on the sigs from the gitian build process
07:42 midnightmagic melik: The gitian signers themselves verify (or should verify) the other gitian sigs as part of the build process, and if any don't match, they should report it. I do.
07:43 melik midnightmagic: assuming if one wanted to participate in this
07:43 melik how does one go about doing it :P
07:43 melik im assuming the more builders, the better
07:47 midnightmagic melik: Yes. The more, and the more distributed, the builders, the better for everyone. You can participate in it by creating a build machine, so, some VM image tools and so forth, and then just running gitian itself. I personally use a build script to run the build scripts. :-) If you like I can put a gist up or something.
07:48 midnightmagic melik: Presumably you know how to use git, and github, and to submit merge requests?
07:48 melik midnightmagic: yes, i just finished setting up my gitian server
07:51 midnightmagic melik: I personally use LXC for it, as I find the KVM process is a little heavier.
07:52 midnightmagic melik: setup in my env which affects the build process:
07:52 midnightmagic declare -x GITIAN_HOST_IP=""
07:52 melik midnightmagic: yeah i just pretty much used the documentation
07:53 midnightmagic MIRROR_HOST=""; MIRROR_HOST_ON_GUEST=""; USE_LXC=1;
07:53 melik ergh instructions from the documetnation*
07:53 melik haha
07:53 melik you automated everything via this script
07:53 melik neat :)
07:54 midnightmagic melik: Subsequently, clone the gitian.sigs repository from the bitcoin github tree, and once you build and arrive at your sigs, submit to your fork, (sign everything including your git commit) and then open a PR. presto.
07:54 melik aye, sweet stuff midnightmagic
07:54 midnightmagic melik: Make very sure you're following the same *format* of the gitian.sigs repository, so you don't for example have a leading 'v' in it and stuff.
07:54 melik yep
07:54 melik absolutely
07:55 midnightmagic yeah man, join the gitian trust. :) the more the merrier.
07:55 melik thanks so much for your help midnightmagic
07:55 melik i'm not a good dev, so can't help out in development
07:56 melik but i can help out with building :-)
08:11 midnightmagic melik: cool beans. Keep an eye on release announcements so you can sync your gitian builds. A problem I've discovered in the past is that building old versions can cause issues. :(