1 2017-02-27T00:17:29  <bitcoin-git> [bitcoin] sipa opened pull request #9868: Abstract out the command line options for block assembly (master...assembleroptions) https://github.com/bitcoin/bitcoin/pull/9868
  2 2017-02-27T00:21:11  *** rgrant has joined #bitcoin-core-dev
  3 2017-02-27T00:25:35  *** wudayoda has quit IRC
  4 2017-02-27T00:25:58  <bitcoin-git> [bitcoin] RHavar opened pull request #9869: Move comment to right spot (master...comment) https://github.com/bitcoin/bitcoin/pull/9869
  5 2017-02-27T00:33:58  *** MarcoFalke has left #bitcoin-core-dev
  6 2017-02-27T00:37:32  *** Chris_Stewart_5 has quit IRC
  7 2017-02-27T00:41:03  *** wudayoda has joined #bitcoin-core-dev
  8 2017-02-27T00:43:26  *** ebfull has joined #bitcoin-core-dev
  9 2017-02-27T00:45:57  *** wudayoda has quit IRC
 10 2017-02-27T00:48:32  <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
 11 2017-02-27T00:48:38  <rgrant> here in the code is this tension resolved?
 12 2017-02-27T00:56:02  *** wolfspraul has quit IRC
 13 2017-02-27T00:56:53  <sipa> rgrant: segwit transactions are non-standard to old nodes
 14 2017-02-27T00:56:53  *** wolfspraul has joined #bitcoin-core-dev
 15 2017-02-27T00:57:44  <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)
 16 2017-02-27T00:58:25  <rgrant> yes, this describes an attack.  but what makes the attack block invalid?
 17 2017-02-27T00:58:45  <sipa> to whom?
 18 2017-02-27T00:59:20  <rgrant> to segwit-enabled nodes and miners
 19 2017-02-27T00:59:34  <sipa> the segwit consensus rules?
 20 2017-02-27T00:59:44  *** chjj has quit IRC
 21 2017-02-27T01:00:10  <sipa> in script/interpreter.h there is a flag SCRIPT_VERIFY_WITNESS
 22 2017-02-27T01:00:32  * rgrant follows along
 23 2017-02-27T01:00:39  <sipa> the block validation code passes this flag to the script execution code when it's invoked for a block that has BIP9 activation
 24 2017-02-27T01:01:39  <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
 25 2017-02-27T01:01:49  <rgrant> but the attacker doesn't set bip9 (though bip9 has activated)
 26 2017-02-27T01:02:06  <sipa> yes
 27 2017-02-27T01:02:18  <sipa> that doesn't matter
 28 2017-02-27T01:02:31  <sipa> bip9 activation isn't dependent on the signalling of the block itself
 29 2017-02-27T01:02:40  <sipa> only on the signalling in the chain's history
 30 2017-02-27T01:05:01  *** belcher has quit IRC
 31 2017-02-27T01:07:01  <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.
 32 2017-02-27T01:08:47  <sipa> what do you mean by rewrites?
 33 2017-02-27T01:09:33  <rgrant> well, attacker wants to use the "anyonecanspend" interpretation of the segwit tx, under the old rules.
 34 2017-02-27T01:09:58  <rgrant> so they just thorw away the witness
 35 2017-02-27T01:11:42  <sipa> ah
 36 2017-02-27T01:12:18  <sipa> under segwit rules, a segwit output can only be spent by an input that has a witness
 37 2017-02-27T01:12:18  *** alpalp has joined #bitcoin-core-dev
 38 2017-02-27T01:12:18  *** alpalp has joined #bitcoin-core-dev
 39 2017-02-27T01:12:37  <sipa> the attacker can't control whether the witness flag is set in other nodes
 40 2017-02-27T01:13:07  <rgrant> is that over in CheckInputs?
 41 2017-02-27T01:13:16  <sipa> no, in the script code
 42 2017-02-27T01:13:48  <sipa> in the case an attacker removes the witness from the spending input, you'll still call validation with the witness flag set
 43 2017-02-27T01:14:13  <sipa> and the script execution will fail if it's a witness output that is being spent withoit having a witness
 44 2017-02-27T01:14:56  <rgrant> okay, i get the mechanism.  now i'm still trying to hunt down the code.
 45 2017-02-27T01:15:57  <rgrant> (also, does this make segwit outputs viral?)
 46 2017-02-27T01:16:47  <rgrant> wait, the input block needs to have a witness, or the input script?
 47 2017-02-27T01:17:32  * rgrant is confused.  
 48 2017-02-27T01:21:53  <sipa> the txin spending a witness output has to have a txinwitness
 49 2017-02-27T01:22:17  <sipa> which implies that the block that that txin is in must be a witness block
 50 2017-02-27T01:23:07  <rgrant> thanks.  and it can be spent to any address.  it's not viral.
 51 2017-02-27T01:23:23  <sipa> right, the outputs don't care
 52 2017-02-27T01:30:23  *** belcher has joined #bitcoin-core-dev
 53 2017-02-27T01:31:35  <bitcoin-git> [bitcoin] sipa opened pull request #9871: [RFC] Add a tree sha512 hash to merge commits (master...merge_sha512) https://github.com/bitcoin/bitcoin/pull/9871
 54 2017-02-27T02:00:48  *** rgrant has left #bitcoin-core-dev
 55 2017-02-27T02:04:15  *** Ylbam has quit IRC
 56 2017-02-27T02:42:11  *** wudayoda has joined #bitcoin-core-dev
 57 2017-02-27T02:46:30  *** wudayoda has quit IRC
 58 2017-02-27T02:53:47  *** wudayoda has joined #bitcoin-core-dev
 59 2017-02-27T02:55:10  *** JackH has quit IRC
 60 2017-02-27T02:58:27  *** wudayoda has quit IRC
 61 2017-02-27T03:26:25  *** alpalp has quit IRC
 62 2017-02-27T03:33:51  *** wudayoda has joined #bitcoin-core-dev
 63 2017-02-27T03:38:27  *** wudayoda has quit IRC
 64 2017-02-27T03:44:37  <bitcoin-git> [bitcoin] kallewoof opened pull request #9872: [qa] Multi-chain support in test framework (master...qa-multi-chain-support) https://github.com/bitcoin/bitcoin/pull/9872
 65 2017-02-27T03:45:10  <gmaxwell> luke-jr: are you going to rebase the remaining multiwallet support now that 0.15 has started?
 66 2017-02-27T03:45:29  <luke-jr> gmaxwell: again? I just did yesterday O.o
 67 2017-02-27T03:46:13  <gmaxwell> oh sorry!
 68 2017-02-27T03:46:15  <luke-jr> hmm, I wonder why Travis is whining
 69 2017-02-27T03:48:33  <gmaxwell> s/are you going to rebase/are you going to fix the travis errors/  :P
 70 2017-02-27T03:49:34  <luke-jr> yes ;)
 71 2017-02-27T03:50:13  <luke-jr> assuming it's not yet another false positive anyway
 72 2017-02-27T03:55:46  *** dodomojo has joined #bitcoin-core-dev
 73 2017-02-27T04:02:16  *** justan0theruser has quit IRC
 74 2017-02-27T04:02:24  *** justanotheruser has joined #bitcoin-core-dev
 75 2017-02-27T04:11:33  *** dodomojo has quit IRC
 76 2017-02-27T04:23:09  *** alpalp has joined #bitcoin-core-dev
 77 2017-02-27T04:23:09  *** alpalp has joined #bitcoin-core-dev
 78 2017-02-27T04:30:23  *** alpalp has quit IRC
 79 2017-02-27T05:04:26  *** chjj has joined #bitcoin-core-dev
 80 2017-02-27T05:23:14  *** Giszmo has quit IRC
 81 2017-02-27T05:26:06  *** dcousens has joined #bitcoin-core-dev
 82 2017-02-27T05:26:17  <dcousens> petertodd: lol,  I guess I'll sit this one out then :)
 83 2017-02-27T05:27:21  <dcousens> Did seem difficult to find documentation/material on what you two are referring too though
 84 2017-02-27T05:28:02  *** Guest91228 has quit IRC
 85 2017-02-27T05:31:13  *** Cory has joined #bitcoin-core-dev
 86 2017-02-27T05:32:17  <sipa> likewise
 87 2017-02-27T05:32:28  <sipa> i was confused by the same SE answer :)
 88 2017-02-27T05:33:22  <achow101> dcousens: sipa: solution - dig through git's source code: https://github.com/git/git/blob/master/gpg-interface.c#L153
 89 2017-02-27T05:34:19  <sipa> cool
 90 2017-02-27T05:34:24  <dcousens> cheers achow101
 91 2017-02-27T05:34:37  *** wudayoda has joined #bitcoin-core-dev
 92 2017-02-27T05:38:57  *** wudayoda has quit IRC
 93 2017-02-27T05:46:36  <sipa> achow101: it's not perfect w.r.t. the commit, only for the tree
 94 2017-02-27T05:46:56  <sipa> so an attack on the commit's claimed history would still apply
 95 2017-02-27T05:47:33  *** justan0theruser has joined #bitcoin-core-dev
 96 2017-02-27T05:48:52  <achow101> sipa: you mean like if someone faked a commit history with a colliding parent commit hash?
 97 2017-02-27T05:49:45  <sipa> yes, and the same resulting tree
 98 2017-02-27T05:49:48  *** justanotheruser has quit IRC
 99 2017-02-27T05:50:15  <sipa> which is certainly much less worrying
