1 2017-07-27 00:11:43 <Chicago> volure, Have a start by consuming the BIP9, BIP91 and BIP141 material at https://github.com/bitcoin/bips
 2 2017-07-27 00:13:57 <volure> Thanks :)
 3 2017-07-27 00:17:32 <Chicago> proposal despite its original 95% signaling requirement.
 4 2017-07-27 00:17:32 <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
 5 2017-07-27 00:30:36 <volure> I see.
 6 2017-07-27 00:32:58 <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.
 7 2017-07-27 00:35:11 <Chicago> gets activated and enforced on the Main network.
 8 2017-07-27 00:35:11 <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.  https://github.com/segsignal/bitcoin  Basically, there wouldn't be a problem until if and when the majority mining operators decide to stop making BIP91 blocks before BIP141
 9 2017-07-27 00:35:11 <volure> sorry. Specifically blocked BIP 91....
10 2017-07-27 00:36:44 <volure> But that would be an intentional process needing 51% support of miners.
11 2017-07-27 00:36:50 <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).
12 2017-07-27 00:37:03 <volure> Is there a window where that would no longer be a threat ?
13 2017-07-27 00:39:00 <Chicago> schedule with the target.
14 2017-07-27 00:39:00 <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
15 2017-07-27 00:40:31 <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.
16 2017-07-27 00:40:37 <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.
17 2017-07-27 00:42:03 <volure> I have this interest because I am running a full node myself. And I dont want to unintentionally/unwittingly aid in the split
18 2017-07-27 00:42:19 <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
19 2017-07-27 00:43:00 <volure> haha. I guess that is true enough.
20 2017-07-27 00:44:01 <Chicago> Like I said, a segsignal node makes sense until BIP141 gets enforced on the Main chain.
21 2017-07-27 00:45:13 <volure> is there something special that needs to be setup for a segsignal node ?
22 2017-07-27 00:46:29 <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:  https://bitcointalk.org/index.php?topic=2039934.msg20306552#msg20306552
23 2017-07-27 02:05:35 <melik> hey midnightmagic you around ?
24 2017-07-27 02:06:35 <midnightmagic> melik: Yes, sir.
25 2017-07-27 02:06:46 <melik> i had a question about the release process
26 2017-07-27 02:07:01 <melik> and noticed that you participate in the gitian builds
27 2017-07-27 02:07:07 <melik> so you'd probably know :P
28 2017-07-27 02:08:28 <melik> Only once the Windows/OS X builds each have 3 matching signatures may they be signed with their respective release keys.
29 2017-07-27 02:09:05 <melik> is this process automated? (the detached-sig creation/signing)
30 2017-07-27 02:09:59 <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.
31 2017-07-27 02:10:07 <melik> how are the 'detached' signatures created ?
32 2017-07-27 02:16:41 <melik> midnightmagic: i'll be back, sorry gotta run
33 2017-07-27 02:16:42 <melik> emergency
34 2017-07-27 02:17:41 <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.
35 2017-07-27 02:17:46 <midnightmagic> melik..  argh
36 2017-07-27 04:10:15 <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
37 2017-07-27 04:10:15 <Mad7Scientist> transaction, that sends 1 BTC back home and now 1 BTC is not backed up in the wallet and the user is notified.
38 2017-07-27 07:10:45 <melik> midnightmagic: im back :) if youre still around
39 2017-07-27 07:29:27 <midnightmagic> melik: hello
40 2017-07-27 07:29:45 <melik> midnightmagic: sorry, about askign a question and running off
41 2017-07-27 07:29:57 <melik> so basically the codesigner carries the secret official keys
42 2017-07-27 07:30:26 <melik> and he just verifies that there were builds from multiple people and that their checksums all match
43 2017-07-27 07:30:42 <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
44 2017-07-27 07:30:45 <melik> then he signs them and releases the signed signatures
45 2017-07-27 07:30:49 <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.
46 2017-07-27 07:30:58 <midnightmagic> melik: In this way, the *signed* binaries are entirely irrelevant.
47 2017-07-27 07:31:27 <midnightmagic> melik: No. The *signature* process can be done by anybody, due to the distribution of trust out to the gitian builds and builders.
48 2017-07-27 07:32:38 <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 bitcoin.org.
49 2017-07-27 07:33:16 <melik> i get it, but i
50 2017-07-27 07:33:27 <melik> i'm still not understanding where the detached signatures come from :(
51 2017-07-27 07:35:00 <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.
52 2017-07-27 07:35:51 <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.
53 2017-07-27 07:36:20 <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.
54 2017-07-27 07:38:57 <melik> midnightmagic: cool, makes sense
55 2017-07-27 07:39:27 <melik> i thought that piece was dependant on the sigs from the gitian build process
56 2017-07-27 07:42:52 <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.
57 2017-07-27 07:43:33 <melik> midnightmagic: assuming if one wanted to participate in this
58 2017-07-27 07:43:40 <melik> how does one go about doing it :P
59 2017-07-27 07:43:59 <melik> im assuming the more builders, the better
60 2017-07-27 07:47:04 <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.
61 2017-07-27 07:48:04 <midnightmagic> melik: Presumably you know how to use git, and github, and to submit merge requests?
62 2017-07-27 07:48:26 <melik> midnightmagic: yes, i just finished setting up my gitian server
63 2017-07-27 07:51:03 <midnightmagic> melik: I personally use LXC for it, as I find the KVM process is a little heavier. https://gist.github.com/midnightmagic/143525b14877d73edc4cd1e213267d39
64 2017-07-27 07:52:24 <midnightmagic> melik: setup in my env which affects the build process:
65 2017-07-27 07:52:26 <midnightmagic> declare -x GITIAN_HOST_IP="10.0.3.1"
66 2017-07-27 07:52:45 <melik> midnightmagic: yeah i just pretty much used the documentation
67 2017-07-27 07:53:08 <midnightmagic> MIRROR_HOST="10.0.3.1"; MIRROR_HOST_ON_GUEST="10.0.3.1"; USE_LXC=1;
68 2017-07-27 07:53:11 <melik> ergh instructions from the documetnation*
69 2017-07-27 07:53:50 <melik> haha
70 2017-07-27 07:53:56 <melik> you automated everything via this script
71 2017-07-27 07:53:59 <melik> neat :)
72 2017-07-27 07:54:10 <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.
73 2017-07-27 07:54:42 <melik> aye, sweet stuff midnightmagic
74 2017-07-27 07:54:42 <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.
75 2017-07-27 07:54:48 <melik> yep
76 2017-07-27 07:54:50 <melik> absolutely
77 2017-07-27 07:55:12 <midnightmagic> yeah man, join the gitian trust. :) the more the merrier.
78 2017-07-27 07:55:27 <melik> thanks so much for your help midnightmagic
79 2017-07-27 07:55:51 <melik> i'm not a good dev, so can't help out in development
80 2017-07-27 07:56:05 <melik> but i can help out with building :-)
81 2017-07-27 08:11:39 <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. :(