12015-10-09T00:01:06 <Luke-Jr> is there a way to get [skip ci] without polluting the commit message?
22015-10-09T00:02:20 <sipa> ask a maintainer to kill the travis job :p
32015-10-09T00:03:23 <Luke-Jr> sipa: are you okay with me asking people to remove it from commit messages and ask maintainers instead? :P
42015-10-09T00:03:45 <Luke-Jr> seems like a waste of time
52015-10-09T00:03:49 <sipa> yeah :)
62015-10-09T00:03:52 *** challisto has quit IRC
72015-10-09T00:03:56 <sipa> i just wouldn't bother
82015-10-09T00:04:12 *** Ylbam has quit IRC
92015-10-09T00:31:07 *** challisto has joined #bitcoin-core-dev
102015-10-09T00:31:07 *** challisto has joined #bitcoin-core-dev
112015-10-09T01:31:16 *** challisto has quit IRC
122015-10-09T01:37:03 *** belcher has quit IRC
132015-10-09T02:01:21 *** PaulCape_ has joined #bitcoin-core-dev
142015-10-09T02:04:00 *** PaulCapestany has quit IRC
152015-10-09T02:20:58 *** molly has joined #bitcoin-core-dev
162015-10-09T02:24:19 *** moli has quit IRC
172015-10-09T02:59:26 *** d_t has quit IRC
182015-10-09T03:00:26 *** d_t has joined #bitcoin-core-dev
192015-10-09T03:12:22 <CodeShark> hmm, SoftForkMajorityDesc needs to be moved into the soft forks unit as well...
202015-10-09T03:14:52 *** d_t has quit IRC
212015-10-09T03:14:58 <CodeShark> would be nice to define the validation rules for each soft fork in its own module as well...so then the entire soft fork can be specified as a unit that just needs to be added and linked to Bitcoin Core
222015-10-09T03:15:25 <CodeShark> no more need for PRs for that :)
232015-10-09T03:15:33 <CodeShark> other than the trivial link
242015-10-09T03:16:27 <CodeShark> totally doable, too
252015-10-09T03:18:17 <CodeShark> I know how to do it...but it would require moving a few things around in main.cpp
262015-10-09T03:18:40 <CodeShark> hopefully can be done without being too extremely invasive
272015-10-09T03:20:05 <CodeShark> the only real question I have is whether this is desirable...should we make it *that* easy to define and deploy a soft fork?
282015-10-09T03:20:52 <CodeShark> would require some changes to script/interpreter.cpp as well
292015-10-09T03:21:30 <CodeShark> but I think that it could be done in a minimally invasive way...keeping what's already there more or less in tact
302015-10-09T03:21:33 <CodeShark> *intact
312015-10-09T03:32:48 *** jgarzik has joined #bitcoin-core-dev
322015-10-09T03:32:48 *** jgarzik has joined #bitcoin-core-dev
332015-10-09T03:37:45 <GitHub142> [bitcoin] dgenr8 opened 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
342015-10-09T03:50:21 *** moli has joined #bitcoin-core-dev
352015-10-09T03:53:19 *** molly has quit IRC
362015-10-09T03:57:50 *** jgarzik has quit IRC
372015-10-09T04:11:25 *** d_t has joined #bitcoin-core-dev
382015-10-09T04:47:42 *** da2ce7 has quit IRC
392015-10-09T05:13:26 *** paveljanik has quit IRC
402015-10-09T05:22:25 *** d_t has quit IRC
412015-10-09T05:57:00 *** PaulCapestany has joined #bitcoin-core-dev
422015-10-09T05:59:10 *** PaulCape_ has quit IRC
432015-10-09T06:01:21 *** d_t has joined #bitcoin-core-dev
442015-10-09T06:06:30 *** Ylbam has joined #bitcoin-core-dev
452015-10-09T06:08:19 *** epilido has joined #bitcoin-core-dev
462015-10-09T06:38:39 *** n0n0__ has joined #bitcoin-core-dev
472015-10-09T07:17:28 *** Squidicuz has quit IRC
482015-10-09T07:17:36 <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
492015-10-09T07:29:10 *** n0n0__ has quit IRC
502015-10-09T07:35:42 *** randy-waterhouse has joined #bitcoin-core-dev
512015-10-09T07:52:31 *** da2ce7 has joined #bitcoin-core-dev
522015-10-09T07:59:47 *** fkhan has quit IRC
532015-10-09T08:00:01 *** da2ce7 has quit IRC
542015-10-09T08:09:30 <wumpus> Luke-Jr: [skip ci] only works in the commit message, not the pull title?
552015-10-09T08:10:03 <Luke-Jr> wumpus: ?
562015-10-09T08:12:24 *** fkhan has joined #bitcoin-core-dev
572015-10-09T08:13:24 <wumpus> Luke-Jr: I mean - what does travis look at, the pull request title or the commit message?
582015-10-09T08:13:44 <Luke-Jr> no idea, I just don't like it in the commit message :p
592015-10-09T08:13:55 <wumpus> hm only commit message from http://docs.travis-ci.com/user/customizing-the-build/
602015-10-09T08:14:03 <wumpus> but it *doesn't have* to be in the first part
612015-10-09T08:14:21 <Luke-Jr> moving it to the long description would be an improvement at least
622015-10-09T08:14:26 *** rubensayshi has joined #bitcoin-core-dev
632015-10-09T08:14:31 <wumpus> you can just [skip ci] hide it somewhere in the description
642015-10-09T08:16:27 <GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d479311dba25...a99b6cb19ee7
652015-10-09T08:16:27 <GitHub84> bitcoin/master b2af29b Pavel JanÃk: Ignore bench_bitcoin binary.
662015-10-09T08:16:28 <GitHub84> bitcoin/master a99b6cb Wladimir J. van der Laan: Merge pull request #6770...
672015-10-09T08:16:32 <GitHub12> [bitcoin] laanwj closed pull request #6770: [Trivial] Ignore bench_bitcoin binary [skip ci] (master...bench_gitignore) https://github.com/bitcoin/bitcoin/pull/6770
682015-10-09T08:17:27 *** da2ce7 has joined #bitcoin-core-dev
692015-10-09T08:21:03 *** ParadoxSpiral has joined #bitcoin-core-dev
702015-10-09T08:21:49 <GitHub52> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a99b6cb19ee7...c82ea8b271c8
712015-10-09T08:21:49 <GitHub52> bitcoin/master 34754ce Chris Kleeschulte: [Trivial] Fixed typo when referring to a previous section in...
722015-10-09T08:21:50 <GitHub52> bitcoin/master c82ea8b Wladimir J. van der Laan: Merge pull request #6783...
732015-10-09T08:21:54 <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
742015-10-09T08:27:06 <GitHub28> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c82ea8b271c8...6cf73b0cd4cf
752015-10-09T08:27:06 <GitHub28> bitcoin/master b22692c Cory Fields: build: Make use of ZMQ_CFLAGS
762015-10-09T08:27:07 <GitHub28> bitcoin/master 6cf73b0 Wladimir J. van der Laan: Merge pull request #6779...
772015-10-09T08:27:16 <GitHub61> [bitcoin] laanwj closed pull request #6779: build: Make use of ZMQ_CFLAGS (master...fix-zmq-cflags) https://github.com/bitcoin/bitcoin/pull/6779
782015-10-09T08:37:06 <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
792015-10-09T08:37:16 <aj> s/think/in thinking/
802015-10-09T08:37:31 *** fkhan has quit IRC
812015-10-09T08:38:08 <Luke-Jr> aj: just the usual softfork expectations given SPV limitations
822015-10-09T08:38:15 <Luke-Jr> 1-block confirmation is never secure for SPV anyway
832015-10-09T08:38:34 <aj> Luke-Jr: afaics for softforks that upgrade OP_NOP's SPV clients won't have that problem
842015-10-09T08:38:51 <aj> Luke-Jr: (or won't have it any worse than normal anyway)
852015-10-09T08:39:16 <Luke-Jr> aj: I don't follow then.
862015-10-09T08:39:59 <aj> Luke-Jr: (1) afaics, apart from elegius, 99.9% of existing hashpower won't mine OP_NOP txns but will mine nSequence transactions
872015-10-09T08:40:29 <Luke-Jr> oh, I see what you mean
882015-10-09T08:40:56 <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
892015-10-09T08:41:24 <aj> Luke-Jr: so SPV clients go from .1% (made up number) of hashpower being a problem to 5% of hashpower being a problem
902015-10-09T08:41:34 <Luke-Jr> aj: I don't think there's ever been a softfork without this "problem"
912015-10-09T08:41:50 <Luke-Jr> well, except BIP66 I guess
922015-10-09T08:42:05 <Luke-Jr> not even that actually
932015-10-09T08:42:22 <Luke-Jr> because older block versions were disallowed
942015-10-09T08:42:42 <Luke-Jr> anyway, 5% of hashpower won't get more than a block or two deep
952015-10-09T08:42:45 <aj> Luke-Jr: afaik SPV clients don't check block versions generally anyway
962015-10-09T08:43:06 <aj> Luke-Jr: OP_CLTV won't have that problem, afaics
972015-10-09T08:43:24 <Luke-Jr> perhaps not. but it will be the first not to.
982015-10-09T08:43:29 <aj> Luke-Jr: (wow)
992015-10-09T08:43:38 <Luke-Jr> and SPV 1-block confirmation is not secure regardless
1002015-10-09T08:44:15 <Luke-Jr> aj: the versionbits stuff does improve on this
1012015-10-09T08:44:41 <Luke-Jr> after the softfork goes active, there is a difficulty-adjustment period (2 weeks) before it is enforced
1022015-10-09T08:45:00 <Luke-Jr> so other miners can upgrade
1032015-10-09T08:45:05 <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?
1042015-10-09T08:45:57 <Luke-Jr> aj: SPV nodes need the full header-history anyway, so they can implement versionbits
1052015-10-09T08:46:29 <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?
1062015-10-09T08:46:49 <Luke-Jr> aj: only if 5% got left behind
1072015-10-09T08:47:19 <Luke-Jr> aj: the expectation is not that those 5% continue mining invalid blocks
1082015-10-09T08:48:11 <aj> Luke-Jr: hmm, is there any way to tell how much hashpower dropped off in previous upgrades?
1092015-10-09T08:48:36 <Luke-Jr> dunno, probably just Deepbit
1102015-10-09T08:48:43 <aj> Deepbit
1112015-10-09T08:48:44 <aj> ?
1122015-10-09T08:49:01 <aj> oh that was a mining pool, not a stats site? :)
1132015-10-09T08:49:07 <Luke-Jr> aj: a mining pool that once had over 50% ;)
1142015-10-09T08:49:37 <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
1152015-10-09T08:50:02 <Luke-Jr> CodeShark: will versionbits impl kill mining when it detects it is being softforked out?
1162015-10-09T08:50:24 <Luke-Jr> ie, getblocktemplate should probably fail if some activated softfork is unsupported
1172015-10-09T08:50:48 <Luke-Jr> CodeShark: btw, I was thinking of the softfork plugin thing a bit ago also, so sounds good to me :P
1182015-10-09T08:50:57 <CodeShark> :)
1192015-10-09T08:51:05 *** fkhan has joined #bitcoin-core-dev
1202015-10-09T08:51:14 <Luke-Jr> maybe harder than it seems though in practice
1212015-10-09T08:52:04 <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 :)
1222015-10-09T08:53:24 <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
1232015-10-09T08:53:57 <aj> be easier to backport pluggable soft forks once the plugin thing exists too, presumably
1242015-10-09T08:54:14 <CodeShark> yes, of course
1252015-10-09T08:54:49 <sipa> what do you mean by plugin system?
1262015-10-09T08:55:03 <CodeShark> I posted something on the mailing list - but I'm guessing you unsubscribed :)
1272015-10-09T08:55:13 <sipa> yes
1282015-10-09T08:55:24 <CodeShark> I can forward it to you if you want
1292015-10-09T08:55:35 <CodeShark> or you can look for the link on linuxfoundation.org :)
1302015-10-09T08:55:39 <aj> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011487.html
1312015-10-09T08:55:50 <aj> and/or http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011491.html
1322015-10-09T08:57:20 <sipa> shouldn't need any changes in primitives... that's only for data types, their construction, and serialization... softforks can't change those
1332015-10-09T08:57:30 <CodeShark> CBlock needs a new default version
1342015-10-09T08:57:44 <CodeShark> or could be implemented in getblocktemplate, I suppose
1352015-10-09T08:57:48 <CodeShark> in principle I agree
1362015-10-09T08:57:58 <CodeShark> CBlock should not be where the default version gets set
1372015-10-09T08:58:07 *** fkhan has quit IRC
1382015-10-09T08:58:10 <sipa> yes, indeed
1392015-10-09T08:58:19 <sipa> those default versions there don't belong
1402015-10-09T08:59:14 <sipa> you say "easily merged units"... that's pretty vague
1412015-10-09T08:59:17 <CodeShark> right - primitives should just handle data access and serialization
1422015-10-09T08:59:22 <sipa> what do you mean specifically?
1432015-10-09T08:59:27 <btcdrak> sipa: will you consider joining again after we get the new list and push offtopic stuff to the new list?
1442015-10-09T08:59:33 <sipa> btcdrak: maybe
1452015-10-09T08:59:39 <CodeShark> sipa: by adding two lines to the makefile and one line to an init function
1462015-10-09T08:59:48 <CodeShark> and two files to the repo :)
1472015-10-09T09:00:11 <CodeShark> at least for starters
1482015-10-09T09:00:21 <CodeShark> long-term it would even be possible to deploy at runtime
1492015-10-09T09:00:22 <sipa> CodeShark: so you pretty much mean... changing the code location organizatiin so that soft forks are the top level?
1502015-10-09T09:00:51 <CodeShark> yeah, I suppose you could say that
1512015-10-09T09:00:55 <sipa> what if soft forks require wallet changes? or block creation code changes?
1522015-10-09T09:01:24 <CodeShark> we start with the consensus hooks...then worry about UI :p
1532015-10-09T09:01:31 <sipa> ok
1542015-10-09T09:02:48 <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"
1552015-10-09T09:02:58 <sipa> but... perhaps
1562015-10-09T09:03:14 <CodeShark> well, if you take a look at how BIP65 and BIP66 are deployed, there aren't too many places really
1572015-10-09T09:03:32 <CodeShark> BIP65 is a tad bit more complex in the sense that it also defines an op code
1582015-10-09T09:04:27 <CodeShark> so we need a hook in the script interpreter
1592015-10-09T09:04:52 <sipa> yeah, i don't like that
1602015-10-09T09:04:57 <sipa> not for consensus
1612015-10-09T09:05:35 <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
1622015-10-09T09:05:37 <wumpus> consensus code should be as simple and straightforward and self-contained as possible, IMO, no hooks and plugins
1632015-10-09T09:05:48 <CodeShark> I think this is about as simple as it gets, though
1642015-10-09T09:05:57 <CodeShark> it makes any change to consensus very easy to review
1652015-10-09T09:06:16 *** go1111111 has quit IRC
1662015-10-09T09:06:19 <CodeShark> the diff becomes trivial
1672015-10-09T09:06:51 <wumpus> does it? interaction/crosstalk issues tend to be problematic for plugin-like systems, what sipa says
1682015-10-09T09:07:14 <wumpus> needs to be easy to follow the execution flow
1692015-10-09T09:07:22 <CodeShark> a soft fork has well-defined abstract behavior
1702015-10-09T09:07:22 <wumpus> and *in which sequence* things are done
1712015-10-09T09:07:35 <CodeShark> the implementor just needs to specify what those behaviors actually are
1722015-10-09T09:09:01 <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
1732015-10-09T09:09:24 <Luke-Jr> CodeShark: so⦠let's say a softfork with segregated witness..?
1742015-10-09T09:10:04 <CodeShark> can we do that cleanly with a soft fork?
1752015-10-09T09:10:13 <Luke-Jr> in theory, I don't see why not
1762015-10-09T09:10:21 <sipa> I don't see how.
1772015-10-09T09:10:23 <Luke-Jr> probably entails p2p protocol changes though
1782015-10-09T09:10:53 *** fkhan has joined #bitcoin-core-dev
1792015-10-09T09:11:07 <sipa> Only in a very non-useful way could you do it, with external data blobs that blocks commit to (like extension blocks).
1802015-10-09T09:11:08 <Luke-Jr> well, we can't segregate the existing scripts - but P2SH-like..
1812015-10-09T09:11:29 <sipa> no
1822015-10-09T09:11:49 <sipa> segregated witness changes how transactions refer to each other
1832015-10-09T09:12:07 <sipa> i guess you can do it by making transactions not contain scriptSigs
1842015-10-09T09:12:12 <Luke-Jr> exactly
1852015-10-09T09:12:43 <sipa> and have separate witness structures that are relayed separately, and committed to in a block's coinbase
1862015-10-09T09:12:46 <sipa> ok
1872015-10-09T09:13:12 *** go1111111 has joined #bitcoin-core-dev
1882015-10-09T09:13:16 <sipa> yeah, that wouldn't easily fit into a hook structure, i think
1892015-10-09T09:13:45 <CodeShark> I'm just thinking about the consensus structures themselves - not the relay mechanisms. I see the p2p stuff as a separate layer
1902015-10-09T09:14:13 <sipa> yes, but even the consensus changes wouldn't easily fit in
1912015-10-09T09:14:16 * Luke-Jr , after breaking softfork plugins, runs off to bed. :P
1922015-10-09T09:14:50 <CodeShark> sipa: I just think of the witness structures as additional validation context
1932015-10-09T09:15:03 <CodeShark> they can be anything, really - any additional state required at validation time
1942015-10-09T09:15:45 <sipa> ok, how does that fit in?
1952015-10-09T09:16:03 <CodeShark> we'd probably need to rearchitect the script interpreter a bit to be more abstract
1962015-10-09T09:16:13 <wumpus> no...
1972015-10-09T09:17:10 <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)
1982015-10-09T09:18:45 <CodeShark> routine ones being stuff like nVersion changes and the kind of stuff we currently do in main.cpp
1992015-10-09T09:19:04 <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
2002015-10-09T09:19:44 <CodeShark> yes, agreed, Luke-Jr. That's sorta what I meant by abstracting the script interpreter a bit more
2012015-10-09T09:19:54 *** fkhan has quit IRC
2022015-10-09T09:19:57 <Luke-Jr> CodeShark: no, in this case we'd have entire duplication of the consensus lib âº
2032015-10-09T09:20:15 <Luke-Jr> (so it can be reused for hardforks as well)
2042015-10-09T09:20:16 <CodeShark> no...the soft fork plugins could use the consensus lib once it's ready
2052015-10-09T09:20:26 <Luke-Jr> CodeShark: well, that's not what I just described
2062015-10-09T09:20:45 <Luke-Jr> and we'll want to do these dynamic calls anyway if we support sidechains in a single node ever
2072015-10-09T09:21:08 <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
2082015-10-09T09:21:39 <CodeShark> then on top of this you have core structures (blocks and transactions) which generally can only change their fields with a hard fork
2092015-10-09T09:21:50 <CodeShark> so let's say they are invariant as well
2102015-10-09T09:22:14 <CodeShark> then on top of this you have context (UTXO, timestamp)
2112015-10-09T09:22:41 <CodeShark> if these checks work, then you run the script
2122015-10-09T09:23:39 <sipa> we don't even get to do simple refactors
2132015-10-09T09:23:55 <CodeShark> sipa: understand this is not a one or two month plan :p
2142015-10-09T09:24:01 <CodeShark> this is probably out at least a year
2152015-10-09T09:24:18 <CodeShark> point is unless we start thinking about this kind of stuff well in advance it will probably never happen
2162015-10-09T09:24:20 <sipa> i'm not convinced it's very useful
2172015-10-09T09:24:34 <CodeShark> ok, then I have some homework to do :)
2182015-10-09T09:24:44 <sipa> the trivial softforks it is targetting are already simple to review
2192015-10-09T09:24:51 <CodeShark> for you, sipa
2202015-10-09T09:24:58 <CodeShark> I'd rather you spend your time doing other stuff :p
2212015-10-09T09:25:03 <CodeShark> for most people it's still very hard
2222015-10-09T09:25:17 *** d_t has quit IRC
2232015-10-09T09:25:19 <sipa> the non-trivial ones will become harder, because they'll need to change the plugin api...
2242015-10-09T09:25:39 <CodeShark> not if we abstract things well enough
2252015-10-09T09:26:15 <CodeShark> there's a sequence of validation steps that can be easily abstracted regardless of the specific rules
2262015-10-09T09:27:16 <sipa> i don't see how you could create an abstraction that keeps working with seggregated witness, for example
2272015-10-09T09:27:40 <CodeShark> isn't segregated witness effectively additional state required for validation?
2282015-10-09T09:28:03 <sipa> seggregated witness, from the point of existing code, removes script and sigScript entirely
2292015-10-09T09:28:08 <CodeShark> let
2302015-10-09T09:28:23 <sipa> and then jntroduces a new primitive data structure, to which consensus rules are applied
2312015-10-09T09:28:55 <sipa> i think you're biased by having seen a few simple soft forks
2322015-10-09T09:28:57 <CodeShark> removes script and sigScript?
2332015-10-09T09:29:27 <sipa> yes, transactions would end up having an empty scriptSig
2342015-10-09T09:29:39 <CodeShark> I get that part - what do you mean by "script"
2352015-10-09T09:29:40 <CodeShark> ?
2362015-10-09T09:29:45 <CodeShark> scriptPubKey?
2372015-10-09T09:29:49 <sipa> by script i mean the script subdir in the code
2382015-10-09T09:30:04 <CodeShark> oh...so interpreter.cpp
2392015-10-09T09:30:14 <CodeShark> and that stuff :)
2402015-10-09T09:30:16 <sipa> of course, it would get reused in a new piece of code
2412015-10-09T09:30:45 <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
2422015-10-09T09:30:57 <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
2432015-10-09T09:31:31 <sipa> how do you deal with cases where more data needs to be exposed to the script interpreter?
2442015-10-09T09:31:42 <CodeShark> I imagine a function Validate(context, transaction)
2452015-10-09T09:31:50 <CodeShark> where context could be extended
2462015-10-09T09:32:12 <CodeShark> but for now it covers the current block tree
2472015-10-09T09:32:16 <CodeShark> and utxo set
2482015-10-09T09:32:20 <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
2492015-10-09T09:32:28 <sipa> no, it's not that easy
2502015-10-09T09:32:54 <sipa> script execution can purposefully not depend on certain data
2512015-10-09T09:32:58 <sipa> like height
2522015-10-09T09:33:26 <sipa> to avoid transactions going from valid to invalid
2532015-10-09T09:34:01 <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
2542015-10-09T09:34:25 <CodeShark> I agree it isn't trivial
2552015-10-09T09:34:26 *** fkhan has joined #bitcoin-core-dev
2562015-10-09T09:34:30 <CodeShark> it's a challenge - but I think it's doable
2572015-10-09T09:34:54 <sipa> i think you're underestimating the costs to others
2582015-10-09T09:34:56 <CodeShark> the trick here is figuring out what sorts of context can be excluded from what types of checks
2592015-10-09T09:35:23 <CodeShark> and what sorts of context are desirable to exclude
2602015-10-09T09:35:41 <CodeShark> again, this is not a one- or two-month plan
2612015-10-09T09:36:02 <sipa> ok: bottom line, i am very skeptical about the benefits
2622015-10-09T09:36:15 <sipa> now let's talk about things we can actually do
2632015-10-09T09:36:58 <CodeShark> but we CAN do this...it's just going to take a much longer time than one release cycle
2642015-10-09T09:37:33 <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 :)
2652015-10-09T09:37:44 <CodeShark> you might be able to convince me of the former
2662015-10-09T09:37:51 <sipa> it's certainly possible with high costs
2672015-10-09T09:38:09 <CodeShark> given our current process, I agree
2682015-10-09T09:38:11 <sipa> but i don't think it's the right direction to.go in
2692015-10-09T09:38:20 <CodeShark> ok - that's more fruitful discussion
2702015-10-09T09:38:31 <sipa> i would aim to have less abstractions, not more
2712015-10-09T09:38:41 <sipa> because they complicate reasoning and proving what code can do
2722015-10-09T09:38:57 <CodeShark> that depends on how the logic is chunked, though
2732015-10-09T09:39:09 <sipa> maybe
2742015-10-09T09:39:17 <sipa> i'm not saying there are no benefits
2752015-10-09T09:39:18 <CodeShark> the mind is capable of handling craploads of complexity as long as it's well-encapsulated with a simple interface
2762015-10-09T09:39:27 <sipa> but it will come at a high cost, and not just reviee cost
2772015-10-09T09:40:32 <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
2782015-10-09T09:40:51 <sipa> you will need to know what all plugins are doing to see whether the result is consensus safe
2792015-10-09T09:41:43 <CodeShark> if the plugins have interdependencies it does potentially add a significant amount of complexity, especially circular dependencies
2802015-10-09T09:41:51 <sipa> that's not what i mean
2812015-10-09T09:42:28 <CodeShark> with this architecture you could simulate whatever rules you wanted and review specific units that focus exactly on the rules in question
2822015-10-09T09:43:05 <sipa> in theory
2832015-10-09T09:43:34 <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 :)
2842015-10-09T09:43:56 <CodeShark> this is process scalability
2852015-10-09T09:43:58 <sipa> CodeShark: i will still review them if they are in plugins
2862015-10-09T09:44:12 <sipa> i don't see how this changes anything
2872015-10-09T09:44:13 <wumpus> at least some people are going to know those lines of code *very* well then
2882015-10-09T09:44:15 <CodeShark> yes, but the author can be tasked with proving them out considerably more before you even touch them
2892015-10-09T09:44:50 <wumpus> ... which is kind of the goal, people need to understand the consensus rules and how everything fits together
2902015-10-09T09:44:51 <CodeShark> we can have a review process where stuff gets better screening before it gets to you
2912015-10-09T09:44:52 <sipa> i don't believe that
2922015-10-09T09:45:09 <sipa> i think more abstraction will only result in more ways a plugin could screw with consensus
2932015-10-09T09:45:38 <sipa> unless it is very minimal, and thus nearly useless
2942015-10-09T09:55:57 <GitHub198> [bitcoin] MarcoFalke opened pull request #6788: [trivial] sync univalue (master...MarcoFalke-2015-syncUnivalue) https://github.com/bitcoin/bitcoin/pull/6788
2952015-10-09T10:34:39 *** epilido has quit IRC
2962015-10-09T10:44:52 *** fkhan has quit IRC
2972015-10-09T10:56:11 *** n0n0__ has joined #bitcoin-core-dev
2982015-10-09T10:59:57 *** fkhan has joined #bitcoin-core-dev
2992015-10-09T11:21:32 <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
3002015-10-09T11:24:58 <wumpus> this is going to force our hand re: new 0.10.x and 0.11.x releases
3012015-10-09T11:34:30 <morcos> would you still consider trying to bundle the other stuff in?
3022015-10-09T11:43:07 <wumpus> I think everything that is currently in the branches should be included (including the LowS enforcement)
3032015-10-09T11:44:50 <wumpus> so it can be announced as dual fix: upnp security issue and mallability nuisance
3042015-10-09T11:45:59 <wumpus> I don't think the CLTV softfork should be included
3052015-10-09T11:48:46 <sipa> i wonder whether we should disconnect softforks entirely from releases
3062015-10-09T11:49:26 <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
3072015-10-09T11:52:18 <wumpus> internal versions 0.11.1.1 and 0.10.3.1?
3082015-10-09T11:52:44 <sipa> i guess we could coopt the lowest digit for that
3092015-10-09T11:52:47 <wumpus> we never use the fourth number
3102015-10-09T11:53:05 <sipa> we have used it occasionally for platform-specific releases
3112015-10-09T11:53:10 <sipa> like windows-only bugfixes
3122015-10-09T11:53:19 <sipa> but that's not a big deal
3132015-10-09T11:53:41 <wumpus> but I'm ok with the idea...
3142015-10-09T11:53:57 <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
3152015-10-09T11:54:18 <wumpus> yes
3162015-10-09T11:55:22 <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"
3172015-10-09T11:55:35 <sipa> to avoid needing huge names for historical softforks
3182015-10-09T11:58:47 <wumpus> though it may be hard to get people to upgrade to a 0.11.1-cltv if they already have 0.11.1
3192015-10-09T12:01:54 <btcdrak> I dont like having a -cltv release.
3202015-10-09T12:02:38 <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.
3212015-10-09T12:02:49 <btcdrak> let's not get overly pedantic
3222015-10-09T12:03:29 <btcdrak> let's release what we have.
3232015-10-09T12:04:04 <wumpus> that's already my plan btcdrak
3242015-10-09T12:04:26 <wumpus> the softfork releease would be what is planned for the end of the month
3252015-10-09T12:04:27 <btcdrak> wumpus: +1
3262015-10-09T12:05:37 <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
3272015-10-09T12:08:17 <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)
3282015-10-09T12:08:39 <btcdrak> OT: how serious is this miniupnp issue?
3292015-10-09T12:09:07 <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
3302015-10-09T12:10:25 <wumpus> as I understand it, any local device could feed invalid data to the UPNP discovery and overflow a buffer
3312015-10-09T12:12:42 <sipa> I understand the downside... it's just an idea.
3322015-10-09T12:13:22 <sipa> I think it makes sense to help understand people that the network rules are more or less independent from the software
3332015-10-09T12:13:48 <wumpus> btcdrak: the TALOS description is quite detailed; I don't know more, haven't tried to exploit it
3342015-10-09T12:14:22 <wumpus> sipa: I absolutely agree - just don't know if version *numbers* are the right way to communciate that :-)
3352015-10-09T12:14:47 <sipa> fair enough
3362015-10-09T12:15:00 <wumpus> may be better to write something in the release notes, if someone is good at writing those things
3372015-10-09T12:15:10 <wumpus> anyhow that's a problem for end of the month
3382015-10-09T12:15:47 <wumpus> I think merging https://github.com/bitcoin/bitcoin/pull/6785 makes sense before 0.11.1
3392015-10-09T12:16:16 <gavinandresen> remote exploit is serious enough to warrant an alert, in my humble opinion
3402015-10-09T12:17:22 <wumpus> yeah, probably
3412015-10-09T12:18:09 <wumpus> I've thought about sending one to make people disable upnp
3422015-10-09T12:18:17 <wumpus> but reconsidered quickly
3432015-10-09T12:18:38 <wumpus> so let's get the new versions out first
3442015-10-09T12:18:41 <sipa> yeah
3452015-10-09T12:18:45 <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
3462015-10-09T12:19:13 <wumpus> CodeShark: don't be crazy, this is not #bitcoin-sciencefiction :p
3472015-10-09T12:19:23 <CodeShark> heh
3482015-10-09T12:19:53 <sipa> ipv6 has a 2^96 times larger address space, so it will take 2^96 times as long to deploy, obviously
3492015-10-09T12:20:41 <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
3502015-10-09T12:21:03 <morcos> its not like its an option you can really choose in addition to getting your upgrades
3512015-10-09T12:21:49 <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.
3522015-10-09T12:21:57 <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
3532015-10-09T12:22:15 <morcos> but no one can argue we were witholding critical security updates if they didn't go along wiht the softfork
3542015-10-09T12:22:20 <CodeShark> lol - the one without is called a command line option...the one with is called the default settings
3552015-10-09T12:23:54 <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
3562015-10-09T12:24:22 <btcdrak> morcos: releasing often is always a good thing
3572015-10-09T12:24:28 <CodeShark> I am very close to having a functioning versionbits implementation, fwiw
3582015-10-09T12:24:35 <morcos> not when people NEED each of the upgrades
3592015-10-09T12:24:44 <morcos> ok so 5
3602015-10-09T12:24:46 <morcos> :)
3612015-10-09T12:24:55 <sipa> fair enough
3622015-10-09T12:25:27 <morcos> 0.12 although a major version upgrade will be essentially required b/c of mempool limiting
3632015-10-09T12:25:55 <CodeShark> in principle, we should probably have version numbers for the protocol itself
3642015-10-09T12:26:02 <CodeShark> separate from the software
3652015-10-09T12:26:03 <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
3662015-10-09T12:26:28 <sipa> CodeShark: we have those...
3672015-10-09T12:26:33 <CodeShark> the block header version is sorta that...but not exactly
3682015-10-09T12:26:38 <sipa> block version numbers for consensus
3692015-10-09T12:26:45 <sipa> protocol version numbers for protocol
3702015-10-09T12:27:13 <CodeShark> with versionbits, we're moving away entirely from sequential numbering
3712015-10-09T12:27:33 <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
3722015-10-09T12:27:50 <morcos> then people can decide which to skip and not just blindly upgrade? but is that asking too much
3732015-10-09T12:28:22 <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â
3742015-10-09T12:28:57 <sipa> where can i read about this vulnerability?
3752015-10-09T12:29:02 <CodeShark> but people behind a firewall might just shut down their node
3762015-10-09T12:29:07 <gavinandresen> sipa: http://talosintel.com/reports/TALOS-2015-0035/
3772015-10-09T12:29:36 <gavinandresen> sipa: ⦠from wumpusâ https://github.com/bitcoin/bitcoin/pull/6789
3782015-10-09T12:29:50 <sipa> so you need access to the local network
3792015-10-09T12:30:48 <sipa> presumably, such situations are more dangerous in corporate networks, where upnp doesn't worn anyway
3802015-10-09T12:31:07 <gavinandresen> âdoesnât workâ != âisnât vulnerableâ though
3812015-10-09T12:31:54 <sipa> sure, just saying that the place where this risk is largest, is one where upnp has no use anywah
3822015-10-09T12:32:10 <gavinandresen> yup
3832015-10-09T12:32:43 <sipa> so i would say it's the opposite... if you're running behind a firewall it's more reason to disable upnp
3842015-10-09T12:33:46 <CodeShark> depends on whether it's a private LAN or a larger shared network, though
3852015-10-09T12:34:28 <gavinandresen> How about: âIf you are running bitcoind on a public LAN, restart ...."
3862015-10-09T12:34:44 <sipa> sounds good
3872015-10-09T12:36:28 <sipa> actually
3882015-10-09T12:36:32 <sipa> no need to even restart
3892015-10-09T12:36:43 <sipa> miniupnp is only called at startup
3902015-10-09T12:37:02 <sipa> so putting it in your config would be enough, to prevent upnp from running next time
3912015-10-09T12:38:01 <CodeShark> unless someone already injected a delayed payload...in which case it's already too late
3922015-10-09T12:39:10 <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
3932015-10-09T12:43:45 <wumpus> yeah@gavinandresen in the GUI too <wumpus> to disable upnp in Bitcoin Core: run with -noupnp, or disable checkbox in GUI under Options â Network â Map port using UPNP
3942015-10-09T12:44:02 <wumpus> but they'll probably forget to enable it again after the new release
3952015-10-09T12:46:09 <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
3962015-10-09T12:51:38 <GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6cf73b0cd4cf...8c7e6138dbcb
3972015-10-09T12:51:39 <GitHub31> bitcoin/master 0cca024 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
3982015-10-09T12:51:39 <GitHub31> bitcoin/master 8c7e613 Wladimir J. van der Laan: Merge pull request #6789...
3992015-10-09T12:51:48 <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
4002015-10-09T12:53:12 *** fanquake has joined #bitcoin-core-dev
4012015-10-09T12:53:12 *** fanquake has quit IRC
4022015-10-09T12:53:12 *** fanquake has joined #bitcoin-core-dev
4032015-10-09T12:54:44 <GitHub25> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/093d7b5895b7dddd98d929fc3851265970b995b7
4042015-10-09T12:54:45 <GitHub25> bitcoin/0.10 093d7b5 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
4052015-10-09T12:56:21 *** fkhan has quit IRC
4062015-10-09T12:56:54 <GitHub163> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/b4ad73f706196272589451ce3d223f3df029eea1
4072015-10-09T12:56:55 <GitHub163> bitcoin/0.11 b4ad73f Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
4082015-10-09T12:58:21 <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
4092015-10-09T12:58:21 <GitHub187> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/b4ad73f70619...b4dc33e9fbbc
4102015-10-09T12:58:21 <GitHub187> bitcoin/0.11 36f14bf Tom Harding: In (strCommand == "tx"), return if AlreadyHave()...
4112015-10-09T12:58:22 <GitHub187> bitcoin/0.11 b4dc33e Wladimir J. van der Laan: Merge pull request #6785...
4122015-10-09T12:59:45 <fanquake> wumpus bugfix release shortly?
4132015-10-09T12:59:50 <wumpus> yes
4142015-10-09T13:01:53 *** n0n0__ has quit IRC
4152015-10-09T13:02:34 *** paveljanik has joined #bitcoin-core-dev
4162015-10-09T13:03:44 <michagogo> How shortly? I'm going offline in about 2 hours.
4172015-10-09T13:04:06 <michagogo> I might be able to start a build and let it run of its very shortly, otherwise I'll do it tomorrow night
4182015-10-09T13:05:58 <wumpus> within two hours, absolutely - I just have to write some release notes, then I'll tag the rc1s
4192015-10-09T13:07:46 *** pigeons has quit IRC
4202015-10-09T13:13:38 *** fkhan has joined #bitcoin-core-dev
4212015-10-09T13:14:45 *** pigeons has joined #bitcoin-core-dev
4222015-10-09T13:15:09 *** pigeons is now known as Guest45978
4232015-10-09T13:20:07 <GitHub135> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/04d0c27fb0b9ce0843b99bcae3c4e106fd817496
4242015-10-09T13:20:07 <GitHub135> bitcoin/0.11 04d0c27 Wladimir J. van der Laan: doc: Update release notes for 0.11.1
4252015-10-09T13:20:59 <wumpus> preliminary release notes for 0.11: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md
4262015-10-09T13:21:09 <wumpus> that is 0.11.1
4272015-10-09T13:27:53 <GitHub74> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/1bf6ac62abc2faad8af76aebfa0887c073e2c9b4
4282015-10-09T13:27:53 <GitHub74> bitcoin/0.10 1bf6ac6 Wladimir J. van der Laan: doc: Update release notes for 0.10.3
4292015-10-09T13:27:59 <wumpus> and for 0.10.3: https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md
4302015-10-09T13:32:24 <GitHub18> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/d7d87a1db1b90094a0dd517b89ef1c40eaedf14c
4312015-10-09T13:32:24 <GitHub18> bitcoin/0.11 d7d87a1 Wladimir J. van der Laan: qt: Update translations before 0.11.1
4322015-10-09T13:33:33 <wumpus> ready to tag
4332015-10-09T13:33:42 <GitHub86> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/44d6bc85285f2cbbee0a7b94924975d3e9d84875
4342015-10-09T13:33:42 <GitHub86> bitcoin/0.10 44d6bc8 Wladimir J. van der Laan: qt: Translations update before 0.10.3
4352015-10-09T13:35:40 <wumpus> * [new tag] v0.10.3rc1 -> v0.10.3rc1 â·············································
4362015-10-09T13:37:39 <wumpus> * [new tag] v0.11.1rc1 -> v0.11.1rc1
4372015-10-09T13:37:47 <sipa> reviewing 0.111.1
4382015-10-09T13:37:52 <sipa> ah, too late
4392015-10-09T13:38:07 <wumpus> no, not too late, you can review while building rc1 :p
4402015-10-09T13:38:28 <wumpus> if there's anything wrong we can always do a rc2 immediately
4412015-10-09T13:38:43 <sipa> the release notes mention bc484ef8db02715e283e4cddd2c972316c0688dd., which was reverted
4422015-10-09T13:39:44 <wumpus> ok, removing that one
4432015-10-09T13:41:16 <GitHub102> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/17ea542aa6323715d22cf6661e9705b3e940e3d1
4442015-10-09T13:41:16 <GitHub102> bitcoin/0.11 17ea542 Wladimir J. van der Laan: doc: #6077 was reverted, don't mention in release notes...
4452015-10-09T13:49:39 *** CodeShark has quit IRC
4462015-10-09T13:49:59 *** CodeShark has joined #bitcoin-core-dev
4472015-10-09T13:51:30 *** CodeShark has quit IRC
4482015-10-09T13:53:06 <morcos> wumpus: did you raise minrelaytxfee?
4492015-10-09T13:56:24 <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
4502015-10-09T13:56:46 <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?
4512015-10-09T14:00:28 *** fanquake has quit IRC
4522015-10-09T14:04:40 <michagogo> hm, `make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common` is erroring
4532015-10-09T14:04:46 <michagogo> or, well
4542015-10-09T14:04:55 <michagogo> it's giving me this message: `/bin/sh: 1: test: qtbase-opensource-src-5.5.0.tar.gz: unexpected operator`
4552015-10-09T14:05:04 <michagogo> and now it seems to be redownloading qt
4562015-10-09T14:05:25 <wumpus> morcos: that was not done
4572015-10-09T14:05:35 <wumpus> maybe for the release end of this month
4582015-10-09T14:05:37 <cfields> michagogo: that's harmless, you can ignore it
4592015-10-09T14:05:49 <michagogo> Hm, did qt get bumped since 0.11.0?
4602015-10-09T14:08:20 <wumpus> #6471 92401c2 Depends: bump to qt 5.5 yes - I remember this was for the TLS1.0+ requirement
4612015-10-09T14:10:54 <michagogo> Oh, I just realized my script for a complete gitian build probably won't work for 0.10
4622015-10-09T14:11:04 <michagogo> I guess I'll do that one manually tomorrow night
4632015-10-09T14:23:53 <GitHub117> [bitcoin] MarcoFalke opened pull request #6790: [devtools] add clang-format.py (master...MarcoFalke-2015-clangFormatWrapper) https://github.com/bitcoin/bitcoin/pull/6790
4642015-10-09T14:26:00 *** CodeShark has joined #bitcoin-core-dev
4652015-10-09T14:35:32 <michagogo> cfields: btw, looks like the mirror on bitcoincore.org isn't up to date
4662015-10-09T14:35:49 <cfields> ugh, i keep meaning to setup a cronjob for that
4672015-10-09T14:35:52 <cfields> what's missing?
4682015-10-09T14:35:56 <michagogo> qt
4692015-10-09T14:35:59 <michagogo> Also, argh
4702015-10-09T14:36:09 <cfields> ok, pulling it in
4712015-10-09T14:36:17 <michagogo> apparently if one component errors out it doesn't keep everything else that was fetched
4722015-10-09T14:37:00 <michagogo> That's really bad
4732015-10-09T14:37:24 <cfields> yea, the multi-sources are a corner-case and kinda handled hammer-style
4742015-10-09T14:37:48 <michagogo> Hm
4752015-10-09T14:38:00 <michagogo> I think this might mean I won't be able to kick the build off before I go offline
4762015-10-09T14:38:09 <michagogo> a 60MB download, took a long time
4772015-10-09T14:38:28 <michagogo> and is now going to have to rerun because a <3 MB file failed to download
4782015-10-09T14:40:05 <michagogo> Is dependency download from within gitian working atm?
4792015-10-09T14:41:04 <cfields> depends on the config. I think it's only an issue with lxc
4802015-10-09T14:41:27 <michagogo> Im using lxc :-(
4812015-10-09T14:42:04 <cfields> ok, links should be good now
4822015-10-09T14:42:11 <cfields> setting up a cronjob
4832015-10-09T14:48:51 *** Cocodude has joined #bitcoin-core-dev
4842015-10-09T14:49:28 <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?
4852015-10-09T14:50:29 *** treehug88 has joined #bitcoin-core-dev
4862015-10-09T14:50:30 <paveljanik> Cocodude, #bitcoin please.
4872015-10-09T14:51:33 *** PaulCape_ has joined #bitcoin-core-dev
4882015-10-09T14:53:46 *** PaulCapestany has quit IRC
4892015-10-09T14:54:24 *** rubensayshi has quit IRC
4902015-10-09T14:58:32 <michagogo> Okay, I *think* I got the build kicked off now.
4912015-10-09T14:59:22 <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.
4922015-10-09T14:59:28 <michagogo> ש×ת ש×××
4932015-10-09T15:01:20 <GitHub193> [bitcoin] MarcoFalke opened pull request #6791: [trivial] Misc cleanup (master...MarcoFalke-2015-trivial2) https://github.com/bitcoin/bitcoin/pull/6791
4942015-10-09T15:01:40 *** challisto has joined #bitcoin-core-dev
4952015-10-09T15:01:40 *** challisto has joined #bitcoin-core-dev
4962015-10-09T15:03:47 *** Cocodude has left #bitcoin-core-dev
4972015-10-09T15:20:51 *** d_t has joined #bitcoin-core-dev
4982015-10-09T15:25:58 <cfields> michagogo: cronjob installed. Should require very minimal manual intervention from now on
4992015-10-09T15:27:08 *** n0n0__ has joined #bitcoin-core-dev
5002015-10-09T15:33:02 *** n0n0__ has quit IRC
5012015-10-09T15:45:17 *** randy-waterhouse has quit IRC
5022015-10-09T15:47:20 <cfields> wumpus: whoops, looks like version bumps were missed for 0.10/0.11 ?
5032015-10-09T15:50:30 <wumpus> yes
5042015-10-09T15:51:15 <wumpus> we'll leave that for rc2
5052015-10-09T15:58:24 <wumpus> my gitian build spends a lot of time in "Upgrading system...". Does making new images avoid that?
5062015-10-09T15:58:40 <wumpus> (KVM build)
5072015-10-09T16:14:28 <GitHub129> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/cf5bf5542a6aba6b97fb69e0d2c11c2cd47f406d
5082015-10-09T16:14:28 <GitHub129> bitcoin/0.10 cf5bf55 Wladimir J. van der Laan: Bump version to 0.10.3
5092015-10-09T16:18:41 <GitHub52> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/717152ccba2a31ceaf7d0e02f6c9ad82843f2176
5102015-10-09T16:18:41 <GitHub52> bitcoin/0.11 717152c Wladimir J. van der Laan: Bump version to 0.11.1
5112015-10-09T16:19:59 <cfields> wumpus: unsure
5122015-10-09T16:38:39 *** randy-waterhouse has joined #bitcoin-core-dev
5132015-10-09T16:55:51 *** d_t has quit IRC
5142015-10-09T16:59:04 *** d_t has joined #bitcoin-core-dev
5152015-10-09T17:15:23 <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
5162015-10-09T17:29:19 *** ghtdak has joined #bitcoin-core-dev
5172015-10-09T17:31:42 *** randy-waterhouse has quit IRC
5182015-10-09T17:41:04 <gmaxwell> I continue to be unhappy with the miniupnp codebase. At least shutting it off more often will help. :)
5192015-10-09T17:41:59 *** CodeShark has quit IRC
5202015-10-09T17:42:39 <GitHub69> [bitcoin] laanwj opened pull request #6793: Bump minrelaytxfee default (master...2015_10_bump_minrelaytxfee) https://github.com/bitcoin/bitcoin/pull/6793
5212015-10-09T17:42:39 <wumpus> we all are
5222015-10-09T17:42:45 *** CodeShark has joined #bitcoin-core-dev
5232015-10-09T17:43:06 <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
5242015-10-09T17:43:34 <wumpus> (too bad we don't really have a way to measure)
5252015-10-09T17:44:06 <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.
5262015-10-09T17:44:09 <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
5272015-10-09T17:44:12 <petertodd> wumpus: removing miniupnpc while adding automatic tor hidden service support would be a decent compromise...
5282015-10-09T17:44:32 <wumpus> petertodd: it's the better way of hole-punching :)
5292015-10-09T17:44:51 <petertodd> wumpus: yup!
5302015-10-09T17:44:56 <gmaxwell> petertodd: not quite a replacement unless we were getting more nodes to come along with a tor client though.
5312015-10-09T17:45:33 <wumpus> it should be able to interface with the TBB that the user has installed
5322015-10-09T17:45:38 <petertodd> gmaxwell: yeah, easiest to do in the context of things like ubuntu packages which can depend on tor
5332015-10-09T17:47:04 <gmaxwell> We had upnp off for bitcoind for a long time. Perhaps we should just default it off for non-QT?
5342015-10-09T17:47:15 <wumpus> alternatively we could switch to an UDP-based protocol and use UDP hole punching on the router *ducks*
5352015-10-09T17:47:29 <wumpus> I really don't like that solution gmaxwell, having anything depend on UI-or-not
5362015-10-09T17:48:11 <gmaxwell> wumpus: well, I'm in damage mitigation mode there. The more places we can turn it off with almost no effect, the better.
5372015-10-09T17:48:31 <wumpus> on average, UI users are generally the most vulnerable to all kinds of attacks
5382015-10-09T17:48:42 <wumpus> so giving them the libupnp burden is wrong
5392015-10-09T17:49:05 <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?
5402015-10-09T17:49:09 <wumpus> (also UI users are most likely to have the wallet enabled)
5412015-10-09T17:49:46 <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.
5422015-10-09T17:49:59 <gmaxwell> wumpus: at the same time UI users are less likely to be subject to heroic attack efforts.
5432015-10-09T17:50:06 <wumpus> I'd just like to make the decision to turn it off
5442015-10-09T17:50:13 <gmaxwell> Also UI users are more likely to have worse vulnerabilities on their system.
5452015-10-09T17:50:33 <wumpus> yes, I want to remove miniupnpc completely
5462015-10-09T17:50:48 <gmaxwell> How about we default it to off in the update?
5472015-10-09T17:51:02 <wumpus> fine with me too
5482015-10-09T17:51:17 <petertodd> gmaxwell: AC
5492015-10-09T17:51:20 <petertodd> gmaxwell: ACK
5502015-10-09T17:51:54 <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.
5512015-10-09T17:52:13 <wumpus> "<gmaxwell> 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
5522015-10-09T17:52:40 <gmaxwell> Absolutely, I was just speaking in terms of averages.
5532015-10-09T17:52:48 <wumpus> well I like the torrent solution... pressure people to add a port forward by showing an ugly icon :-)
5542015-10-09T17:53:05 <petertodd> gmaxwell: what % of reachable nodes correspond to residential ip addrs?
5552015-10-09T17:54:14 <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'
5562015-10-09T17:54:33 <wumpus> anyhow, yes let's default upnp to no
5572015-10-09T17:56:15 *** PaulCape_ has quit IRC
5582015-10-09T17:59:14 *** PaulCapestany has joined #bitcoin-core-dev
5592015-10-09T18:00:14 *** d_t has quit IRC
5602015-10-09T18:01:38 *** d_t has joined #bitcoin-core-dev
5612015-10-09T18:03:02 <GitHub169> [bitcoin] gmaxwell opened pull request #6794: Default UPNP to off. (master...upnp_default_off) https://github.com/bitcoin/bitcoin/pull/6794
5622015-10-09T18:03:19 * wumpus tries to understand the autotools magic of --[enable|disable]-upnp-default
5632015-10-09T18:03:26 <wumpus> oh, you got it already gmaxwell?
5642015-10-09T18:04:08 <gmaxwell> ah, well I missed that autotools had magic there.
5652015-10-09T18:04:10 <wumpus> no, you changed the source code instead of the build system default
5662015-10-09T18:04:25 <gmaxwell> I think we should rip that out. Opinion?
5672015-10-09T18:04:31 <gmaxwell> (the autotools part)
5682015-10-09T18:04:42 <gmaxwell> (also the message handling was wrong, incidentally.)
5692015-10-09T18:05:02 <wumpus> I don't get it.
5702015-10-09T18:05:28 <gmaxwell> well not wrong, but redundant with the code.
5712015-10-09T18:05:45 <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"
5722015-10-09T18:05:54 <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. :)
5732015-10-09T18:06:03 <gmaxwell> Yea, thats the original makefile behavior.
5742015-10-09T18:06:07 <petertodd> away .
5752015-10-09T18:06:40 <wumpus> -upnp Use UPnP to map the listening port (default: 0)
5762015-10-09T18:07:37 <wumpus> it already defaults to 0?
5772015-10-09T18:07:43 <gmaxwell> no.
5782015-10-09T18:07:53 <gmaxwell> see the twisty mase of IFdefs my patch removes.
5792015-10-09T18:08:01 <wumpus> then why do I get that?
5802015-10-09T18:08:16 <gmaxwell> !
5812015-10-09T18:08:31 <sipa> it's default on for qt, default off for bitcoind, no?
5822015-10-09T18:08:34 <wumpus> (yes, I have installed the library and dev headers)
5832015-10-09T18:08:37 <wumpus> no, it's not sipa
5842015-10-09T18:08:54 <gmaxwell> sipa: I said that earlier and was corrected... it used to do that but apparently was changed when we changed the build system.
5852015-10-09T18:09:04 <wumpus> configure:27112: checking whether to build with UPnP enabled by default
5862015-10-09T18:09:04 <wumpus> configure:27120: result: no
5872015-10-09T18:09:05 <sipa> oh really...?
5882015-10-09T18:09:13 <wumpus> anyone get something else in config.log?
5892015-10-09T18:09:27 <sipa> ah, maybe it's off by default, but we turn it on in release builds?
5902015-10-09T18:09:39 <wumpus> (I haven't overridden it)
5912015-10-09T18:09:46 <wumpus> that might be it, let's see
5922015-10-09T18:09:48 <gmaxwell> my system is too weird a test point.
5932015-10-09T18:10:13 <wumpus> sipa: you're right
5942015-10-09T18:10:26 <wumpus> so only the gitian builds enable it by default
5952015-10-09T18:10:46 <gmaxwell> Okay, gonna close that second pull.
5962015-10-09T18:11:06 <GitHub125> [bitcoin] gmaxwell closed pull request #6794: Default UPNP to off. (master...upnp_default_off) https://github.com/bitcoin/bitcoin/pull/6794
5972015-10-09T18:11:37 <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.
5982015-10-09T18:11:54 <sipa> i do think we need to get rid of that confusing logic...
5992015-10-09T18:12:22 <gmaxwell> well we could rip out all that stuff that lets you default it to on.
6002015-10-09T18:13:13 <wumpus> fine with me
6012015-10-09T18:22:56 <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
6022015-10-09T18:32:55 *** fkhan has quit IRC
6032015-10-09T18:32:59 *** ParadoxSpiral_ has joined #bitcoin-core-dev
6042015-10-09T18:36:37 *** ParadoxSpiral has quit IRC
6052015-10-09T18:41:34 *** Thireus has joined #bitcoin-core-dev
6062015-10-09T18:42:08 <Luke-Jr> wumpus: what is the purpose in removing the --[enable|disable]-upnp-default
6072015-10-09T18:43:10 <wumpus> Luke-Jr: we don't have --XXX-default options for other settings either
6082015-10-09T18:43:47 <Luke-Jr> wumpus: is there any similar option? particularly, that enables a compile-time feature disabled by default
6092015-10-09T18:43:58 <wumpus> I don't think so
6102015-10-09T18:44:17 <Luke-Jr> it only makes sense to remove this one, if the default is always ON
6112015-10-09T18:44:31 <wumpus> "set this at runtime instead"
6122015-10-09T18:45:01 <wumpus> come on, do you really care about this?
6132015-10-09T18:45:10 <Luke-Jr> wumpus: yes, because I will now have to support a patch to do it
6142015-10-09T18:45:30 <wumpus> why not just set it in bitcoin.conf instead?
6152015-10-09T18:45:44 <Luke-Jr> that involves manipulating bitcoin.conf
6162015-10-09T18:45:57 <wumpus> yeh it does...
6172015-10-09T18:46:24 <Luke-Jr> people who install bitcoin-qt[upnp] shouldn't need to take additional steps to enable UPnP
6182015-10-09T18:46:35 <Luke-Jr> people who don't want UPnP would disable it at compile-time
6192015-10-09T18:46:46 <wumpus> with qt it's even simpler, you can enable it in the options
6202015-10-09T18:47:04 <Luke-Jr> that's not simpler
6212015-10-09T18:47:05 <wumpus> --with-upnp *adds the feature* it doesn't enable it
6222015-10-09T18:47:16 <wumpus> it never did
6232015-10-09T18:47:23 <Luke-Jr> exactly why the separate option is needed
6242015-10-09T18:47:30 *** fkhan has joined #bitcoin-core-dev
6252015-10-09T18:47:36 <wumpus> zmq is exactly the same
6262015-10-09T18:47:50 <wumpus> --with-zmq builds with libzmq, it doesn't *enable* it
6272015-10-09T18:48:05 <sipa> Luke-Jr: but as things are right now, we at least temporarily seem to not want it enabled by default
6282015-10-09T18:48:07 <wumpus> if you want it, enable it in your config
6292015-10-09T18:48:11 <Luke-Jr> nobody uses ZMQ though; whereas UPnP *should* be used
6302015-10-09T18:48:23 <wumpus> no, UPnP should not be used, it's a grave risk
6312015-10-09T18:48:40 <wumpus> this isn't the first vulnerability in it
6322015-10-09T18:48:45 <Luke-Jr> it's a grave risk to disable it too
6332015-10-09T18:48:54 <wumpus> well at least not a remote code execution...
6342015-10-09T18:49:16 <Luke-Jr> sipa: so we should distribute binaries with it disabled by default, I agree with that
6352015-10-09T18:49:22 <btcdrak> so we just need to point users to instructions on how to port forward.
6362015-10-09T18:49:37 <btcdrak> there must be plenty tutorials already out there
6372015-10-09T18:49:40 <wumpus> btcdrak: agreed, same as torrent clients have done for years, upnp is unreliable at best
6382015-10-09T18:49:43 <paveljanik> btcdrak, +1
6392015-10-09T18:49:48 <Luke-Jr> but if someone is explicitly compiling a build with UPnP, they shouldn't need extra steps
6402015-10-09T18:50:04 <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
6412015-10-09T18:50:18 <btcdrak> wumpus: we should just pull upnp out. I mean, this is people's money we're talking about potentially
6422015-10-09T18:50:31 <Luke-Jr> sipa: for example, installing on Gentoo, I have no sane way to set a config option for the user
6432015-10-09T18:50:45 <Eliel> sipa: I think luke's point is that to the user it feels like setting _two_ config options that way.
6442015-10-09T18:51:08 <wumpus> Luke-Jr: as said, it's the same for the other optional features, apart from the wallet
6452015-10-09T18:51:39 <wumpus> I'm done arguing this, agree with btcdrak, I'd prefer to remove upnp support completely, this is already a compromise
6462015-10-09T18:51:51 <Luke-Jr> â¦
6472015-10-09T18:52:14 <btcdrak> Let me go find some port forwarding tutorials
6482015-10-09T18:52:26 <wumpus> why do you want to expose users to the risk of upnp on gentoo by default?
6492015-10-09T18:52:31 <Luke-Jr> btcdrak: you're assuming the user even has access to the router
6502015-10-09T18:52:35 * Eliel wonders how much work it'd be to implement just the subset of upnp that bitcoin needs.
6512015-10-09T18:52:36 <Luke-Jr> wumpus: it's not by default
6522015-10-09T18:52:45 <Luke-Jr> wumpus: by default, it won't even be built with UPnP support
6532015-10-09T18:53:00 <sipa> Luke-Jr: then why do you need a compile-time option for it?
6542015-10-09T18:53:04 <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.
6552015-10-09T18:53:08 <wumpus> if they don't have access to the router, upnp shouldn't be enabled either, it breaches the security policy too
6562015-10-09T18:53:11 <Luke-Jr> sipa: so when users enable it, they actually get it
6572015-10-09T18:53:23 <sipa> Luke-Jr: they can enable it by enabling it!
6582015-10-09T18:53:26 <Luke-Jr> gmaxwell: huh? the binaries have always had it on by default, no?
6592015-10-09T18:53:33 <gmaxwell> Luke-Jr: they do get it, by enabling it in the config! making it compile time is kinda psycho!
6602015-10-09T18:53:44 <Luke-Jr> sipa: they enable it system-wide by setting USE=upnp and recompiling
6612015-10-09T18:53:57 <gmaxwell> Luke-Jr: no bitcoin-qt did but bitcoind didn't until the switch off of makefiles, AFAIK.
6622015-10-09T18:54:06 <Luke-Jr> wumpus: UPnP just fixes a bug in NAT
6632015-10-09T18:54:27 <Luke-Jr> gmaxwell: but Bitcoin-Qt is what end users use
6642015-10-09T18:55:00 <Luke-Jr> obviously servers (the target for bitcoind) do not need UPnP
6652015-10-09T18:57:27 <Luke-Jr> anyway, --[enable|disable]-upnp-default has real use and zero cost. removing it for no reason is just annoying and wastes time.
6662015-10-09T18:58:27 <wumpus> the trinary option USE_UPNP confuses me every time, but apart from that, you're probably right...
6672015-10-09T18:59:47 *** Thireus has quit IRC
6682015-10-09T18:59:48 <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...
6692015-10-09T19:00:31 <sipa> --reindex-default would be useful for systems with crappy disks
6702015-10-09T19:01:26 <wumpus> heh
6712015-10-09T19:02:11 <Luke-Jr> meh
6722015-10-09T19:02:56 <Luke-Jr> IF it is going to be removed in master, can we at least keep it around in backports?
6732015-10-09T19:07:11 <wumpus> I think the point of this is to backport it
6742015-10-09T19:07:50 <wumpus> but ok, I'll change my pull to only change the descriptors, this is not worth wasting so much time over
6752015-10-09T19:11:19 *** skyraider has joined #bitcoin-core-dev
6762015-10-09T19:11:38 <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.
6772015-10-09T19:11:51 <wumpus> someone that cares enough could still remove the --upnp-default setting in master
6782015-10-09T19:11:58 <skyraider> there is a value for "master" - a 16-byte value of some kind. however, "master" has no semantic meaning; unclear what this is.
6792015-10-09T19:12:23 <wumpus> skyraider: questions about BIPs are really off topic here
6802015-10-09T19:12:40 <skyraider> ok sorry
6812015-10-09T19:12:47 <sipa> skyraider: read BIP32, it clearly specifies what master means
6822015-10-09T19:12:47 <skyraider> correct channel?
6832015-10-09T19:12:50 <Luke-Jr> #bitcoin-dev
6842015-10-09T19:13:04 <wumpus> #bitcoin or #bitcoin-dev
6852015-10-09T19:13:24 <sipa> oh, it calls it seed
6862015-10-09T19:17:22 <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.
6872015-10-09T19:17:45 <gmaxwell> which doesn't seem totally nutty. But the fact that supporting this craps up our code base, is .. unfortunate.
6882015-10-09T19:18:37 <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 :)
6892015-10-09T19:19:41 <gmaxwell> I certantly would prefer to make it so the entire action of the default is via changing that global const.
6902015-10-09T19:20:00 <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'
6912015-10-09T19:20:54 <gmaxwell> E.g. I'd also be fine with UPNP_DEFAULT = false being overridable with a UPNP_DEFAULT_ON ifdef.
6922015-10-09T19:21:02 <gmaxwell> and then gentoo need not even SED.
6932015-10-09T19:21:09 <gmaxwell> could just set a cflag.
6942015-10-09T19:21:14 <Luke-Jr> CXXFLAGS="-DUPNP_DEFAULT_ON" would also be fairly simple
6952015-10-09T19:21:50 <Luke-Jr> not sure it's better than sed though, if it was a single well-defined location
6962015-10-09T19:22:14 <wumpus> setting a cflag wouldn't work, the default is a constant, not a macro
6972015-10-09T19:22:18 <gmaxwell> Luke-Jr: the sed is more likely to get disrupted by code motion.
6982015-10-09T19:22:31 <gmaxwell> wumpus: I mean having a macro that changes the constant.
6992015-10-09T19:22:32 <Luke-Jr> gmaxwell: true
7002015-10-09T19:22:42 <wumpus> ugh, if you're going with a macro anyway, then you may just as well keep the configure option
7012015-10-09T19:22:57 <wumpus> as we have a macro for that now: USE_UPNP
7022015-10-09T19:23:13 <wumpus> but ok, I'm done with this, not going to spend anymore time on it
7032015-10-09T19:23:29 <sipa> i think this discussion has now wasted more time than the combined benefit of the 5 gentoo bitcoin users who set use=upnp
7042015-10-09T19:23:37 <sipa> i don't care
7052015-10-09T19:23:38 <wumpus> yeah...
7062015-10-09T19:23:57 <Luke-Jr> >_<
7072015-10-09T19:24:08 <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.
7082015-10-09T19:24:14 <gmaxwell> It's a few more bytes and not an unreasonable ask.
7092015-10-09T19:24:44 <gmaxwell> And it's nice to get rid of the crazy overload of the define value.
7102015-10-09T19:24:53 <gmaxwell> and make this simpler.
7112015-10-09T19:24:53 <wumpus> please just keep it as it is now
7122015-10-09T19:24:59 <wumpus> I'm sure you have something more serious to do
7132015-10-09T19:25:56 <wumpus> can we make a decision about mempool limiting? :p
7142015-10-09T19:26:53 <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
7152015-10-09T19:27:27 <wumpus> kanzure: read back, sipa already answered that a while back
7162015-10-09T19:27:45 <sipa> kanzure: it should be called seed
7172015-10-09T19:27:50 <kanzure> i was looking at wrong channel, sorry
7182015-10-09T19:28:07 <kanzure> sipa is not in -dev so i was confused
7192015-10-09T19:29:53 <kanzure> i am not sure that "master (hex)" is clearly defined.
7202015-10-09T19:30:09 *** Thireus has joined #bitcoin-core-dev
7212015-10-09T19:32:09 <sipa> kanzure: it isn't, it should be called seed :)
7222015-10-09T19:35:16 <wumpus> should we add that to the topic? we keep getting that question :p
7232015-10-09T19:35:43 <kanzure> was asked in other channel, sipa wasn't around, question kept getting misinterpreted, seems natural to hunt down author
7242015-10-09T19:39:11 <CodeShark> kanzure: if you want to know anything about BIP32, I also had a thing or two to do with it in the past ;)
7252015-10-09T19:40:24 <CodeShark> btw, we should update one of the links on that page
7262015-10-09T19:40:34 <CodeShark> going to submit a PR
7272015-10-09T19:41:30 <kanzure> https://github.com/bitcoin/bips/pull/217
7282015-10-09T19:42:22 <CodeShark> yeah, it should be called seed ;)
7292015-10-09T19:45:32 *** CodeShark has quit IRC
7302015-10-09T19:45:38 *** fkhan has quit IRC
7312015-10-09T19:45:42 *** CodeShark has joined #bitcoin-core-dev
7322015-10-09T19:46:00 <wumpus> yes, it should...
7332015-10-09T19:48:04 <CodeShark> hey! I'm not in the acknowledgements for BIP32
7342015-10-09T19:48:17 <CodeShark> I believe I added support for it before anyone else :p
7352015-10-09T19:48:43 <CodeShark> and I also fixed up the text and wrote the test vector code
7362015-10-09T19:48:48 <CodeShark> ;)
7372015-10-09T19:50:05 <CodeShark> then everyone else copied my whole parallel tree implementation
7382015-10-09T19:50:07 <CodeShark> for multisig
7392015-10-09T19:50:12 <CodeShark> but bah :p
7402015-10-09T19:50:48 <sipa> so add yourself
7412015-10-09T19:50:59 <wumpus> this is not really on topic here
7422015-10-09T19:51:23 <wumpus> but yes, go add yourself
7432015-10-09T19:59:41 <CodeShark> https://github.com/bitcoin/bips/pull/218
7442015-10-09T20:00:29 *** fkhan has joined #bitcoin-core-dev
7452015-10-09T20:02:26 <CodeShark> is the bips repo offtopic here?
7462015-10-09T20:04:01 <wumpus> well, BIPs are on topic when it relates to implementing them in Bitcoin Core, but not on their own
7472015-10-09T20:05:37 *** treehug88 has quit IRC
7482015-10-09T20:16:33 *** belcher has joined #bitcoin-core-dev
7492015-10-09T20:18:44 <paveljanik> wumpus, 0.10 doesn't contain 649f5d9c1100bb3cbace724900f035939df5ea11. It was backported to 0.11 only. OK?
7502015-10-09T20:20:25 <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
7512015-10-09T20:20:51 <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
7522015-10-09T20:21:07 <morcos> any pre-0.12 nodes will just miss out on txs unnecessarily
7532015-10-09T20:21:31 <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
7542015-10-09T20:22:16 <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?
7552015-10-09T20:22:30 <morcos> i'm commenting here instead of pull, b/c i'm just brainstorming what makes sense
7562015-10-09T20:23:54 *** Thireus1 has joined #bitcoin-core-dev
7572015-10-09T20:24:44 *** Thireus has quit IRC
7582015-10-09T20:44:42 <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
7592015-10-09T21:30:59 *** paveljanik has quit IRC
7602015-10-09T21:51:29 *** Thireus1 has quit IRC
7612015-10-09T23:00:29 *** BashCo_ has joined #bitcoin-core-dev
7622015-10-09T23:02:24 *** BashCo has quit IRC
7632015-10-09T23:22:06 *** d_t has quit IRC
7642015-10-09T23:52:09 *** skyraider has quit IRC