12017-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
  22017-02-27T00:21:11  *** rgrant has joined #bitcoin-core-dev
  32017-02-27T00:25:35  *** wudayoda has quit IRC
  42017-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
  52017-02-27T00:33:58  *** MarcoFalke has left #bitcoin-core-dev
  62017-02-27T00:37:32  *** Chris_Stewart_5 has quit IRC
  72017-02-27T00:41:03  *** wudayoda has joined #bitcoin-core-dev
  82017-02-27T00:43:26  *** ebfull has joined #bitcoin-core-dev
  92017-02-27T00:45:57  *** wudayoda has quit IRC
 102017-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
 112017-02-27T00:48:38  <rgrant> here in the code is this tension resolved?
 122017-02-27T00:56:02  *** wolfspraul has quit IRC
 132017-02-27T00:56:53  <sipa> rgrant: segwit transactions are non-standard to old nodes
 142017-02-27T00:56:53  *** wolfspraul has joined #bitcoin-core-dev
 152017-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)
 162017-02-27T00:58:25  <rgrant> yes, this describes an attack.  but what makes the attack block invalid?
 172017-02-27T00:58:45  <sipa> to whom?
 182017-02-27T00:59:20  <rgrant> to segwit-enabled nodes and miners
 192017-02-27T00:59:34  <sipa> the segwit consensus rules?
 202017-02-27T00:59:44  *** chjj has quit IRC
 212017-02-27T01:00:10  <sipa> in script/interpreter.h there is a flag SCRIPT_VERIFY_WITNESS
 222017-02-27T01:00:32  * rgrant follows along
 232017-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
 242017-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
 252017-02-27T01:01:49  <rgrant> but the attacker doesn't set bip9 (though bip9 has activated)
 262017-02-27T01:02:06  <sipa> yes
 272017-02-27T01:02:18  <sipa> that doesn't matter
 282017-02-27T01:02:31  <sipa> bip9 activation isn't dependent on the signalling of the block itself
 292017-02-27T01:02:40  <sipa> only on the signalling in the chain's history
 302017-02-27T01:05:01  *** belcher has quit IRC
 312017-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.
 322017-02-27T01:08:47  <sipa> what do you mean by rewrites?
 332017-02-27T01:09:33  <rgrant> well, attacker wants to use the "anyonecanspend" interpretation of the segwit tx, under the old rules.
 342017-02-27T01:09:58  <rgrant> so they just thorw away the witness
 352017-02-27T01:11:42  <sipa> ah
 362017-02-27T01:12:18  <sipa> under segwit rules, a segwit output can only be spent by an input that has a witness
 372017-02-27T01:12:18  *** alpalp has joined #bitcoin-core-dev
 382017-02-27T01:12:18  *** alpalp has joined #bitcoin-core-dev
 392017-02-27T01:12:37  <sipa> the attacker can't control whether the witness flag is set in other nodes
 402017-02-27T01:13:07  <rgrant> is that over in CheckInputs?
 412017-02-27T01:13:16  <sipa> no, in the script code
 422017-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
 432017-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
 442017-02-27T01:14:56  <rgrant> okay, i get the mechanism.  now i'm still trying to hunt down the code.
 452017-02-27T01:15:57  <rgrant> (also, does this make segwit outputs viral?)
 462017-02-27T01:16:47  <rgrant> wait, the input block needs to have a witness, or the input script?
 472017-02-27T01:17:32  * rgrant is confused.  
 482017-02-27T01:21:53  <sipa> the txin spending a witness output has to have a txinwitness
 492017-02-27T01:22:17  <sipa> which implies that the block that that txin is in must be a witness block
 502017-02-27T01:23:07  <rgrant> thanks.  and it can be spent to any address.  it's not viral.
 512017-02-27T01:23:23  <sipa> right, the outputs don't care
 522017-02-27T01:30:23  *** belcher has joined #bitcoin-core-dev
 532017-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
 542017-02-27T02:00:48  *** rgrant has left #bitcoin-core-dev
 552017-02-27T02:04:15  *** Ylbam has quit IRC
 562017-02-27T02:42:11  *** wudayoda has joined #bitcoin-core-dev
 572017-02-27T02:46:30  *** wudayoda has quit IRC
 582017-02-27T02:53:47  *** wudayoda has joined #bitcoin-core-dev
 592017-02-27T02:55:10  *** JackH has quit IRC
 602017-02-27T02:58:27  *** wudayoda has quit IRC
 612017-02-27T03:26:25  *** alpalp has quit IRC
 622017-02-27T03:33:51  *** wudayoda has joined #bitcoin-core-dev
 632017-02-27T03:38:27  *** wudayoda has quit IRC
 642017-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
 652017-02-27T03:45:10  <gmaxwell> luke-jr: are you going to rebase the remaining multiwallet support now that 0.15 has started?
 662017-02-27T03:45:29  <luke-jr> gmaxwell: again? I just did yesterday O.o
 672017-02-27T03:46:13  <gmaxwell> oh sorry!
 682017-02-27T03:46:15  <luke-jr> hmm, I wonder why Travis is whining
 692017-02-27T03:48:33  <gmaxwell> s/are you going to rebase/are you going to fix the travis errors/  :P
 702017-02-27T03:49:34  <luke-jr> yes ;)
 712017-02-27T03:50:13  <luke-jr> assuming it's not yet another false positive anyway
 722017-02-27T03:55:46  *** dodomojo has joined #bitcoin-core-dev
 732017-02-27T04:02:16  *** justan0theruser has quit IRC
 742017-02-27T04:02:24  *** justanotheruser has joined #bitcoin-core-dev
 752017-02-27T04:11:33  *** dodomojo has quit IRC
 762017-02-27T04:23:09  *** alpalp has joined #bitcoin-core-dev
 772017-02-27T04:23:09  *** alpalp has joined #bitcoin-core-dev
 782017-02-27T04:30:23  *** alpalp has quit IRC
 792017-02-27T05:04:26  *** chjj has joined #bitcoin-core-dev
 802017-02-27T05:23:14  *** Giszmo has quit IRC
 812017-02-27T05:26:06  *** dcousens has joined #bitcoin-core-dev
 822017-02-27T05:26:17  <dcousens> petertodd: lol,  I guess I'll sit this one out then :)
 832017-02-27T05:27:21  <dcousens> Did seem difficult to find documentation/material on what you two are referring too though
 842017-02-27T05:28:02  *** Guest91228 has quit IRC
 852017-02-27T05:31:13  *** Cory has joined #bitcoin-core-dev
 862017-02-27T05:32:17  <sipa> likewise
 872017-02-27T05:32:28  <sipa> i was confused by the same SE answer :)
 882017-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
 892017-02-27T05:34:19  <sipa> cool
 902017-02-27T05:34:24  <dcousens> cheers achow101
 912017-02-27T05:34:37  *** wudayoda has joined #bitcoin-core-dev
 922017-02-27T05:38:57  *** wudayoda has quit IRC
 932017-02-27T05:46:36  <sipa> achow101: it's not perfect w.r.t. the commit, only for the tree
 942017-02-27T05:46:56  <sipa> so an attack on the commit's claimed history would still apply
 952017-02-27T05:47:33  *** justan0theruser has joined #bitcoin-core-dev
 962017-02-27T05:48:52  <achow101> sipa: you mean like if someone faked a commit history with a colliding parent commit hash?
 972017-02-27T05:49:45  <sipa> yes, and the same resulting tree
 982017-02-27T05:49:48  *** justanotheruser has quit IRC
 992017-02-27T05:50:15  <sipa> which is certainly much less worrying