100 2017-02-27T05:50:27  <achow101> ok. but isn't the point to make sure the tree is the right tree and not some colliding tree?
101 2017-02-27T05:51:08  <sipa> well a commit object in git is both a resulting tree and a history for it
102 2017-02-27T05:51:32  <sipa> with this method we're only avoiding SHA1 for the tree
103 2017-02-27T05:52:38  <achow101> right.
104 2017-02-27T05:56:50  <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?
105 2017-02-27T05:57:12  <sipa> interesting idea
106 2017-02-27T05:58:32  <achow101> actually that only happens on builds of master, not any of the releases, so not particularly important
107 2017-02-27T06:06:30  *** paveljanik has quit IRC
108 2017-02-27T06:14:38  *** wudayoda has joined #bitcoin-core-dev
109 2017-02-27T06:15:51  *** lclc has joined #bitcoin-core-dev
110 2017-02-27T06:17:16  <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.
111 2017-02-27T06:18:57  *** wudayoda has quit IRC
112 2017-02-27T06:19:43  <achow101> wumpus: ok
113 2017-02-27T06:44:55  *** wudayoda has joined #bitcoin-core-dev
114 2017-02-27T06:49:27  *** wudayoda has quit IRC
115 2017-02-27T06:55:07  <dcousens> wumpus: true, nevermind
116 2017-02-27T06:59:17  <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
117 2017-02-27T06:59:22  <dcousens> (e.g https://stackoverflow.com/questions/1951519/when-should-i-use-stdsize-t)
118 2017-02-27T07:01:48  <wumpus> it just doesn't matter here
119 2017-02-27T07:02:20  <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
120 2017-02-27T07:03:00  <dcousens> not worth discussing any further :)
121 2017-02-27T07:03:19  <wumpus> this was meant as a quick fix to get an compileissue out of the way
122 2017-02-27T07:03:22  <wumpus> indeed, no need to drag it out
123 2017-02-27T07:07:47  *** dcousens has quit IRC
124 2017-02-27T07:08:04  *** dcousens has joined #bitcoin-core-dev
125 2017-02-27T07:08:44  <wumpus> whoa, did I still manage to make it fail travis?
126 2017-02-27T07:09:06  <wumpus> oh the "recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed." issue again, unrelated
127 2017-02-27T07:11:09  <wumpus> I'm in good company, even "move comment" pulls fail
128 2017-02-27T07:11:20  <dcousens> ha
129 2017-02-27T07:22:19  <wumpus> looks like there is another intermittent travis issue: timeouts in make check (probably test_bitcoin related too)
130 2017-02-27T07:25:00  *** wudayoda has joined #bitcoin-core-dev
131 2017-02-27T07:27:07  <gmaxwell> test_bitcoin is really slow...
132 2017-02-27T07:28:11  <wumpus> well it hangs *before* the "N testcases" line... it's not supposed to spend *any* time there
133 2017-02-27T07:29:27  <wumpus> still haven't managed to catch the test_bitcoin mutex issue, this may be a different symptom of it
134 2017-02-27T07:29:27  *** wudayoda has quit IRC
135 2017-02-27T07:33:52  <wumpus> this is making travis as good as useless
136 2017-02-27T07:36:04  <gmaxwell> maybe we need to start making PRs with most of test_bitcoin commented out?
137 2017-02-27T07:37:00  <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
138 2017-02-27T07:37:43  <wumpus> bisecting might work, though that's difficult with unrelabile reprodicibility
139 2017-02-27T07:37:59  <wumpus> e.g. go way back and find the commit where this started
140 2017-02-27T07:38:54  <wumpus> the funny thing is that #9851 is passing every single time now that I added debug information
141 2017-02-27T07:38:58  <gribble> https://github.com/bitcoin/bitcoin/issues/9851 | [do not merge] travis gdb parachute for #9825 by laanwj · Pull Request #9851 · bitcoin/bitcoin · GitHub
142 2017-02-27T07:39:07  <gmaxwell> it fails enough perhaps that just retrying each step 5 times might be enough.
143 2017-02-27T07:39:08  <wumpus> if that's not a classic example of a heisenbug I don't know
144 2017-02-27T07:39:20  *** owowo has quit IRC
145 2017-02-27T07:40:27  <wumpus> it seems to fail in runs, I wonder if it somehow gets cached on a PR
146 2017-02-27T07:40:53  <wumpus> I suppose that makes sense it it's something the C compiler/ linker does - ccache caches things, which are re-used next time
147 2017-02-27T07:41:40  *** BashCo_ has quit IRC
148 2017-02-27T07:46:45  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6206252e5073...c7e57ce98154
149 2017-02-27T07:46:46  <bitcoin-git> bitcoin/master 864890a Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
150 2017-02-27T07:46:46  <bitcoin-git> bitcoin/master c7e57ce Wladimir J. van der Laan: Merge #9839: [qa] Make import-rescan.py watchonly check reliable...
151 2017-02-27T07:47:16  <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
152 2017-02-27T07:52:06  <wumpus> cfields: is it possible to download a PR's cache remotely?
153 2017-02-27T08:04:27  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/eddaa6b35d41aefead1a57ea54e7e15ce069f79a
154 2017-02-27T08:04:28  <bitcoin-git> bitcoin/0.14 eddaa6b Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
155 2017-02-27T08:04:33  <wumpus> hm no, never mind, I don't think that's going to help at all either...
156 2017-02-27T08:04:40  *** BashCo has joined #bitcoin-core-dev
157 2017-02-27T08:05:04  *** wudayoda has joined #bitcoin-core-dev
158 2017-02-27T08:09:27  *** wudayoda has quit IRC
159 2017-02-27T08:21:53  <bitcoin-git> [bitcoin] laanwj opened pull request #9873: [do not merge] upload test_bitcoin executable for #9825 (master...2017_02_travis_upload) https://github.com/bitcoin/bitcoin/pull/9873
160 2017-02-27T08:28:32  *** str4d has joined #bitcoin-core-dev
161 2017-02-27T08:49:05  *** paveljanik has joined #bitcoin-core-dev
162 2017-02-27T08:49:05  *** paveljanik has joined #bitcoin-core-dev
163 2017-02-27T08:51:14  *** moli_ has quit IRC
164 2017-02-27T09:13:55  *** afk11 has quit IRC
165 2017-02-27T09:14:19  *** arubi has quit IRC
166 2017-02-27T09:14:43  *** wasi has quit IRC
167 2017-02-27T09:22:46  *** JackH has joined #bitcoin-core-dev
168 2017-02-27T09:27:18  *** wasi has joined #bitcoin-core-dev
169 2017-02-27T09:27:31  *** afk11 has joined #bitcoin-core-dev
170 2017-02-27T09:27:45  *** arubi has joined #bitcoin-core-dev
171 2017-02-27T09:29:40  *** Guyver2 has joined #bitcoin-core-dev
172 2017-02-27T09:30:57  *** str4d has quit IRC
173 2017-02-27T09:35:09  *** paveljanik has quit IRC
174 2017-02-27T09:38:03  *** str4d has joined #bitcoin-core-dev
175 2017-02-27T09:38:45  *** Ylbam has joined #bitcoin-core-dev
176 2017-02-27T09:44:02  *** AaronvanW has joined #bitcoin-core-dev
177 2017-02-27T09:45:24  <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*
178 2017-02-27T09:45:26  <gribble> https://github.com/bitcoin/bitcoin/issues/9825 | Intermittent FAIL: test/test_bitcoin in Travis · Issue #9825 · bitcoin/bitcoin · GitHub
179 2017-02-27T09:54:23  *** str4d has quit IRC
180 2017-02-27T10:01:03  *** wasi has quit IRC
181 2017-02-27T10:01:22  *** wasi has joined #bitcoin-core-dev
182 2017-02-27T10:06:01  *** wudayoda has joined #bitcoin-core-dev
183 2017-02-27T10:10:27  *** wudayoda has quit IRC
184 2017-02-27T10:33:20  *** jannes has joined #bitcoin-core-dev
185 2017-02-27T10:34:14  <Victorsueca> wumpus: it's a quantum bug
186 2017-02-27T10:46:03  *** wudayoda has joined #bitcoin-core-dev
187 2017-02-27T10:46:20  <luke-jr> ew, we were using printf for hex strings?
188 2017-02-27T10:50:27  *** wudayoda has quit IRC
189 2017-02-27T10:53:27  *** chjj has quit IRC
190 2017-02-27T11:06:20  <wumpus> yes, fairly sure that code is inherited from satoshi
191 2017-02-27T11:18:19  * luke-jr peers at Travis giving him a restart button that doesn't work
192 2017-02-27T11:18:33  <luke-jr> can someone restart the two non-passing https://travis-ci.org/bitcoin/bitcoin/builds/205383975 ?
193 2017-02-27T11:18:38  <luke-jr> I can't see any issue to fix
194 2017-02-27T11:19:27  *** rafalcpp has quit IRC
195 2017-02-27T11:23:21  <wumpus> sure...
196 2017-02-27T11:23:30  <wumpus> Victorsueca: either that or we need an exorcist
197 2017-02-27T11:24:42  <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)"
198 2017-02-27T11:24:57  <luke-jr> I can't reproduce it :/
199 2017-02-27T11:25:20  <Victorsueca> maybe the code is ok and the problem is at travis?
200 2017-02-27T11:25:55  <wumpus> luke-jr: restarting it...
201 2017-02-27T11:25:58  *** wudayoda has joined #bitcoin-core-dev
202 2017-02-27T11:26:17  <wumpus> Victorsueca: it's possible, though that doesn't explain why it always fails in the same (or similar) place
203 2017-02-27T11:27:32  <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
204 2017-02-27T11:27:40  <luke-jr> hmm, I wonder..
205 2017-02-27T11:29:33  <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
206 2017-02-27T11:29:51  *** chjj has joined #bitcoin-core-dev
207 2017-02-27T11:30:27  *** wudayoda has quit IRC
208 2017-02-27T11:41:09  <luke-jr> is wallet_tests/rescan really acceptable? it's assigning pwalletMain for a test to a stack variable, and leaving it there?
209 2017-02-27T11:42:56  *** moli_ has joined #bitcoin-core-dev
210 2017-02-27T12:05:06  *** BashCo_ has joined #bitcoin-core-dev
211 2017-02-27T12:06:05  *** wudayoda has joined #bitcoin-core-dev
212 2017-02-27T12:07:40  *** BashCo has quit IRC
213 2017-02-27T12:09:16  <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
214 2017-02-27T12:10:22  <luke-jr> I wonder if that's the cause - signrawtransaction can use the wallet when available
215 2017-02-27T12:10:25  <wumpus> but yes any test after that that assumes pwalletMain is set to something will crash or do bad things
216 2017-02-27T12:10:27  *** wudayoda has quit IRC
217 2017-02-27T12:10:34  <luke-jr> I just can't reproduce to confirm
218 2017-02-27T12:10:55  <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?
219 2017-02-27T12:11:17  <wumpus> yes, you might be on to something
220 2017-02-27T12:12:05  <wumpus> the next test using the walletMain after that will corrupt
221 2017-02-27T12:12:15  <wumpus> +the stack
222 2017-02-27T12:16:44  <bitcoin-git> [bitcoin] laanwj opened pull request #9875: tests: Fix dangling pwalletMain pointer in wallet tests (master...2017_02_wallet_test_dangle) https://github.com/bitcoin/bitcoin/pull/9875
223 2017-02-27T12:30:55  *** alpalp has joined #bitcoin-core-dev
224 2017-02-27T12:37:01  *** d9b4bef9 has quit IRC
225 2017-02-27T12:38:14  *** d9b4bef9 has joined #bitcoin-core-dev
226 2017-02-27T12:40:03  <bitcoin-git> [bitcoin] laanwj closed pull request #9875: tests: Fix dangling pwalletMain pointer in wallet tests (master...2017_02_wallet_test_dangle) https://github.com/bitcoin/bitcoin/pull/9875
227 2017-02-27T12:42:24  <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?
228 2017-02-27T12:43:54  *** MarcoFalke has joined #bitcoin-core-dev
229 2017-02-27T12:44:01  <wumpus> yes, will re-trigger after travis finishes on master
230 2017-02-27T12:53:53  <wumpus> which it did
231 2017-02-27T13:02:08  <wumpus> luke-jr: still the same issue in your pull, unfortunately: https://travis-ci.org/bitcoin/bitcoin/jobs/205383977#L2475
232 2017-02-27T13:02:13  <luke-jr> :/
233 2017-02-27T13:03:26  <luke-jr> why doesn't it give any details on the exception?
234 2017-02-27T13:04:20  <wumpus> yes pretty crappy. You could try adding your own catch{} around it temporarily
235 2017-02-27T13:07:05  * luke-jr ponders why this is mingw-specific
236 2017-02-27T13:15:08  <wumpus> luke-jr: you'll need to remove the BOOST_CHECK_NO_THROW( too
237 2017-02-27T13:15:21  <luke-jr> oh
238 2017-02-27T13:15:24  <wumpus> otherwise that will catch it for you
239 2017-02-27T13:18:57  *** nickler has quit IRC
240 2017-02-27T13:21:36  *** nickler has joined #bitcoin-core-dev
241 2017-02-27T13:31:07  *** moli_ has quit IRC
242 2017-02-27T13:32:55  *** moli_ has joined #bitcoin-core-dev
243 2017-02-27T13:33:48  *** alpalp has quit IRC
244 2017-02-27T13:51:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
245 2017-02-27T13:58:57  *** moli_ has quit IRC
246 2017-02-27T14:03:32  *** moli_ has joined #bitcoin-core-dev
247 2017-02-27T14:15:25  <bitcoin-git> [bitcoin] jnewbery opened pull request #9876: Remove wildcard imports from qa (master...remove_wildcard_imports) https://github.com/bitcoin/bitcoin/pull/9876
248 2017-02-27T14:17:44  *** GreenIsMyPepper has quit IRC
249 2017-02-27T14:48:01  *** rafalcpp has joined #bitcoin-core-dev
250 2017-02-27T15:02:06  *** wudayoda has joined #bitcoin-core-dev
251 2017-02-27T15:06:23  <bitcoin-git> [bitcoin] laanwj closed pull request #9851: [do not merge] travis gdb parachute for #9825 (master...2017_02_travisissue) https://github.com/bitcoin/bitcoin/pull/9851
252 2017-02-27T15:06:27  *** wudayoda has quit IRC
253 2017-02-27T15:21:17  *** Giszmo has joined #bitcoin-core-dev
254 2017-02-27T15:21:40  *** wudayoda has joined #bitcoin-core-dev
255 2017-02-27T15:24:47  *** adiabat has quit IRC
256 2017-02-27T15:25:57  *** wudayoda has quit IRC
257 2017-02-27T15:30:02  *** wudayoda has joined #bitcoin-core-dev
258 2017-02-27T15:31:42  *** lclc has quit IRC
259 2017-02-27T15:41:53  *** mol has joined #bitcoin-core-dev
260 2017-02-27T15:45:16  *** moli_ has quit IRC
261 2017-02-27T15:50:02  *** eenoch_ is now known as eenoch
262 2017-02-27T15:55:55  *** adiabat has joined #bitcoin-core-dev
263 2017-02-27T16:03:27  *** abpa has joined #bitcoin-core-dev
264 2017-02-27T16:03:55  *** wudayoda has quit IRC
265 2017-02-27T16:04:57  *** abpa has quit IRC
266 2017-02-27T16:06:24  *** wudayoda has joined #bitcoin-core-dev
267 2017-02-27T16:17:17  <morcos> wumpus: i think #9548 has enough ACK's if you want to merge
268 2017-02-27T16:17:19  <gribble> https://github.com/bitcoin/bitcoin/issues/9548 | Remove min reasonable fee by morcos · Pull Request #9548 · bitcoin/bitcoin · GitHub
269 2017-02-27T16:20:39  *** nickler has quit IRC
270 2017-02-27T16:24:05  *** nickler has joined #bitcoin-core-dev
271 2017-02-27T16:30:32  *** harding has joined #bitcoin-core-dev
272 2017-02-27T16:32:17  *** paveljanik has joined #bitcoin-core-dev
273 2017-02-27T16:35:48  *** lclc has joined #bitcoin-core-dev
274 2017-02-27T16:37:59  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9878: Mention bumpfee in 0.14 release notes. (0.14...pr/bnote) https://github.com/bitcoin/bitcoin/pull/9878
275 2017-02-27T16:52:06  *** abpa has joined #bitcoin-core-dev
276 2017-02-27T17:12:13  *** Giszmo has quit IRC
277 2017-02-27T17:17:27  <luke-jr> wumpus: with the trys added, the same stuff won't fail :|
278 2017-02-27T17:18:04  * luke-jr puts them before the try <.<
279 2017-02-27T17:27:56  *** Giszmo has joined #bitcoin-core-dev
280 2017-02-27T17:36:16  *** droark has quit IRC
281 2017-02-27T17:40:15  *** adiabat has quit IRC
282 2017-02-27T17:58:17  *** BashCo_ has quit IRC
283 2017-02-27T17:58:51  *** wudayoda has quit IRC
284 2017-02-27T18:09:44  *** bsm1175322 has joined #bitcoin-core-dev
285 2017-02-27T18:21:43  *** wudayoda has joined #bitcoin-core-dev
286 2017-02-27T18:29:24  *** lclc has quit IRC
287 2017-02-27T18:38:51  *** lightningbot has joined #bitcoin-core-dev
288 2017-02-27T18:43:30  *** justan0theruser has quit IRC
289 2017-02-27T18:59:15  *** justan0theruser has joined #bitcoin-core-dev
290 2017-02-27T19:35:04  *** lclc has joined #bitcoin-core-dev
291 2017-02-27T19:48:42  <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
292 2017-02-27T19:49:01  <Chris_Stewart_5> however, can't this happen if we have to duplicate a txid to make sure a node has two leaves?
293 2017-02-27T19:52:36  *** nickler has quit IRC
294 2017-02-27T19:53:51  *** nickler has joined #bitcoin-core-dev
295 2017-02-27T19:56:52  *** jnewbery has quit IRC
296 2017-02-27T19:57:12  <sipa> Chris_Stewart_5: it's exactly designed to test that
297 2017-02-27T19:57:41  <sipa> duplicate txids in the tree are invalid
298 2017-02-27T20:00:24  <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
299 2017-02-27T20:00:39  <sipa> Chris_Stewart_5: "filtered out"?
300 2017-02-27T20:00:49  <sipa> Chris_Stewart_5: a block with duplicate txids is invalid in the first place
301 2017-02-27T20:01:08  <sipa> it can't ever occur in any block we have
302 2017-02-27T20:03:56  <sipa> by definition such a block would have a double spend
303 2017-02-27T20:04:04  <Chris_Stewart_5> Yeah, I guess I was getting confused with 'MerkleBlocks' and just merkle tree computations
304 2017-02-27T20:05:03  <Chris_Stewart_5> and they aren't conceptually the same tree
305 2017-02-27T20:05:53  <sipa> yes they are...
306 2017-02-27T20:06:12  <sipa> a MerkleBlock is just the merkle tree of a block with some branches removed
307 2017-02-27T20:07:02  <sipa> it couldn't prove anything if it wasn't the same tree
308 2017-02-27T20:07:20  *** lclc has quit IRC
309 2017-02-27T20:08:29  <Chris_Stewart_5> Ok, help me understand this then.
310 2017-02-27T20:08:37  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L14-L18 and the example below it
311 2017-02-27T20:09:09  <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?
312 2017-02-27T20:09:25  <Chris_Stewart_5> and just provide the hash for 'f'
313 2017-02-27T20:09:29  <sipa> that's about how the merkle root hash is computed
314 2017-02-27T20:09:34  <sipa> not what is in it
315 2017-02-27T20:09:45  <sipa> it's illegal for a transaction to be repeated inside a block
316 2017-02-27T20:10:11  *** lclc has joined #bitcoin-core-dev
317 2017-02-27T20:10:12  <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_
318 2017-02-27T20:10:36  <sipa> that case is handled in the else branch of the MerkleBlock code you linked to
319 2017-02-27T20:17:52  <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?
320 2017-02-27T20:17:57  <BlueMatt> most mysterious travis failure ever: https://travis-ci.org/bitcoin/bitcoin/builds/205914634
321 2017-02-27T20:18:04  <BlueMatt> no log?
322 2017-02-27T20:18:06  <sipa> Chris_Stewart_5: yes?
323 2017-02-27T20:18:15  <sipa> Chris_Stewart_5: but you're not duplicating the transaction in the tree
324 2017-02-27T20:18:30  <sipa> Chris_Stewart_5: you're just duplicating an entry when computing the next level
325 2017-02-27T20:18:48  <sipa> just read the code
326 2017-02-27T20:19:35  <sipa> Chris_Stewart_5: https://github.com/bitcoin/bitcoin/blob/master/src/merkleblock.cpp#L119-L128
327 2017-02-27T20:20:11  <sipa> that if selects whether we're in the normal case, or the 'last entry of an odd-sized level' case
328 2017-02-27T20:20:28  <sipa> only in the first one we require the two lower level hashes to be different
329 2017-02-27T20:20:45  <sipa> in the second case there still is only one hash, but we duplicate it for the purpose of computing the parent level
330 2017-02-27T20:20:58  <Chris_Stewart_5> yeah, that is what i was missing. Thanks.
331 2017-02-27T20:24:51  *** lclc_ has joined #bitcoin-core-dev
332 2017-02-27T20:26:17  *** lclc has quit IRC
333 2017-02-27T20:33:01  <luke-jr> wumpus: weird, re-pushing with a new commit-id (no code changes) passes Travis now
334 2017-02-27T20:36:25  *** BashCo has joined #bitcoin-core-dev
335 2017-02-27T21:09:26  *** lclc_ has quit IRC
336 2017-02-27T21:12:29  *** lclc has joined #bitcoin-core-dev
337 2017-02-27T21:13:04  <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
338 2017-02-27T21:14:01  <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
339 2017-02-27T21:14:22  <sipa> petertodd: i don't think that's useful without reviewing that code myself :)
340 2017-02-27T21:15:22  <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
341 2017-02-27T21:16:13  <sipa> it seems my gpg key (which was created in 2015) used sha1 to sign the subkeys
342 2017-02-27T21:16:19  <sipa> horror.
343 2017-02-27T21:16:41  <petertodd> heh, yeah, I think the defaults were changed pretty recently...
344 2017-02-27T21:18:15  *** wudayoda has quit IRC
345 2017-02-27T21:20:28  *** wudayoda has joined #bitcoin-core-dev
346 2017-02-27T21:23:31  *** wasi has quit IRC
347 2017-02-27T21:24:57  *** lclc has quit IRC
348 2017-02-27T21:28:57  *** jtimon has joined #bitcoin-core-dev
349 2017-02-27T21:32:42  *** wasi has joined #bitcoin-core-dev
350 2017-02-27T21:35:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/94e5ba9ba290...88c2ae3ed2bb
351 2017-02-27T21:35:09  <bitcoin-git> bitcoin/master 988ce2d Chris Stewart: Adding 'amount' label to tx_valid/tx_invalid.json files
352 2017-02-27T21:35:10  <bitcoin-git> bitcoin/master 88c2ae3 MarcoFalke: Merge #9350: [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json...
353 2017-02-27T21:35:21  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9350: [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json (master...master) https://github.com/bitcoin/bitcoin/pull/9350
354 2017-02-27T21:42:06  *** laurentmt has joined #bitcoin-core-dev
355 2017-02-27T22:02:16  *** jnewbery has joined #bitcoin-core-dev
356 2017-02-27T22:12:18  *** jannes has quit IRC
357 2017-02-27T22:20:01  *** laurentmt has quit IRC
358 2017-02-27T22:30:18  *** droark has joined #bitcoin-core-dev
359 2017-02-27T22:36:23  *** Guyver2 has quit IRC
360 2017-02-27T22:36:45  *** wudayoda has quit IRC
361 2017-02-27T22:37:32  *** wudayoda has joined #bitcoin-core-dev
362 2017-02-27T22:43:57  *** wudayoda has quit IRC
363 2017-02-27T22:49:52  <dcousens> petertodd: no problem :),  we all got there in the end :)
364 2017-02-27T23:39:54  *** AaronvanW has quit IRC
365 2017-02-27T23:40:37  *** MarcoFalke has left #bitcoin-core-dev
366 2017-02-27T23:41:15  *** AaronvanW has joined #bitcoin-core-dev
367 2017-02-27T23:41:33  <jeremyrubin> Is anyone else kinds surprised that github didn't have a ready to go sha256 (or whatever) version of git?
368 2017-02-27T23:42:06  <sipa> what does github have to do with that?
369 2017-02-27T23:42:26  <sipa> it's perhaps surprising that git itself never prioritized upgrading to a better hash function
370 2017-02-27T23:42:31  <jeremyrubin> They have a lot of money on git
371 2017-02-27T23:42:45  <jeremyrubin> it's like a bitcoin company not investing in any core dev ;)
372 2017-02-27T23:42:50  <sipa> no
373 2017-02-27T23:43:02  <sipa> it's like a bitcoin company not developing their own altcoin
374 2017-02-27T23:43:13  <dcousens> haha
375 2017-02-27T23:43:14  <jeremyrubin> Example:
376 2017-02-27T23:43:21  <jeremyrubin> github could run an internal git chain
377 2017-02-27T23:43:24  <jeremyrubin> using upgraded hashes
378 2017-02-27T23:43:34  <dcousens> jeremyrubin: how do you know they don't?
379 2017-02-27T23:43:43  <sipa> jeremyrubin: you're missing my point
380 2017-02-27T23:43:56  <dcousens> GitHub is about compatibility with git
381 2017-02-27T23:43:59  <jeremyrubin> could test it out pushing the broken pdfs :p
382 2017-02-27T23:44:17  <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
383 2017-02-27T23:44:20  *** ebfull has quit IRC
384 2017-02-27T23:44:37  <sipa> OR switching the hash function is hard, so nobody has a working version
385 2017-02-27T23:45:05  <sipa> suggesting that github would do so without compatibility with git itself seems ridiculous
386 2017-02-27T23:46:18  <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
387 2017-02-27T23:46:33  <jeremyrubin> Maybe I don't use very many tools on top of git
388 2017-02-27T23:46:46  <sipa> you're literally saying here that github fork their own version of git
389 2017-02-27T23:46:57  <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...
390 2017-02-27T23:46:57  *** AaronvanW has quit IRC
391 2017-02-27T23:47:13  <jeremyrubin> sipa:yeah, I think they should. It's not bitcoin :p
392 2017-02-27T23:47:22  <sipa> jeremyrubin: I think *git* should support sha2
393 2017-02-27T23:47:33  <luke-jr> jeremyrubin: to rephrase: you're saying GitHub should stop supporting git ;)
394 2017-02-27T23:47:37  <jeremyrubin> yeah, but it seems Linus has his head... somewhere
395 2017-02-27T23:47:48  <cfields> Linus' mail said it's in the works.. does it not exist somewhere?
396 2017-02-27T23:47:50  <jeremyrubin> They can support both?
397 2017-02-27T23:48:50  <jeremyrubin> No reason to not have git and gitsha2 available simultaneously.
398 2017-02-27T23:48:52  <sipa> i think i'd stop using github if they did that
399 2017-02-27T23:48:56  <dcousens> jeremyrubin: I suppose it depends on how its done... maybe its a soft-fork haha
400 2017-02-27T23:49:02  <sipa> it would feel like an embrace-and-extend
401 2017-02-27T23:50:11  <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
402 2017-02-27T23:50:22  <bsm117532> Hey look it's zooko https://lwn.net/Articles/370907/
403 2017-02-27T23:52:59  <jeremyrubin> I guess I should be more vocal as a customer :p
404 2017-02-27T23:59:41  <jeremyrubin> emailed github support asking what they're doing :p