1 2017-04-11 00:43:53 0|bsm117532|Is there any way for a BIP37 SPV client to obtain the coinbase transaction, if he doesn't know its txid?
2 2017-04-11 02:13:58 0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10181: Include cleanup (06master...062017-04-10-includes) 02 https://github.com/bitcoin/bitcoin/pull/10181
3 2017-04-11 06:23:54 0|jonasschnelli|jcorgan: I have started with BIP151... sipa also mentioned he want to work on this
4 2017-04-11 06:57:44 0|sipa|after the p2p network refactoringb:)
5 2017-04-11 07:03:59 0|jcorgan|I'm mostly interested in authenticated addnode and connect over Tor, after which encryption is icing on the cake
6 2017-04-11 07:04:22 0|jcorgan|but willing to spend cycles on 151 if it helps advance the cause
7 2017-04-11 07:06:50 0|gmaxwell|jcorgan: our encryption is message auth + encryption, and auth needs message auth. the encryption is just gravy.
8 2017-04-11 07:08:10 0|wumpus|yes tor authenticates the hidden service you connect to, it can't be used to authenticate the incoming connection
9 2017-04-11 07:08:22 0|wumpus|so would still need something there
10 2017-04-11 07:10:26 0|jcorgan|got it
11 2017-04-11 07:11:26 0|jcorgan|let me know how i can fit in to your plans. time of course is always limited but this seems an area i can both help out in and is important to me personally.
12 2017-04-11 07:11:39 0|wumpus|encryption over tor hidden services is unnecessary, though I believe some sites do use e.g. https over tor to be able to have the tor endpoint communicate with the https endpoint "last mile" on an internal LAN encrypted
13 2017-04-11 07:12:14 0|wumpus|(this way, the tor endpoint cannot sniff the connection, it could mitm though)
14 2017-04-11 07:12:28 0|jcorgan|i always worry about exit nodes but they are really no different from any other chokepoint like an ISP
15 2017-04-11 07:12:33 0|gmaxwell|the HS encryption/auth is kind of weak, the HS-NG stuff is much stronger (and I believe even includes a post-quantum perfect forward secrecy, unless that didn't make it in).
16 2017-04-11 07:13:19 0|wumpus|yes I also avoid exit nodes as much as possible, a lot of services are available as onion nowadays
17 2017-04-11 07:16:40 0|bitcoin-git|[13bitcoin] 15tjps opened pull request #10182: [scheduler] Switched CScheduler to C++11 threading primitives (06master...06tjps_scheduler) 02 https://github.com/bitcoin/bitcoin/pull/10182
18 2017-04-11 07:16:51 0|wumpus|though I think it's mainly exit nodes that helped tor gain adoption, it's hard to get critical mass for an isolated network, as cjdns, i2p etc have found out
19 2017-04-11 07:17:41 0|wumpus|yes the new HS stuff sounds interesting, haven't looked at it in detail yet
20 2017-04-11 07:18:05 0|jcorgan|exit nodes are indeed crucial, but subject to both legal coercion and operation by less than friendly entities
21 2017-04-11 07:18:34 0|jcorgan|so as usual being able to do end-to-end authentication oneself is the only way to mitigate.
22 2017-04-11 07:19:27 0|jcorgan|as well as encryption using a key one can control, but with bitcoin traffic that seems less than essential
23 2017-04-11 07:19:42 0|wumpus|indeed; also exit node use is free, so what is the incentive. Seems lots of security researchers etc run them just to be able to sample traffic
24 2017-04-11 07:21:28 0|jcorgan|anyway, jonasschnelli, when you get the time clue me in on how best to help your efforts and i'll let you know what i can commit to
25 2017-04-11 07:21:44 0|wumpus|well at least with HSes there are no exit nodes involved
26 2017-04-11 07:57:22 0|gmaxwell|petertodd: if you get a chance, please timestamp e2337a7e94f62658180b763e9c1afb70577e32cdad2b06dfce839558912a123f
27 2017-04-11 09:42:24 0|bitcoin-git|[13bitcoin] 15KibbledJiveElkZoo opened pull request #10183: Don't default rescan on private/public key imports. (06master...06rpc_rescan_fixes) 02 https://github.com/bitcoin/bitcoin/pull/10183
28 2017-04-11 11:32:35 0|jonasschnelli|hmm... getaddrinfo on OSX seems not to respect the TTL... I get the same results as 1h ago from a seed.
29 2017-04-11 11:32:50 0|jonasschnelli|No problem on linux (get fresh addresses every time I call getaddrinfo)
30 2017-04-11 11:36:27 0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #10184: [Wallet] Worst case performance improvement on KeyPool filtering (06master...06hdinternalperf) 02 https://github.com/bitcoin/bitcoin/pull/10184
31 2017-04-11 13:32:08 0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10185: [0.14] Mention dbcache memory changes in release notes (060.14...062017-04-relnotes-0.14.1) 02 https://github.com/bitcoin/bitcoin/pull/10185
32 2017-04-11 13:33:08 0|BlueMatt|cfields: do you have a take on #10182?
33 2017-04-11 13:33:09 0|gribble|https://github.com/bitcoin/bitcoin/issues/10182 | [scheduler] Switched CScheduler to C++11 threading primitives by tjps ÷ Pull Request #10182 ÷ bitcoin/bitcoin ÷ GitHub
34 2017-04-11 14:11:01 0|cfields|BlueMatt: sure
35 2017-04-11 14:34:52 0|petertodd|gmaxwell: done. BTW there's a javascript timestamper on https://opentimestamps.org now, although it doesn't seem to work on my local version of firefox :(
36 2017-04-11 14:37:27 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number (06master...06remove_SYNC_TRANSACTION_NOT_IN_BLOCK_magic_number) 02 https://github.com/bitcoin/bitcoin/pull/10186
37 2017-04-11 14:45:46 0|cfields|petertodd: neat!
38 2017-04-11 14:47:01 0|cfields|petertodd: why not allow a hash to be specified though? It's a shame I'd have to read the javascript to be sure I'm not actually revealing my file.
39 2017-04-11 14:52:28 0|jannes|petertodd: nit: "Company using OpenTimeStamps" should be "Companies...", I guess.
40 2017-04-11 16:39:47 0|jcorgan|what are the various version numbers (0.2, 0.3, etc.) seen in the uasf trackers? my google-fu has deserted me today
41 2017-04-11 16:41:27 0|instagibbs|jcorgan, some other repo's numbering of bip148
42 2017-04-11 16:42:14 0|bincap|jcorgan: there were some proposals, and they used various versions. activation date was other in old one afair
43 2017-04-11 16:42:30 0|jcorgan|ah, got it
44 2017-04-11 17:37:30 0|wumpus|I don't understand what's wrong with travis on master
45 2017-04-11 17:37:47 0|wumpus|https://travis-ci.org/bitcoin/bitcoin/jobs/220971234 shows as a failed build, but the build, the unit tests and the functional tests seem to pass
46 2017-04-11 17:38:09 0|wumpus|same for https://travis-ci.org/bitcoin/bitcoin/jobs/220971232
47 2017-04-11 17:38:27 0|wumpus|did something mess up the return codes?
48 2017-04-11 17:39:22 0|BlueMatt|yes
49 2017-04-11 17:39:23 0|BlueMatt|"
50 2017-04-11 17:39:23 0|BlueMatt|"The command "if [ "$RUN_TESTS" = "true" ]; then test/functional/test_runner.py --coverage --quiet ${extended}; fi" exited with 1.
51 2017-04-11 17:39:28 0|BlueMatt|jnewbery:
52 2017-04-11 17:40:21 0|wumpus|oh I see, apparently it sees a skipped tests as a failure, in the final check
53 2017-04-11 17:40:51 0|BlueMatt|ahh, cool
54 2017-04-11 17:41:45 0|jnewbery|yes - my fault. Here: https://github.com/bitcoin/bitcoin/commit/63062bda1ac0b57cb92e663596650a6e42508f15#diff-a5b9b84e3a3387476629e74ddb227a7eL271
55 2017-04-11 17:41:54 0|jnewbery|it'll only cause travis to fail for cron jobs
56 2017-04-11 17:42:01 0|jnewbery|sorry. I'll PR a fix
57 2017-04-11 17:42:33 0|wumpus|already working on it
58 2017-04-11 17:44:05 0|jnewbery|s/test_result.status == "Passed"/test_result.status != "Failed"/
59 2017-04-11 17:45:27 0|wumpus|yes, well, I'm adding a was_succesful property to TestResult and putting the string check there
60 2017-04-11 17:47:00 0|jnewbery|ok, let me know the PR number and I'm happy to review
61 2017-04-11 17:52:55 0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10187: tests: Fix test_runner return value in case of skipped test (06master...062017_04_fix_tracis) 02 https://github.com/bitcoin/bitcoin/pull/10187
62 2017-04-11 18:02:06 0|wumpus|hrm the wallet_dump.py test seems to fail locally here
63 2017-04-11 18:07:06 0|jnewbery|try clearing the cache
64 2017-04-11 18:07:27 0|jnewbery|hd split causes a couple of tests to fail if the cache isn't cleared
65 2017-04-11 18:08:30 0|wumpus|gah.. yes, afraid it is the cache again
66 2017-04-11 18:09:31 0|BlueMatt|sipa: yo
67 2017-04-11 18:10:20 0|instagibbs|I have "rm -r cache/" on hotkey by now
68 2017-04-11 18:10:44 0|jnewbery|I'm tempted to PR removing the cache at the start of each test_runner run
69 2017-04-11 18:11:15 0|wumpus|jnewbery: yes please
70 2017-04-11 18:12:06 0|BlueMatt|sipa: I'm super confused on #10148: did you get hashUpto and hashBest confused in ReplayBlocks? The way I read BatchWrite hashBest is the block which has been fully flushed, upto is the possible-partially-flushed tip. But ReplayBlocks seems to use them the other way
71 2017-04-11 18:12:08 0|gribble|https://github.com/bitcoin/bitcoin/issues/10148 | Use non-atomic flushing with block replay by sipa ÷ Pull Request #10148 ÷ bitcoin/bitcoin ÷ GitHub
72 2017-04-11 18:12:35 0|wumpus|adds a few seconds to the test run in worst-case, but saves a lot of seconds in thinking/troubleshooting time when the tests fail for inexplcable reasons again
73 2017-04-11 18:13:28 0|jnewbery|wumpus: agreed
74 2017-04-11 18:14:01 0|wumpus|and for travis it won't even make a difference
75 2017-04-11 18:29:17 0|sipa|BlueMatt: yes, you read it correctly
76 2017-04-11 18:31:26 0|sipa|you first update upto, so that if you crash in the middle, Best is still the old best, and Upto is the new one
77 2017-04-11 18:31:51 0|sipa|then at startup you process the blocks between Best and Upto, in that order
78 2017-04-11 18:32:32 0|BlueMatt|ohoh, yes, i confused myself
79 2017-04-11 19:23:45 0|petertodd|cfields: I think that's a good idea! though the guys who did the website might prefer that functionality be an "advanced" option
80 2017-04-11 19:24:16 0|petertodd|cfields: also, there's actually a hex operator in the opentimestamps standard, so if you timestamp a file containing a hex-encoded digest, you can later convert that into a timestamp directly on the file itself
81 2017-04-11 19:30:42 0|petertodd|jannes: thanks! filed a pull-req for that
82 2017-04-11 20:15:37 0|cfields|petertodd: ah, sha256d finally explained :p
83 2017-04-11 20:35:39 0|bitcoin-git|[13bitcoin] 15theuni opened pull request #10189: devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. (06master...06private-nodeid) 02 https://github.com/bitcoin/bitcoin/pull/10189
84 2017-04-11 20:52:57 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10190: Mining functional tests (including regression test for submitblock) (06master...06mining_functional_test) 02 https://github.com/bitcoin/bitcoin/pull/10190
85 2017-04-11 20:59:30 0|jtimon|cfields: #10189 is awesome! independently of it being validated by travis (which is awesome), if I had used scripts instead of emacs and kept them in the commit messages like here some disruptive would have been so simple to rebase and review (I mean, not that that kind of change is hard to review, but even simpler with this). Now it seems so obvious that I feel kind of stupid for not having thought about it before
86 2017-04-11 20:59:31 0|gribble|https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni ÷ Pull Request #10189 ÷ bitcoin/bitcoin ÷ GitHub
87 2017-04-11 21:00:29 0|cfields|jtimon: hehe, glad you like it. I was going to poke you to check it out, but you beat me to it :)
88 2017-04-11 21:02:34 0|cfields|jtimon: and now we have some incentive to write a few simple scripts to move chunks of code around. Combining those two things, that should make reviewing move-only changes much simpler
89 2017-04-11 21:03:19 0|cfields|ofc they still have to be reviewed for correctness (and correctness of the script), but at least it's easy to see where the changes come from.
90 2017-04-11 21:04:21 0|jtimon|right, and again trivial to rebase (just run the script again to rewrite the commit, trivial)
91 2017-04-11 21:04:41 0|cfields|jtimon: yep
92 2017-04-11 21:04:41 0|jtimon|I just saw it by accident but it is very exciting to me
93 2017-04-11 21:06:11 0|jtimon|cfields: how stable is it? I saw you force pushed recently
94 2017-04-11 21:06:33 0|jtimon|I assume a simple last minute fix
95 2017-04-11 21:06:41 0|cfields|jtimon: i need to force probably one more time. Travis' environment is kinda weird, they build from a detached head
96 2017-04-11 21:09:26 0|jtimon|cfields: let me know when you're finished, I want to test it by writting something else using it
97 2017-04-11 21:10:01 0|cfields|jtimon: ok. Pushed. Finished if Travis is happy with that last one.
98 2017-04-11 21:11:35 0|jtimon|btw, maybe we could add something to the dev notes about using a specific prefix to identiy this kind of commit, maybe "scripted-diff: net: Use accessor rather than node's id directly" or "net: scripted-diff: Use accessor rather than node's id directly"
99 2017-04-11 21:15:21 0|cfields|sure, that makes sense
100 2017-04-11 21:16:15 0|jtimon|it's a way to make it more explicit that those are easier to review thanks to the scripts
101 2017-04-11 21:16:25 0|cfields|jtimon: be careful if you're using it locally. It uses your live repo/workdir. It attempts to put everything back the way it found it, but I certainly wouldn't trust that for now.
102 2017-04-11 21:17:23 0|cfields|(it works by detaching HEAD, reverting the commit in question, running the script, and comparing the result to HEAD^)
103 2017-04-11 21:17:28 0|cfields|yep, agreed
104 2017-04-11 21:17:31 0|jtimon|thanks for the heads up, I will copy the workdir just in case before using it
105 2017-04-11 21:29:23 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10191: [trivial] Remove unused submit block parameters argument (06master...06remove_submit_block_params) 02 https://github.com/bitcoin/bitcoin/pull/10191
106 2017-04-11 21:43:28 0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #10191: [trivial] Remove unused submit block parameters argument (06master...06remove_submit_block_params) 02 https://github.com/bitcoin/bitcoin/pull/10191
107 2017-04-11 21:57:32 0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10192: Cache full script execution results in addition to signatures (06master...062017-04-cache-scriptchecks) 02 https://github.com/bitcoin/bitcoin/pull/10192
108 2017-04-11 21:58:27 0|BlueMatt|^ 1.7x faster in naive braindead benchmark, yay
109 2017-04-11 22:11:02 0|gmaxwell|It's logically the same as the ecdsa cache but more efficient most of the time.
110 2017-04-11 22:11:23 0|gmaxwell|(except in the case of certian dos attacks, which is part of why we didn't change the signature cache to work that way.
111 2017-04-11 22:11:25 0|gmaxwell|)
112 2017-04-11 22:13:01 0|BlueMatt|indeed, that is pointed out in the PR text
113 2017-04-11 22:13:17 0|BlueMatt|the win I measured is just overhead of spinning up the sigcache stuff
114 2017-04-11 22:13:22 0|BlueMatt|s/sigcache/sigcheck threads/
115 2017-04-11 22:13:33 0|BlueMatt|and looping over the scripts, even with sigcache set to always return true
116 2017-04-11 22:13:50 0|gmaxwell|well it's also just a lot less work, doesn't have to run the signature hashing, doesn't have to hash the message hash to look up in the cash, does a lot less lookup.
117 2017-04-11 22:13:59 0|BlueMatt|(hence why i stopped at 284k - thats the first block which has a tx which checks that a signature is NOT valid)
118 2017-04-11 22:14:05 0|BlueMatt|yup
119 2017-04-11 22:18:36 0|cfields|huh.
120 2017-04-11 22:20:40 0|gmaxwell|BlueMatt: when you made the sigcache return true, where did you do that? pre or post its internal hashing?
121 2017-04-11 22:20:54 0|BlueMatt|s/return false/return true/
122 2017-04-11 22:20:56 0|BlueMatt|so post
123 2017-04-11 22:21:01 0|BlueMatt|but compiler may have optimized it all out
124 2017-04-11 22:21:06 0|BlueMatt|its internal hashing is cheap, though
125 2017-04-11 22:21:14 0|BlueMatt|its just getting bytes out of the uint256
126 2017-04-11 22:22:15 0|gmaxwell|not that internal hashing, the signature cache SHA256(message|pubkey|flags) and uses the result as the key.
127 2017-04-11 22:22:27 0|BlueMatt|ohoh, very much post that
128 2017-04-11 22:22:45 0|BlueMatt|sipa: did you misread the ")" in the patch?
129 2017-04-11 22:22:50 0|BlueMatt|it is outside of getarg?
130 2017-04-11 22:39:10 0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #10125: Exit bitcoind immediately on shutdown instead of 200ms later (06master...062017-03-faster-shutdown) 02 https://github.com/bitcoin/bitcoin/pull/10125
131 2017-04-11 22:46:18 0|cfields|jtimon: pushed one last version. Sorry. Really done now.
132 2017-04-11 22:59:00 0|jtimon|cfields: awesome, no worries, was doing something else
133 2017-04-11 22:59:46 0|bitcoin-git|13bitcoin/06master 14e96462f 15Wladimir J. van der Laan: tests: Fix test_runner return value in case of skipped test...
134 2017-04-11 22:59:46 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/67023e9004ba...b44adf92342a
135 2017-04-11 22:59:47 0|bitcoin-git|13bitcoin/06master 14b44adf9 15MarcoFalke: Merge #10187: tests: Fix test_runner return value in case of skipped test...
136 2017-04-11 23:00:15 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10187: tests: Fix test_runner return value in case of skipped test (06master...062017_04_fix_tracis) 02 https://github.com/bitcoin/bitcoin/pull/10187
137 2017-04-11 23:01:24 0|jtimon|but yeah, I plan to give a "tested ack by opening this other pr, making it fail on purpose as you can see in this travis link and then fixing it by squashing the part that was left out on purpuse" to #10189
138 2017-04-11 23:01:25 0|gribble|https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni ÷ Pull Request #10189 ÷ bitcoin/bitcoin ÷ GitHub
139 2017-04-11 23:05:02 0|jtimon|now I'm mostly worried about GITHUB_MAX_OPENED_PRS_PER_PROJECT if everyone reviews 10189 like that :p