1002017-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?
1012017-02-27T05:51:08  <sipa> well a commit object in git is both a resulting tree and a history for it
1022017-02-27T05:51:32  <sipa> with this method we're only avoiding SHA1 for the tree
1032017-02-27T05:52:38  <achow101> right.
1042017-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?
1052017-02-27T05:57:12  <sipa> interesting idea
1062017-02-27T05:58:32  <achow101> actually that only happens on builds of master, not any of the releases, so not particularly important
1072017-02-27T06:06:30  *** paveljanik has quit IRC
1082017-02-27T06:14:38  *** wudayoda has joined #bitcoin-core-dev
1092017-02-27T06:15:51  *** lclc has joined #bitcoin-core-dev
1102017-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.
1112017-02-27T06:18:57  *** wudayoda has quit IRC
1122017-02-27T06:19:43  <achow101> wumpus: ok
1132017-02-27T06:44:55  *** wudayoda has joined #bitcoin-core-dev
1142017-02-27T06:49:27  *** wudayoda has quit IRC
1152017-02-27T06:55:07  <dcousens> wumpus: true, nevermind
1162017-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
1172017-02-27T06:59:22  <dcousens> (e.g https://stackoverflow.com/questions/1951519/when-should-i-use-stdsize-t)
1182017-02-27T07:01:48  <wumpus> it just doesn't matter here
1192017-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
1202017-02-27T07:03:00  <dcousens> not worth discussing any further :)
1212017-02-27T07:03:19  <wumpus> this was meant as a quick fix to get an compileissue out of the way
1222017-02-27T07:03:22  <wumpus> indeed, no need to drag it out
1232017-02-27T07:07:47  *** dcousens has quit IRC
1242017-02-27T07:08:04  *** dcousens has joined #bitcoin-core-dev
1252017-02-27T07:08:44  <wumpus> whoa, did I still manage to make it fail travis?
1262017-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
1272017-02-27T07:11:09  <wumpus> I'm in good company, even "move comment" pulls fail
1282017-02-27T07:11:20  <dcousens> ha
1292017-02-27T07:22:19  <wumpus> looks like there is another intermittent travis issue: timeouts in make check (probably test_bitcoin related too)
1302017-02-27T07:25:00  *** wudayoda has joined #bitcoin-core-dev
1312017-02-27T07:27:07  <gmaxwell> test_bitcoin is really slow...
1322017-02-27T07:28:11  <wumpus> well it hangs *before* the "N testcases" line... it's not supposed to spend *any* time there
1332017-02-27T07:29:27  <wumpus> still haven't managed to catch the test_bitcoin mutex issue, this may be a different symptom of it
1342017-02-27T07:29:27  *** wudayoda has quit IRC
1352017-02-27T07:33:52  <wumpus> this is making travis as good as useless
1362017-02-27T07:36:04  <gmaxwell> maybe we need to start making PRs with most of test_bitcoin commented out?
1372017-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
1382017-02-27T07:37:43  <wumpus> bisecting might work, though that's difficult with unrelabile reprodicibility
1392017-02-27T07:37:59  <wumpus> e.g. go way back and find the commit where this started
1402017-02-27T07:38:54  <wumpus> the funny thing is that #9851 is passing every single time now that I added debug information
1412017-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
1422017-02-27T07:39:07  <gmaxwell> it fails enough perhaps that just retrying each step 5 times might be enough.
1432017-02-27T07:39:08  <wumpus> if that's not a classic example of a heisenbug I don't know
1442017-02-27T07:39:20  *** owowo has quit IRC
1452017-02-27T07:40:27  <wumpus> it seems to fail in runs, I wonder if it somehow gets cached on a PR
1462017-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
1472017-02-27T07:41:40  *** BashCo_ has quit IRC
1482017-02-27T07:46:45  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6206252e5073...c7e57ce98154
1492017-02-27T07:46:46  <bitcoin-git> bitcoin/master 864890a Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
1502017-02-27T07:46:46  <bitcoin-git> bitcoin/master c7e57ce Wladimir J. van der Laan: Merge #9839: [qa] Make import-rescan.py watchonly check reliable...
1512017-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
1522017-02-27T07:52:06  <wumpus> cfields: is it possible to download a PR's cache remotely?
1532017-02-27T08:04:27  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/eddaa6b35d41aefead1a57ea54e7e15ce069f79a
1542017-02-27T08:04:28  <bitcoin-git> bitcoin/0.14 eddaa6b Russell Yanofsky: [qa] Make import-rescan.py watchonly check reliable...
1552017-02-27T08:04:33  <wumpus> hm no, never mind, I don't think that's going to help at all either...
1562017-02-27T08:04:40  *** BashCo has joined #bitcoin-core-dev
1572017-02-27T08:05:04  *** wudayoda has joined #bitcoin-core-dev
1582017-02-27T08:09:27  *** wudayoda has quit IRC
1592017-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
1602017-02-27T08:28:32  *** str4d has joined #bitcoin-core-dev
1612017-02-27T08:49:05  *** paveljanik has joined #bitcoin-core-dev
1622017-02-27T08:49:05  *** paveljanik has joined #bitcoin-core-dev
1632017-02-27T08:51:14  *** moli_ has quit IRC
1642017-02-27T09:13:55  *** afk11 has quit IRC
1652017-02-27T09:14:19  *** arubi has quit IRC
1662017-02-27T09:14:43  *** wasi has quit IRC
1672017-02-27T09:22:46  *** JackH has joined #bitcoin-core-dev
1682017-02-27T09:27:18  *** wasi has joined #bitcoin-core-dev
1692017-02-27T09:27:31  *** afk11 has joined #bitcoin-core-dev
1702017-02-27T09:27:45  *** arubi has joined #bitcoin-core-dev
1712017-02-27T09:29:40  *** Guyver2 has joined #bitcoin-core-dev
1722017-02-27T09:30:57  *** str4d has quit IRC
1732017-02-27T09:35:09  *** paveljanik has quit IRC
1742017-02-27T09:38:03  *** str4d has joined #bitcoin-core-dev
1752017-02-27T09:38:45  *** Ylbam has joined #bitcoin-core-dev
1762017-02-27T09:44:02  *** AaronvanW has joined #bitcoin-core-dev
1772017-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*
1782017-02-27T09:45:26  <gribble> https://github.com/bitcoin/bitcoin/issues/9825 | Intermittent FAIL: test/test_bitcoin in Travis · Issue #9825 · bitcoin/bitcoin · GitHub
1792017-02-27T09:54:23  *** str4d has quit IRC
1802017-02-27T10:01:03  *** wasi has quit IRC
1812017-02-27T10:01:22  *** wasi has joined #bitcoin-core-dev
1822017-02-27T10:06:01  *** wudayoda has joined #bitcoin-core-dev
1832017-02-27T10:10:27  *** wudayoda has quit IRC
1842017-02-27T10:33:20  *** jannes has joined #bitcoin-core-dev
1852017-02-27T10:34:14  <Victorsueca> wumpus: it's a quantum bug
1862017-02-27T10:46:03  *** wudayoda has joined #bitcoin-core-dev
1872017-02-27T10:46:20  <luke-jr> ew, we were using printf for hex strings?
1882017-02-27T10:50:27  *** wudayoda has quit IRC
1892017-02-27T10:53:27  *** chjj has quit IRC
1902017-02-27T11:06:20  <wumpus> yes, fairly sure that code is inherited from satoshi
1912017-02-27T11:18:19  * luke-jr peers at Travis giving him a restart button that doesn't work
1922017-02-27T11:18:33  <luke-jr> can someone restart the two non-passing https://travis-ci.org/bitcoin/bitcoin/builds/205383975 ?
1932017-02-27T11:18:38  <luke-jr> I can't see any issue to fix
1942017-02-27T11:19:27  *** rafalcpp has quit IRC
1952017-02-27T11:23:21  <wumpus> sure...
1962017-02-27T11:23:30  <wumpus> Victorsueca: either that or we need an exorcist
1972017-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)"
1982017-02-27T11:24:57  <luke-jr> I can't reproduce it :/
1992017-02-27T11:25:20  <Victorsueca> maybe the code is ok and the problem is at travis?
2002017-02-27T11:25:55  <wumpus> luke-jr: restarting it...
2012017-02-27T11:25:58  *** wudayoda has joined #bitcoin-core-dev
2022017-02-27T11:26:17  <wumpus> Victorsueca: it's possible, though that doesn't explain why it always fails in the same (or similar) place
2032017-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
2042017-02-27T11:27:40  <luke-jr> hmm, I wonder..
2052017-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
2062017-02-27T11:29:51  *** chjj has joined #bitcoin-core-dev
2072017-02-27T11:30:27  *** wudayoda has quit IRC
2082017-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?
2092017-02-27T11:42:56  *** moli_ has joined #bitcoin-core-dev
2102017-02-27T12:05:06  *** BashCo_ has joined #bitcoin-core-dev
2112017-02-27T12:06:05  *** wudayoda has joined #bitcoin-core-dev
2122017-02-27T12:07:40  *** BashCo has quit IRC
2132017-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
2142017-02-27T12:10:22  <luke-jr> I wonder if that's the cause - signrawtransaction can use the wallet when available
2152017-02-27T12:10:25  <wumpus> but yes any test after that that assumes pwalletMain is set to something will crash or do bad things
2162017-02-27T12:10:27  *** wudayoda has quit IRC
2172017-02-27T12:10:34  <luke-jr> I just can't reproduce to confirm
2182017-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?
2192017-02-27T12:11:17  <wumpus> yes, you might be on to something
2202017-02-27T12:12:05  <wumpus> the next test using the walletMain after that will corrupt
2212017-02-27T12:12:15  <wumpus> +the stack
2222017-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
2232017-02-27T12:30:55  *** alpalp has joined #bitcoin-core-dev
2242017-02-27T12:37:01  *** d9b4bef9 has quit IRC
2252017-02-27T12:38:14  *** d9b4bef9 has joined #bitcoin-core-dev
2262017-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
2272017-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?
2282017-02-27T12:43:54  *** MarcoFalke has joined #bitcoin-core-dev
2292017-02-27T12:44:01  <wumpus> yes, will re-trigger after travis finishes on master
2302017-02-27T12:53:53  <wumpus> which it did
2312017-02-27T13:02:08  <wumpus> luke-jr: still the same issue in your pull, unfortunately: https://travis-ci.org/bitcoin/bitcoin/jobs/205383977#L2475
2322017-02-27T13:02:13  <luke-jr> :/
2332017-02-27T13:03:26  <luke-jr> why doesn't it give any details on the exception?
2342017-02-27T13:04:20  <wumpus> yes pretty crappy. You could try adding your own catch{} around it temporarily
2352017-02-27T13:07:05  * luke-jr ponders why this is mingw-specific
2362017-02-27T13:15:08  <wumpus> luke-jr: you'll need to remove the BOOST_CHECK_NO_THROW( too
2372017-02-27T13:15:21  <luke-jr> oh
2382017-02-27T13:15:24  <wumpus> otherwise that will catch it for you
2392017-02-27T13:18:57  *** nickler has quit IRC
2402017-02-27T13:21:36  *** nickler has joined #bitcoin-core-dev
2412017-02-27T13:31:07  *** moli_ has quit IRC
2422017-02-27T13:32:55  *** moli_ has joined #bitcoin-core-dev
2432017-02-27T13:33:48  *** alpalp has quit IRC
2442017-02-27T13:51:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2452017-02-27T13:58:57  *** moli_ has quit IRC
2462017-02-27T14:03:32  *** moli_ has joined #bitcoin-core-dev
2472017-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
2482017-02-27T14:17:44  *** GreenIsMyPepper has quit IRC
2492017-02-27T14:48:01  *** rafalcpp has joined #bitcoin-core-dev
2502017-02-27T15:02:06  *** wudayoda has joined #bitcoin-core-dev
2512017-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
2522017-02-27T15:06:27  *** wudayoda has quit IRC
2532017-02-27T15:21:17  *** Giszmo has joined #bitcoin-core-dev
2542017-02-27T15:21:40  *** wudayoda has joined #bitcoin-core-dev
2552017-02-27T15:24:47  *** adiabat has quit IRC
2562017-02-27T15:25:57  *** wudayoda has quit IRC
2572017-02-27T15:30:02  *** wudayoda has joined #bitcoin-core-dev
2582017-02-27T15:31:42  *** lclc has quit IRC
2592017-02-27T15:41:53  *** mol has joined #bitcoin-core-dev
2602017-02-27T15:45:16  *** moli_ has quit IRC
2612017-02-27T15:50:02  *** eenoch_ is now known as eenoch
2622017-02-27T15:55:55  *** adiabat has joined #bitcoin-core-dev
2632017-02-27T16:03:27  *** abpa has joined #bitcoin-core-dev
2642017-02-27T16:03:55  *** wudayoda has quit IRC
2652017-02-27T16:04:57  *** abpa has quit IRC
2662017-02-27T16:06:24  *** wudayoda has joined #bitcoin-core-dev
2672017-02-27T16:17:17  <morcos> wumpus: i think #9548 has enough ACK's if you want to merge
2682017-02-27T16:17:19  <gribble> https://github.com/bitcoin/bitcoin/issues/9548 | Remove min reasonable fee by morcos · Pull Request #9548 · bitcoin/bitcoin · GitHub
2692017-02-27T16:20:39  *** nickler has quit IRC
2702017-02-27T16:24:05  *** nickler has joined #bitcoin-core-dev
2712017-02-27T16:30:32  *** harding has joined #bitcoin-core-dev
2722017-02-27T16:32:17  *** paveljanik has joined #bitcoin-core-dev
2732017-02-27T16:35:48  *** lclc has joined #bitcoin-core-dev
2742017-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
2752017-02-27T16:52:06  *** abpa has joined #bitcoin-core-dev
2762017-02-27T17:12:13  *** Giszmo has quit IRC
2772017-02-27T17:17:27  <luke-jr> wumpus: with the trys added, the same stuff won't fail :|
2782017-02-27T17:18:04  * luke-jr puts them before the try <.<
2792017-02-27T17:27:56  *** Giszmo has joined #bitcoin-core-dev
2802017-02-27T17:36:16  *** droark has quit IRC
2812017-02-27T17:40:15  *** adiabat has quit IRC
2822017-02-27T17:58:17  *** BashCo_ has quit IRC
2832017-02-27T17:58:51  *** wudayoda has quit IRC
2842017-02-27T18:09:44  *** bsm1175322 has joined #bitcoin-core-dev
2852017-02-27T18:21:43  *** wudayoda has joined #bitcoin-core-dev
2862017-02-27T18:29:24  *** lclc has quit IRC
2872017-02-27T18:38:51  *** lightningbot has joined #bitcoin-core-dev
2882017-02-27T18:43:30  *** justan0theruser has quit IRC
2892017-02-27T18:59:15  *** justan0theruser has joined #bitcoin-core-dev
2902017-02-27T19:35:04  *** lclc has joined #bitcoin-core-dev
2912017-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
2922017-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?
2932017-02-27T19:52:36  *** nickler has quit IRC
2942017-02-27T19:53:51  *** nickler has joined #bitcoin-core-dev
2952017-02-27T19:56:52  *** jnewbery has quit IRC
2962017-02-27T19:57:12  <sipa> Chris_Stewart_5: it's exactly designed to test that
2972017-02-27T19:57:41  <sipa> duplicate txids in the tree are invalid
2982017-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
2992017-02-27T20:00:39  <sipa> Chris_Stewart_5: "filtered out"?
3002017-02-27T20:00:49  <sipa> Chris_Stewart_5: a block with duplicate txids is invalid in the first place
3012017-02-27T20:01:08  <sipa> it can't ever occur in any block we have
3022017-02-27T20:03:56  <sipa> by definition such a block would have a double spend
3032017-02-27T20:04:04  <Chris_Stewart_5> Yeah, I guess I was getting confused with 'MerkleBlocks' and just merkle tree computations
3042017-02-27T20:05:03  <Chris_Stewart_5> and they aren't conceptually the same tree
3052017-02-27T20:05:53  <sipa> yes they are...
3062017-02-27T20:06:12  <sipa> a MerkleBlock is just the merkle tree of a block with some branches removed
3072017-02-27T20:07:02  <sipa> it couldn't prove anything if it wasn't the same tree
3082017-02-27T20:07:20  *** lclc has quit IRC
3092017-02-27T20:08:29  <Chris_Stewart_5> Ok, help me understand this then.
3102017-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
3112017-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?
3122017-02-27T20:09:25  <Chris_Stewart_5> and just provide the hash for 'f'
3132017-02-27T20:09:29  <sipa> that's about how the merkle root hash is computed
3142017-02-27T20:09:34  <sipa> not what is in it
3152017-02-27T20:09:45  <sipa> it's illegal for a transaction to be repeated inside a block
3162017-02-27T20:10:11  *** lclc has joined #bitcoin-core-dev
3172017-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_
3182017-02-27T20:10:36  <sipa> that case is handled in the else branch of the MerkleBlock code you linked to
3192017-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?
3202017-02-27T20:17:57  <BlueMatt> most mysterious travis failure ever: https://travis-ci.org/bitcoin/bitcoin/builds/205914634
3212017-02-27T20:18:04  <BlueMatt> no log?
3222017-02-27T20:18:06  <sipa> Chris_Stewart_5: yes?
3232017-02-27T20:18:15  <sipa> Chris_Stewart_5: but you're not duplicating the transaction in the tree
3242017-02-27T20:18:30  <sipa> Chris_Stewart_5: you're just duplicating an entry when computing the next level
3252017-02-27T20:18:48  <sipa> just read the code
3262017-02-27T20:19:35  <sipa> Chris_Stewart_5: https://github.com/bitcoin/bitcoin/blob/master/src/merkleblock.cpp#L119-L128
3272017-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
3282017-02-27T20:20:28  <sipa> only in the first one we require the two lower level hashes to be different
3292017-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
3302017-02-27T20:20:58  <Chris_Stewart_5> yeah, that is what i was missing. Thanks.
3312017-02-27T20:24:51  *** lclc_ has joined #bitcoin-core-dev
3322017-02-27T20:26:17  *** lclc has quit IRC
3332017-02-27T20:33:01  <luke-jr> wumpus: weird, re-pushing with a new commit-id (no code changes) passes Travis now
3342017-02-27T20:36:25  *** BashCo has joined #bitcoin-core-dev
3352017-02-27T21:09:26  *** lclc_ has quit IRC
3362017-02-27T21:12:29  *** lclc has joined #bitcoin-core-dev
3372017-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
3382017-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
3392017-02-27T21:14:22  <sipa> petertodd: i don't think that's useful without reviewing that code myself :)
3402017-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
3412017-02-27T21:16:13  <sipa> it seems my gpg key (which was created in 2015) used sha1 to sign the subkeys
3422017-02-27T21:16:19  <sipa> horror.
3432017-02-27T21:16:41  <petertodd> heh, yeah, I think the defaults were changed pretty recently...
3442017-02-27T21:18:15  *** wudayoda has quit IRC
3452017-02-27T21:20:28  *** wudayoda has joined #bitcoin-core-dev
3462017-02-27T21:23:31  *** wasi has quit IRC
3472017-02-27T21:24:57  *** lclc has quit IRC
3482017-02-27T21:28:57  *** jtimon has joined #bitcoin-core-dev
3492017-02-27T21:32:42  *** wasi has joined #bitcoin-core-dev
3502017-02-27T21:35:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/94e5ba9ba290...88c2ae3ed2bb
3512017-02-27T21:35:09  <bitcoin-git> bitcoin/master 988ce2d Chris Stewart: Adding 'amount' label to tx_valid/tx_invalid.json files
3522017-02-27T21:35:10  <bitcoin-git> bitcoin/master 88c2ae3 MarcoFalke: Merge #9350: [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json...
3532017-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
3542017-02-27T21:42:06  *** laurentmt has joined #bitcoin-core-dev
3552017-02-27T22:02:16  *** jnewbery has joined #bitcoin-core-dev
3562017-02-27T22:12:18  *** jannes has quit IRC
3572017-02-27T22:20:01  *** laurentmt has quit IRC
3582017-02-27T22:30:18  *** droark has joined #bitcoin-core-dev
3592017-02-27T22:36:23  *** Guyver2 has quit IRC
3602017-02-27T22:36:45  *** wudayoda has quit IRC
3612017-02-27T22:37:32  *** wudayoda has joined #bitcoin-core-dev
3622017-02-27T22:43:57  *** wudayoda has quit IRC
3632017-02-27T22:49:52  <dcousens> petertodd: no problem :),  we all got there in the end :)
3642017-02-27T23:39:54  *** AaronvanW has quit IRC
3652017-02-27T23:40:37  *** MarcoFalke has left #bitcoin-core-dev
3662017-02-27T23:41:15  *** AaronvanW has joined #bitcoin-core-dev
3672017-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?
3682017-02-27T23:42:06  <sipa> what does github have to do with that?
3692017-02-27T23:42:26  <sipa> it's perhaps surprising that git itself never prioritized upgrading to a better hash function
3702017-02-27T23:42:31  <jeremyrubin> They have a lot of money on git
3712017-02-27T23:42:45  <jeremyrubin> it's like a bitcoin company not investing in any core dev ;)
3722017-02-27T23:42:50  <sipa> no
3732017-02-27T23:43:02  <sipa> it's like a bitcoin company not developing their own altcoin
3742017-02-27T23:43:13  <dcousens> haha
3752017-02-27T23:43:14  <jeremyrubin> Example:
3762017-02-27T23:43:21  <jeremyrubin> github could run an internal git chain
3772017-02-27T23:43:24  <jeremyrubin> using upgraded hashes
3782017-02-27T23:43:34  <dcousens> jeremyrubin: how do you know they don't?
3792017-02-27T23:43:43  <sipa> jeremyrubin: you're missing my point
3802017-02-27T23:43:56  <dcousens> GitHub is about compatibility with git
3812017-02-27T23:43:59  <jeremyrubin> could test it out pushing the broken pdfs :p
3822017-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
3832017-02-27T23:44:20  *** ebfull has quit IRC
3842017-02-27T23:44:37  <sipa> OR switching the hash function is hard, so nobody has a working version
3852017-02-27T23:45:05  <sipa> suggesting that github would do so without compatibility with git itself seems ridiculous
3862017-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
3872017-02-27T23:46:33  <jeremyrubin> Maybe I don't use very many tools on top of git
3882017-02-27T23:46:46  <sipa> you're literally saying here that github fork their own version of git
3892017-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...
3902017-02-27T23:46:57  *** AaronvanW has quit IRC
3912017-02-27T23:47:13  <jeremyrubin> sipa:yeah, I think they should. It's not bitcoin :p
3922017-02-27T23:47:22  <sipa> jeremyrubin: I think *git* should support sha2
3932017-02-27T23:47:33  <luke-jr> jeremyrubin: to rephrase: you're saying GitHub should stop supporting git ;)
3942017-02-27T23:47:37  <jeremyrubin> yeah, but it seems Linus has his head... somewhere
3952017-02-27T23:47:48  <cfields> Linus' mail said it's in the works.. does it not exist somewhere?
3962017-02-27T23:47:50  <jeremyrubin> They can support both?
3972017-02-27T23:48:50  <jeremyrubin> No reason to not have git and gitsha2 available simultaneously.
3982017-02-27T23:48:52  <sipa> i think i'd stop using github if they did that
3992017-02-27T23:48:56  <dcousens> jeremyrubin: I suppose it depends on how its done... maybe its a soft-fork haha
4002017-02-27T23:49:02  <sipa> it would feel like an embrace-and-extend
4012017-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
4022017-02-27T23:50:22  <bsm117532> Hey look it's zooko https://lwn.net/Articles/370907/
4032017-02-27T23:52:59  <jeremyrubin> I guess I should be more vocal as a customer :p
4042017-02-27T23:59:41  <jeremyrubin> emailed github support asking what they're doing :p