--- Day changed Fri Oct 09 2015 00:17 -!- Squidicuz [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has quit [Ping timeout: 250 seconds] 00:17 < GitHub108> [bitcoin] Diapolo closed pull request #6288: [Qt] fix debug console window handling when e.g. minimized (master...show-rpconsole) https://github.com/bitcoin/bitcoin/pull/6288 00:29 -!- n0n0__ [~n0n0@x4d067290.dyn.telefonica.de] has quit [Ping timeout: 250 seconds] 00:35 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 00:52 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 00:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-joobpgnlmpudepcs] has quit [Ping timeout: 260 seconds] 01:00 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Quit: ZNC - http://znc.in] 01:09 < wumpus> Luke-Jr: [skip ci] only works in the commit message, not the pull title? 01:10 < Luke-Jr> wumpus: ? 01:12 -!- fkhan [weechat@gateway/vpn/mullvad/x-vacljtpvaggeezem] has joined #bitcoin-core-dev 01:13 < wumpus> Luke-Jr: I mean - what does travis look at, the pull request title or the commit message? 01:13 < Luke-Jr> no idea, I just don't like it in the commit message :p 01:13 < wumpus> hm only commit message from http://docs.travis-ci.com/user/customizing-the-build/ 01:14 < wumpus> but it *doesn't have* to be in the first part 01:14 < Luke-Jr> moving it to the long description would be an improvement at least 01:14 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev 01:14 < wumpus> you can just [skip ci] hide it somewhere in the description 01:16 < GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d479311dba25...a99b6cb19ee7 01:16 < GitHub84> bitcoin/master b2af29b Pavel Janík: Ignore bench_bitcoin binary. 01:16 < GitHub84> bitcoin/master a99b6cb Wladimir J. van der Laan: Merge pull request #6770... 01:16 < GitHub12> [bitcoin] laanwj closed pull request #6770: [Trivial] Ignore bench_bitcoin binary [skip ci] (master...bench_gitignore) https://github.com/bitcoin/bitcoin/pull/6770 01:17 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 01:21 -!- ParadoxSpiral [~ParadoxSp@p508B8A2B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 01:21 < GitHub52> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a99b6cb19ee7...c82ea8b271c8 01:21 < GitHub52> bitcoin/master 34754ce Chris Kleeschulte: [Trivial] Fixed typo when referring to a previous section in... 01:21 < GitHub52> bitcoin/master c82ea8b Wladimir J. van der Laan: Merge pull request #6783... 01:21 < GitHub66> [bitcoin] laanwj closed pull request #6783: [Trivial] Fixed typo in depends/README.md [skip ci] (master...depends_readme_typo) https://github.com/bitcoin/bitcoin/pull/6783 01:27 < GitHub28> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c82ea8b271c8...6cf73b0cd4cf 01:27 < GitHub28> bitcoin/master b22692c Cory Fields: build: Make use of ZMQ_CFLAGS 01:27 < GitHub28> bitcoin/master 6cf73b0 Wladimir J. van der Laan: Merge pull request #6779... 01:27 < GitHub61> [bitcoin] laanwj closed pull request #6779: build: Make use of ZMQ_CFLAGS (master...fix-zmq-cflags) https://github.com/bitcoin/bitcoin/pull/6779 01:37 < aj> wumpus, Luke-Jr: am i completely off-base think bip68/nSequence for relative locktime will cause SPV clients to see bad confirmations on about 5% of blocks for a while after activation? cf http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011467.html 01:37 < aj> s/think/in thinking/ 01:37 -!- fkhan [weechat@gateway/vpn/mullvad/x-vacljtpvaggeezem] has quit [Read error: Connection reset by peer] 01:38 < Luke-Jr> aj: just the usual softfork expectations given SPV limitations 01:38 < Luke-Jr> 1-block confirmation is never secure for SPV anyway 01:38 < aj> Luke-Jr: afaics for softforks that upgrade OP_NOP's SPV clients won't have that problem 01:38 < aj> Luke-Jr: (or won't have it any worse than normal anyway) 01:39 < Luke-Jr> aj: I don't follow then. 01:39 < aj> Luke-Jr: (1) afaics, apart from elegius, 99.9% of existing hashpower won't mine OP_NOP txns but will mine nSequence transactions 01:40 < Luke-Jr> oh, I see what you mean 01:40 < aj> Luke-Jr: (2) post softfork, 5% of miners haven't upgraded. but eligius has, so no one will mine OP_NOP stuff, but 5% will mine bad nSeq/relative-timelock txns 01:41 < aj> Luke-Jr: so SPV clients go from .1% (made up number) of hashpower being a problem to 5% of hashpower being a problem 01:41 < Luke-Jr> aj: I don't think there's ever been a softfork without this "problem" 01:41 < Luke-Jr> well, except BIP66 I guess 01:42 < Luke-Jr> not even that actually 01:42 < Luke-Jr> because older block versions were disallowed 01:42 < Luke-Jr> anyway, 5% of hashpower won't get more than a block or two deep 01:42 < aj> Luke-Jr: afaik SPV clients don't check block versions generally anyway 01:43 < aj> Luke-Jr: OP_CLTV won't have that problem, afaics 01:43 < Luke-Jr> perhaps not. but it will be the first not to. 01:43 < aj> Luke-Jr: (wow) 01:43 < Luke-Jr> and SPV 1-block confirmation is not secure regardless 01:44 < Luke-Jr> aj: the versionbits stuff does improve on this 01:44 < Luke-Jr> after the softfork goes active, there is a difficulty-adjustment period (2 weeks) before it is enforced 01:45 < Luke-Jr> so other miners can upgrade 01:45 < aj> Luke-Jr: versionbits maybe makes it a little harder, in that after activation the bit's not set anymore, so you can't even compare the nVersion of the latest block to see that something odd's happening? 01:45 < Luke-Jr> aj: SPV nodes need the full header-history anyway, so they can implement versionbits 01:46 < aj> Luke-Jr: i think, without a soft-fork upgrade, to exploit a SPV client, you need to use your own hashpower to mine a will-be-orphaned block to trick SPV clients; but immediately after soft-fork activation, you have 5% of other people's (ie *free*!) hashpower that will mine will-be-orphaned blocks for you? 01:46 < Luke-Jr> aj: only if 5% got left behind 01:47 < Luke-Jr> aj: the expectation is not that those 5% continue mining invalid blocks 01:48 < aj> Luke-Jr: hmm, is there any way to tell how much hashpower dropped off in previous upgrades? 01:48 < Luke-Jr> dunno, probably just Deepbit 01:48 < aj> Deepbit 01:48 < aj> ? 01:49 < aj> oh that was a mining pool, not a stats site? :) 01:49 < Luke-Jr> aj: a mining pool that once had over 50% ;) 01:49 < CodeShark> two things: 1) clients that do not recognize the version can (and *should*) warn the user that something might be up. 2) 1-confirmation reorgs are typical in the daily course of business...around soft fork activations, thin clients (that don't validate blocks) should be even more careful 01:50 < Luke-Jr> CodeShark: will versionbits impl kill mining when it detects it is being softforked out? 01:50 < Luke-Jr> ie, getblocktemplate should probably fail if some activated softfork is unsupported 01:50 < Luke-Jr> CodeShark: btw, I was thinking of the softfork plugin thing a bit ago also, so sounds good to me :P 01:50 < CodeShark> :) 01:51 -!- fkhan [weechat@gateway/vpn/mullvad/x-nkcvzzclrfrwxaja] has joined #bitcoin-core-dev 01:51 < Luke-Jr> maybe harder than it seems though in practice 01:52 < CodeShark> I have some ideas for how to do it...but if we're going to be doing a bunch of refactors after 0.12 is released, I figure this is a good area on which to focus :) 01:53 < CodeShark> we don't want to have to backport each individual soft fork perpetually...and it might actually be easier to backport the plugin thing 01:53 < aj> be easier to backport pluggable soft forks once the plugin thing exists too, presumably 01:54 < CodeShark> yes, of course 01:54 < sipa> what do you mean by plugin system? 01:55 < CodeShark> I posted something on the mailing list - but I'm guessing you unsubscribed :) 01:55 < sipa> yes 01:55 < CodeShark> I can forward it to you if you want 01:55 < CodeShark> or you can look for the link on linuxfoundation.org :) 01:55 < aj> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011487.html 01:55 < aj> and/or http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011491.html 01:57 < sipa> shouldn't need any changes in primitives... that's only for data types, their construction, and serialization... softforks can't change those 01:57 < CodeShark> CBlock needs a new default version 01:57 < CodeShark> or could be implemented in getblocktemplate, I suppose 01:57 < CodeShark> in principle I agree 01:57 < CodeShark> CBlock should not be where the default version gets set 01:58 -!- fkhan [weechat@gateway/vpn/mullvad/x-nkcvzzclrfrwxaja] has quit [Ping timeout: 250 seconds] 01:58 < sipa> yes, indeed 01:58 < sipa> those default versions there don't belong 01:59 < sipa> you say "easily merged units"... that's pretty vague 01:59 < CodeShark> right - primitives should just handle data access and serialization 01:59 < sipa> what do you mean specifically? 01:59 < btcdrak> sipa: will you consider joining again after we get the new list and push offtopic stuff to the new list? 01:59 < sipa> btcdrak: maybe 01:59 < CodeShark> sipa: by adding two lines to the makefile and one line to an init function 01:59 < CodeShark> and two files to the repo :) 02:00 < CodeShark> at least for starters 02:00 < CodeShark> long-term it would even be possible to deploy at runtime 02:00 < sipa> CodeShark: so you pretty much mean... changing the code location organizatiin so that soft forks are the top level? 02:00 < CodeShark> yeah, I suppose you could say that 02:00 < sipa> what if soft forks require wallet changes? or block creation code changes? 02:01 < CodeShark> we start with the consensus hooks...then worry about UI :p 02:01 < sipa> ok 02:02 < sipa> my concern is readability... hooks result in less readable execution flow, and much harder to reason about things like "whatever this hook does, the result is always soft fotk safe" 02:02 < sipa> but... perhaps 02:03 < CodeShark> well, if you take a look at how BIP65 and BIP66 are deployed, there aren't too many places really 02:03 < CodeShark> BIP65 is a tad bit more complex in the sense that it also defines an op code 02:04 < CodeShark> so we need a hook in the script interpreter 02:04 < sipa> yeah, i don't like that 02:04 < sipa> not for consensus 02:05 < CodeShark> we can keep that part separate for now, I suppose - the soft fork deployment would also modify script/interpreter.cpp if we don't add a hook 02:05 < wumpus> consensus code should be as simple and straightforward and self-contained as possible, IMO, no hooks and plugins 02:05 < CodeShark> I think this is about as simple as it gets, though 02:05 < CodeShark> it makes any change to consensus very easy to review 02:06 -!- go1111111 [~go1111111@162.244.138.37] has quit [Quit: Leaving] 02:06 < CodeShark> the diff becomes trivial 02:06 < wumpus> does it? interaction/crosstalk issues tend to be problematic for plugin-like systems, what sipa says 02:07 < wumpus> needs to be easy to follow the execution flow 02:07 < CodeShark> a soft fork has well-defined abstract behavior 02:07 < wumpus> and *in which sequence* things are done 02:07 < CodeShark> the implementor just needs to specify what those behaviors actually are 02:09 < CodeShark> the execution flow is even easier to follow with this kind of architecture...because in the stable consensus code itself the specifics of the rule are encapsulated...and in the rule definition itself there's nothing else BUT the rule definition 02:09 < Luke-Jr> CodeShark: so… let's say a softfork with segregated witness..? 02:10 < CodeShark> can we do that cleanly with a soft fork? 02:10 < Luke-Jr> in theory, I don't see why not 02:10 < sipa> I don't see how. 02:10 < Luke-Jr> probably entails p2p protocol changes though 02:10 -!- fkhan [weechat@gateway/vpn/mullvad/x-fxiglncanzmhhyrn] has joined #bitcoin-core-dev 02:11 < sipa> Only in a very non-useful way could you do it, with external data blobs that blocks commit to (like extension blocks). 02:11 < Luke-Jr> well, we can't segregate the existing scripts - but P2SH-like.. 02:11 < sipa> no 02:11 < sipa> segregated witness changes how transactions refer to each other 02:12 < sipa> i guess you can do it by making transactions not contain scriptSigs 02:12 < Luke-Jr> exactly 02:12 < sipa> and have separate witness structures that are relayed separately, and committed to in a block's coinbase 02:12 < sipa> ok 02:13 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev 02:13 < sipa> yeah, that wouldn't easily fit into a hook structure, i think 02:13 < CodeShark> I'm just thinking about the consensus structures themselves - not the relay mechanisms. I see the p2p stuff as a separate layer 02:14 < sipa> yes, but even the consensus changes wouldn't easily fit in 02:14 * Luke-Jr , after breaking softfork plugins, runs off to bed. :P 02:14 < CodeShark> sipa: I just think of the witness structures as additional validation context 02:15 < CodeShark> they can be anything, really - any additional state required at validation time 02:15 < sipa> ok, how does that fit in? 02:16 < CodeShark> we'd probably need to rearchitect the script interpreter a bit to be more abstract 02:16 < wumpus> no... 02:17 < CodeShark> or we could just accept that not everything is solved by the plugin and some kinds of soft forks still would require additional modifications to the consensus code (but they would be far fewer than before, and the routine ones would all be covered) 02:18 < CodeShark> routine ones being stuff like nVersion changes and the kind of stuff we currently do in main.cpp 02:19 < Luke-Jr> when/if at some point we dynamically call libbitcoinconsensus, we could implement softforks as a forked lib, and have the node call libbitcoinconsensus_softfork's CheckBlock etc and also libbitcoinconsensus_original CheckBlock etc to enforce softfork behaviour; this makes the changes *simpler* and less risky 02:19 < CodeShark> yes, agreed, Luke-Jr. That's sorta what I meant by abstracting the script interpreter a bit more 02:19 -!- fkhan [weechat@gateway/vpn/mullvad/x-fxiglncanzmhhyrn] has quit [Ping timeout: 246 seconds] 02:19 < Luke-Jr> CodeShark: no, in this case we'd have entire duplication of the consensus lib ☺ 02:20 < Luke-Jr> (so it can be reused for hardforks as well) 02:20 < CodeShark> no...the soft fork plugins could use the consensus lib once it's ready 02:20 < Luke-Jr> CodeShark: well, that's not what I just described 02:20 < Luke-Jr> and we'll want to do these dynamic calls anyway if we support sidechains in a single node ever 02:21 < CodeShark> I'm saying at the core level, there are a few things that are fundamental and invariant - amongst these are the block header tree, PoW, and version rules 02:21 < CodeShark> then on top of this you have core structures (blocks and transactions) which generally can only change their fields with a hard fork 02:21 < CodeShark> so let's say they are invariant as well 02:22 < CodeShark> then on top of this you have context (UTXO, timestamp) 02:22 < CodeShark> if these checks work, then you run the script 02:23 < sipa> we don't even get to do simple refactors 02:23 < CodeShark> sipa: understand this is not a one or two month plan :p 02:24 < CodeShark> this is probably out at least a year 02:24 < CodeShark> point is unless we start thinking about this kind of stuff well in advance it will probably never happen 02:24 < sipa> i'm not convinced it's very useful 02:24 < CodeShark> ok, then I have some homework to do :) 02:24 < sipa> the trivial softforks it is targetting are already simple to review 02:24 < CodeShark> for you, sipa 02:24 < CodeShark> I'd rather you spend your time doing other stuff :p 02:25 < CodeShark> for most people it's still very hard 02:25 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:25 < sipa> the non-trivial ones will become harder, because they'll need to change the plugin api... 02:25 < CodeShark> not if we abstract things well enough 02:26 < CodeShark> there's a sequence of validation steps that can be easily abstracted regardless of the specific rules 02:27 < sipa> i don't see how you could create an abstraction that keeps working with seggregated witness, for example 02:27 < CodeShark> isn't segregated witness effectively additional state required for validation? 02:28 < sipa> seggregated witness, from the point of existing code, removes script and sigScript entirely 02:28 < CodeShark> let 02:28 < sipa> and then jntroduces a new primitive data structure, to which consensus rules are applied 02:28 < sipa> i think you're biased by having seen a few simple soft forks 02:28 < CodeShark> removes script and sigScript? 02:29 < sipa> yes, transactions would end up having an empty scriptSig 02:29 < CodeShark> I get that part - what do you mean by "script" 02:29 < CodeShark> ? 02:29 < CodeShark> scriptPubKey? 02:29 < sipa> by script i mean the script subdir in the code 02:30 < CodeShark> oh...so interpreter.cpp 02:30 < CodeShark> and that stuff :) 02:30 < sipa> of course, it would get reused in a new piece of code 02:30 < CodeShark> yes, as I pointed out the script interpreter could be far better abstracted to cover vastly more potential use cases...and with the benefit of hindsight 02:30 < sipa> but from the point of existing code - and that's what your abstraction framework can deal with - it just completely deletes the concept of script from bitcoin 02:31 < sipa> how do you deal with cases where more data needs to be exposed to the script interpreter? 02:31 < CodeShark> I imagine a function Validate(context, transaction) 02:31 < CodeShark> where context could be extended 02:32 < CodeShark> but for now it covers the current block tree 02:32 < CodeShark> and utxo set 02:32 < sipa> you can't just expose the entirety of consensus state to transaction validation, or it could break caches that assume certain data doesn't influence validation outcome 02:32 < sipa> no, it's not that easy 02:32 < sipa> script execution can purposefully not depend on certain data 02:32 < sipa> like height 02:33 < sipa> to avoid transactions going from valid to invalid 02:34 < CodeShark> who says the context structure needs to maintain everything? it could be pruned...and if Validate requires missing context when called it can throw an error 02:34 < CodeShark> I agree it isn't trivial 02:34 -!- fkhan [weechat@gateway/vpn/mullvad/x-mpprkhildpqvupda] has joined #bitcoin-core-dev 02:34 < CodeShark> it's a challenge - but I think it's doable 02:34 < sipa> i think you're underestimating the costs to others 02:34 < CodeShark> the trick here is figuring out what sorts of context can be excluded from what types of checks 02:35 < CodeShark> and what sorts of context are desirable to exclude 02:35 < CodeShark> again, this is not a one- or two-month plan 02:36 < sipa> ok: bottom line, i am very skeptical about the benefits 02:36 < sipa> now let's talk about things we can actually do 02:36 < CodeShark> but we CAN do this...it's just going to take a much longer time than one release cycle 02:37 < CodeShark> the argument that it doesn't have that many benefits is an acceptable one - but that it isn't possible I don't accept :) 02:37 < CodeShark> you might be able to convince me of the former 02:37 < sipa> it's certainly possible with high costs 02:38 < CodeShark> given our current process, I agree 02:38 < sipa> but i don't think it's the right direction to.go in 02:38 < CodeShark> ok - that's more fruitful discussion 02:38 < sipa> i would aim to have less abstractions, not more 02:38 < sipa> because they complicate reasoning and proving what code can do 02:38 < CodeShark> that depends on how the logic is chunked, though 02:39 < sipa> maybe 02:39 < sipa> i'm not saying there are no benefits 02:39 < CodeShark> the mind is capable of handling craploads of complexity as long as it's well-encapsulated with a simple interface 02:39 < sipa> but it will come at a high cost, and not just reviee cost 02:40 < sipa> CodeShark: unless the API is perfect, and the different modiles are guaeanteed to be isolated from each other, i don't think the abstraction you can introduce is sufficient for consensus purposes 02:40 < sipa> you will need to know what all plugins are doing to see whether the result is consensus safe 02:41 < CodeShark> if the plugins have interdependencies it does potentially add a significant amount of complexity, especially circular dependencies 02:41 < sipa> that's not what i mean 02:42 < CodeShark> with this architecture you could simulate whatever rules you wanted and review specific units that focus exactly on the rules in question 02:43 < sipa> in theory 02:43 < CodeShark> sipa: I just don't think bitcoin can perpetually keep on adding new features at the protocol level if each proposed change requires a handful of people such as yourself to review the same lines of code over and over again :) 02:43 < CodeShark> this is process scalability 02:43 < sipa> CodeShark: i will still review them if they are in plugins 02:44 < sipa> i don't see how this changes anything 02:44 < wumpus> at least some people are going to know those lines of code *very* well then 02:44 < CodeShark> yes, but the author can be tasked with proving them out considerably more before you even touch them 02:44 < wumpus> ... which is kind of the goal, people need to understand the consensus rules and how everything fits together 02:44 < CodeShark> we can have a review process where stuff gets better screening before it gets to you 02:44 < sipa> i don't believe that 02:45 < sipa> i think more abstraction will only result in more ways a plugin could screw with consensus 02:45 < sipa> unless it is very minimal, and thus nearly useless 02:55 < GitHub198> [bitcoin] MarcoFalke opened pull request #6788: [trivial] sync univalue (master...MarcoFalke-2015-syncUnivalue) https://github.com/bitcoin/bitcoin/pull/6788 03:34 -!- epilido [~epilido@71-87-184-104.dhcp.jcsn.tn.charter.com] has quit [Quit: Leaving] 03:44 -!- fkhan [weechat@gateway/vpn/mullvad/x-mpprkhildpqvupda] has quit [Read error: Connection reset by peer] 03:56 -!- n0n0__ [~n0n0@x4d067290.dyn.telefonica.de] has joined #bitcoin-core-dev 03:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-wfahfojopamrfjgb] has joined #bitcoin-core-dev 04:21 < GitHub133> [bitcoin] laanwj opened pull request #6789: Update miniupnpc to 1.9.20151008 (master...2015_10_mitigate_upnp_buffer_overflow) https://github.com/bitcoin/bitcoin/pull/6789 04:24 < wumpus> this is going to force our hand re: new 0.10.x and 0.11.x releases 04:34 < morcos> would you still consider trying to bundle the other stuff in? 04:43 < wumpus> I think everything that is currently in the branches should be included (including the LowS enforcement) 04:44 < wumpus> so it can be announced as dual fix: upnp security issue and mallability nuisance 04:45 < wumpus> I don't think the CLTV softfork should be included 04:48 < sipa> i wonder whether we should disconnect softforks entirely from releases 04:49 < sipa> eg have 0.11.1 and 0.10.3 now, and whenever ready, we do a 0.11.1-cltv and 0.10.3-cltv release 04:52 < wumpus> internal versions 0.11.1.1 and 0.10.3.1? 04:52 < sipa> i guess we could coopt the lowest digit for that 04:52 < wumpus> we never use the fourth number 04:53 < sipa> we have used it occasionally for platform-specific releases 04:53 < sipa> like windows-only bugfixes 04:53 < sipa> but that's not a big deal 04:53 < wumpus> but I'm ok with the idea... 04:53 < sipa> i mean in terms of branding... that would make it much more transparent which softforks are implemented, and that they are independent from the client code largely 04:54 < wumpus> yes 04:55 < sipa> in backports you could keep the naming after activatiin, while for new major releases you could have a "0.12 includes softforks bip16, 34, 66, and 68 in all releases" 04:55 < sipa> to avoid needing huge names for historical softforks 04:58 < wumpus> though it may be hard to get people to upgrade to a 0.11.1-cltv if they already have 0.11.1 05:01 < btcdrak> I dont like having a -cltv release. 05:02 < btcdrak> I think we should patch with miniupnp on top of the current 0.11.1 and 0.10.3 branches with all their fixes and release that. 05:02 < btcdrak> let's not get overly pedantic 05:03 < btcdrak> let's release what we have. 05:04 < wumpus> that's already my plan btcdrak 05:04 < wumpus> the softfork releease would be what is planned for the end of the month 05:04 < btcdrak> wumpus: +1 05:05 < wumpus> by the normal numbering that would be 0.11.2 now, but there's something to be said for (but also against) making it a "special" release because it only enables a softfork 05:08 < btcdrak> that's overly complex because then if you need to release security/maintenance, you have to have maintenance version of the softfork release. Better the status quo and then it will get a lot easier with versionbits (which is near first draft implementation I hear from CodeShark) 05:08 < btcdrak> OT: how serious is this miniupnp issue? 05:09 < wumpus> I don't have a strong opinion about version numbers, I prefer just counting up, but if many people want to do a specially-named release I'm not opposed 05:10 < wumpus> as I understand it, any local device could feed invalid data to the UPNP discovery and overflow a buffer 05:12 < sipa> I understand the downside... it's just an idea. 05:13 < sipa> I think it makes sense to help understand people that the network rules are more or less independent from the software 05:13 < wumpus> btcdrak: the TALOS description is quite detailed; I don't know more, haven't tried to exploit it 05:14 < wumpus> sipa: I absolutely agree - just don't know if version *numbers* are the right way to communciate that :-) 05:14 < sipa> fair enough 05:15 < wumpus> may be better to write something in the release notes, if someone is good at writing those things 05:15 < wumpus> anyhow that's a problem for end of the month 05:15 < wumpus> I think merging https://github.com/bitcoin/bitcoin/pull/6785 makes sense before 0.11.1 05:16 < gavinandresen> remote exploit is serious enough to warrant an alert, in my humble opinion 05:17 < wumpus> yeah, probably 05:18 < wumpus> I've thought about sending one to make people disable upnp 05:18 < wumpus> but reconsidered quickly 05:18 < wumpus> so let's get the new versions out first 05:18 < sipa> yeah 05:18 < CodeShark> one day, in about a century or two, we'll be able to move to IPv6 and this will no longer be an issue :p 05:19 < wumpus> CodeShark: don't be crazy, this is not #bitcoin-sciencefiction :p 05:19 < CodeShark> heh 05:19 < sipa> ipv6 has a 2^96 times larger address space, so it will take 2^96 times as long to deploy, obviously 05:20 < morcos> i understand why we want to logically separate soft forks, but practically speaking it doesn't really work that well, especially with ISM kind, either everyone adopts them or not 05:21 < morcos> its not like its an option you can really choose in addition to getting your upgrades 05:21 < btcdrak> I agree with you morcos. But I think it all goes away with versionbits because there will be a way for people to disable the softfork "vote" on their node. 05:21 < morcos> how about this, let release two versions of 0.11.1 simultaneously, one with soft fork and one without, so that way people don't really have to update twice 05:22 < morcos> but no one can argue we were witholding critical security updates if they didn't go along wiht the softfork 05:22 < CodeShark> lol - the one without is called a command line option...the one with is called the default settings 05:23 < morcos> i just think the downside of now possibly 4 releases in the time span of 4-5 months outweighs the confusing the soft fork aspect 05:24 < btcdrak> morcos: releasing often is always a good thing 05:24 < CodeShark> I am very close to having a functioning versionbits implementation, fwiw 05:24 < morcos> not when people NEED each of the upgrades 05:24 < morcos> ok so 5 05:24 < morcos> :) 05:24 < sipa> fair enough 05:25 < morcos> 0.12 although a major version upgrade will be essentially required b/c of mempool limiting 05:25 < CodeShark> in principle, we should probably have version numbers for the protocol itself 05:26 < CodeShark> separate from the software 05:26 < btcdrak> morcos: I think users would be happier to know CVEs get patched asap, and not have to wait for a patch Tuesday. If we need an extra in between release or two for security reasons then that's just how it has to be. miniupnpc is forcing our hand here 05:26 < sipa> CodeShark: we have those... 05:26 < CodeShark> the block header version is sorta that...but not exactly 05:26 < sipa> block version numbers for consensus 05:26 < sipa> protocol version numbers for protocol 05:27 < CodeShark> with versionbits, we're moving away entirely from sequential numbering 05:27 < morcos> btcdrak: yes possibly if we could more concretely agree on the roadmap, then more releases would be ok. mini-upnp patched now.. softfork to follow for CLTV in 3 weeks, 0.12 with mempool limiting a couple months later (likely before CLTV activates) , CSV a month or so later 05:27 < morcos> then people can decide which to skip and not just blindly upgrade? but is that asking too much 05:28 < gavinandresen> Anybody object to me tweeting: “If you're running bitcoind NOT behind a firewall, restart with -upnp=0 -- there is a critical miniupnpc library vulnerability” 05:28 < sipa> where can i read about this vulnerability? 05:29 < CodeShark> but people behind a firewall might just shut down their node 05:29 < gavinandresen> sipa: http://talosintel.com/reports/TALOS-2015-0035/ 05:29 < gavinandresen> sipa: … from wumpus’ https://github.com/bitcoin/bitcoin/pull/6789 05:29 < sipa> so you need access to the local network 05:30 < sipa> presumably, such situations are more dangerous in corporate networks, where upnp doesn't worn anyway 05:31 < gavinandresen> “doesn’t work” != “isn’t vulnerable” though 05:31 < sipa> sure, just saying that the place where this risk is largest, is one where upnp has no use anywah 05:32 < gavinandresen> yup 05:32 < sipa> so i would say it's the opposite... if you're running behind a firewall it's more reason to disable upnp 05:33 < CodeShark> depends on whether it's a private LAN or a larger shared network, though 05:34 < gavinandresen> How about: “If you are running bitcoind on a public LAN, restart ...." 05:34 < sipa> sounds good 05:36 < sipa> actually 05:36 < sipa> no need to even restart 05:36 < sipa> miniupnp is only called at startup 05:37 < sipa> so putting it in your config would be enough, to prevent upnp from running next time 05:38 < CodeShark> unless someone already injected a delayed payload...in which case it's already too late 05:39 < gavinandresen> sipa: ACK, I added a comment to the pull request. Unfortunately, I have to turn into a pumpkin now (committed to attend an event here all day) so I can’t help gitian build 05:43 < wumpus> yeah@gavinandresen in the GUI too to disable upnp in Bitcoin Core: run with -noupnp, or disable checkbox in GUI under Options → Network → Map port using UPNP 05:44 < wumpus> but they'll probably forget to enable it again after the new release 05:46 < wumpus> I think it will be pretty hard to exploit this - it's a buffer overflow on the stack, and we have address space randomization, -fstack-protector- non-executable stack, enabled for the builds 05:51 < GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6cf73b0cd4cf...8c7e6138dbcb 05:51 < GitHub31> bitcoin/master 0cca024 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008... 05:51 < GitHub31> bitcoin/master 8c7e613 Wladimir J. van der Laan: Merge pull request #6789... 05:51 < GitHub1> [bitcoin] laanwj closed pull request #6789: Update miniupnpc to 1.9.20151008 (master...2015_10_mitigate_upnp_buffer_overflow) https://github.com/bitcoin/bitcoin/pull/6789 05:53 -!- fanquake [~Adium@106-68-35-109.dyn.iinet.net.au] has joined #bitcoin-core-dev 05:53 -!- fanquake [~Adium@106-68-35-109.dyn.iinet.net.au] has quit [Changing host] 05:53 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev 05:54 < GitHub25> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/093d7b5895b7dddd98d929fc3851265970b995b7 05:54 < GitHub25> bitcoin/0.10 093d7b5 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008... 05:56 -!- fkhan [weechat@gateway/vpn/mullvad/x-wfahfojopamrfjgb] has quit [Ping timeout: 255 seconds] 05:56 < GitHub163> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/b4ad73f706196272589451ce3d223f3df029eea1 05:56 < GitHub163> bitcoin/0.11 b4ad73f Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008... 05:58 < GitHub175> [bitcoin] laanwj closed pull request #6785: Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave() (0.11...already_have_0.11) https://github.com/bitcoin/bitcoin/pull/6785 05:58 < GitHub187> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/b4ad73f70619...b4dc33e9fbbc 05:58 < GitHub187> bitcoin/0.11 36f14bf Tom Harding: In (strCommand == "tx"), return if AlreadyHave()... 05:58 < GitHub187> bitcoin/0.11 b4dc33e Wladimir J. van der Laan: Merge pull request #6785... 05:59 < fanquake> wumpus bugfix release shortly? 05:59 < wumpus> yes 06:01 -!- n0n0__ [~n0n0@x4d067290.dyn.telefonica.de] has quit [Ping timeout: 244 seconds] 06:02 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 06:03 < michagogo> How shortly? I'm going offline in about 2 hours. 06:04 < michagogo> I might be able to start a build and let it run of its very shortly, otherwise I'll do it tomorrow night 06:05 < wumpus> within two hours, absolutely - I just have to write some release notes, then I'll tag the rc1s 06:07 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 240 seconds] 06:13 -!- fkhan [weechat@gateway/vpn/mullvad/x-vcenufzxfztexmxt] has joined #bitcoin-core-dev 06:14 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev 06:15 -!- pigeons is now known as Guest45978 06:20 < GitHub135> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/04d0c27fb0b9ce0843b99bcae3c4e106fd817496 06:20 < GitHub135> bitcoin/0.11 04d0c27 Wladimir J. van der Laan: doc: Update release notes for 0.11.1 06:20 < wumpus> preliminary release notes for 0.11: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md 06:21 < wumpus> that is 0.11.1 06:27 < GitHub74> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/1bf6ac62abc2faad8af76aebfa0887c073e2c9b4 06:27 < GitHub74> bitcoin/0.10 1bf6ac6 Wladimir J. van der Laan: doc: Update release notes for 0.10.3 06:27 < wumpus> and for 0.10.3: https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md 06:32 < GitHub18> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/d7d87a1db1b90094a0dd517b89ef1c40eaedf14c 06:32 < GitHub18> bitcoin/0.11 d7d87a1 Wladimir J. van der Laan: qt: Update translations before 0.11.1 06:33 < wumpus> ready to tag 06:33 < GitHub86> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/44d6bc85285f2cbbee0a7b94924975d3e9d84875 06:33 < GitHub86> bitcoin/0.10 44d6bc8 Wladimir J. van der Laan: qt: Translations update before 0.10.3 06:35 < wumpus> * [new tag] v0.10.3rc1 -> v0.10.3rc1 │············································· 06:37 < wumpus> * [new tag] v0.11.1rc1 -> v0.11.1rc1 06:37 < sipa> reviewing 0.111.1 06:37 < sipa> ah, too late 06:38 < wumpus> no, not too late, you can review while building rc1 :p 06:38 < wumpus> if there's anything wrong we can always do a rc2 immediately 06:38 < sipa> the release notes mention bc484ef8db02715e283e4cddd2c972316c0688dd., which was reverted 06:39 < wumpus> ok, removing that one 06:41 < GitHub102> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/17ea542aa6323715d22cf6661e9705b3e940e3d1 06:41 < GitHub102> bitcoin/0.11 17ea542 Wladimir J. van der Laan: doc: #6077 was reverted, don't mention in release notes... 06:49 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds] 06:49 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 06:51 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit] 06:53 < morcos> wumpus: did you raise minrelaytxfee? 06:56 < morcos> it looks like no, i know there was some controversy about it, and maybe 10x is too big a jump, but its going to be a long time until 0.12 is released, and these mempool attacks are a big problem 06:56 < morcos> i think raising the default to at least double is worthwhile, maybe we could get some ACKS on that and get it merged too? 07:00 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Quit: Leaving.] 07:04 < michagogo> hm, `make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common` is erroring 07:04 < michagogo> or, well 07:04 < michagogo> it's giving me this message: `/bin/sh: 1: test: qtbase-opensource-src-5.5.0.tar.gz: unexpected operator` 07:05 < michagogo> and now it seems to be redownloading qt 07:05 < wumpus> morcos: that was not done 07:05 < wumpus> maybe for the release end of this month 07:05 < cfields> michagogo: that's harmless, you can ignore it 07:05 < michagogo> Hm, did qt get bumped since 0.11.0? 07:08 < wumpus> #6471 92401c2 Depends: bump to qt 5.5 yes - I remember this was for the TLS1.0+ requirement 07:10 < michagogo> Oh, I just realized my script for a complete gitian build probably won't work for 0.10 07:11 < michagogo> I guess I'll do that one manually tomorrow night 07:23 < GitHub117> [bitcoin] MarcoFalke opened pull request #6790: [devtools] add clang-format.py (master...MarcoFalke-2015-clangFormatWrapper) https://github.com/bitcoin/bitcoin/pull/6790 07:26 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 07:35 < michagogo> cfields: btw, looks like the mirror on bitcoincore.org isn't up to date 07:35 < cfields> ugh, i keep meaning to setup a cronjob for that 07:35 < cfields> what's missing? 07:35 < michagogo> qt 07:35 < michagogo> Also, argh 07:36 < cfields> ok, pulling it in 07:36 < michagogo> apparently if one component errors out it doesn't keep everything else that was fetched 07:37 < michagogo> That's really bad 07:37 < cfields> yea, the multi-sources are a corner-case and kinda handled hammer-style 07:37 < michagogo> Hm 07:38 < michagogo> I think this might mean I won't be able to kick the build off before I go offline 07:38 < michagogo> a 60MB download, took a long time 07:38 < michagogo> and is now going to have to rerun because a <3 MB file failed to download 07:40 < michagogo> Is dependency download from within gitian working atm? 07:41 < cfields> depends on the config. I think it's only an issue with lxc 07:41 < michagogo> Im using lxc :-( 07:42 < cfields> ok, links should be good now 07:42 < cfields> setting up a cronjob 07:48 -!- Cocodude [~marc@109.169.23.186] has joined #bitcoin-core-dev 07:49 < Cocodude> Hello. My bitcoind is taking up > 4 GB RAM right now. Is there a recommended way to bring that down? Is it somewhat due to the UTXOs? 07:50 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:50 < paveljanik> Cocodude, #bitcoin please. 07:51 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 07:53 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds] 07:54 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] 07:58 < michagogo> Okay, I *think* I got the build kicked off now. 07:59 < michagogo> If you see a PR from me with the sigs for 0.11.1rc1 in a few hours, it worked. If not, I'll figure out why an fix it tomorrow night. Now, I g2g. 07:59 < michagogo> שבת שלום 08:01 < GitHub193> [bitcoin] MarcoFalke opened pull request #6791: [trivial] Misc cleanup (master...MarcoFalke-2015-trivial2) https://github.com/bitcoin/bitcoin/pull/6791 08:01 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has joined #bitcoin-core-dev 08:01 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has quit [Changing host] 08:01 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev 08:03 -!- Cocodude [~marc@109.169.23.186] has left #bitcoin-core-dev [] 08:20 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:25 < cfields> michagogo: cronjob installed. Should require very minimal manual intervention from now on 08:27 -!- n0n0__ [~n0n0@x4d067290.dyn.telefonica.de] has joined #bitcoin-core-dev 08:33 -!- n0n0__ [~n0n0@x4d067290.dyn.telefonica.de] has quit [Read error: Connection reset by peer] 08:45 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 08:47 < cfields> wumpus: whoops, looks like version bumps were missed for 0.10/0.11 ? 08:50 < wumpus> yes 08:51 < wumpus> we'll leave that for rc2 08:58 < wumpus> my gitian build spends a lot of time in "Upgrading system...". Does making new images avoid that? 08:58 < wumpus> (KVM build) 09:14 < GitHub129> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/cf5bf5542a6aba6b97fb69e0d2c11c2cd47f406d 09:14 < GitHub129> bitcoin/0.10 cf5bf55 Wladimir J. van der Laan: Bump version to 0.10.3 09:18 < GitHub52> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/717152ccba2a31ceaf7d0e02f6c9ad82843f2176 09:18 < GitHub52> bitcoin/0.11 717152c Wladimir J. van der Laan: Bump version to 0.11.1 09:19 < cfields> wumpus: unsure 09:38 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 09:55 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:15 < GitHub44> [bitcoin] gmaxwell opened pull request #6792: Defaults UPNP to off when discovery is disabled. (master...upnp_off_on_ip) https://github.com/bitcoin/bitcoin/pull/6792 10:29 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 10:31 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds] 10:41 < gmaxwell> I continue to be unhappy with the miniupnp codebase. At least shutting it off more often will help. :) 10:41 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 10:42 < GitHub69> [bitcoin] laanwj opened pull request #6793: Bump minrelaytxfee default (master...2015_10_bump_minrelaytxfee) https://github.com/bitcoin/bitcoin/pull/6793 10:42 < wumpus> we all are 10:42 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 10:43 < wumpus> I'd love to get rid of miniupnpc, if we all agree it's a bigger risk than the gain it is to the network we can still remove it for rc2 10:43 < wumpus> (too bad we don't really have a way to measure) 10:44 < gmaxwell> We could go even further in turning it off, e.g. defaulting it to off if the user appears to have a routable IP. 10:44 < wumpus> there are other upnp libraries but they aren't any better with regard to codebase, UPNP *is* an ugly protocol with XML and al, so that's not an option 10:44 < petertodd> wumpus: removing miniupnpc while adding automatic tor hidden service support would be a decent compromise... 10:44 < wumpus> petertodd: it's the better way of hole-punching :) 10:44 < petertodd> wumpus: yup! 10:44 < gmaxwell> petertodd: not quite a replacement unless we were getting more nodes to come along with a tor client though. 10:45 < wumpus> it should be able to interface with the TBB that the user has installed 10:45 < petertodd> gmaxwell: yeah, easiest to do in the context of things like ubuntu packages which can depend on tor 10:47 < gmaxwell> We had upnp off for bitcoind for a long time. Perhaps we should just default it off for non-QT? 10:47 < wumpus> alternatively we could switch to an UDP-based protocol and use UDP hole punching on the router *ducks* 10:47 < wumpus> I really don't like that solution gmaxwell, having anything depend on UI-or-not 10:48 < gmaxwell> wumpus: well, I'm in damage mitigation mode there. The more places we can turn it off with almost no effect, the better. 10:48 < wumpus> on average, UI users are generally the most vulnerable to all kinds of attacks 10:48 < wumpus> so giving them the libupnp burden is wrong 10:49 < gmaxwell> I agree. But assuming (bad assumption) we don't want to generally turn it off, how much can we turn it off with no effect? 10:49 < wumpus> (also UI users are most likely to have the wallet enabled) 10:49 < gmaxwell> and I think the PR I just opened is pretty fine, as I think would going back to the configuration where bitcoind has it off by default.... but I agree these get less of the benefit. 10:49 < gmaxwell> wumpus: at the same time UI users are less likely to be subject to heroic attack efforts. 10:50 < wumpus> I'd just like to make the decision to turn it off 10:50 < gmaxwell> Also UI users are more likely to have worse vulnerabilities on their system. 10:50 < wumpus> yes, I want to remove miniupnpc completely 10:50 < gmaxwell> How about we default it to off in the update? 10:51 < wumpus> fine with me too 10:51 < petertodd> gmaxwell: AC 10:51 < petertodd> gmaxwell: ACK 10:51 < gmaxwell> I believe this will result in a substantial reduction in reachable nodes. I don't know how substantial. If it does, we can deal with it. They likely weren't the most usable nodes. 10:52 < wumpus> " Also UI users are more likely to have worse vulnerabilities on their system." probably , but what if they're running the UI on the only computer they had that was safe :p 10:52 < gmaxwell> Absolutely, I was just speaking in terms of averages. 10:52 < wumpus> well I like the torrent solution... pressure people to add a port forward by showing an ugly icon :-) 10:53 < petertodd> gmaxwell: what % of reachable nodes correspond to residential ip addrs? 10:54 < wumpus> though we already do, the 'network connectivity' icon is never full without incoming connections, but it could be more insistent in warning 'it appears that the port is unreachable, see XXX for instructions on forwarding' 10:54 < wumpus> anyhow, yes let's default upnp to no 10:56 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .] 10:59 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 11:00 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:01 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:03 < GitHub169> [bitcoin] gmaxwell opened pull request #6794: Default UPNP to off. (master...upnp_default_off) https://github.com/bitcoin/bitcoin/pull/6794 11:03 * wumpus tries to understand the autotools magic of --[enable|disable]-upnp-default 11:03 < wumpus> oh, you got it already gmaxwell? 11:04 < gmaxwell> ah, well I missed that autotools had magic there. 11:04 < wumpus> no, you changed the source code instead of the build system default 11:04 < gmaxwell> I think we should rip that out. Opinion? 11:04 < gmaxwell> (the autotools part) 11:04 < gmaxwell> (also the message handling was wrong, incidentally.) 11:05 < wumpus> I don't get it. 11:05 < gmaxwell> well not wrong, but redundant with the code. 11:05 < wumpus> I think it is : USE_UPNP 1 means "enabled by default" USE_UPNP 0 means "not enabled by default" USE_UPNP undefined means "not compiled in" 11:05 < gmaxwell> In any case, if you want to do it via build, feel free to ignore my PR. Sorry! :) I'm trying to safe you effort. :) 11:06 < gmaxwell> Yea, thats the original makefile behavior. 11:06 < petertodd> away . 11:06 < wumpus> -upnp Use UPnP to map the listening port (default: 0) 11:07 < wumpus> it already defaults to 0? 11:07 < gmaxwell> no. 11:07 < gmaxwell> see the twisty mase of IFdefs my patch removes. 11:08 < wumpus> then why do I get that? 11:08 < gmaxwell> ! 11:08 < sipa> it's default on for qt, default off for bitcoind, no? 11:08 < wumpus> (yes, I have installed the library and dev headers) 11:08 < wumpus> no, it's not sipa 11:08 < gmaxwell> sipa: I said that earlier and was corrected... it used to do that but apparently was changed when we changed the build system. 11:09 < wumpus> configure:27112: checking whether to build with UPnP enabled by default 11:09 < wumpus> configure:27120: result: no 11:09 < sipa> oh really...? 11:09 < wumpus> anyone get something else in config.log? 11:09 < sipa> ah, maybe it's off by default, but we turn it on in release builds? 11:09 < wumpus> (I haven't overridden it) 11:09 < wumpus> that might be it, let's see 11:09 < gmaxwell> my system is too weird a test point. 11:10 < wumpus> sipa: you're right 11:10 < wumpus> so only the gitian builds enable it by default 11:10 < gmaxwell> Okay, gonna close that second pull. 11:11 < GitHub125> [bitcoin] gmaxwell closed pull request #6794: Default UPNP to off. (master...upnp_default_off) https://github.com/bitcoin/bitcoin/pull/6794 11:11 < gmaxwell> the first with disabling it when discover is enabled should probably still go in so long as we have a build option to default it to on. 11:11 < sipa> i do think we need to get rid of that confusing logic... 11:12 < gmaxwell> well we could rip out all that stuff that lets you default it to on. 11:13 < wumpus> fine with me 11:22 < GitHub178> [bitcoin] laanwj opened pull request #6795: net: Disable upnp by default (master...2015_10_disable_upnp_default) https://github.com/bitcoin/bitcoin/pull/6795 11:32 -!- fkhan [weechat@gateway/vpn/mullvad/x-vcenufzxfztexmxt] has quit [Read error: Connection reset by peer] 11:32 -!- ParadoxSpiral_ [~ParadoxSp@p508B90C8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 11:36 -!- ParadoxSpiral [~ParadoxSp@p508B8A2B.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 11:41 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 11:42 < Luke-Jr> wumpus: what is the purpose in removing the --[enable|disable]-upnp-default 11:43 < wumpus> Luke-Jr: we don't have --XXX-default options for other settings either 11:43 < Luke-Jr> wumpus: is there any similar option? particularly, that enables a compile-time feature disabled by default 11:43 < wumpus> I don't think so 11:44 < Luke-Jr> it only makes sense to remove this one, if the default is always ON 11:44 < wumpus> "set this at runtime instead" 11:45 < wumpus> come on, do you really care about this? 11:45 < Luke-Jr> wumpus: yes, because I will now have to support a patch to do it 11:45 < wumpus> why not just set it in bitcoin.conf instead? 11:45 < Luke-Jr> that involves manipulating bitcoin.conf 11:45 < wumpus> yeh it does... 11:46 < Luke-Jr> people who install bitcoin-qt[upnp] shouldn't need to take additional steps to enable UPnP 11:46 < Luke-Jr> people who don't want UPnP would disable it at compile-time 11:46 < wumpus> with qt it's even simpler, you can enable it in the options 11:47 < Luke-Jr> that's not simpler 11:47 < wumpus> --with-upnp *adds the feature* it doesn't enable it 11:47 < wumpus> it never did 11:47 < Luke-Jr> exactly why the separate option is needed 11:47 -!- fkhan [weechat@gateway/vpn/mullvad/x-cihgqsvpfdzxmtjy] has joined #bitcoin-core-dev 11:47 < wumpus> zmq is exactly the same 11:47 < wumpus> --with-zmq builds with libzmq, it doesn't *enable* it 11:48 < sipa> Luke-Jr: but as things are right now, we at least temporarily seem to not want it enabled by default 11:48 < wumpus> if you want it, enable it in your config 11:48 < Luke-Jr> nobody uses ZMQ though; whereas UPnP *should* be used 11:48 < wumpus> no, UPnP should not be used, it's a grave risk 11:48 < wumpus> this isn't the first vulnerability in it 11:48 < Luke-Jr> it's a grave risk to disable it too 11:48 < wumpus> well at least not a remote code execution... 11:49 < Luke-Jr> sipa: so we should distribute binaries with it disabled by default, I agree with that 11:49 < btcdrak> so we just need to point users to instructions on how to port forward. 11:49 < btcdrak> there must be plenty tutorials already out there 11:49 < wumpus> btcdrak: agreed, same as torrent clients have done for years, upnp is unreliable at best 11:49 < paveljanik> btcdrak, +1 11:49 < Luke-Jr> but if someone is explicitly compiling a build with UPnP, they shouldn't need extra steps 11:50 < sipa> Luke-Jr: but someone who compiles themselves should get it on by default? those users are exactly the ones who can set a config option too 11:50 < btcdrak> wumpus: we should just pull upnp out. I mean, this is people's money we're talking about potentially 11:50 < Luke-Jr> sipa: for example, installing on Gentoo, I have no sane way to set a config option for the user 11:50 < Eliel> sipa: I think luke's point is that to the user it feels like setting _two_ config options that way. 11:51 < wumpus> Luke-Jr: as said, it's the same for the other optional features, apart from the wallet 11:51 < wumpus> I'm done arguing this, agree with btcdrak, I'd prefer to remove upnp support completely, this is already a compromise 11:51 < Luke-Jr> … 11:52 < btcdrak> Let me go find some port forwarding tutorials 11:52 < wumpus> why do you want to expose users to the risk of upnp on gentoo by default? 11:52 < Luke-Jr> btcdrak: you're assuming the user even has access to the router 11:52 * Eliel wonders how much work it'd be to implement just the subset of upnp that bitcoin needs. 11:52 < Luke-Jr> wumpus: it's not by default 11:52 < Luke-Jr> wumpus: by default, it won't even be built with UPnP support 11:53 < sipa> Luke-Jr: then why do you need a compile-time option for it? 11:53 < gmaxwell> Luke-Jr: we went years without having upnp on by default for bitcoind. We saw no benefit from making it more on by default in our binaries. 11:53 < wumpus> if they don't have access to the router, upnp shouldn't be enabled either, it breaches the security policy too 11:53 < Luke-Jr> sipa: so when users enable it, they actually get it 11:53 < sipa> Luke-Jr: they can enable it by enabling it! 11:53 < Luke-Jr> gmaxwell: huh? the binaries have always had it on by default, no? 11:53 < gmaxwell> Luke-Jr: they do get it, by enabling it in the config! making it compile time is kinda psycho! 11:53 < Luke-Jr> sipa: they enable it system-wide by setting USE=upnp and recompiling 11:53 < gmaxwell> Luke-Jr: no bitcoin-qt did but bitcoind didn't until the switch off of makefiles, AFAIK. 11:54 < Luke-Jr> wumpus: UPnP just fixes a bug in NAT 11:54 < Luke-Jr> gmaxwell: but Bitcoin-Qt is what end users use 11:55 < Luke-Jr> obviously servers (the target for bitcoind) do not need UPnP 11:57 < Luke-Jr> anyway, --[enable|disable]-upnp-default has real use and zero cost. removing it for no reason is just annoying and wastes time. 11:58 < wumpus> the trinary option USE_UPNP confuses me every time, but apart from that, you're probably right... 11:59 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.] 11:59 < wumpus> but I don't want to wake up to people adding similar options to set other defaults at compile time, if you have --upnp-default why not --minfee-default, --zmq-default, --maxreceiveoption-default and so on... 12:00 < sipa> --reindex-default would be useful for systems with crappy disks 12:01 < wumpus> heh 12:02 < Luke-Jr> meh 12:02 < Luke-Jr> IF it is going to be removed in master, can we at least keep it around in backports? 12:07 < wumpus> I think the point of this is to backport it 12:07 < wumpus> but ok, I'll change my pull to only change the descriptors, this is not worth wasting so much time over 12:11 -!- skyraider [uid41097@gateway/web/irccloud.com/x-pacyjijtvyrsvecr] has joined #bitcoin-core-dev 12:11 < skyraider> what's the value of the master public key and master chain code in the Bip32 Test Vector 1? this doesn't seem to be specified. 12:11 < wumpus> someone that cares enough could still remove the --upnp-default setting in master 12:11 < skyraider> there is a value for "master" - a 16-byte value of some kind. however, "master" has no semantic meaning; unclear what this is. 12:12 < wumpus> skyraider: questions about BIPs are really off topic here 12:12 < skyraider> ok sorry 12:12 < sipa> skyraider: read BIP32, it clearly specifies what master means 12:12 < skyraider> correct channel? 12:12 < Luke-Jr> #bitcoin-dev 12:13 < wumpus> #bitcoin or #bitcoin-dev 12:13 < sipa> oh, it calls it seed 12:17 < gmaxwell> wumpus: at least I understand luke's complaint now. Basically the model is that gentoo users who want to use upnp ubiquitiously on their system would set a useflag. 12:17 < gmaxwell> which doesn't seem totally nutty. But the fact that supporting this craps up our code base, is .. unfortunate. 12:18 < wumpus> I suppose the useflag could do a sed -i s/UPNP_DEFAULT = 0/UPNP_DEFAULT = 1/ src/net.h as well .. ok that moves the hackyness to gentoo :) 12:19 < gmaxwell> I certantly would prefer to make it so the entire action of the default is via changing that global const. 12:20 < wumpus> though I still think that it would be just as acceptable to have a distinction between 'adding support for a feature' and 'enabling a feature' 12:20 < gmaxwell> E.g. I'd also be fine with UPNP_DEFAULT = false being overridable with a UPNP_DEFAULT_ON ifdef. 12:21 < gmaxwell> and then gentoo need not even SED. 12:21 < gmaxwell> could just set a cflag. 12:21 < Luke-Jr> CXXFLAGS="-DUPNP_DEFAULT_ON" would also be fairly simple 12:21 < Luke-Jr> not sure it's better than sed though, if it was a single well-defined location 12:22 < wumpus> setting a cflag wouldn't work, the default is a constant, not a macro 12:22 < gmaxwell> Luke-Jr: the sed is more likely to get disrupted by code motion. 12:22 < gmaxwell> wumpus: I mean having a macro that changes the constant. 12:22 < Luke-Jr> gmaxwell: true 12:22 < wumpus> ugh, if you're going with a macro anyway, then you may just as well keep the configure option 12:22 < wumpus> as we have a macro for that now: USE_UPNP 12:23 < wumpus> but ok, I'm done with this, not going to spend anymore time on it 12:23 < sipa> i think this discussion has now wasted more time than the combined benefit of the 5 gentoo bitcoin users who set use=upnp 12:23 < sipa> i don't care 12:23 < wumpus> yeah... 12:23 < Luke-Jr> >_< 12:24 < gmaxwell> wumpus: I'd happily change it if it were my PR to be just like you suggest plus letting the constant get overridden with a define, with no build system explicit support for it. 12:24 < gmaxwell> It's a few more bytes and not an unreasonable ask. 12:24 < gmaxwell> And it's nice to get rid of the crazy overload of the define value. 12:24 < gmaxwell> and make this simpler. 12:24 < wumpus> please just keep it as it is now 12:24 < wumpus> I'm sure you have something more serious to do 12:25 < wumpus> can we make a decision about mempool limiting? :p 12:26 < kanzure> sipa: what is the nature and data type of the "master" variable specified in bip32 test vector 1? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Test_vector_1 12:27 < wumpus> kanzure: read back, sipa already answered that a while back 12:27 < sipa> kanzure: it should be called seed 12:27 < kanzure> i was looking at wrong channel, sorry 12:28 < kanzure> sipa is not in -dev so i was confused 12:29 < kanzure> i am not sure that "master (hex)" is clearly defined. 12:30 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 12:32 < sipa> kanzure: it isn't, it should be called seed :) 12:35 < wumpus> should we add that to the topic? we keep getting that question :p 12:35 < kanzure> was asked in other channel, sipa wasn't around, question kept getting misinterpreted, seems natural to hunt down author 12:39 < CodeShark> kanzure: if you want to know anything about BIP32, I also had a thing or two to do with it in the past ;) 12:40 < CodeShark> btw, we should update one of the links on that page 12:40 < CodeShark> going to submit a PR 12:41 < kanzure> https://github.com/bitcoin/bips/pull/217 12:42 < CodeShark> yeah, it should be called seed ;) 12:45 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 12:45 -!- fkhan [weechat@gateway/vpn/mullvad/x-cihgqsvpfdzxmtjy] has quit [Read error: Connection reset by peer] 12:45 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 12:46 < wumpus> yes, it should... 12:48 < CodeShark> hey! I'm not in the acknowledgements for BIP32 12:48 < CodeShark> I believe I added support for it before anyone else :p 12:48 < CodeShark> and I also fixed up the text and wrote the test vector code 12:48 < CodeShark> ;) 12:50 < CodeShark> then everyone else copied my whole parallel tree implementation 12:50 < CodeShark> for multisig 12:50 < CodeShark> but bah :p 12:50 < sipa> so add yourself 12:50 < wumpus> this is not really on topic here 12:51 < wumpus> but yes, go add yourself 12:59 < CodeShark> https://github.com/bitcoin/bips/pull/218 13:00 -!- fkhan [weechat@gateway/vpn/mullvad/x-cdzfoyypnealqplb] has joined #bitcoin-core-dev 13:02 < CodeShark> is the bips repo offtopic here? 13:04 < wumpus> well, BIPs are on topic when it relates to implementing them in Bitcoin Core, but not on their own 13:05 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 13:16 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 13:18 < paveljanik> wumpus, 0.10 doesn't contain 649f5d9c1100bb3cbace724900f035939df5ea11. It was backported to 0.11 only. OK? 13:20 < morcos> wumpus: it's a bit tricky to think of what the right value should be for minrelaytxfee. i agree we should only be thinking of what we want it set to in 0.11/0.10 13:20 < morcos> but if we set it too high, and then magically in the future things just work nicely with lower tx fees b/c of limited mempool or something 13:21 < morcos> any pre-0.12 nodes will just miss out on txs unnecessarily 13:21 < morcos> and if we left the fee low on those, they'd probably be ok, bc it'd be hard to carry out the attack when most of the network wouldn't relay 13:22 < morcos> so maybe the right solution here is to raise it up higher (to temporarily protect against mempool attacks) and then once 0.12 is release, the next 0.11 release can reduce it again? 13:22 < morcos> i'm commenting here instead of pull, b/c i'm just brainstorming what makes sense 13:23 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 13:24 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 13:44 < GitHub123> [bitcoin] TheBlueMatt opened pull request #6796: Update debian/changelog and slight tweak to debian/control (master...debian) https://github.com/bitcoin/bitcoin/pull/6796 14:30 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 14:51 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Ping timeout: 252 seconds] 16:00 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 16:02 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds] 16:22 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:52 -!- skyraider [uid41097@gateway/web/irccloud.com/x-pacyjijtvyrsvecr] has quit [Quit: Connection closed for inactivity] 17:02 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 255 seconds] 17:07 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 17:12 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev 17:19 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 17:22 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmpwalhzkkkjcjtz] has quit [Quit: Connection closed for inactivity] 19:09 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 19:19 < morcos> has anybody really looked into the recent attack closely? 19:20 < morcos> one thing i find curious is when i start up a new node, it fills up pretty quickly 19:21 < morcos> at a much faster rate than an old node's mempool is growing, so that implies old txs are still showing up 19:21 < morcos> the question is, is that because somebody is rebroadcasting them over and over and if so, how come they are propogating? people keep starting up fresh nodes with empty mempools? 19:22 < morcos> or is this behavior just a "natural" feedback cycle of the network 19:22 < morcos> would it go away when the recentRejects code is widespread? 19:23 < morcos> do we need to reconsider how wallet rebroadcast works? 19:28 < morcos> hmm.. maybe the recentRejcts code isn't going to help that much since it resets 19:30 < morcos> BlueMatt: sipa: sdaftuar: this seems like it could be a problem with limited mempools if there is some way to induce this kind of behavior 19:31 < morcos> where you are relayed many many times. 19:32 < morcos> some of these txs seem to have been requested by my nodes half a dozen times or more 19:32 < morcos> maybe its particularly bad b/c of peer churn now too? 19:38 < petertodd> morcos: the random drop strategy of XT may be helping these txs get rebroadcast 19:38 < morcos> i think that'd be mostly true for any eviction strategy though right? 19:39 < petertodd> morcos: no, the random drop stategy means they can be rebroadcast 19:39 < petertodd> morcos: deterministic strategies don't let that happen in the same way 19:39 < morcos> sort of, you could evict it but then later accept it (and relay it again) 19:40 < petertodd> morcos: exactly 19:40 < morcos> even with 6722 i'm saying 19:40 < morcos> you wouldn't immediately accept it again 19:40 < petertodd> morcos: less of an issue there though, as minfee will rise accordingly 19:40 < petertodd> morcos: random drop allows that to happen wholesale 19:40 < Luke-Jr> oh. 19:41 < Luke-Jr> are we rebroadcasting received wtx still? could spammers target real users to get the amplification? 19:41 < morcos> yeah i guess you might be right that its a lot better 19:41 < morcos> Luke-Jr: ooo, hadn't thought about that.. htats terrible 19:41 < morcos> dont' think thats happening here, since the txs tend to be 100 inputs -> 1 output 19:42 < morcos> and so no room to target somebody else 19:42 < petertodd> Luke-Jr: wouldn't be an issue w/ deterministic dropping mind you 19:42 < Luke-Jr> a possible risk tho 19:42 < Luke-Jr> petertodd: it's an issue as long as you rebroadcast your own crap 19:42 < petertodd> Luke-Jr: it's a privacy issue, but much less of a network-wide DoS one 19:42 < Luke-Jr> petertodd: get enough nodes doing it.. 19:43 < petertodd> Luke-Jr: not very likely; too few btc core wallets out there (sadly!) 19:43 < Luke-Jr> :| 19:43 < morcos> i agree with Luke-Jr, seems like its worth thinking about more. increase min fee helps a lot, but once there is enough diversity in the network 19:44 < morcos> it may be able to keep bouncing around 19:44 < morcos> ha! too few core wallets saves the day 19:44 < petertodd> morcos: well, clever attackers would have some anyone-can-spend outputs and do it that way... 19:44 < petertodd> morcos: which incidentally, I have seen before 19:45 < petertodd> bbl 19:46 < Luke-Jr> petertodd: anyone-can-spend outputs are not recognised by the wallet.. 19:56 < phantomcircuit> for good reason 19:58 < Luke-Jr> multiple good reasons :p 20:00 < midnightmagic> w 19 20:10 -!- Guest7151 [~attar@202.67.36.244] has joined #bitcoin-core-dev 20:10 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 20:13 -!- Guest7151 is now known as attar66 20:13 < attar66> hi 20:14 < attar66> no body talk? 20:21 < petertodd> Luke-Jr: there's a bunch of people automatically grabbing anyone-can-spend outputs, of all types (e.g. known privkey too) 20:27 < gmaxwell> morcos: normally there is no rebroadcast, but over the years there have been no shortage of idiots who amplify. 20:27 < gmaxwell> it would be useful to check to see which peers are giving you these transactions (turn up debugging) 20:36 -!- attar66 [~attar@202.67.36.244] has quit [Ping timeout: 250 seconds] 21:08 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev 21:09 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Client Quit] 21:32 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 22:07 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 22:07 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:15 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:34 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Remote host closed the connection] 22:34 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev 22:40 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection] 22:42 -!- lightningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev 23:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 23:10 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 23:11 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 23:24 < wumpus> morcos: sure, mintxfee could be reduced again in e.g. a later 0.10.x/0.11.x version, if 0.12 is released and mempool limiting works - if those versions still matter by that time 23:31 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 23:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:38 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 23:45 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 23:57 -!- PRab [~chatzilla@2601:40a:8000:8f9b:7023:f46d:1955:e417] has quit [Ping timeout: 246 seconds] 23:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dpuqfmrklfrjqeqm] has joined #bitcoin-core-dev 23:59 -!- PRab [~chatzilla@2601:40a:8000:8f9b:7023:f46d:1955:e417] has joined #bitcoin-core-dev