1 2017-02-27 00:17:31	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9868: Abstract out the command line options for block assembly (06master...06assembleroptions) 02https://github.com/bitcoin/bitcoin/pull/9868
  2 2017-02-27 00:26:00	0|bitcoin-git|[13bitcoin] 15RHavar opened pull request #9869: Move comment to right spot (06master...06comment) 02https://github.com/bitcoin/bitcoin/pull/9869
  3 2017-02-27 00:48:33	0|rgrant|if a guard node can protect old mining infrastructure, then nothing that old mining software normally produces makes its blocks invalid.  but since segwit scripts are spendable by anyone according to the old rules, some non-segwit blocks must be reliably orphaned, should an attacker get hold of segwit "anyonecanspend" transactions and mine them to different outputs (again, under the old rules).  w
  4 2017-02-27 00:48:39	0|rgrant|here in the code is this tension resolved?
  5 2017-02-27 00:56:54	0|sipa|rgrant: segwit transactions are non-standard to old nodes
  6 2017-02-27 00:57:45	0|sipa|so unless the old miners intentionally bypass those checks, they'll never produce segwit-invalid blocks (but they might build on top of a segwit-invalid block that someone else produced)
  7 2017-02-27 00:58:26	0|rgrant|yes, this describes an attack.  but what makes the attack block invalid?
  8 2017-02-27 00:58:46	0|sipa|to whom?
  9 2017-02-27 00:59:21	0|rgrant|to segwit-enabled nodes and miners
 10 2017-02-27 00:59:35	0|sipa|the segwit consensus rules?
 11 2017-02-27 01:00:12	0|sipa|in script/interpreter.h there is a flag SCRIPT_VERIFY_WITNESS
 12 2017-02-27 01:00:34	0|sipa|the block validation code passes this flag to the script execution code when it's invoked for a block that has BIP9 activation
 13 2017-02-27 01:01:40	0|sipa|and there is conditional code that executes after the normal script execution in that case, which may fail the execution even though the normal execution succeeded
 14 2017-02-27 01:01:50	0|rgrant|but the attacker doesn't set bip9 (though bip9 has activated)
 15 2017-02-27 01:02:07	0|sipa|yes
 16 2017-02-27 01:02:19	0|sipa|that doesn't matter
 17 2017-02-27 01:02:33	0|sipa|bip9 activation isn't dependent on the signalling of the block itself
 18 2017-02-27 01:02:42	0|sipa|only on the signalling in the chain's history
 19 2017-02-27 01:07:02	0|rgrant|right.  so segwit has activated, and attacker mines this bad block that rewrites a segwit transaction that otherwise hasn't made it into a block yet.  and i'm here in interpreter.cpp VerifyScript, where in my case i believe emptyWitness will be used.
 20 2017-02-27 01:08:48	0|sipa|what do you mean by rewrites?
 21 2017-02-27 01:09:35	0|rgrant|well, attacker wants to use the "anyonecanspend" interpretation of the segwit tx, under the old rules.
 22 2017-02-27 01:10:00	0|rgrant|so they just thorw away the witness
 23 2017-02-27 01:11:44	0|sipa|ah
 24 2017-02-27 01:12:19	0|sipa|under segwit rules, a segwit output can only be spent by an input that has a witness
 25 2017-02-27 01:12:38	0|sipa|the attacker can't control whether the witness flag is set in other nodes
 26 2017-02-27 01:13:09	0|rgrant|is that over in CheckInputs?
 27 2017-02-27 01:13:17	0|sipa|no, in the script code
 28 2017-02-27 01:13:49	0|sipa|in the case an attacker removes the witness from the spending input, you'll still call validation with the witness flag set
 29 2017-02-27 01:14:15	0|sipa|and the script execution will fail if it's a witness output that is being spent withoit having a witness
 30 2017-02-27 01:14:58	0|rgrant|okay, i get the mechanism.  now i'm still trying to hunt down the code.
 31 2017-02-27 01:15:59	0|rgrant|(also, does this make segwit outputs viral?)
 32 2017-02-27 01:16:48	0|rgrant|wait, the input block needs to have a witness, or the input script?
 33 2017-02-27 01:21:54	0|sipa|the txin spending a witness output has to have a txinwitness
 34 2017-02-27 01:22:19	0|sipa|which implies that the block that that txin is in must be a witness block
 35 2017-02-27 01:23:09	0|rgrant|thanks.  and it can be spent to any address.  it's not viral.
 36 2017-02-27 01:23:24	0|sipa|right, the outputs don't care
 37 2017-02-27 01:31:37	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9871: [RFC] Add a tree sha512 hash to merge commits (06master...06merge_sha512) 02https://github.com/bitcoin/bitcoin/pull/9871
 38 2017-02-27 03:44:38	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9872: [qa] Multi-chain support in test framework (06master...06qa-multi-chain-support) 02https://github.com/bitcoin/bitcoin/pull/9872
 39 2017-02-27 03:45:12	0|gmaxwell|luke-jr: are you going to rebase the remaining multiwallet support now that 0.15 has started?
 40 2017-02-27 03:45:30	0|luke-jr|gmaxwell: again? I just did yesterday O.o
 41 2017-02-27 03:46:15	0|gmaxwell|oh sorry!
 42 2017-02-27 03:46:17	0|luke-jr|hmm, I wonder why Travis is whining
 43 2017-02-27 03:48:35	0|gmaxwell|s/are you going to rebase/are you going to fix the travis errors/  :P
 44 2017-02-27 03:49:35	0|luke-jr|yes ;)
 45 2017-02-27 03:50:14	0|luke-jr|assuming it's not yet another false positive anyway
 46 2017-02-27 05:26:18	0|dcousens|petertodd: lol,  I guess I'll sit this one out then :)
 47 2017-02-27 05:27:22	0|dcousens|Did seem difficult to find documentation/material on what you two are referring too though
 48 2017-02-27 05:32:19	0|sipa|likewise
 49 2017-02-27 05:32:29	0|sipa|i was confused by the same SE answer :)
 50 2017-02-27 05:33:24	0|achow101|dcousens: sipa: solution - dig through git's source code: https://github.com/git/git/blob/master/gpg-interface.c#L153
 51 2017-02-27 05:34:20	0|sipa|cool
 52 2017-02-27 05:34:26	0|dcousens|cheers achow101
 53 2017-02-27 05:46:37	0|sipa|achow101: it's not perfect w.r.t. the commit, only for the tree
 54 2017-02-27 05:46:57	0|sipa|so an attack on the commit's claimed history would still apply
 55 2017-02-27 05:48:54	0|achow101|sipa: you mean like if someone faked a commit history with a colliding parent commit hash?
 56 2017-02-27 05:49:47	0|sipa|yes, and the same resulting tree
 57 2017-02-27 05:50:16	0|sipa|which is certainly much less worrying
 58 2017-02-27 05:50:29	0|achow101|ok. but isn't the point to make sure the tree is the right tree and not some colliding tree?
 59 2017-02-27 05:51:10	0|sipa|well a commit object in git is both a resulting tree and a history for it
 60 2017-02-27 05:51:34	0|sipa|with this method we're only avoiding SHA1 for the tree
 61 2017-02-27 05:52:39	0|achow101|right.
 62 2017-02-27 05:56:51	0|achow101|another thought: the client version contains part of the commit hash (at least for master). should that be changed to be the sha256 hash instead?
 63 2017-02-27 05:57:13	0|sipa|interesting idea
 64 2017-02-27 05:58:33	0|achow101|actually that only happens on builds of master, not any of the releases, so not particularly important
 65 2017-02-27 06:17:18	0|wumpus|it's part of the commit id - which is there to be able to look up the right revision for troubleshooting. It's not there for security. Please don't replace it with anything else.
 66 2017-02-27 06:19:45	0|achow101|wumpus: ok
 67 2017-02-27 06:55:09	0|dcousens|wumpus: true, nevermind
 68 2017-02-27 06:59:18	0|dcousens|wumpus: my point for the for loop counter was more as a standard, use of `size_t` is the recommended type for when dealing with indexes... while I totally agree this is suitable as `unsigned int`, it was more of a standard
 69 2017-02-27 06:59:24	0|dcousens|(e.g https://stackoverflow.com/questions/1951519/when-should-i-use-stdsize-t)
 70 2017-02-27 07:01:50	0|wumpus|it just doesn't matter here
 71 2017-02-27 07:02:21	0|dcousens|wumpus: *shrug*, I know, just new code, might as well avoid issues if somehow this gets pulled out later to some generic function blah blah
 72 2017-02-27 07:03:02	0|dcousens|not worth discussing any further :)
 73 2017-02-27 07:03:20	0|wumpus|this was meant as a quick fix to get an compileissue out of the way
 74 2017-02-27 07:03:24	0|wumpus|indeed, no need to drag it out
 75 2017-02-27 07:08:45	0|wumpus|whoa, did I still manage to make it fail travis?
 76 2017-02-27 07:09:08	0|wumpus|oh the "recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed." issue again, unrelated
 77 2017-02-27 07:11:10	0|wumpus|I'm in good company, even "move comment" pulls fail
 78 2017-02-27 07:11:21	0|dcousens|ha
 79 2017-02-27 07:22:21	0|wumpus|looks like there is another intermittent travis issue: timeouts in make check (probably test_bitcoin related too)
 80 2017-02-27 07:27:08	0|gmaxwell|test_bitcoin is really slow...
 81 2017-02-27 07:28:12	0|wumpus|well it hangs *before* the "N testcases" line... it's not supposed to spend *any* time there
 82 2017-02-27 07:29:28	0|wumpus|still haven't managed to catch the test_bitcoin mutex issue, this may be a different symptom of it
 83 2017-02-27 07:33:53	0|wumpus|this is making travis as good as useless
 84 2017-02-27 07:36:05	0|gmaxwell|maybe we need to start making PRs with most of test_bitcoin commented out?
 85 2017-02-27 07:37:01	0|wumpus|the problem is that it happens during initialization, not during run of the tests. So we'd need to be commenting out global variables and such
 86 2017-02-27 07:37:44	0|wumpus|bisecting might work, though that's difficult with unrelabile reprodicibility
 87 2017-02-27 07:38:01	0|wumpus|e.g. go way back and find the commit where this started
 88 2017-02-27 07:38:55	0|wumpus|the funny thing is that #9851 is passing every single time now that I added debug information
 89 2017-02-27 07:38:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9851 | [do not merge] travis gdb parachute for #9825 by laanwj · Pull Request #9851 · bitcoin/bitcoin · GitHub
 90 2017-02-27 07:39:08	0|gmaxwell|it fails enough perhaps that just retrying each step 5 times might be enough.
 91 2017-02-27 07:39:10	0|wumpus|if that's not a classic example of a heisenbug I don't know
 92 2017-02-27 07:40:28	0|wumpus|it seems to fail in runs, I wonder if it somehow gets cached on a PR
 93 2017-02-27 07:40:55	0|wumpus|I suppose that makes sense it it's something the C compiler/ linker does - ccache caches things, which are re-used next time
 94 2017-02-27 07:46:47	0|bitcoin-git|13bitcoin/06master 14864890a 15Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
 95 2017-02-27 07:46:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6206252e5073...c7e57ce98154
 96 2017-02-27 07:46:48	0|bitcoin-git|13bitcoin/06master 14c7e57ce 15Wladimir J. van der Laan: Merge #9839: [qa] Make import-rescan.py watchonly check reliable...
 97 2017-02-27 07:47:18	0|wumpus|if it's really an initialization order fiasco, the root cause for sometimes failing could be randomization in e.g. the linker or compiler with regard to what gets put where
 98 2017-02-27 07:52:08	0|wumpus|cfields: is it possible to download a PR's cache remotely?
 99 2017-02-27 08:04:29	0|bitcoin-git|13bitcoin/060.14 14eddaa6b 15Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
