< jonasschnelli>
jcorgan: I have started with BIP151... sipa also mentioned he want to work on this
< sipa>
after the p2p network refactoringb:)
< jcorgan>
I'm mostly interested in authenticated addnode and connect over Tor, after which encryption is icing on the cake
< jcorgan>
but willing to spend cycles on 151 if it helps advance the cause
< gmaxwell>
jcorgan: our encryption is message auth + encryption, and auth needs message auth. the encryption is just gravy.
< wumpus>
yes tor authenticates the hidden service you connect to, it can't be used to authenticate the incoming connection
< wumpus>
so would still need something there
< jcorgan>
got it
< 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.
< 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
< wumpus>
(this way, the tor endpoint cannot sniff the connection, it could mitm though)
< jcorgan>
i always worry about exit nodes but they are really no different from any other chokepoint like an ISP
< 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).
< wumpus>
yes I also avoid exit nodes as much as possible, a lot of services are available as onion nowadays
< bitcoin-git>
[bitcoin] tjps opened pull request #10182: [scheduler] Switched CScheduler to C++11 threading primitives (master...tjps_scheduler) https://github.com/bitcoin/bitcoin/pull/10182
< 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
< wumpus>
yes the new HS stuff sounds interesting, haven't looked at it in detail yet
< jcorgan>
exit nodes are indeed crucial, but subject to both legal coercion and operation by less than friendly entities
< jcorgan>
so as usual being able to do end-to-end authentication oneself is the only way to mitigate.
< jcorgan>
as well as encryption using a key one can control, but with bitcoin traffic that seems less than essential
< 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
< 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
< wumpus>
well at least with HSes there are no exit nodes involved
< gmaxwell>
petertodd: if you get a chance, please timestamp e2337a7e94f62658180b763e9c1afb70577e32cdad2b06dfce839558912a123f
< bitcoin-git>
[bitcoin] KibbledJiveElkZoo opened pull request #10183: Don't default rescan on private/public key imports. (master...rpc_rescan_fixes) https://github.com/bitcoin/bitcoin/pull/10183
< jonasschnelli>
hmm... getaddrinfo on OSX seems not to respect the TTL... I get the same results as 1h ago from a seed.
< jonasschnelli>
No problem on linux (get fresh addresses every time I call getaddrinfo)
< bitcoin-git>
[bitcoin] NicolasDorier opened pull request #10184: [Wallet] Worst case performance improvement on KeyPool filtering (master...hdinternalperf) https://github.com/bitcoin/bitcoin/pull/10184
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #10185: [0.14] Mention dbcache memory changes in release notes (0.14...2017-04-relnotes-0.14.1) https://github.com/bitcoin/bitcoin/pull/10185
< BlueMatt>
cfields: do you have a take on #10182?
< 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 :(
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number (master...remove_SYNC_TRANSACTION_NOT_IN_BLOCK_magic_number) https://github.com/bitcoin/bitcoin/pull/10186
< cfields>
petertodd: neat!
< 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.
< jannes>
petertodd: nit: "Company using OpenTimeStamps" should be "Companies...", I guess.
< jcorgan>
what are the various version numbers (0.2, 0.3, etc.) seen in the uasf trackers? my google-fu has deserted me today
< instagibbs>
jcorgan, some other repo's numbering of bip148
< bincap>
jcorgan: there were some proposals, and they used various versions. activation date was other in old one afair
< jcorgan>
ah, got it
< wumpus>
I don't understand what's wrong with travis on master
< wumpus>
yes, well, I'm adding a was_succesful property to TestResult and putting the string check there
< jnewbery>
ok, let me know the PR number and I'm happy to review
< bitcoin-git>
[bitcoin] laanwj opened pull request #10187: tests: Fix test_runner return value in case of skipped test (master...2017_04_fix_tracis) https://github.com/bitcoin/bitcoin/pull/10187
< wumpus>
hrm the wallet_dump.py test seems to fail locally here
< jnewbery>
try clearing the cache
< jnewbery>
hd split causes a couple of tests to fail if the cache isn't cleared
< wumpus>
gah.. yes, afraid it is the cache again
< BlueMatt>
sipa: yo
< instagibbs>
I have "rm -r cache/" on hotkey by now
< jnewbery>
I'm tempted to PR removing the cache at the start of each test_runner run
< wumpus>
jnewbery: yes please
< 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
< 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
< jnewbery>
wumpus: agreed
< wumpus>
and for travis it won't even make a difference
< sipa>
BlueMatt: yes, you read it correctly
< 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
< sipa>
then at startup you process the blocks between Best and Upto, in that order
< BlueMatt>
ohoh, yes, i confused myself
< petertodd>
cfields: I think that's a good idea! though the guys who did the website might prefer that functionality be an "advanced" option
< 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
< petertodd>
jannes: thanks! filed a pull-req for that
< bitcoin-git>
[bitcoin] theuni opened pull request #10189: devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. (master...private-nodeid) https://github.com/bitcoin/bitcoin/pull/10189
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10190: Mining functional tests (including regression test for submitblock) (master...mining_functional_test) https://github.com/bitcoin/bitcoin/pull/10190
< 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
< 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
< cfields>
jtimon: hehe, glad you like it. I was going to poke you to check it out, but you beat me to it :)
< 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
< 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.
< jtimon>
right, and again trivial to rebase (just run the script again to rewrite the commit, trivial)
< cfields>
jtimon: yep
< jtimon>
I just saw it by accident but it is very exciting to me
< jtimon>
cfields: how stable is it? I saw you force pushed recently
< jtimon>
I assume a simple last minute fix
< cfields>
jtimon: i need to force probably one more time. Travis' environment is kinda weird, they build from a detached head
< jtimon>
cfields: let me know when you're finished, I want to test it by writting something else using it
< cfields>
jtimon: ok. Pushed. Finished if Travis is happy with that last one.
< 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"
< cfields>
sure, that makes sense
< jtimon>
it's a way to make it more explicit that those are easier to review thanks to the scripts
< 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.
< cfields>
(it works by detaching HEAD, reverting the commit in question, running the script, and comparing the result to HEAD^)
< cfields>
yep, agreed
< jtimon>
thanks for the heads up, I will copy the workdir just in case before using it
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #10192: Cache full script execution results in addition to signatures (master...2017-04-cache-scriptchecks) https://github.com/bitcoin/bitcoin/pull/10192
< BlueMatt>
^ 1.7x faster in naive braindead benchmark, yay
< * cfields>
suppresses his initial reaction and reads the PR in full
< gmaxwell>
It's logically the same as the ecdsa cache but more efficient most of the time.
< 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.
< gmaxwell>
)
< BlueMatt>
indeed, that is pointed out in the PR text
< BlueMatt>
the win I measured is just overhead of spinning up the sigcache stuff
< BlueMatt>
s/sigcache/sigcheck threads/
< BlueMatt>
and looping over the scripts, even with sigcache set to always return true
< 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.
< BlueMatt>
(hence why i stopped at 284k - thats the first block which has a tx which checks that a signature is NOT valid)
< BlueMatt>
yup
< cfields>
huh.
< gmaxwell>
BlueMatt: when you made the sigcache return true, where did you do that? pre or post its internal hashing?
< BlueMatt>
s/return false/return true/
< BlueMatt>
so post
< BlueMatt>
but compiler may have optimized it all out
< BlueMatt>
its internal hashing is cheap, though
< BlueMatt>
its just getting bytes out of the uint256
< gmaxwell>
not that internal hashing, the signature cache SHA256(message|pubkey|flags) and uses the result as the key.
< BlueMatt>
ohoh, very much post that
< BlueMatt>
sipa: did you misread the ")" in the patch?
< BlueMatt>
it is outside of getarg?
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #10125: Exit bitcoind immediately on shutdown instead of 200ms later (master...2017-03-faster-shutdown) https://github.com/bitcoin/bitcoin/pull/10125
< cfields>
jtimon: pushed one last version. Sorry. Really done now.
< jtimon>
cfields: awesome, no worries, was doing something else
< bitcoin-git>
bitcoin/master e96462f Wladimir J. van der Laan: tests: Fix test_runner return value in case of skipped test...
< bitcoin-git>
bitcoin/master b44adf9 MarcoFalke: Merge #10187: tests: Fix test_runner return value in case of skipped test...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10187: tests: Fix test_runner return value in case of skipped test (master...2017_04_fix_tracis) https://github.com/bitcoin/bitcoin/pull/10187
< 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
< 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
< jtimon>
now I'm mostly worried about GITHUB_MAX_OPENED_PRS_PER_PROJECT if everyone reviews 10189 like that :p