--- Day changed Wed Nov 11 2015
00:05 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 244 seconds]
00:06 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
00:13 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 260 seconds]
00:13 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev
00:14 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
00:19 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 272 seconds]
00:22 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
00:23 -!- judomaster [d868caba@gateway/web/freenode/ip.216.104.202.186] has joined #bitcoin-core-dev
00:29 < wumpus> gmaxwell: heh it's things like that make me so fed up with C. in this case snprintf resturn specification is different per platform, so it could have been OK on windows, but on Linux it returns the length that the output would be without buffer limit. So if the application sends that many bytes to the network, and you control an arbitrary string input, you have a configurable memory contents leak :)
00:30 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
00:30 < wumpus> gmaxwell: which happens to be very useful if you need  to know the stack cookie and function addresses
00:34 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
00:40 < Luke-Jr> wait what? snprintf doesn't do that on Windows? :/
00:40 < midnightmagic> miniupnpd (the other side of the coin) I'm not sure is any better. in the event that a client requests an impermissible port, rather than say something useful it instead says that doing so would conflict with an already existing mapping (which doesn't exist)
00:41 <@sipa>        Concerning the return value of snprintf(), SUSv2 and C99 contradict each other: when snprintf() is called with size=0 then SUSv2 stipulates an unspecified return value less  than
00:41 <@sipa>        1,  while  C99  allows  str to be NULL in this case, and gives the return value (as always) as the number of characters that would have been written in case the output string has
00:41 <@sipa>        been large enough.
00:41 <@sipa> snprintf doesn't exist in C89
00:42 < Luke-Jr> If len > count, count characters are stored in buffer, no null-terminator is appended, and a negative value is returned. <-- wtf Microsoft
00:43 <@sipa> That obeys the SUSv2 standard.
00:43 < wumpus> Luke-Jr: not just the return value, in multiple ways it doesn't behave the same on all platforms. we had issues due to that was well, one of the reasons why bitcoin core switched to a typesafe library for formatting that doesn't rely on libc
00:43 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
00:44 < wumpus> Luke-Jr: anyhow as C programmer you're supposed to know all these trivia, and if not you'll create awful security holes, there is zero leeway for human error
00:45 < Luke-Jr> If buffer is a null pointer and count is zero, len is returned as the count of characters required to format the output, not including the terminating null. To make a successful call with the same argument and locale parameters, allocate a buffer holding at least len + 1 characters.
00:45 < Luke-Jr> hm
00:45 < wumpus> yep.
00:47 < sipa> Luke-Jr: the 'best practice' way to use snprintf is with a wrapper that checks the return value, and if larger than the buffer size, reallocate to exactly that size, and if not, double it... and then retry
00:47 < Luke-Jr> "Also, some buggy older systems ignore the length and overrun the buffer (e.g., 64-bit Solaris 7)." -.-
00:47 < wumpus> another pet peeve with *printf is how the formatting characters are different per platform, at least for not-so-obscure types like 64 bit integers, size_t's, etc...
00:48 < sipa> or how putting type information in a string is just crazy
00:48 < wumpus> and then there is a header which sould privide handy macros for that.. **but it doesn't exist on every platform**
00:48 < wumpus> GRR...
00:48 < Luke-Jr> wumpus: PRId64
00:48 < wumpus> sipa: oh yes
00:48 < wumpus> Luke-Jr: no need to tell me :p
00:48 < Luke-Jr> what platform doesn't have it? :p
00:48 < wumpus> Luke-Jr: I find those issues because my head is filled with nonsense like that
00:49 < sipa> hey let's bypass the minimal type safety C provides, because converting any data to a string should be possible with a single function call
00:51 < wumpus> sipa: yes and initiallly to an arbitrary-length string, buffer limiting was introduced later, hey because it's an afterthought right :-) 
00:52 < sipa> i think when these functions were designed, the programmer and the user were considered to be one, and if you're writing outside of your buffer, well then you're just stupid and making your computer do weird things, right?
00:52 < wumpus> and then the format string vulnerabilities, in which someone accidentally passes a user-provided string to the first argument to *printf.  Those functions birthed whole classes of bugs.
00:52 < Luke-Jr> heh
00:53 < CodeShark> when these functions were designed they were just a convenience to avoid having to write directly to io devices in assembly language :p
00:53 < wumpus> sipa: true, many of it was before the networked world. What does it matter if you crash your MSX home computer :)
00:55 < Luke-Jr> oh well, is it really a security issue if I just say I require C99? :P
00:55 < Luke-Jr> then it's Windows at fault, right? <.<
00:55 < wumpus> Luke-Jr: then you exclude windows, which, now in 2015, still doesn't implement C99. I used to be angry about that, but now udnerstand they rightly have moved on from C :)
00:56 < wumpus> s/windows/MS compiler/
00:56 < CodeShark> type safety was a luxury back in the early 70's :p
00:56 < Luke-Jr> I already excluded MS compiler <.<
00:56 < Luke-Jr> I'm not sure MingW has a workaround for this snprintf thing though
00:57 < wumpus> but be careful: mingw behaves cameleon-like, in some things it's like posix in some ways it's like MSVC
00:57 < CodeShark> or even the late 70's for that matter :p
00:57 < wumpus> Luke-Jr: it behaves in the windows way
00:59 < wumpus> CodeShark: but all those ideas did originate from them, and other languages such as PASCAL were ahead of C in some ways
00:59 < wumpus> s/them/the 70's/
00:59 < CodeShark> true - PASCAL was far more heavily typed...if only it hadn't been so verbose :)
01:00 < wumpus> e.g. ADA, another dinosaur, has very strict types and array bounds checking
01:01 < CodeShark> ADA wasn't very practical for systems level programming, though
01:02 < CodeShark> but it did introduce a number of very important paradigms
01:02 < Luke-Jr> no, it looks like MingW is C99-compatible, at least with -std=c99
01:03 < sipa> it links against msvc's runtime, no?
01:03 < wumpus> right, I just mean that it is not the case that no one back then thought about security. Maybe it was the step from e.g. mainframes to home computers that lost a lot of knowledge. Suddenly doing things "fast" was more important than being robust :)
01:04 < Luke-Jr> sipa: in some cases, it will override stuff
01:04 < wumpus> Luke-Jr: please don't assume that affects strprintf
01:05 < Luke-Jr> you mean snprintf?
01:05 < wumpus> ye
01:05 < Luke-Jr> wumpus: I checked the headers
01:05 < Luke-Jr> it has an override *and* a comment explaining this
01:05 < wumpus> ok. Well you checked. I just said 'don't assume' :)
01:05 < Luke-Jr> ☺
01:06 < wumpus> maybe add a test that makes sure
01:06 < Luke-Jr> well, part of why I checked is, my code should have crashed badly if it got Windows behaviour :P
01:14 < GitHub126> [bitcoin] jonasschnelli opened pull request #6984: don't enforce maxuploadtarget's disconnect for whitelisted peers (master...2015/11/maxupload_whitebind) https://github.com/bitcoin/bitcoin/pull/6984
01:19 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
01:26 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
01:30 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 265 seconds]
01:32 -!- judomaster [d868caba@gateway/web/freenode/ip.216.104.202.186] has quit [Ping timeout: 246 seconds]
01:54 < warren> I have a Windows 10 machine 80% sync'ed now, shut it down for now.
01:55 < warren> wumpus: how did you simulate system crashes?
01:55 < jonasschnelli> would this additional doc make sense? https://github.com/bitcoin/bitcoin/commit/f6b96ce09ec827bb9be0fd926b199009dd08bfd4
01:55 < warren> will play with it tomorrow, g'nite
01:55 < jonasschnelli> If yes, anyone up to "fix the english"?
01:55 < wumpus> warren: NotMyFault is nice for that https://technet.microsoft.com/en-us/sysinternals/bb963901.aspx
01:56 < fanquake> jonasschnelli Can do shortly
01:56 < wumpus> it offers a menu of different crashes, e.g. from the kernel, from userspace, from I/O, and as a bonus you can even change the color of the BSOD :-)
01:56 < jonasschnelli> cool. You could do a commit on top of my branch https://github.com/jonasschnelli/bitcoin/commits/2015/11/MarcoFalke-2015-maxupload
01:57 < jonasschnelli> fanquake: than i can open a PR with both commits
01:57 < jonasschnelli> fanquake: or if to complicated, just write comments. Whatever is best for you.
01:58 < sipa> warren: set a large dbcache, and start closing bitcoin-qt right before the crash
01:58 < sipa> warren: that will make sure leveldb is writing stuff out during the crash
01:59 < fanquake> jonasschnelli ok
02:00 < fanquake> wumpus pushed a commit to bump zeromq.
02:00 < wumpus> thanks
02:01 < wumpus> fanquake: thanks for the mail
02:04 -!- d4de [~d4de@41.234.235.169] has quit [Ping timeout: 250 seconds]
02:07 < wumpus> fanquake: re: #1040 I still think we should move the manpage from contrib/debian to a place where it gets installed on 'make install', it's not just useful for debian
02:09 < wumpus> .TH BITCOIND "1" "January 2011" "bitcoind 3.19"    ... hah, and the build tooling should fill those in automatically
02:10  * sipa remembers the 100 Mbyte blockchain
02:11 < wumpus> hehe, oh no, 100 MB, that must be the end, we'll never be able to handle a chain that big!
02:12 < sipa> sorry, the 95.4 MiB blockchain
02:12 < fanquake> *used to be able to cpu mine .1 btc a day*
02:13 < fanquake> wumpus i can open a pull to amend some of the man page issue if you'd like
02:13 < sipa> *used to be able to GPU mine 50 BTC a day*
02:14 < fanquake> I hacked together a 5970 + 5830 to mine for a while. Missed the 50btc a day ship however.
02:21 < wumpus> fanquake:It'd be nice to close that lnog-standing (but minor) issue
02:23  * wumpus didn't even know we had a 'getaddednodeinfo' RPC call 
02:24 < fanquake> heh, it's always interesting going over all the "older" issues
02:26 < wumpus> especially nice if issues are solved not because someone actively went on solving the issue, but as by-product of another change
02:27 < wumpus> (that's the positive counterpart of 'changes introduce unexpected issues', they also close unexpected issues sometimes!)
02:29 < fanquake> jonasschnelli How did you go with the trusty gitian build?
02:30 < wumpus> for https://github.com/bitcoin/bitcoin/issues//2368 "Consider reducing 'getblocks' limit below 500" I have no idea whether it's still relevant, but the limit is still hardcoded to 500 
02:33 < wumpus> apparently it never killed us, but the issue may be based on a misunderstanding? that getblocks returns block data, instead of INVs?
02:35 < wumpus> fanquake: what vmbuilder are you using?
02:35 < sipa> wumpus: in old code we sent getdatas instantly for all invs we received
02:36 < wumpus> yes that seems to be the place to solve the issue, not in getblocks
02:36 < wumpus> ok, closing then
02:37 < fanquake> wumpus debian8 base, latest gitianbuilder, is that what you mean?
02:38 < wumpus> fanquake: but on debian you have to build vmbuilder from source, right?
02:38 < fanquake> ah sorry, I'm using vm-builder_0.12.4+bzr489
02:38 < wumpus> (e.g. the one included wasn't new enough to support ubuntu, this was described in the doc/gitian-building.md)
02:38 < fanquake> building from source yes
02:39 < fanquake> Ok. I see there is a newer version available from http://archive.ubuntu.com/ubuntu/pool/universe/v/vm-builder/. I'll send a pull to update the gitian guide to use that version.
02:40 < wumpus> mine (on Ubuntu 14.04) is also 0.12.4 though. But I suppose using a newer one may be worth a try, as it's failing while building the image.
02:41 < fanquake> is yours 489 or 494 (latest)?
02:42 < wumpus> building VM images is, unfortunately, still somewhat of a black art, needing root and support from the OS and loopback devices etc. The linux kernel library project https://github.com/lkl seems promising for the future as it'd simplify doing all the filesystems manipulation etc from userspace.
02:44 < wumpus> Version: 0.12.4+bzr489-0ubuntu2
02:45 < wumpus> " The currently supported distros are: * Ubuntu Dapper, Gutsy, Hardy, Intrepid, Jaunty, and Karmic." oh no... either they stopped updating the software, or they stopped updating the package description
02:46 < GitHub21> [bitcoin] fanquake opened pull request #6985: [gitian] Use latest vm-builder ( 0.12.4+bzr494 ) on Debian (master...patch-3) https://github.com/bitcoin/bitcoin/pull/6985
02:47 < wumpus> "apt-get python-vm-bulder" gets me 96 perl packages, boggles
02:48 < wumpus> oh it gets all of libvirt, even the daemon... whyy 
02:50 < wumpus> anyhow what I was trying to find out: Ubuntu 15.10 also still has 0.12.4+bzr489-0ubuntu2, with the same package description. I vaguely remember the author saying they will do a new package for 16.04 tho, the code is almost-unmaintained and what they recommend is using the ready-made daily ubuntu cloud images
02:50 < wumpus> (but that'd make deterministic verification really hard for us)
02:53 < wumpus> anyway, it should be able to make 14.04/trusty images, I've used it for that (on Ubuntu) multiple times
02:55 < fanquake> jonasschnelli You can grab the commit from https://github.com/fanquake/bitcoin/commits/fixupdoc
02:55 < fanquake> I  cherrypicked you doc commit and added
02:57 < fanquake> Another depends to consider bumping is qt. They've released a 5.5.1 bugfix, just looking through the notes to see if any of our issues might have been solved.
02:58 < fanquake> Release notes https://wiki.qt.io/Change-files-in-Qt-5.5.1
03:08 < fanquake> wumpus looks like the newer vmbuilder has fixed it. The build no longer errors out, and finishes successfully,
03:11 < wumpus> awesome!
03:13 < fanquake> You can pull the commit in #6985 into your PR if you want.
03:13 < wumpus> I will, thanks
03:14 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:15 < wumpus> oh nm, you already filed a pull, I'll just merge that - it's sort of independent of using a new release for building
03:16 < jonasschnelli> fanquake: thanks! Will have a look soon.
03:20 < GitHub144> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/de7d4591a7ce...38a4f267e82a
03:20 < GitHub144> bitcoin/master 7791395 Michael: [gitian] Use vm-builder_0.12.4+bzr494 on Debian
03:20 < GitHub144> bitcoin/master 38a4f26 Wladimir J. van der Laan: Merge pull request #6985...
03:20 < GitHub105> [bitcoin] laanwj closed pull request #6985: [gitian] Use latest vm-builder ( 0.12.4+bzr494 ) on Debian (master...patch-3) https://github.com/bitcoin/bitcoin/pull/6985
03:22 < wumpus> (btw apart from being a bad fit for the gitian process, the pre-built cloud images are awfully convenient - ready-built qcow2 images that can be configured in a few seconds - only remining timesink is apt-get install of toolchains)
03:23 < GitHub113> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/38a4f267e82a...cb841e75135e
03:23 < GitHub113> bitcoin/master 7267843 Jorge Timón: Globals: Make AcceptBlockHeader static (Fix #6163)...
03:23 < GitHub113> bitcoin/master cb841e7 Wladimir J. van der Laan: Merge pull request #6982...
03:23 < GitHub58> [bitcoin] laanwj closed pull request #6982: Globals: Make AcceptBlockHeader static (Fix #6163) (AcceptBlockHeader) (master...fix-6163) https://github.com/bitcoin/bitcoin/pull/6982
03:29 < wumpus> fanquake: re: https://wiki.qt.io/Change-files-in-Qt-5.5.1   doesn't even seem complete yet, I clicked 'qtbase' and it complains about an invalid branch :-)
03:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:34 < fanquake> wumpus yea, you have to click on changes-5.5.1 up the top, and you should get to http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1
03:34 < fanquake> Not sure why it doesn't just redirect straight there though.
03:37 < wumpus> likely very fresh
03:41  * wumpus is hopeful about the lack of complaints about 0.11.2rc1/0.10.4rc1
03:41 < fanquake> *hopes that doesn't just reflect a lack of testing :o"
03:41 < wumpus> sshhh
03:42 < fanquake> Does someone have download counts for the RCs?
03:42 < fanquake> Would be interesting to see the numbers
03:45 < wumpus> I don't have access to the logs I think
03:55 < GitHub40> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb841e75135e...3ac70609345a
03:55 < GitHub40> bitcoin/master 17c4d9d Cory Fields: build: Split hardening/fPIE options out...
03:55 < GitHub40> bitcoin/master 69d0513 Cory Fields: build: Use fPIC rather than fPIE for qt objects....
03:55 < GitHub40> bitcoin/master 3ac7060 Wladimir J. van der Laan: Merge pull request #6978...
03:55 < GitHub127> [bitcoin] laanwj closed pull request #6978: Alternative fix for #6248 (qt+fPIE) (master...qt-pie) https://github.com/bitcoin/bitcoin/pull/6978
04:03 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
04:19 < jtimon> phantomcircuit: a library with all the pure functions in bitcoin? what do you mean by pure functions?
04:21 < phantomcircuit> jtimon, no side effects, ie inputs -> outputs no state modified
04:29 < GitHub104> [bitcoin] jtimon opened pull request #6986: Globals: Don't call Params() from miner.cpp (master...global-chainparams-miner) https://github.com/bitcoin/bitcoin/pull/6986
04:33 < GitHub19> [bitcoin] jonasschnelli opened pull request #6987: [doc] add documentation about reducing traffic (master...2015/11/doc_traffic) https://github.com/bitcoin/bitcoin/pull/6987
04:34 < jtimon> phantomcircuit: oh, I see, cfields and I have been calling that "library ready" code. libbitcoinconsensus is obviously library ready and at a higher level there's some more that will be required for a complete libconsensus but not that many
04:35 < jtimon> phantomcircuit: I mean, wait, no "library ready" is even more strict since it doesn't even use the state as input
04:36 < jtimon> for example, checkTransaction checkBlockHeader and checkBlock, those are almost ready apart from uses of error(), Params() and other things that are trivial to solve (if, eventually, one day, we want to do that)
04:38 < jtimon> phantomcircuit: anyway I don't know of any library with functions from bitcoin core besides libbitcoinconsensus with its VerifyScript()
04:38 < wumpus> as long as all inputs and outputs are passed to/from the function explicitly, it qualifies as 'pure function'. This also means no i/o!
04:40 < wumpus> (although ofc. people in functional languages like to cheat by passing 'the state of the world' as input and as output of a function, so that i/o can exist in their 'pure' world :-) )
04:42 < jtimon> wumpus: well, ContextualCheckBlock, for example, doesn't modify the state, but it takes stateful structures explicitly as parameter CBlockIndex* (containing a pointer to a chain index) and a separated VerifyBlock would currently also take at least a CCoinsViewCache like ConnectBlock does. It may be a pure function, but it's not ready for libconsensus
04:46 < jtimon> phantomcircuit: anyway, I'm curious about the question, what motivated you to ask me that?
04:48 < wumpus> probably refering to the RPC calls that are (either truly or effectively) pure functions
04:49 < wumpus> parts of the raw tx API, validateaddress (if no wallet), etc
04:51 < phantomcircuit> jtimon, looking for easy things to fuzz :)
04:51 < jtimon> oh, I see
04:52 < jtimon> phantomcircuit: so the name of the functions is enough for you, right?
04:54 < jtimon> as said just from the top of my head checkTransaction checkBlockHeader and checkBlock come to mind (although they are quite simple anyway), probably wumpus has more names "at hand"
04:55 -!- MarcoFalke [8af60234@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.52] has joined #bitcoin-core-dev
04:56 < wumpus> off the top of my head: everyting in utilstrencodings.h, base58 parsing/generation, serialization/deserialization primitives, uint256 and other encapsulated classes
04:56 < jtimon> in fact we could easily expose those 3 in libbitcoinconsensus right now (assuming we want to)
04:57 < wumpus> everything in src/crypto
04:58 < jtimon> mhmm, I think base58 is still coupled with the global Params() for Base58Prefix ...
04:58 < wumpus> CScript, CScriptCompressor etc
04:58 < jtimon> everything in current libbitcoinconsensus includes everything in src/crypto
04:58 < wumpus> jtimon: read-only though, that doesn't matter for fuzzing
04:59 < jtimon> wumpus: gotcha
04:59 < wumpus> essentailly you want functions that are idempotent, not necessarily pure
05:06  * wumpus thinks it would be nice if someone collected release notes "Notable changes" into an organized documentation, people go through the trouble of documenting things for release notes , but after a release it's essentially forgotten
05:17 -!- MarcoFalke [8af60234@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.52] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
05:17 < wumpus> should probably add the part about torcontrol to doc/tor.md as well
05:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
05:20 < jtimon> wumpus: if #6625 was merged right now it wouldn't compile because transaction_tests.cpp now requires "#include "main.h" // For minRelayTxFee and DEFAULT_MIN_RELAY_TX_FEE"
05:21 < jtimon> wumpus: can I push the rebased and fixed version or preemptively fix it in the old version without rebasing?
05:22 < jtimon> s/can/should
05:24 < jtimon> btw gmaxwell a re-"gmaxwell was here" on #6625 (a subset of #6672 without libconsensus related movements) would be appreciated
05:25 < jtimon> after this little fix
05:26 < harding> wumpus: you mean just extracting the "Notable changes" sections from all past releases into a single document hosted somewhere?
05:28 < jtimon> wumpus: gmaxwell: never mind there's also new uses of MAX_BLOCK_SIZE in net.cpp so I have to rebase and fix more things
05:36 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
05:43 < jtimon> wumpus: oh, no, that was what I already fixed but didn't squashed, so my question remains, rebase and fix or preemptively fix ?
05:53 < wumpus> harding: not literally - I just meant, it's easy to lose track of documentation that was written just for the release notes
05:54 < wumpus> harding: but e.g. jonasschelli is doing the right thing in #6987 by also creating a file in doc
05:58 < jonasschnelli> harding: https://github.com/bitcoin/bitcoin/pull/6987 could also be something for bitcoin.org?
05:59 < wumpus> yes, was about to mention that, there is also overlap with the documentation on bitcoin.org (att least the bitcoin core section)
06:01 < harding> wumpus: ah.  We do link to the Bitcoin Core documentation directory ( https://bitcoin.org/en/bitcoin-core/help#documentation ), although not prominently.
06:01 < harding> jonasschnelli: I do think that we could intergrate 6987 to useful effect into https://bitcoin.org/en/full-node
06:02 -!- rubensayshi_ [~ruben@91.206.81.13] has joined #bitcoin-core-dev
06:02 < wumpus> jtimon: I'm not sure - what is the problem to be fixed?
06:05 < jtimon> wumpus previously main.h was only included for CheckTransaction so I removed it in https://github.com/jtimon/bitcoin/commit/7ec074dca2ec60d7f1c0711be31d165121ead600#diff-4f6d60b6976522cec2974a0aea9a5ab3L14 but in the future (rebased version) it will also be needed for minRelayTxFee and DEFAULT_MIN_RELAY_TX_FEE and cannot be removed (just change the comment instead)
06:07 -!- pigeons [~pigeons@94.242.209.214] has quit [Remote host closed the connection]
06:07 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
06:07 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
06:07 -!- pigeons is now known as Guest78100
06:08 < jtimon> eventually (assuming minRelayTxFee and DEFAULT_MIN_RELAY_TX_FEE ever move to the policy dir) we will be able to remove that main.h include, but not just yet
06:08 -!- Netsplit *.net <-> *.split quits: rubensayshi, NLNico, Ylbam
06:09 < wumpus> ok... well if you need the include then keep it
06:10 < wumpus> I mean this in a test, anything goes :)
06:11 < jtimon> yeah, the question is whether to rebase or not, the problem is only visible if I rebase
06:13 < jtimon> I mean I have already rebased, for me it's simpler to just push the rebased version, but it's worse for reviewers. I can easily "backport" the fix but it's kind of weird to have that  "// For minRelayTxFee and DEFAULT_MIN_RELAY_TX_FEE" comment without rebasing...
06:16 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
06:16 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nekjdpoeudabktmv] has joined #bitcoin-core-dev
06:20 -!- jgarzik [~jgarzik@172.85.35.242] has joined #bitcoin-core-dev
06:20 -!- jgarzik [~jgarzik@172.85.35.242] has quit [Changing host]
06:20 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
06:21 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
06:28 < jtimon> wumpus: I had to rebase anyway because both #6382 and #5970 depend on #6625 (in fact, that's how I discovered the problem)
06:33 < wumpus> ok, yes rebasing makes sense then
06:33 < jtimon> wumpus: ok, thanks
06:46 < GitHub18> [bitcoin] MarcoFalke opened pull request #6988: [doc] Fix FIXME for libblkmaker in release-notes.md (master...MarcoFalke-2015-docFixme) https://github.com/bitcoin/bitcoin/pull/6988
07:08 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
07:09 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
07:10 -!- skyraider [uid41097@gateway/web/irccloud.com/x-ypvlsifmivyvbxmj] has joined #bitcoin-core-dev
07:12 -!- zooko [~user@2601:281:8001:26aa:90a:ed6a:1101:a1c0] has quit [Quit: brb rebooting to new linux kernel]
07:25 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has joined #bitcoin-core-dev
07:42 -!- ParadoxSpiral [~ParadoxSp@p508B9BB2.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:02 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]
08:03 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
08:04 < morcos> phantomcircuit: ping, want to understand your privacy concerns with respect to wallet txs in mempool
08:05 < morcos> is the idea that you don't want people to be able to go around polling nodes trying to get them to respond to a getdata for a tx that should have been evicted
08:05 < morcos> and if they responded, they have a good probability of being the tx author?
08:07 < morcos> i don't think i was suggesting changing that, but I do think it is important for users to know that their tx may no longer be in mempools.  it'll be an indication to them that they may want to rebroadcast it or RBF it.
08:08 < morcos> so perhaps the mempool needs to let the wallet know it evicted or something similar and the wallet can inform hte user
08:11 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
08:12 < phantomcircuit> morcos, wallet should poll the mempool if anything
08:12 < phantomcircuit> the potential to leak which transactions are in the local wallet is pretty high even if we're careful
08:12 < sipa> it already does, and reports 'conflicted' for those transactions, afaikM
08:13 < morcos> sipa: yes, but it would be nice if it could identify the reason the tx is no longer in the mempool
08:13 < morcos> how to know, hey it got evicted
08:13 < sipa> right
08:13 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-yiscehqgmxpizsgl] has joined #bitcoin-core-dev
08:15 < phantomcircuit> sipa, iirc the mempool notifies the wallet of all changes, right?
08:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:16 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
08:16 < morcos> during tomorrows meeting we should try to game plan an order to review some of these open pulls we'd like to get in for 0.12.  I think if we put the effort in we can have a much better and more complete/consistent release.  There are quite a few things that are half way between fixes and new features that in my opinion really should be in the release, so we don't get complaints like this about conflicted txs
08:16 < jgarzik> phantomcircuit, sipa: how/where is the mempool/wallet connection made, now?   signals?
08:17 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has quit [Ping timeout: 240 seconds]
08:17 -!- skyraider [uid41097@gateway/web/irccloud.com/x-ypvlsifmivyvbxmj] has quit [Ping timeout: 240 seconds]
08:17 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Ping timeout: 240 seconds]
08:17 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds]
08:17 < jgarzik> That was one area of open question in the mempool-janitor stuff from year+ ago.
08:18 -!- skyraider_ is now known as skyraider
08:18 < morcos> there might be a notification via signal on ATMP, but i dont' think there is any way to inform of eviction is there?
08:18 -!- wump is now known as wumpus
08:18 < sipa> my opinion back then was that mempool transactions from the wallet should be protected from eviction; i don't think that's a good idea anymore due to the privacy concerns that raises
08:19 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
08:19 < morcos> yeah SyncWithWallets signals the wallet on txs entering the mempool or removing it for being mined or removing it for being conflicted
08:20 < sipa> that was more applicable to randon eviction though, as now the mempool aims to be some sort of subset of most likely to be mined transactions
08:20 < morcos> perhaps we can call it within ATMP for evicted txs?
08:20 < sipa> and if your wallet tx is not in that, it probably means those transactions are effectively at risk of not confirming
08:22 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 276 seconds]
08:23 < phantomcircuit> sipa, even with random eviction it's a bad idea...
08:23 < phantomcircuit> especially when combined with "mempool"
08:24 < sipa> phantomcircuit: the privacy concern is always there, but with random eviction, being evicted does not have any meaning for the wallet user
08:24 < sipa> now it does
08:24 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
08:25 < morcos> anyway, looks a bit messy to add it, but this is the kind of thing that I think is worth trying to get right before a major release
08:25 < sipa> perhaps the criterion for 'conflicted' should actually be that a conficting transaction is found; if not we can just call it "unclear" or something
08:27 < jgarzik> RE meeting - I would like two buckets for 0.12 - "must have" and "really want to have, if it's ready in time, but not a release blocker"
08:27 < jgarzik> too easy to continue slipping a release for one more awesome change
08:28 < jgarzik> time-based releases are different from feature releases - they are more lumpy
08:28 < sipa> the must haves should probably mostly be "fix known regressions"
08:28 < sipa> the chain limits and wallet/mempool interactions probably belong there
08:30 < jgarzik> +1
08:30 < morcos> Yes, thats why we should use the next 2 weeks to get in all the really want to haves!  and then we can worry about the must haves after.. :)
08:30 < jgarzik> ;p
08:31 < morcos> I will be sad if we don't merge a good subset of the performance improvements.  But even just for those, its useful to decide on an order to knock them out, since they interact to some degree.
08:32 < sipa> morcos: i hope a large part of them (if not all) go in
08:37 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
08:37 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:42 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
08:43 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has joined #bitcoin-core-dev
08:49 < wumpus> morcos: I think it's important to make a distinction between fixes that need to get in and performance improvements that would be nice, but may also be risky
08:51 < morcos> wumpus: yep agreed, i'm just hoping that if we work together we'll be able to get a lot in before the deadline sneaks up on us (says the guy that needs to start reviewing instead of creating more things to be reviewed)
08:52 < wumpus> agreed
08:52 < wumpus> just thinking that it's important to prioritize, there is so much open
08:52 < sipa> morcos: i am right to say that #5967 (if it works as intended) would fix the problem of ModifyNewCoins being unusable for coinbases?
08:53 < morcos> sipa: i was wondering about that and it was on my list to go back and check it
08:55 < sipa> it explicitly creates the case where a child cache has a non-fresh entry for something the parent cache does not have, in its tests
08:55 < morcos> entirely possible, but i want to carefully think about combining 5967 with modify new coins, probably worth doing even if its not going to be merged as just another way of making sure the thinking is correct
08:55 < morcos> yeah that sounds right
09:05 < sipa> morcos: writing a new coin to a child cache while the parent does not have it but the grandparent does is identical to the cache where the parent had it when the coin was written, and then had the parent flushed
09:06 < sipa> so i believe that 5967 exactly covers the unnecessary assumption, and tests it
09:06 < morcos> sipa: before i try to parse your statement, thinking about 5967 made me realize removing the assert without 5967 would have been broken with the ModifyNewCoins
09:07 < morcos> sipa: ok yes i agree with your statement and i think 5967 would allow ModifyNewCoins to be used in both cases and just not flag coinbases as FRESH
09:08 < sipa> morcos: you would have caught it by adding ModifyNewCoin calls in the unit tests
09:08 < morcos> sipa: ha ha. exactly!
09:09 < morcos> ok so do you want to do 5967 as well then?   
09:10 < morcos> I will perhaps put them all in one pull so it can be tested all together (once i write the unit tests)
09:10 < sipa> morcos: i'd say first do ModifyNewCoins as-is, adding unit tests for it
09:10 < sipa> morcos: then just removing the assert + ModifyNewCoins for coinbases without fresh flag should fa
09:11 < sipa> fail
09:11 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
09:11 < morcos> sure, ok that makes sense.  separate PR can add 5967 and change ModifyNewCoins, and that can be added or not later
09:12 < GitHub96> [bitcoin] laanwj opened pull request #6990: http: speed up shutdown (master...2015_11_threadexit) https://github.com/bitcoin/bitcoin/pull/6990
09:15 < GitHub188> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3ac70609345a...44d7b561bc75
09:15 < GitHub188> bitcoin/master 0817bf7 MarcoFalke: [doc] Fix FIXME for libblkmaker in release-notes.md
09:15 < GitHub188> bitcoin/master 44d7b56 Wladimir J. van der Laan: Merge pull request #6988...
09:15 < GitHub175> [bitcoin] laanwj closed pull request #6988: [doc] Fix FIXME for libblkmaker in release-notes.md (master...MarcoFalke-2015-docFixme) https://github.com/bitcoin/bitcoin/pull/6988
09:18 < sipa> morcos: realizing that you could have introduced a bug is a good reason to add a test that would detect it :)
09:22 < GitHub109> [bitcoin] laanwj closed pull request #6300: getblockhash: Return RPC_NOT_FOUND when nHeight > chainActive.Height() (master...master) https://github.com/bitcoin/bitcoin/pull/6300
09:22 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
09:27 < GitHub144> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/44d7b561bc75...c9743062a37c
09:27 < GitHub144> bitcoin/master 6a776fa Jonas Schnelli: [doc] add documentation how to reduce traffic
09:27 < GitHub144> bitcoin/master 42bae94 fanquake: [doc] Improve lanaguge in reducetraffic.md
09:27 < GitHub144> bitcoin/master c974306 Wladimir J. van der Laan: Merge pull request #6987...
09:28 < GitHub82> [bitcoin] laanwj closed pull request #6987: [doc] add documentation about reducing traffic (master...2015/11/doc_traffic) https://github.com/bitcoin/bitcoin/pull/6987
09:30 < GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9743062a37c...2f71b07d5ed6
09:30 < GitHub59> bitcoin/master 40b77d4 Wladimir J. van der Laan: Always allow getheaders from whitelisted peers...
09:30 < GitHub59> bitcoin/master 2f71b07 Wladimir J. van der Laan: Merge pull request #6974...
09:30 < GitHub183> [bitcoin] laanwj closed pull request #6974: Always allow getheaders from whitelisted peers (master...2015_11_whitelisted_allow_headers) https://github.com/bitcoin/bitcoin/pull/6974
09:35 < morcos> gmaxwell: how much do you care about this effectiveSize = max(size/MAX_BLOCK_SIZE,sigOps/MAX_BLOCK_SIGOPS) thing?
09:36 < morcos> its not that difficult to implement, but it touches a lot of things, assuming we make descendant packages track it which i think is important.  its too risky to make the default mining prioritization differ a lot from the eviction code.
09:37 < morcos> but then does it also affect package limits, are they 101kbs of actual size or 101kbs of effective size?  etc..   and do you sum that by summing maxes, etc. etc..   all doable, but i think i need to work on cleaning up these other pulls first
09:39 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-core-dev
09:39 -!- rubensayshi_ [~ruben@91.206.81.13] has quit [Ping timeout: 265 seconds]
09:44 < GitHub2> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2f71b07d5ed6...cbf9609c71c6
09:44 < GitHub2> bitcoin/master 7085728 Wladimir J. van der Laan: doc: there is no libboost-base-dev, add missing sudo...
09:44 < GitHub2> bitcoin/master cbf9609 Wladimir J. van der Laan: Merge pull request #6969...
09:44 < GitHub167> [bitcoin] laanwj closed pull request #6969: doc: there is no libboost-base-dev, add missing sudo in release notes (master...2015_11_docfix) https://github.com/bitcoin/bitcoin/pull/6969
09:57 < morcos> sipa: any reason why the BatchWrite for CCoinsViewTest writes all entries and not just the dirty ones?  I think it should only write DIRTY ones.. I'm not sure what the right way to keep it in sync with what CCoinsViewDB does, but that makes the most sense to me.
09:58 < sipa> it only writes dirty ones afaik?
09:58 < sipa> ah, the test
09:58 < sipa> i missed that
10:00 < morcos> ok, i'm changing it to follow same logic as CCoinsViewDB... 
10:00 < gmaxwell> morcos: I don't care about the specific thing done, but something needs to be done about the sigops flooding attack. The obvious next alternative is to threshold it, but I'm doubtful a threshold can be set that won't randomly bite people with lots of p2pkh outputs.
10:05 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Read error: Connection reset by peer]
10:12 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: No route to host]
10:19 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds]
10:28 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving]
10:34 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
10:55 < GitHub3> [bitcoin] petertodd opened pull request #6991: Minor: Clarify 'fee' field in fundrawtransaction help text (master...clarify-fundrawtransaction-help) https://github.com/bitcoin/bitcoin/pull/6991
11:03 < jgarzik> btcdrak, release manager != project lead...    bitcoin core is intentionally decentralized ever since Satoshi turned things over to Gavin.
11:04 < jgarzik> I've been release manager before, for example.
11:08 -!- onetime [~onetime@c-68-56-130-168.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
11:15 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
11:16 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
11:16 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
11:21 -!- onetime [~onetime@c-68-56-130-168.hsd1.mi.comcast.net] has quit []
11:23 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
11:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
11:39 -!- JackH [~Jack@host-80-43-141-3.as13285.net] has quit [Ping timeout: 260 seconds]
12:28 < GitHub131> [bitcoin] sdaftuar opened pull request #6992: [WIP] [Mempool] Add space for priority transactions (master...add-priority-to-mempool) https://github.com/bitcoin/bitcoin/pull/6992
12:42 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
12:50 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
12:50 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Remote host closed the connection]
13:06 -!- jgarzik [~jgarzik@rrcs-208-105-49-99.nyc.biz.rr.com] has joined #bitcoin-core-dev
13:06 -!- jgarzik [~jgarzik@rrcs-208-105-49-99.nyc.biz.rr.com] has quit [Changing host]
13:06 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
13:29 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
13:49 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
14:18 < michagogo> 12:50:56 <wumpus> (but that'd make deterministic verification really hard for us) <-- How come? AFAIK it doesn't matter if you use a daily image or a release image or debootstrap or whatever, as soon as you upgrade it should all be the same...
14:18 < michagogo> I mean, it's not like vmbuilder is deterministic, IIRC
14:21 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
14:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:35 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
14:38 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
14:45 < gmaxwell> michagogo: you're suggesting using daily images for buids? if so thats a terrible idea, as it would make it much easier to compromise everyone's builder images.
14:46 < michagogo> gmaxwell: I wasn't, no
14:47 < michagogo> 12:50:37 <wumpus> anyhow what I was trying to find out: Ubuntu 15.10 also still has 0.12.4+bzr489-0ubuntu2, with the same package description. I vaguely remember the author saying they will do a new package for 16.04 tho, the code is almost-unmaintained and what they recommend is using the ready-made daily ubuntu cloud images
14:48 < michagogo> gmaxwell: also, I don't think the idea was "use today's image each time you build", I think it was "use today's image when you want to create the base VM"
14:49 < michagogo> So I wasn't the one bringing it up, but I don't think I really see any reason not to, as I said above
14:51 < michagogo> (Of course, I might just be missing something obvious)
15:05 -!- ParadoxSpiral [~ParadoxSp@p508B9BB2.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
15:07 < jtimon> dcousens: hopefully you like #6597 now, it seems I coded that too fast and it was hurting performance for no good reason
15:13 < dcousens> jtimon: nice
15:14 < dcousens> jtimon: I'm still 100% over the implications of the change (will keep running through it in my head) but, the code looks good.  
15:17 < jtimon> dcousens: I think the change you chosed as an example doesn't actually hurt performance since non-genesis block were comparing the hashes anyway (just after checking the pow instead of before), but there were other places (which I'm not sure I had to touch even before rebasing and testing #6382 again) where your arguments certainly applied
15:17 < dcousens> jtimon: indeed, it compares the hash right after, but, this is cleaner :)
15:17 < dcousens> and at least, we only do it once now
15:18 < dcousens> well, less*
15:18 < jtimon> and it's when throwing an error...thanks for the review!
15:20 < gmaxwell> sipa: it was the right thing to do, but I think splitting the libsecp256k1 PR now means that no one is going to comment on the first part. :-/
15:21 < jtimon> gmaxwell: I'm afraid I can just concept ack on the first part
15:21 < sipa> gmaxwell: by first part you mean "the earlier PR", or "the PR whose commits now go first" ?
15:23 < jtimon> I meant #6983
15:28 < gmaxwell> sipa: the latter
15:31 -!- jgarzik [~jgarzik@216.57.20.67] has joined #bitcoin-core-dev
15:31 -!- jgarzik [~jgarzik@216.57.20.67] has quit [Changing host]
15:31 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
15:31 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit]
15:33 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has quit [Ping timeout: 246 seconds]
15:47 < sipa> gmaxwell: meh
15:59 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
16:00 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
16:01 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
16:04 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
16:04 -!- [1]evoskuil is now known as evoskuil
16:12 -!- skyraider [uid41097@gateway/web/irccloud.com/x-yiscehqgmxpizsgl] has quit [Quit: Connection closed for inactivity]
17:26 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
17:32 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has joined #bitcoin-core-dev
17:40 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
17:42 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has quit [Ping timeout: 246 seconds]
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nekjdpoeudabktmv] has quit [Quit: Connection closed for inactivity]
17:54 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
18:00 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
18:00 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
18:00 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-core-dev
18:25 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Read error: Connection reset by peer]
18:26 < GitHub16> [bitcoin] pstratem opened pull request #6993: Add -blocksonly option (master...blocksonly) https://github.com/bitcoin/bitcoin/pull/6993
18:30 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
18:30 < gmaxwell> phantomcircuit: does that actually work?!
18:30 < gmaxwell> add docs.
18:31 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
18:49 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
18:55 < phantomcircuit> gmaxwell, yeah it does
18:57 < phantomcircuit> i had completely forgotten about the fRelay flag
19:08 < dcousens> phantomcircuit: its cool tbh haha
19:21 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: Leaving]
19:23 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
19:33 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
19:50 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Quit: Leaving.]
19:50 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
20:19 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
20:19 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Read error: Connection reset by peer]
20:19 -!- [1]evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
20:19 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
20:21 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
20:21 -!- [1]evoskuil is now known as evoskuil
20:27 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
20:31 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
20:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
20:56 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
21:14 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
21:18 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
21:38 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has left #bitcoin-core-dev []
21:48 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
21:49 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:49 < dcousens> conceptually, phantomcircuit I feel like you could separate mempool from bitcoind with -blocksonly :P
21:51 < dcousens> phantomcircuit: also, would it be worth just dropping the transactions before they even get to AcceptToMempool?
21:51 < dcousens> or would advertising you don't care about txs be a BIP requiring protocol change?
21:55 < dcousens> gmaxwell: getdata being dropping the transactions before ATM? :P
21:56 < gmaxwell> jinx I guess. :)
21:56 < dcousens> haha
22:00 < gmaxwell> but yea, I think he should change it to not getdata any announcements instead from non-whitebound peers, and leave the mempool alone. 
22:00 < dcousens> gmaxwell: agreed, most likely the mempool would always be empty
22:00 < dcousens> but that is intended
22:00 < dcousens> (obviously)
22:01 < gmaxwell> Right but then you could still use this node to e.g. relay transactions created by an offline wallet behind it and such.
22:01 < dcousens> gmaxwell: or as I was thinking, have multiple relay nodes with decent bandwidth, but low memory, backed by a [lower] bandwidth blockchain node
22:02 < dcousens> assuming you had a service big enough where that is warranted anyway
22:02 < dcousens> hmmm, though, its the mempool that takes all the memory anyway haha
22:03 < dcousens> well, it'll be interesting to play with for sure
22:03 < phantomcircuit> dcousens, im dropping them in AcceptToMempool to prevent leaking which transactions are yours
22:03 < phantomcircuit> im not sure i did a thorough job of that though
22:04 < gmaxwell> phantomcircuit: nah, don't do that. Turning off wallet broadcast (already an option) is how thats achieved.
22:05 < dcousens> gmaxwell: what about if it was submitted via RPC?
22:05 < gmaxwell> Then we want to relay it.
22:05 < dcousens> gmaxwell: sure, but, that seems counter to the point of preventing leakage
22:06 < gmaxwell> blocksonly shouldn't refuse to relay transactions when you've specifically asked it to so. :)
22:06 < gmaxwell> dcousens: if you don't want it to broadcast a transaction then don't ask it to!
22:06 < dcousens> gmaxwell: sure, but, you could say the same about using it as a wallet
22:06 < phantomcircuit> gmaxwell, well then it's a one line patch
22:07 < gmaxwell> phantomcircuit: I think not, you need to avoid getdataing if they ignore your flags.
22:07 < dcousens> gmaxwell: I agree with you, just pointing out the logic didn't work with what phantomcircuit logic said "preventing leaking [of] transactions which are yours"
22:08 -!- CodeShark_ [uid126576@gateway/web/irccloud.com/x-eerhljpbdupbgeou] has joined #bitcoin-core-dev
22:08 < gmaxwell> dcousens: his current behavior will not relay a sendrawtransaction.
22:08 -!- CodeShark_ [uid126576@gateway/web/irccloud.com/x-eerhljpbdupbgeou] has quit [Client Quit]
22:08 < gmaxwell> I thought you were asking what would happen in my proposed change.
22:08 < dcousens> dw, I was
22:08 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit []
22:09 -!- CodeShark_ [uid126576@gateway/web/irccloud.com/x-kruzkurxlvkpfcjp] has joined #bitcoin-core-dev
22:09 < dcousens> unimportant, semantics are clear either way ;)
22:09 -!- CodeShark_ [uid126576@gateway/web/irccloud.com/x-kruzkurxlvkpfcjp] has quit [Client Quit]
22:09 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-keiuhngghbfgyoci] has joined #bitcoin-core-dev
22:10 < gmaxwell> phantomcircuit: so I think behavior should be when set, you will set the flag (to suppress inv announcements), and ignore getdatas.  But only from non-white peers.  And then anything sendraw/wallet will still work like normal, and if you don't want that for privacy reasons..then disable wallet broadcast and don't use sendraw. :) 
22:10 < gmaxwell> I imagine post 0.12 we'll also make this behavior one of the things we do in response to running into bandwidth limits.
22:11 < gmaxwell> (e.g. if you get too close to your limit, go into blocks only mode.)
22:11 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
22:12 < phantomcircuit> gmaxwell, that reminds me, thoughts on having a global settings object? (something that ya know.. actually acquired a lock)
22:13 < gmaxwell> Big lock protecting bag-of-assorted things isn't generally great.
22:14 < gmaxwell> in any case, not needed here, auto-blocks only I think is out of scope for 0.12.  It's a pretty big behavior change, and we'd have to do something about the transaction privacy loss. (hopefully fix that via a seperate private announcement mechenism)
22:15 < dcousens> gmaxwell: by auto, do you mean default?
22:15 < dcousens> oh, you mean auto bandwidth response
22:15 < dcousens> nvm
22:17 < phantomcircuit> gmaxwell, could equally be a separate lock on each of the settings
22:18 < gmaxwell> phantomcircuit: right for settings that should chang at runtime the setting should be read in init and set in a datastructure with its own lock for further changes.
22:20 < phantomcircuit> gmaxwell, well and most of them can just be atomic ints
22:21 < gmaxwell> We are not yet using C++ new enough to have standard atomic types.
22:21 < gmaxwell> And plain integers ARE NOT ATOMIC.
22:23 < jgarzik> without help
22:24 < gmaxwell> sure, you can use locks. Or custom asm or what not.
22:25 < jgarzik> gcc & clang provide atomic intrinsics to give C/C++ level access to cmpxchg, ints with lock prefixes and more.
22:25 < jgarzik> not C++ standard but it is available on all our platforms
22:25 < phantomcircuit> gmaxwell, something something boost atomic
22:26 < phantomcircuit> (im opposed to using boost in places where replacing it would be a giant headache, this is not one of them)
22:26 < gmaxwell> Well we'll upgrade to C++11 probably sooner rather than later and pick up language standard atomics.
22:27 < jgarzik> phantomcircuit, nod, http://www.boost.org/doc/libs/1_59_0/doc/html/atomic.html 
22:27 < gmaxwell> /usually/ one shouldn't be directly using atomics in any case except in performance crticial algorithims or when building lower level constructs to be used from other things. 
22:28 < gmaxwell> If the boost stuff is drop in for c++11 too than thats not so bad.
22:28 < jgarzik> that's the idea
22:29 < gmaxwell> I think we're already in a mode of only using boost features that aren't in C++11 if we have reason good enough to justify reimplementing them internally in any case. (e.g. mempool indexing)
22:32 < jgarzik> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
22:52 < phantomcircuit> gmaxwell, hmm so im thinking blocksonly should be undocumented as there are actually very few people who should be running such a thing
22:53 < phantomcircuit> the privacy loss form running with blocksonly and walletbroadcast=1 is potentially huge
22:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ghxpvhmldrcwsaxh] has joined #bitcoin-core-dev
22:55 < dcousens> phantomcircuit: that seems wrong
22:55 < dcousens> maybe a compile flag to allow it
22:55 < dcousens> or something
22:56 < wumpus> just disable walletbroadcast by default if it's enabled?
22:56 < dcousens> but not undocumented
22:56 < dcousens> or that ^
22:56 < wumpus> and emit a warning to the log
22:57 < wumpus> PRIVACYWARNING: wallet broadcasting has been disabled, because any transaction you send while not relaying transactions will stand out like a sore thumb
22:57 < phantomcircuit> wumpus, maybe... that's just what we need a more complicated tree of which settings are compatible :P
22:57 < wumpus> if you are sure you want to enable this, use -walletbroadcast
22:57 < gmaxwell> phantomcircuit: yea, you can imply walletbroadcast off for that case. We have handling like this for many options related to privacy.
22:57 < wumpus> you call that complicated?
22:57 < sipa> phantomcircuit: wallet broadcasting and whitelisting are already inherently a privacy leak
22:58 < gmaxwell> though I think you are GREATLY overestimating the improvement relay has on privacy.
22:58 < dcousens> wumpus: he just doesn't want to make it more than 1 or 2 lines
22:58 < gmaxwell> I think either way (defaulting walletbroadcast off or on) is okay with me, though I would leave it defaulting on.
22:59 < phantomcircuit> i uh dcousens *shhhh*
22:59 < wumpus> 'it is a already bad' is no excuse for allowing things to get silently even worse, hence the warning.
23:00 < wumpus> that's the problem with privacy everywhere, people think well we have no privacy already anyway, so why not do this and this also, it's not like it could get any worse. Yes, it can get worse.
23:00 < sipa> wumpus: agree, but to someone already listening on many nodes in the network, if they're connected to the original broadcaster too, they have a fairly good chance of finding you
23:00 < gmaxwell> wumpus: I don't know if it makes it worse or not, it might-- so fair enough.
23:01 < sipa> not relaying transactions otherwise just reduces the noticed; it doesn't fix the fact that information is being leaked
23:01 < wumpus> gmaxwell: well if you never send transactions then suddenlly send one, that makes it extremely clear it's yours, doesn't it?
23:01 < gmaxwell> sipa: research so far suggests that its currently about 100% effective if you transact more than once. 
23:01 < gmaxwell> wumpus: well with whitebind, perhaps not! (also if we start turning this on dynamically in the future e.g. when low on bandwidth) perhaps not.  But fair enough.
23:01 < sipa> s/noticed/noise/ i do not comprehend how i made that typo
23:02 < gmaxwell> phantomcircuit: so go softset off wallet broadcast and log, see the other examples in init.cpp.
23:02 < wumpus> I just don't like a setting that can silently make your privacy worse
23:02 < gmaxwell> wumpus: yup easily avoided, I agree.
23:02 < sipa> i'm fine with default off
23:02 < wumpus> the other option would be to indeed not document the option
23:03 < wumpus> but I think a warning + disable wallet broadcast by default is good enough
23:03 < sipa> what about whitebind?
23:03 < wumpus> what's with whitebind?
23:03 < wumpus> you mean - do relay transactions for whitelisters?
23:03 < sipa> whitelisted peers that relay transactions
23:04 < gmaxwell> I think it'll be a nice bandwidth reduction feature for watching wallets. It's a >2x reduction in bandwidth (probably more like 3x typically) and also saves you from a number of dos attacks. :)
23:04 < gmaxwell> I think it should relay for whitelisted peers. So you can use a node configured like this as a gateway to get your transactions to the outside world.
23:04 < wumpus> gmaxwell: it is a great feature, but the catch is that you have to make sure you're silent yourself, as there is no noise to hide in. That's acceptable, but needs to be transparent.
23:05 < sipa> how is whitelisting different from wallet broadcasting yourself?
23:06 < gmaxwell> because you choose and configure whitelists, it's like setting broadcast=1
23:06 < sipa> even if it doesn't disclose the ip of the actual sender anymore, they do know an ip address that the sender trusts
23:06 < wumpus> right it's something you have to explicitly enable
23:06 < gmaxwell> That could be a seperate setting. I've wanted that before, to control the forced relay for whitehosts.
23:06 < wumpus> ... which could come with a warning, of course
23:07 < sipa> wumpus: then how is it different from walletbroadcast?
23:07 < wumpus> sipa: my proposal is that walletbroadcast would be disabled by default if block-only
23:07 < wumpus> whitelist already *is* disabled by default
23:07 < sipa> hmm, ok
23:07 < wumpus> walletbroadcast is enabled by default
23:07 < sipa> ok, that is a fair point
23:08 < gmaxwell> Whitelist is a bot too overloaded. We might want to add a whiterelay that controls the forced relay for whitelisted hosts, which defaults on, but is soft-off with blocksonly
23:08 < wumpus> there are probably more ways that whitelisted peers can screw up your privacy :D
23:08 < gmaxwell> s/bot/bit/
23:08 < wumpus> they're sort of trusted
23:08 < gmaxwell> yea, we already bypass mempool policy
23:08 < sipa> wumpus: they are very trusted... but you yourself are also trusted
23:09 < sipa> if you do a wallet transaction, you expect it to be relayed; if a whitelisted peer relays a transaction, you also expect it to be relayed
23:10 < wumpus> the wallet may also rebroadcast old transactions
23:10 < wumpus> that's the scary part
23:10 < sipa> whitelisted peers will also rebroadcast old transactions
23:10 < wumpus> even transactions sent to you
23:10 < wumpus> ok  -I feel this is not constructive anymore
23:10 < wumpus> don't introduce features that may silently reduce user's privacy even more, that's all I ask
23:11 < sipa> ok
23:11 < wumpus> if there is warning, or a knob that has to be explicitly enabled, I'm ok with it
23:12 < gmaxwell> yea, seems simple enough, softset off walletbroadcast when this is set.
23:12 < wumpus> right
23:12 < wumpus> and yes, whitelisted peers have to be careful, we should document that
23:13 < gmaxwell> yea, we should document that already because they are already deanonymizing.
23:14 < gmaxwell> (not even the primary reason I really don't like the whitepeer relay rules--)
23:14 < wumpus> and yeah we could have an option to not relay transactions from whitelisted peers...
23:14 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]
23:14 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
23:14 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 250 seconds]
23:14 < gmaxwell> (I mostly don't like them because I whitebinded the relaynetwork client and p2pool for obvious reasons, and then found they were blowing past my relay policy :-/ )
23:14 < sipa> gmaxwell: i think the rebroadcasting is fundamentally the problem, because nobody but the owner of the transaction will rebroadcast
23:15 < sipa> an alternative is peers syncing the mempool with each other...
23:15 < gmaxwell> sipa: It's fairly busted without that, in fact. 
23:15 < sipa> so transaction owners don't need to rebroadcast randomly
23:15 < wumpus> policy 192.168.1.* { allow relay; bypass relaypolicy; } policy bind :1234 { ... }   *ducks*
23:16 < sipa> it is... in theory you can end up with a cordon of nodes that already know your transaction between you and miners
23:16 < gmaxwell> Right now on any given publically accessible node >=15 peers are spynodes that connect to everyone. They also use addr behavior to infer things about the non-listening peers behind them; and research shows high success rates for even single transaction origins. If you make a couple transactions in the current network you should assume your origin WILL be idenfied.
23:17 < gmaxwell> To avoid this we need an actually private broadcast mechenism.
23:17 < wumpus> yes
23:17 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
23:18 < gmaxwell> and once we have that, it would work just as well for rebroadcast. :)
23:18 < wumpus> we need a private transaction mechanism badly, but we already knew that I think :)
23:18 < gmaxwell> and also would remove some of these discussions since then the p2p protocol would not have any privacy implications for full nodes (beyond running a node at all. :) )
23:19 < wumpus> right, it would, but it doesn't affect our decisions right now because it's entirely hypothetical :)
23:19 < gmaxwell> Just another benefit. It's really nice to not have to consider privacy implications for things; especially when the current state is bad enough that it can be hard to tell if you're making it worse. :)
23:20 < gmaxwell> E.g. one of the problems with peer rotation, ... in privacy.
23:20 < gmaxwell> er is privacy.
23:20 < sipa> we just need separate networks for block relay and tx relay :)
23:20 < gmaxwell> One of the problems with pruning ... is privacy (makes nodes more fingerprintable; so you can track nodes across tor and then correlate transactions they originate)
23:21 < sipa> well... i guess the same arguments apply to mining actually, it's just much less data to analyse, but ideally you also don't want to be able to pinpoint block creators
23:21 < gmaxwell> yadda yadda. All becomes more tidy if these things are seperated.  In one sense you can see that privacy and partition resistance are actually in conflict.
23:21 < gmaxwell> For privacy you want to tell your transactions to very few parties, hopefully not attackers. For partition resistance you want to talk to everyone. :)
23:22 < gmaxwell> sipa: yea, though different problems; mining is very latency sensntive; tx broadcast is not.
23:22 < GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cbf9609c71c6...5fcc14ee0562
23:22 < GitHub183> bitcoin/master b5cbd39 James O'Beirne: Add basic coverage reporting for RPC tests...
23:22 < sipa> and partitioning for tx relay is less of a problem
23:22 < GitHub183> bitcoin/master 5fcc14e Wladimir J. van der Laan: Merge pull request #6804...
23:22 < GitHub198> [bitcoin] laanwj closed pull request #6804: [tests] Add basic coverage reporting for RPC tests (master...rpc_coverage) https://github.com/bitcoin/bitcoin/pull/6804
23:23 < wumpus> even dropping off your transactions to a random node over Tor is better than publicly broadcasting your transaction from your own node
23:29 < gmaxwell> yea, but requires having a tor client. :(
23:30 < wumpus> it does, having a tor client seems more and more a requirement for any kind of privacy unfortunately
23:31 < gmaxwell> it's just a lot of code and exposure, hate having reason to mix things like that with other things that have critical security requirements.
23:31 < wumpus> a tor bitcoin bundle would be pretty nice
23:31 < wumpus> well at least it gives plenty of noise to hide in
23:32 < wumpus> if you were to say, set up an onion routing network just for transactions, even partaking in it would still leak a lot information about you. Also, if you write it yourself doesn't make it any less 'code and exposure'
23:33 < gmaxwell> It's true, for tx broadcast though, one could send a transaction through a high latency mixmaster like system entered via normal internet. And the daemon could just send an empty message an interior hop one ever couple minutes to hide the traffic. Doing the first hop over tor is superior, but I think not strictly needed.
23:34 < wumpus> I agree that such a solution could theoretically be better, the problem as we've seen for years is that no one is implementing such a thing, and tor already exists
23:34 < gmaxwell> wumpus: the client could be quite simple relative to tor (which at the very begining immediately needs a full SSL stack)
23:34 < gmaxwell> Indeed.
23:34 < gmaxwell> Actually someone contacted me recently about implementing such a thing, but I don't know if they will.
23:35 < gmaxwell> (well they said they will, and asked if I'd be willing/able to review; but you know most things don't actually happen :) )
23:36 < gmaxwell> wumpus: e.g. sending client for such a thing could encrypt a message, connect to a TCP socket, and send it over. Never reading a byte off the socket even. Attack surface would be incompariable to tor. :)
23:38 < wumpus> the reason that Tor uses SSL, by the way, is that that masquerading as SSL is one of the few feasible ways to hide an encrypted connection in plain sight
23:39 < gmaxwell> Indeed, for good reason. I don't think you're going to manage to hide that you're sending a transaction at all unless you use tor... but you well could hide which transaction you were sending. Esp if you don't mind broadcast taking a minute.
23:39 < wumpus> if you start with your own such system you'd very soon run against the same issue
23:41 < gmaxwell> (in particular it's completely reasonable to have high cover traffic, if you don't mind latency... just send a 100k message into the routing network every N minutes, containing some random assortment of transactions from the public network, and any of your own).  If you're not running this over tor, you'll stand out as a user of the software but not more than that.
23:41 < gmaxwell> )
23:42 < wumpus> well you could still hide that you're sending a transaction by hiding in noise, e.g. also using the system to automatically send other people's transactions
23:42 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:43 < wumpus> just like the relaying system we have now but encrypted, and high-latency, and with padding so that you can't look at the envelope and identify by the size, etc etc
23:43 < gmaxwell> exactly. which is also good in that if someone finds out how to distinguish transactions exiting the system they might seek to punish their authors, but if you're sending random other transactions into the system, what exits will not just be from witting users.
23:45 < kanzure> we are still missing out on a high-latency mixnet of some kind
23:45 < wumpus> but anyhow - just like 5 years ago, I'd be pleasantly surprised if someone build something like that
23:45 < wumpus> exactly kanzure
23:45 < gmaxwell> prior to bitcoin they were hard(er) because of flooding attacks, but we have a one-two punch here: we have highly valuable tiny messages AND mechenisms to stop flooding attacks.
23:52 < wumpus> lol "On January 23, 2006, the Russian FSB accused Britain of using wireless dead drops concealed inside hollowed-out rocks to collect espionage information from agents in Russia. According to the Russian authorities, the agent delivering information would approach the rock and transmit data wirelessly into it from a hand-held device, and later his British handlers would   pick up the stored data by similar means." If 
23:52 < wumpus> everything fails, we could always use fake rocks :-)
23:53 < gmaxwell> "some of us already are"
23:54 < randy-waterhouse> yes, btcoin has been accused of using "fake rocks" many times already
23:55 < wumpus> randy-waterhouse: any links?
23:55  * phantomcircuit looks at scrollback
23:55 -!- MarcoFalke [50edea96@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.150] has joined #bitcoin-core-dev
23:56 < randy-waterhouse> wumpus: tongue-in-cheek reference to "fake gold" accusations
23:56 < MarcoFalke> wumpus, using `-proxy` I get "2015-11-12 07:43:06 ERROR: Proxy error: connection not allowed
23:56 < MarcoFalke> " for .onion and "2015-11-12 07:43:56 ERROR: Proxy error: host unreachable
23:56 < MarcoFalke> " for the seeds
23:57 < MarcoFalke> Are those implying censorship?
23:57 < wumpus> randy-waterhouse: ahh old pyrite, or fool's gold :-)
23:57 < randy-waterhouse> heh, right
23:58 < wumpus> MarcoFalke: it may just mean what it says - the proxy cannot reach those hosts
23:58 < wumpus> MarcoFalke: sometimes hosts are truly unreachable. I think you need to look at tor's logging to see if it can reach the first hop to troubleshoot this
23:59 < wumpus> but at least you're one step further- you get errors from the proxy, instead of the level before of connecting to the proxy