100 2017-02-27 08:04:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/eddaa6b35d41aefead1a57ea54e7e15ce069f79a
101 2017-02-27 08:04:35	0|wumpus|hm no, never mind, I don't think that's going to help at all either...
102 2017-02-27 08:21:55	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9873: [do not merge] upload test_bitcoin executable for #9825 (06master...062017_02_travis_upload) 02https://github.com/bitcoin/bitcoin/pull/9873
103 2017-02-27 09:45:25	0|wumpus|awesome, I started debugging #9825 again and all pulls start passing! Start observing and the bug goes away, stop looking and it comes back. The unobserved state is a fog of probabilities, a window of and for error.  *wheee*
104 2017-02-27 09:45:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/9825 | Intermittent FAIL: test/test_bitcoin in Travis · Issue #9825 · bitcoin/bitcoin · GitHub
105 2017-02-27 10:34:16	0|Victorsueca|wumpus: it's a quantum bug
106 2017-02-27 10:46:21	0|luke-jr|ew, we were using printf for hex strings?
107 2017-02-27 11:06:21	0|wumpus|yes, fairly sure that code is inherited from satoshi
108 2017-02-27 11:18:34	0|luke-jr|can someone restart the two non-passing https://travis-ci.org/bitcoin/bitcoin/builds/205383975 ?
109 2017-02-27 11:18:39	0|luke-jr|I can't see any issue to fix
110 2017-02-27 11:23:22	0|wumpus|sure...
111 2017-02-27 11:23:32	0|wumpus|Victorsueca: either that or we need an exorcist
112 2017-02-27 11:24:43	0|wumpus|luke-jr: this doesn't seem the typical issue "test/rpc_tests.cpp(73): error: in "rpc_tests/rpc_rawparams": unexpected exception thrown by CallRPC(std::string("signrawtransaction ")+rawtx)"
113 2017-02-27 11:24:58	0|luke-jr|I can't reproduce it :/
114 2017-02-27 11:25:22	0|Victorsueca|maybe the code is ok and the problem is at travis?
115 2017-02-27 11:25:56	0|wumpus|luke-jr: restarting it...
116 2017-02-27 11:26:19	0|wumpus|Victorsueca: it's possible, though that doesn't explain why it always fails in the same (or similar) place
117 2017-02-27 11:27:34	0|Victorsueca|so either the code is bad or travis is using some non-standard compiler that throws shit at the fan when it hits that part
118 2017-02-27 11:27:41	0|luke-jr|hmm, I wonder..
119 2017-02-27 11:29:34	0|wumpus|it should be using stock trusty gcc - but yes it seems some non-determinism/randomization in the compiler is causing a bad test_bitcoin sometimes
120 2017-02-27 11:41:11	0|luke-jr|is wallet_tests/rescan really acceptable? it's assigning pwalletMain for a test to a stack variable, and leaving it there?
121 2017-02-27 12:09:17	0|wumpus|luke-jr: it'd be cleaner to reset it to NULL at the end of the test. Hopefully, though, that whole nonsense can go away when there's a better way to pass in the wallet via RPC context
122 2017-02-27 12:10:23	0|luke-jr|I wonder if that's the cause - signrawtransaction can use the wallet when available
123 2017-02-27 12:10:27	0|wumpus|but yes any test after that that assumes pwalletMain is set to something will crash or do bad things
124 2017-02-27 12:10:36	0|luke-jr|I just can't reproduce to confirm
125 2017-02-27 12:10:57	0|wumpus|yes, thinking about it - WalletTestingSetup sets up pwalletMain. Setting it to NULL would be bad too, it needs to be restored to its original value?
126 2017-02-27 12:11:19	0|wumpus|yes, you might be on to something
127 2017-02-27 12:12:06	0|wumpus|the next test using the walletMain after that will corrupt
128 2017-02-27 12:12:16	0|wumpus|+the stack
129 2017-02-27 12:16:46	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9875: tests: Fix dangling pwalletMain pointer in wallet tests (06master...062017_02_wallet_test_dangle) 02https://github.com/bitcoin/bitcoin/pull/9875
130 2017-02-27 12:40:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9875: tests: Fix dangling pwalletMain pointer in wallet tests (06master...062017_02_wallet_test_dangle) 02https://github.com/bitcoin/bitcoin/pull/9875
131 2017-02-27 12:42:25	0|luke-jr|wumpus: so now if we restart that Travis job, it should merge in with that fix and we can tell if that was the issue?
132 2017-02-27 12:44:03	0|wumpus|yes, will re-trigger after travis finishes on master
133 2017-02-27 12:53:55	0|wumpus|which it did
134 2017-02-27 13:02:10	0|wumpus|luke-jr: still the same issue in your pull, unfortunately: https://travis-ci.org/bitcoin/bitcoin/jobs/205383977#L2475
135 2017-02-27 13:02:14	0|luke-jr|:/
136 2017-02-27 13:03:28	0|luke-jr|why doesn't it give any details on the exception?
137 2017-02-27 13:04:22	0|wumpus|yes pretty crappy. You could try adding your own catch{} around it temporarily
138 2017-02-27 13:15:10	0|wumpus|luke-jr: you'll need to remove the BOOST_CHECK_NO_THROW( too
139 2017-02-27 13:15:23	0|luke-jr|oh
140 2017-02-27 13:15:25	0|wumpus|otherwise that will catch it for you
141 2017-02-27 14:15:27	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9876: Remove wildcard imports from qa (06master...06remove_wildcard_imports) 02https://github.com/bitcoin/bitcoin/pull/9876
142 2017-02-27 15:06:25	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9851: [do not merge] travis gdb parachute for #9825 (06master...062017_02_travisissue) 02https://github.com/bitcoin/bitcoin/pull/9851
143 2017-02-27 16:17:19	0|morcos|wumpus: i think #9548 has enough ACK's if you want to merge
144 2017-02-27 16:17:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/9548 | Remove min reasonable fee by morcos · Pull Request #9548 · bitcoin/bitcoin · GitHub
145 2017-02-27 16:38:01	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9878: Mention bumpfee in 0.14 release notes. (060.14...06pr/bnote) 02https://github.com/bitcoin/bitcoin/pull/9878
146 2017-02-27 17:17:28	0|luke-jr|wumpus: with the trys added, the same stuff won't fail :|
147 2017-02-27 19:48:44	0|Chris_Stewart_5|I have a question about partial merkle trees and extracting matches, we have this piece of code inside of 'TraverseAndExtract' https://github.com/bitcoin/bitcoin/blob/master/src/merkleblock.cpp#L121-L125
148 2017-02-27 19:49:02	0|Chris_Stewart_5|however, can't this happen if we have to duplicate a txid to make sure a node has two leaves?
149 2017-02-27 19:57:13	0|sipa|Chris_Stewart_5: it's exactly designed to test that
150 2017-02-27 19:57:43	0|sipa|duplicate txids in the tree are invalid
151 2017-02-27 20:00:26	0|Chris_Stewart_5|sipa: Ok, and where is that duplicate txid filtered out when building the merkle tree? On this line? https://github.com/bitcoin/bitcoin/blob/master/src/merkleblock.cpp#L81-L82
152 2017-02-27 20:00:41	0|sipa|Chris_Stewart_5: "filtered out"?
153 2017-02-27 20:00:50	0|sipa|Chris_Stewart_5: a block with duplicate txids is invalid in the first place
154 2017-02-27 20:01:09	0|sipa|it can't ever occur in any block we have
155 2017-02-27 20:03:58	0|sipa|by definition such a block would have a double spend
156 2017-02-27 20:04:00	0|Chris_Stewart_5|Yeah, I guess I was getting confused with 'MerkleBlocks' and just merkle tree computations
157 2017-02-27 20:05:04	0|Chris_Stewart_5|and they aren't conceptually the same tree
158 2017-02-27 20:05:54	0|sipa|yes they are...
159 2017-02-27 20:06:14	0|sipa|a MerkleBlock is just the merkle tree of a block with some branches removed
160 2017-02-27 20:07:04	0|sipa|it couldn't prove anything if it wasn't the same tree
161 2017-02-27 20:08:30	0|Chris_Stewart_5|Ok, help me understand this then.
162 2017-02-27 20:08:39	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L14-L18 and the example below it
163 2017-02-27 20:09:10	0|Chris_Stewart_5|would not be serialized as the entire tree when sending it over the network, correct? It would prune the 'rightmost' branch 'f' right?
164 2017-02-27 20:09:26	0|Chris_Stewart_5|and just provide the hash for 'f'
165 2017-02-27 20:09:30	0|sipa|that's about how the merkle root hash is computed
166 2017-02-27 20:09:35	0|sipa|not what is in it
167 2017-02-27 20:09:47	0|sipa|it's illegal for a transaction to be repeated inside a block
168 2017-02-27 20:10:14	0|sipa|yet, if there is at any level of the tree an odd number of entries, we duplicate the last one _for the purpose of computing the root_
169 2017-02-27 20:10:37	0|sipa|that case is handled in the else branch of the MerkleBlock code you linked to
170 2017-02-27 20:17:53	0|Chris_Stewart_5|Hmm ok, so if we have a block with 3 txs in it, and we wanted to send a merkle block to a spv node to prove a tx occurred in that block, we wouldn't have to duplicate that 3rd txid to recompute the hash of the parent node? and thus prove to the SPV node the tx occurred?
171 2017-02-27 20:17:59	0|BlueMatt|most mysterious travis failure ever: https://travis-ci.org/bitcoin/bitcoin/builds/205914634
172 2017-02-27 20:18:01	0|BlueMatt|no log?
173 2017-02-27 20:18:08	0|sipa|Chris_Stewart_5: yes?
174 2017-02-27 20:18:16	0|sipa|Chris_Stewart_5: but you're not duplicating the transaction in the tree
175 2017-02-27 20:18:31	0|sipa|Chris_Stewart_5: you're just duplicating an entry when computing the next level
176 2017-02-27 20:18:50	0|sipa|just read the code
177 2017-02-27 20:19:36	0|sipa|Chris_Stewart_5: https://github.com/bitcoin/bitcoin/blob/master/src/merkleblock.cpp#L119-L128
178 2017-02-27 20:20:12	0|sipa|that if selects whether we're in the normal case, or the 'last entry of an odd-sized level' case
179 2017-02-27 20:20:29	0|sipa|only in the first one we require the two lower level hashes to be different
180 2017-02-27 20:20:46	0|sipa|in the second case there still is only one hash, but we duplicate it for the purpose of computing the parent level
181 2017-02-27 20:20:59	0|Chris_Stewart_5|yeah, that is what i was missing. Thanks.
182 2017-02-27 20:33:02	0|luke-jr|wumpus: weird, re-pushing with a new commit-id (no code changes) passes Travis now
183 2017-02-27 21:13:05	0|petertodd|dcousens: don't feel bad, it's a very confusing issue; and my apologies if my answers were a bit terse! was trying to get something else done at the same time
184 2017-02-27 21:14:02	0|petertodd|dcousens, sipa: my best advice is to get a copy of the opentimestamps client and run the git integration code with the verbose switch on to see exactly what's happening under the hood
185 2017-02-27 21:14:24	0|sipa|petertodd: i don't think that's useful without reviewing that code myself :)
186 2017-02-27 21:15:08	0|petertodd|sipa: I just mean, it's an implementation of something that hooks into the low-level git signing code, so it's an easy way to see exactly what's being signed
187 2017-02-27 21:16:15	0|sipa|it seems my gpg key (which was created in 2015) used sha1 to sign the subkeys
188 2017-02-27 21:16:21	0|sipa|horror.
189 2017-02-27 21:16:42	0|petertodd|heh, yeah, I think the defaults were changed pretty recently...
190 2017-02-27 21:35:11	0|bitcoin-git|13bitcoin/06master 1488c2ae3 15MarcoFalke: Merge #9350: [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json...
191 2017-02-27 21:35:11	0|bitcoin-git|13bitcoin/06master 14988ce2d 15Chris Stewart: Adding 'amount' label to tx_valid/tx_invalid.json files
192 2017-02-27 21:35:11	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/94e5ba9ba290...88c2ae3ed2bb
193 2017-02-27 21:35:22	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9350: [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9350
194 2017-02-27 22:49:53	0|dcousens|petertodd: no problem :),  we all got there in the end :)
195 2017-02-27 23:41:35	0|jeremyrubin|Is anyone else kinds surprised that github didn't have a ready to go sha256 (or whatever) version of git?
196 2017-02-27 23:42:08	0|sipa|what does github have to do with that?
197 2017-02-27 23:42:28	0|sipa|it's perhaps surprising that git itself never prioritized upgrading to a better hash function
198 2017-02-27 23:42:32	0|jeremyrubin|They have a lot of money on git
199 2017-02-27 23:42:47	0|jeremyrubin|it's like a bitcoin company not investing in any core dev ;)
200 2017-02-27 23:42:51	0|sipa|no
201 2017-02-27 23:43:04	0|sipa|it's like a bitcoin company not developing their own altcoin
202 2017-02-27 23:43:15	0|dcousens|haha
203 2017-02-27 23:43:15	0|jeremyrubin|Example:
204 2017-02-27 23:43:22	0|jeremyrubin|github could run an internal git chain
205 2017-02-27 23:43:26	0|jeremyrubin|using upgraded hashes
206 2017-02-27 23:43:35	0|dcousens|jeremyrubin: how do you know they don't?
207 2017-02-27 23:43:44	0|sipa|jeremyrubin: you're missing my point
208 2017-02-27 23:43:58	0|dcousens|GitHub is about compatibility with git
209 2017-02-27 23:44:00	0|jeremyrubin|could test it out pushing the broken pdfs :p
210 2017-02-27 23:44:19	0|sipa|either changing git's hash function is easy, and a fork or branch with support for it would be sponsored, and be available, and they'd use it
211 2017-02-27 23:44:38	0|sipa|OR switching the hash function is hard, so nobody has a working version
212 2017-02-27 23:45:06	0|sipa|suggesting that github would do so without compatibility with git itself seems ridiculous
213 2017-02-27 23:46:20	0|jeremyrubin|idk -- I would expect a large fraction of github users could pretty quickly migrate to "git2.0" if github sent them an email detailing the changes
214 2017-02-27 23:46:35	0|jeremyrubin|Maybe I don't use very many tools on top of git
215 2017-02-27 23:46:47	0|sipa|you're literally saying here that github fork their own version of git
216 2017-02-27 23:46:58	0|bsm117532|jeremyrubin: I've been very surprised there doesn't seem to exist a sha2 version of git.  I've thought about writing one myself.  Especially integrating opentimestamps and commit signing...
217 2017-02-27 23:47:14	0|jeremyrubin|sipa:yeah, I think they should. It's not bitcoin :p
218 2017-02-27 23:47:23	0|sipa|jeremyrubin: I think *git* should support sha2
219 2017-02-27 23:47:34	0|luke-jr|jeremyrubin: to rephrase: you're saying GitHub should stop supporting git ;)
220 2017-02-27 23:47:38	0|jeremyrubin|yeah, but it seems Linus has his head... somewhere
221 2017-02-27 23:47:50	0|cfields|Linus' mail said it's in the works.. does it not exist somewhere?
222 2017-02-27 23:47:51	0|jeremyrubin|They can support both?
223 2017-02-27 23:48:51	0|jeremyrubin|No reason to not have git and gitsha2 available simultaneously.
224 2017-02-27 23:48:53	0|sipa|i think i'd stop using github if they did that
225 2017-02-27 23:48:58	0|dcousens|jeremyrubin: I suppose it depends on how its done... maybe its a soft-fork haha
226 2017-02-27 23:49:03	0|sipa|it would feel like an embrace-and-extend
227 2017-02-27 23:50:12	0|sipa|if they truly felt sha2 is important, and willing to put money on that, they could subsidize or contribute towards sha2 support in git itself... not suddenly switch to an incompatible fork themselves
228 2017-02-27 23:50:24	0|bsm117532|Hey look it's zooko https://lwn.net/Articles/370907/
229 2017-02-27 23:53:00	0|jeremyrubin|I guess I should be more vocal as a customer :p
230 2017-02-27 23:59:43	0|jeremyrubin|emailed github support asking what they're doing :p