1 2015-10-09T00:01:06  <Luke-Jr> is there a way to get [skip ci] without polluting the commit message?
  2 2015-10-09T00:02:20  <sipa> ask a maintainer to kill the travis job :p
  3 2015-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
  4 2015-10-09T00:03:45  <Luke-Jr> seems like a waste of time
  5 2015-10-09T00:03:49  <sipa> yeah :)
  6 2015-10-09T00:03:52  *** challisto has quit IRC
  7 2015-10-09T00:03:56  <sipa> i just wouldn't bother
  8 2015-10-09T00:04:12  *** Ylbam has quit IRC
  9 2015-10-09T00:31:07  *** challisto has joined #bitcoin-core-dev
 10 2015-10-09T00:31:07  *** challisto has joined #bitcoin-core-dev
 11 2015-10-09T01:31:16  *** challisto has quit IRC
 12 2015-10-09T01:37:03  *** belcher has quit IRC
 13 2015-10-09T02:01:21  *** PaulCape_ has joined #bitcoin-core-dev
 14 2015-10-09T02:04:00  *** PaulCapestany has quit IRC
 15 2015-10-09T02:20:58  *** molly has joined #bitcoin-core-dev
 16 2015-10-09T02:24:19  *** moli has quit IRC
 17 2015-10-09T02:59:26  *** d_t has quit IRC
 18 2015-10-09T03:00:26  *** d_t has joined #bitcoin-core-dev
 19 2015-10-09T03:12:22  <CodeShark> hmm, SoftForkMajorityDesc needs to be moved into the soft forks unit as well...
 20 2015-10-09T03:14:52  *** d_t has quit IRC
 21 2015-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
 22 2015-10-09T03:15:25  <CodeShark> no more need for PRs for that :)
 23 2015-10-09T03:15:33  <CodeShark> other than the trivial link
 24 2015-10-09T03:16:27  <CodeShark> totally doable, too
 25 2015-10-09T03:18:17  <CodeShark> I know how to do it...but it would require moving a few things around in main.cpp
 26 2015-10-09T03:18:40  <CodeShark> hopefully can be done without being too extremely invasive
 27 2015-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?
 28 2015-10-09T03:20:52  <CodeShark> would require some changes to script/interpreter.cpp as well
 29 2015-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
 30 2015-10-09T03:21:33  <CodeShark> *intact
 31 2015-10-09T03:32:48  *** jgarzik has joined #bitcoin-core-dev
 32 2015-10-09T03:32:48  *** jgarzik has joined #bitcoin-core-dev
 33 2015-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
 34 2015-10-09T03:50:21  *** moli has joined #bitcoin-core-dev
 35 2015-10-09T03:53:19  *** molly has quit IRC
 36 2015-10-09T03:57:50  *** jgarzik has quit IRC
 37 2015-10-09T04:11:25  *** d_t has joined #bitcoin-core-dev
 38 2015-10-09T04:47:42  *** da2ce7 has quit IRC
 39 2015-10-09T05:13:26  *** paveljanik has quit IRC
 40 2015-10-09T05:22:25  *** d_t has quit IRC
 41 2015-10-09T05:57:00  *** PaulCapestany has joined #bitcoin-core-dev
 42 2015-10-09T05:59:10  *** PaulCape_ has quit IRC
 43 2015-10-09T06:01:21  *** d_t has joined #bitcoin-core-dev
 44 2015-10-09T06:06:30  *** Ylbam has joined #bitcoin-core-dev
 45 2015-10-09T06:08:19  *** epilido has joined #bitcoin-core-dev
 46 2015-10-09T06:38:39  *** n0n0__ has joined #bitcoin-core-dev
 47 2015-10-09T07:17:28  *** Squidicuz has quit IRC
 48 2015-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
 49 2015-10-09T07:29:10  *** n0n0__ has quit IRC
 50 2015-10-09T07:35:42  *** randy-waterhouse has joined #bitcoin-core-dev
 51 2015-10-09T07:52:31  *** da2ce7 has joined #bitcoin-core-dev
 52 2015-10-09T07:59:47  *** fkhan has quit IRC
 53 2015-10-09T08:00:01  *** da2ce7 has quit IRC
 54 2015-10-09T08:09:30  <wumpus> Luke-Jr: [skip ci] only works in the commit message, not the pull title?
 55 2015-10-09T08:10:03  <Luke-Jr> wumpus: ?
 56 2015-10-09T08:12:24  *** fkhan has joined #bitcoin-core-dev
 57 2015-10-09T08:13:24  <wumpus> Luke-Jr: I mean - what does travis look at, the pull request title or the commit message?
 58 2015-10-09T08:13:44  <Luke-Jr> no idea, I just don't like it in the commit message :p
 59 2015-10-09T08:13:55  <wumpus> hm only commit message from http://docs.travis-ci.com/user/customizing-the-build/
 60 2015-10-09T08:14:03  <wumpus> but it *doesn't have* to be in the first part
 61 2015-10-09T08:14:21  <Luke-Jr> moving it to the long description would be an improvement at least
 62 2015-10-09T08:14:26  *** rubensayshi has joined #bitcoin-core-dev
 63 2015-10-09T08:14:31  <wumpus> you can just [skip ci] hide it somewhere in the description
 64 2015-10-09T08:16:27  <GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d479311dba25...a99b6cb19ee7
 65 2015-10-09T08:16:27  <GitHub84> bitcoin/master b2af29b Pavel Janík: Ignore bench_bitcoin binary.
 66 2015-10-09T08:16:28  <GitHub84> bitcoin/master a99b6cb Wladimir J. van der Laan: Merge pull request #6770...
 67 2015-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
 68 2015-10-09T08:17:27  *** da2ce7 has joined #bitcoin-core-dev
 69 2015-10-09T08:21:03  *** ParadoxSpiral has joined #bitcoin-core-dev
 70 2015-10-09T08:21:49  <GitHub52> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a99b6cb19ee7...c82ea8b271c8
 71 2015-10-09T08:21:49  <GitHub52> bitcoin/master 34754ce Chris Kleeschulte: [Trivial] Fixed typo when referring to a previous section in...
 72 2015-10-09T08:21:50  <GitHub52> bitcoin/master c82ea8b Wladimir J. van der Laan: Merge pull request #6783...
 73 2015-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
 74 2015-10-09T08:27:06  <GitHub28> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c82ea8b271c8...6cf73b0cd4cf
 75 2015-10-09T08:27:06  <GitHub28> bitcoin/master b22692c Cory Fields: build: Make use of ZMQ_CFLAGS
 76 2015-10-09T08:27:07  <GitHub28> bitcoin/master 6cf73b0 Wladimir J. van der Laan: Merge pull request #6779...
 77 2015-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
 78 2015-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
 79 2015-10-09T08:37:16  <aj> s/think/in thinking/
 80 2015-10-09T08:37:31  *** fkhan has quit IRC
 81 2015-10-09T08:38:08  <Luke-Jr> aj: just the usual softfork expectations given SPV limitations
 82 2015-10-09T08:38:15  <Luke-Jr> 1-block confirmation is never secure for SPV anyway
 83 2015-10-09T08:38:34  <aj> Luke-Jr: afaics for softforks that upgrade OP_NOP's SPV clients won't have that problem
 84 2015-10-09T08:38:51  <aj> Luke-Jr: (or won't have it any worse than normal anyway)
 85 2015-10-09T08:39:16  <Luke-Jr> aj: I don't follow then.
 86 2015-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
 87 2015-10-09T08:40:29  <Luke-Jr> oh, I see what you mean
 88 2015-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
 89 2015-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
 90 2015-10-09T08:41:34  <Luke-Jr> aj: I don't think there's ever been a softfork without this "problem"
 91 2015-10-09T08:41:50  <Luke-Jr> well, except BIP66 I guess
 92 2015-10-09T08:42:05  <Luke-Jr> not even that actually
 93 2015-10-09T08:42:22  <Luke-Jr> because older block versions were disallowed
 94 2015-10-09T08:42:42  <Luke-Jr> anyway, 5% of hashpower won't get more than a block or two deep
 95 2015-10-09T08:42:45  <aj> Luke-Jr: afaik SPV clients don't check block versions generally anyway
 96 2015-10-09T08:43:06  <aj> Luke-Jr: OP_CLTV won't have that problem, afaics
 97 2015-10-09T08:43:24  <Luke-Jr> perhaps not. but it will be the first not to.
 98 2015-10-09T08:43:29  <aj> Luke-Jr: (wow)
 99 2015-10-09T08:43:38  <Luke-Jr> and SPV 1-block confirmation is not secure regardless
100 2015-10-09T08:44:15  <Luke-Jr> aj: the versionbits stuff does improve on this
101 2015-10-09T08:44:41  <Luke-Jr> after the softfork goes active, there is a difficulty-adjustment period (2 weeks) before it is enforced
102 2015-10-09T08:45:00  <Luke-Jr> so other miners can upgrade
103 2015-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?
104 2015-10-09T08:45:57  <Luke-Jr> aj: SPV nodes need the full header-history anyway, so they can implement versionbits
105 2015-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?
106 2015-10-09T08:46:49  <Luke-Jr> aj: only if 5% got left behind
107 2015-10-09T08:47:19  <Luke-Jr> aj: the expectation is not that those 5% continue mining invalid blocks
108 2015-10-09T08:48:11  <aj> Luke-Jr: hmm, is there any way to tell how much hashpower dropped off in previous upgrades?
109 2015-10-09T08:48:36  <Luke-Jr> dunno, probably just Deepbit
110 2015-10-09T08:48:43  <aj> Deepbit
111 2015-10-09T08:48:44  <aj> ?
112 2015-10-09T08:49:01  <aj> oh that was a mining pool, not a stats site? :)
113 2015-10-09T08:49:07  <Luke-Jr> aj: a mining pool that once had over 50% ;)
114 2015-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
115 2015-10-09T08:50:02  <Luke-Jr> CodeShark: will versionbits impl kill mining when it detects it is being softforked out?
116 2015-10-09T08:50:24  <Luke-Jr> ie, getblocktemplate should probably fail if some activated softfork is unsupported
117 2015-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
118 2015-10-09T08:50:57  <CodeShark> :)
119 2015-10-09T08:51:05  *** fkhan has joined #bitcoin-core-dev
120 2015-10-09T08:51:14  <Luke-Jr> maybe harder than it seems though in practice
121 2015-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 :)
122 2015-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
123 2015-10-09T08:53:57  <aj> be easier to backport pluggable soft forks once the plugin thing exists too, presumably
124 2015-10-09T08:54:14  <CodeShark> yes, of course
125 2015-10-09T08:54:49  <sipa> what do you mean by plugin system?
126 2015-10-09T08:55:03  <CodeShark> I posted something on the mailing list - but I'm guessing you unsubscribed :)
127 2015-10-09T08:55:13  <sipa> yes
128 2015-10-09T08:55:24  <CodeShark> I can forward it to you if you want
129 2015-10-09T08:55:35  <CodeShark> or you can look for the link on linuxfoundation.org :)
130 2015-10-09T08:55:39  <aj> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011487.html
131 2015-10-09T08:55:50  <aj> and/or http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011491.html
132 2015-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
133 2015-10-09T08:57:30  <CodeShark> CBlock needs a new default version
134 2015-10-09T08:57:44  <CodeShark> or could be implemented in getblocktemplate, I suppose
135 2015-10-09T08:57:48  <CodeShark> in principle I agree
136 2015-10-09T08:57:58  <CodeShark> CBlock should not be where the default version gets set
137 2015-10-09T08:58:07  *** fkhan has quit IRC
138 2015-10-09T08:58:10  <sipa> yes, indeed
139 2015-10-09T08:58:19  <sipa> those default versions there don't belong
140 2015-10-09T08:59:14  <sipa> you say "easily merged units"... that's pretty vague
141 2015-10-09T08:59:17  <CodeShark> right - primitives should just handle data access and serialization
142 2015-10-09T08:59:22  <sipa> what do you mean specifically?
143 2015-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?
144 2015-10-09T08:59:33  <sipa> btcdrak: maybe
145 2015-10-09T08:59:39  <CodeShark> sipa: by adding two lines to the makefile and one line to an init function
146 2015-10-09T08:59:48  <CodeShark> and two files to the repo :)
147 2015-10-09T09:00:11  <CodeShark> at least for starters
148 2015-10-09T09:00:21  <CodeShark> long-term it would even be possible to deploy at runtime
149 2015-10-09T09:00:22  <sipa> CodeShark: so you pretty much mean... changing the code location organizatiin so that soft forks are the top level?
150 2015-10-09T09:00:51  <CodeShark> yeah, I suppose you could say that
151 2015-10-09T09:00:55  <sipa> what if soft forks require wallet changes? or block creation code changes?
152 2015-10-09T09:01:24  <CodeShark> we start with the consensus hooks...then worry about UI :p
153 2015-10-09T09:01:31  <sipa> ok
154 2015-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"
155 2015-10-09T09:02:58  <sipa> but... perhaps
156 2015-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
157 2015-10-09T09:03:32  <CodeShark> BIP65 is a tad bit more complex in the sense that it also defines an op code
158 2015-10-09T09:04:27  <CodeShark> so we need a hook in the script interpreter
159 2015-10-09T09:04:52  <sipa> yeah, i don't like that
160 2015-10-09T09:04:57  <sipa> not for consensus
161 2015-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
162 2015-10-09T09:05:37  <wumpus> consensus code should be as simple and straightforward and self-contained as possible, IMO, no hooks and plugins
163 2015-10-09T09:05:48  <CodeShark> I think this is about as simple as it gets, though
164 2015-10-09T09:05:57  <CodeShark> it makes any change to consensus very easy to review
165 2015-10-09T09:06:16  *** go1111111 has quit IRC
166 2015-10-09T09:06:19  <CodeShark> the diff becomes trivial
167 2015-10-09T09:06:51  <wumpus> does it? interaction/crosstalk issues tend to be problematic for plugin-like systems, what sipa says
168 2015-10-09T09:07:14  <wumpus> needs to be easy to follow the execution flow
169 2015-10-09T09:07:22  <CodeShark> a soft fork has well-defined abstract behavior
170 2015-10-09T09:07:22  <wumpus> and *in which sequence* things are done
171 2015-10-09T09:07:35  <CodeShark> the implementor just needs to specify what those behaviors actually are
172 2015-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
173 2015-10-09T09:09:24  <Luke-Jr> CodeShark: so… let's say a softfork with segregated witness..?
174 2015-10-09T09:10:04  <CodeShark> can we do that cleanly with a soft fork?
175 2015-10-09T09:10:13  <Luke-Jr> in theory, I don't see why not
176 2015-10-09T09:10:21  <sipa> I don't see how.
177 2015-10-09T09:10:23  <Luke-Jr> probably entails p2p protocol changes though
178 2015-10-09T09:10:53  *** fkhan has joined #bitcoin-core-dev
179 2015-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).
180 2015-10-09T09:11:08  <Luke-Jr> well, we can't segregate the existing scripts - but P2SH-like..
181 2015-10-09T09:11:29  <sipa> no
182 2015-10-09T09:11:49  <sipa> segregated witness changes how transactions refer to each other
183 2015-10-09T09:12:07  <sipa> i guess you can do it by making transactions not contain scriptSigs
184 2015-10-09T09:12:12  <Luke-Jr> exactly
185 2015-10-09T09:12:43  <sipa> and have separate witness structures that are relayed separately, and committed to in a block's coinbase
186 2015-10-09T09:12:46  <sipa> ok
187 2015-10-09T09:13:12  *** go1111111 has joined #bitcoin-core-dev
188 2015-10-09T09:13:16  <sipa> yeah, that wouldn't easily fit into a hook structure, i think
189 2015-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
190 2015-10-09T09:14:13  <sipa> yes, but even the consensus changes wouldn't easily fit in
191 2015-10-09T09:14:16  * Luke-Jr , after breaking softfork plugins, runs off to bed. :P
192 2015-10-09T09:14:50  <CodeShark> sipa: I just think of the witness structures as additional validation context
193 2015-10-09T09:15:03  <CodeShark> they can be anything, really - any additional state required at validation time
194 2015-10-09T09:15:45  <sipa> ok, how does that fit in?
195 2015-10-09T09:16:03  <CodeShark> we'd probably need to rearchitect the script interpreter a bit to be more abstract
196 2015-10-09T09:16:13  <wumpus> no...
197 2015-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)
198 2015-10-09T09:18:45  <CodeShark> routine ones being stuff like nVersion changes and the kind of stuff we currently do in main.cpp
199 2015-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
200 2015-10-09T09:19:44  <CodeShark> yes, agreed, Luke-Jr. That's sorta what I meant by abstracting the script interpreter a bit more
201 2015-10-09T09:19:54  *** fkhan has quit IRC
202 2015-10-09T09:19:57  <Luke-Jr> CodeShark: no, in this case we'd have entire duplication of the consensus lib ☺
203 2015-10-09T09:20:15  <Luke-Jr> (so it can be reused for hardforks as well)
204 2015-10-09T09:20:16  <CodeShark> no...the soft fork plugins could use the consensus lib once it's ready
205 2015-10-09T09:20:26  <Luke-Jr> CodeShark: well, that's not what I just described
206 2015-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
207 2015-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
208 2015-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
209 2015-10-09T09:21:50  <CodeShark> so let's say they are invariant as well
210 2015-10-09T09:22:14  <CodeShark> then on top of this you have context (UTXO, timestamp)
211 2015-10-09T09:22:41  <CodeShark> if these checks work, then you run the script
212 2015-10-09T09:23:39  <sipa> we don't even get to do simple refactors
213 2015-10-09T09:23:55  <CodeShark> sipa: understand this is not a one or two month plan :p
214 2015-10-09T09:24:01  <CodeShark> this is probably out at least a year
215 2015-10-09T09:24:18  <CodeShark> point is unless we start thinking about this kind of stuff well in advance it will probably never happen
216 2015-10-09T09:24:20  <sipa> i'm not convinced it's very useful
217 2015-10-09T09:24:34  <CodeShark> ok, then I have some homework to do :)
218 2015-10-09T09:24:44  <sipa> the trivial softforks it is targetting are already simple to review
219 2015-10-09T09:24:51  <CodeShark> for you, sipa
220 2015-10-09T09:24:58  <CodeShark> I'd rather you spend your time doing other stuff :p
221 2015-10-09T09:25:03  <CodeShark> for most people it's still very hard
222 2015-10-09T09:25:17  *** d_t has quit IRC
223 2015-10-09T09:25:19  <sipa> the non-trivial ones will become harder, because they'll need to change the plugin api...
224 2015-10-09T09:25:39  <CodeShark> not if we abstract things well enough
225 2015-10-09T09:26:15  <CodeShark> there's a sequence of validation steps that can be easily abstracted regardless of the specific rules
226 2015-10-09T09:27:16  <sipa> i don't see how you could create an abstraction that keeps working with seggregated witness, for example
227 2015-10-09T09:27:40  <CodeShark> isn't segregated witness effectively additional state required for validation?
228 2015-10-09T09:28:03  <sipa> seggregated witness, from the point of existing code, removes script and sigScript entirely
229 2015-10-09T09:28:08  <CodeShark> let
230 2015-10-09T09:28:23  <sipa> and then jntroduces a new primitive data structure, to which consensus rules are applied
231 2015-10-09T09:28:55  <sipa> i think you're biased by having seen a few simple soft forks
232 2015-10-09T09:28:57  <CodeShark> removes script and sigScript?
233 2015-10-09T09:29:27  <sipa> yes, transactions would end up having an empty scriptSig
234 2015-10-09T09:29:39  <CodeShark> I get that part - what do you mean by "script"
235 2015-10-09T09:29:40  <CodeShark> ?
236 2015-10-09T09:29:45  <CodeShark> scriptPubKey?
237 2015-10-09T09:29:49  <sipa> by script i mean the script subdir in the code
238 2015-10-09T09:30:04  <CodeShark> oh...so interpreter.cpp
239 2015-10-09T09:30:14  <CodeShark> and that stuff :)
240 2015-10-09T09:30:16  <sipa> of course, it would get reused in a new piece of code
241 2015-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
242 2015-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
243 2015-10-09T09:31:31  <sipa> how do you deal with cases where more data needs to be exposed to the script interpreter?
244 2015-10-09T09:31:42  <CodeShark> I imagine a function Validate(context, transaction)
245 2015-10-09T09:31:50  <CodeShark> where context could be extended
246 2015-10-09T09:32:12  <CodeShark> but for now it covers the current block tree
247 2015-10-09T09:32:16  <CodeShark> and utxo set
248 2015-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
249 2015-10-09T09:32:28  <sipa> no, it's not that easy
250 2015-10-09T09:32:54  <sipa> script execution can purposefully not depend on certain data
251 2015-10-09T09:32:58  <sipa> like height
252 2015-10-09T09:33:26  <sipa> to avoid transactions going from valid to invalid
253 2015-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
254 2015-10-09T09:34:25  <CodeShark> I agree it isn't trivial
255 2015-10-09T09:34:26  *** fkhan has joined #bitcoin-core-dev
256 2015-10-09T09:34:30  <CodeShark> it's a challenge - but I think it's doable
257 2015-10-09T09:34:54  <sipa> i think you're underestimating the costs to others
258 2015-10-09T09:34:56  <CodeShark> the trick here is figuring out what sorts of context can be excluded from what types of checks
259 2015-10-09T09:35:23  <CodeShark> and what sorts of context are desirable to exclude
260 2015-10-09T09:35:41  <CodeShark> again, this is not a one- or two-month plan
261 2015-10-09T09:36:02  <sipa> ok: bottom line, i am very skeptical about the benefits
262 2015-10-09T09:36:15  <sipa> now let's talk about things we can actually do
263 2015-10-09T09:36:58  <CodeShark> but we CAN do this...it's just going to take a much longer time than one release cycle
264 2015-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 :)
265 2015-10-09T09:37:44  <CodeShark> you might be able to convince me of the former
266 2015-10-09T09:37:51  <sipa> it's certainly possible with high costs
267 2015-10-09T09:38:09  <CodeShark> given our current process, I agree
268 2015-10-09T09:38:11  <sipa> but i don't think it's the right direction to.go in
269 2015-10-09T09:38:20  <CodeShark> ok - that's more fruitful discussion
270 2015-10-09T09:38:31  <sipa> i would aim to have less abstractions, not more
271 2015-10-09T09:38:41  <sipa> because they complicate reasoning and proving what code can do
272 2015-10-09T09:38:57  <CodeShark> that depends on how the logic is chunked, though
273 2015-10-09T09:39:09  <sipa> maybe
274 2015-10-09T09:39:17  <sipa> i'm not saying there are no benefits
275 2015-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
276 2015-10-09T09:39:27  <sipa> but it will come at a high cost, and not just reviee cost
277 2015-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
278 2015-10-09T09:40:51  <sipa> you will need to know what all plugins are doing to see whether the result is consensus safe
279 2015-10-09T09:41:43  <CodeShark> if the plugins have interdependencies it does potentially add a significant amount of complexity, especially circular dependencies
280 2015-10-09T09:41:51  <sipa> that's not what i mean
281 2015-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
282 2015-10-09T09:43:05  <sipa> in theory
283 2015-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 :)
284 2015-10-09T09:43:56  <CodeShark> this is process scalability
285 2015-10-09T09:43:58  <sipa> CodeShark: i will still review them if they are in plugins
286 2015-10-09T09:44:12  <sipa> i don't see how this changes anything
287 2015-10-09T09:44:13  <wumpus> at least some people are going to know those lines of code *very* well then
288 2015-10-09T09:44:15  <CodeShark> yes, but the author can be tasked with proving them out considerably more before you even touch them
289 2015-10-09T09:44:50  <wumpus> ... which is kind of the goal, people need to understand the consensus rules and how everything fits together
290 2015-10-09T09:44:51  <CodeShark> we can have a review process where stuff gets better screening before it gets to you
291 2015-10-09T09:44:52  <sipa> i don't believe that
292 2015-10-09T09:45:09  <sipa> i think more abstraction will only result in more ways a plugin could screw with consensus
293 2015-10-09T09:45:38  <sipa> unless it is very minimal, and thus nearly useless
294 2015-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
295 2015-10-09T10:34:39  *** epilido has quit IRC
296 2015-10-09T10:44:52  *** fkhan has quit IRC
297 2015-10-09T10:56:11  *** n0n0__ has joined #bitcoin-core-dev
298 2015-10-09T10:59:57  *** fkhan has joined #bitcoin-core-dev
299 2015-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
300 2015-10-09T11:24:58  <wumpus> this is going to force our hand re: new 0.10.x and 0.11.x releases
301 2015-10-09T11:34:30  <morcos> would you still consider trying to bundle the other stuff in?
302 2015-10-09T11:43:07  <wumpus> I think everything that is currently in the branches should be included (including the LowS enforcement)
303 2015-10-09T11:44:50  <wumpus> so it can be announced as dual fix: upnp security issue and mallability nuisance
304 2015-10-09T11:45:59  <wumpus> I don't think the CLTV softfork should be included
305 2015-10-09T11:48:46  <sipa> i wonder whether we should disconnect softforks entirely from releases
306 2015-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
307 2015-10-09T11:52:18  <wumpus> internal versions 0.11.1.1 and 0.10.3.1?
308 2015-10-09T11:52:44  <sipa> i guess we could coopt the lowest digit for that
309 2015-10-09T11:52:47  <wumpus> we never use the fourth number
310 2015-10-09T11:53:05  <sipa> we have used it occasionally for platform-specific releases
311 2015-10-09T11:53:10  <sipa> like windows-only bugfixes
312 2015-10-09T11:53:19  <sipa> but that's not a big deal
313 2015-10-09T11:53:41  <wumpus> but I'm ok with the idea...
314 2015-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
315 2015-10-09T11:54:18  <wumpus> yes
316 2015-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"
317 2015-10-09T11:55:35  <sipa> to avoid needing huge names for historical softforks
318 2015-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
319 2015-10-09T12:01:54  <btcdrak> I dont like having a -cltv release.
320 2015-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.
321 2015-10-09T12:02:49  <btcdrak> let's not get overly pedantic
322 2015-10-09T12:03:29  <btcdrak> let's release what we have.
323 2015-10-09T12:04:04  <wumpus> that's already my plan btcdrak
324 2015-10-09T12:04:26  <wumpus> the softfork releease  would be what is planned for the end of the month
325 2015-10-09T12:04:27  <btcdrak> wumpus: +1
326 2015-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
327 2015-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)
328 2015-10-09T12:08:39  <btcdrak> OT: how serious is this miniupnp issue?
329 2015-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
330 2015-10-09T12:10:25  <wumpus> as I understand it, any local device could feed invalid data to the UPNP discovery and overflow a buffer
331 2015-10-09T12:12:42  <sipa> I understand the downside... it's just an idea.
332 2015-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
333 2015-10-09T12:13:48  <wumpus> btcdrak: the TALOS description is quite detailed; I don't know more, haven't tried to exploit it
334 2015-10-09T12:14:22  <wumpus> sipa: I absolutely agree - just don't know if version *numbers* are the right way to communciate that :-)
335 2015-10-09T12:14:47  <sipa> fair enough
336 2015-10-09T12:15:00  <wumpus> may be better to write something in the release notes, if someone is good at writing those things
337 2015-10-09T12:15:10  <wumpus> anyhow that's a problem for end of the month
338 2015-10-09T12:15:47  <wumpus> I think merging https://github.com/bitcoin/bitcoin/pull/6785 makes sense before 0.11.1
339 2015-10-09T12:16:16  <gavinandresen> remote exploit is serious enough to warrant an alert, in my humble opinion
340 2015-10-09T12:17:22  <wumpus> yeah, probably
341 2015-10-09T12:18:09  <wumpus> I've thought about sending one to make people disable upnp
342 2015-10-09T12:18:17  <wumpus> but reconsidered quickly
343 2015-10-09T12:18:38  <wumpus> so let's get the new versions out first
344 2015-10-09T12:18:41  <sipa> yeah
345 2015-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
346 2015-10-09T12:19:13  <wumpus> CodeShark: don't be crazy, this is not #bitcoin-sciencefiction :p
347 2015-10-09T12:19:23  <CodeShark> heh
348 2015-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
349 2015-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
350 2015-10-09T12:21:03  <morcos> its not like its an option you can really choose in addition to getting your upgrades
351 2015-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.
352 2015-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
353 2015-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
354 2015-10-09T12:22:20  <CodeShark> lol - the one without is called a command line option...the one with is called the default settings
355 2015-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
356 2015-10-09T12:24:22  <btcdrak> morcos: releasing often is always a good thing
357 2015-10-09T12:24:28  <CodeShark> I am very close to having a functioning versionbits implementation, fwiw
358 2015-10-09T12:24:35  <morcos> not when people NEED each of the upgrades
359 2015-10-09T12:24:44  <morcos> ok so 5
360 2015-10-09T12:24:46  <morcos> :)
361 2015-10-09T12:24:55  <sipa> fair enough
362 2015-10-09T12:25:27  <morcos> 0.12 although a major version upgrade will be essentially required b/c of mempool limiting
363 2015-10-09T12:25:55  <CodeShark> in principle, we should probably have version numbers for the protocol itself
364 2015-10-09T12:26:02  <CodeShark> separate from the software
365 2015-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
366 2015-10-09T12:26:28  <sipa> CodeShark: we have those...
367 2015-10-09T12:26:33  <CodeShark> the block header version is sorta that...but not exactly
368 2015-10-09T12:26:38  <sipa> block version numbers for consensus
369 2015-10-09T12:26:45  <sipa> protocol version numbers for protocol
370 2015-10-09T12:27:13  <CodeShark> with versionbits, we're moving away entirely from sequential numbering
371 2015-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
372 2015-10-09T12:27:50  <morcos> then people can decide which to skip and not just blindly upgrade?  but is that asking too much
373 2015-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”
374 2015-10-09T12:28:57  <sipa> where can i read about this vulnerability?
375 2015-10-09T12:29:02  <CodeShark> but people behind a firewall might just shut down their node
376 2015-10-09T12:29:07  <gavinandresen> sipa: http://talosintel.com/reports/TALOS-2015-0035/
377 2015-10-09T12:29:36  <gavinandresen> sipa: … from wumpus’  https://github.com/bitcoin/bitcoin/pull/6789
378 2015-10-09T12:29:50  <sipa> so you need access to the local network
379 2015-10-09T12:30:48  <sipa> presumably, such situations are more dangerous in corporate networks, where upnp doesn't worn anyway
380 2015-10-09T12:31:07  <gavinandresen> “doesn’t work” != “isn’t vulnerable” though
381 2015-10-09T12:31:54  <sipa> sure, just saying that the place where this risk is largest, is one where upnp has no use anywah
382 2015-10-09T12:32:10  <gavinandresen> yup
383 2015-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
384 2015-10-09T12:33:46  <CodeShark> depends on whether it's a private LAN or a larger shared network, though
385 2015-10-09T12:34:28  <gavinandresen> How about:  “If you are running bitcoind on a public LAN, restart ...."
386 2015-10-09T12:34:44  <sipa> sounds good
387 2015-10-09T12:36:28  <sipa> actually
388 2015-10-09T12:36:32  <sipa> no need to even restart
389 2015-10-09T12:36:43  <sipa> miniupnp is only called at startup
390 2015-10-09T12:37:02  <sipa> so putting it in your config would be enough, to prevent upnp from running next time
391 2015-10-09T12:38:01  <CodeShark> unless someone already injected a delayed payload...in which case it's already too late
392 2015-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
393 2015-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
394 2015-10-09T12:44:02  <wumpus> but they'll probably forget to enable it again after the new release
395 2015-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
396 2015-10-09T12:51:38  <GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6cf73b0cd4cf...8c7e6138dbcb
397 2015-10-09T12:51:39  <GitHub31> bitcoin/master 0cca024 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
398 2015-10-09T12:51:39  <GitHub31> bitcoin/master 8c7e613 Wladimir J. van der Laan: Merge pull request #6789...
399 2015-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
400 2015-10-09T12:53:12  *** fanquake has joined #bitcoin-core-dev
401 2015-10-09T12:53:12  *** fanquake has quit IRC
402 2015-10-09T12:53:12  *** fanquake has joined #bitcoin-core-dev
403 2015-10-09T12:54:44  <GitHub25> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/093d7b5895b7dddd98d929fc3851265970b995b7
404 2015-10-09T12:54:45  <GitHub25> bitcoin/0.10 093d7b5 Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
405 2015-10-09T12:56:21  *** fkhan has quit IRC
406 2015-10-09T12:56:54  <GitHub163> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/b4ad73f706196272589451ce3d223f3df029eea1
407 2015-10-09T12:56:55  <GitHub163> bitcoin/0.11 b4ad73f Wladimir J. van der Laan: Update miniupnpc to 1.9.20151008...
408 2015-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
409 2015-10-09T12:58:21  <GitHub187> [bitcoin] laanwj pushed 2 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/b4ad73f70619...b4dc33e9fbbc
410 2015-10-09T12:58:21  <GitHub187> bitcoin/0.11 36f14bf Tom Harding: In (strCommand == "tx"), return if AlreadyHave()...
411 2015-10-09T12:58:22  <GitHub187> bitcoin/0.11 b4dc33e Wladimir J. van der Laan: Merge pull request #6785...
412 2015-10-09T12:59:45  <fanquake> wumpus bugfix release shortly?
413 2015-10-09T12:59:50  <wumpus> yes
414 2015-10-09T13:01:53  *** n0n0__ has quit IRC
415 2015-10-09T13:02:34  *** paveljanik has joined #bitcoin-core-dev
416 2015-10-09T13:03:44  <michagogo> How shortly? I'm going offline in about 2 hours.
417 2015-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
418 2015-10-09T13:05:58  <wumpus> within two hours, absolutely - I just have to write some release notes, then I'll tag the rc1s
419 2015-10-09T13:07:46  *** pigeons has quit IRC
420 2015-10-09T13:13:38  *** fkhan has joined #bitcoin-core-dev
421 2015-10-09T13:14:45  *** pigeons has joined #bitcoin-core-dev
422 2015-10-09T13:15:09  *** pigeons is now known as Guest45978
423 2015-10-09T13:20:07  <GitHub135> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/04d0c27fb0b9ce0843b99bcae3c4e106fd817496
424 2015-10-09T13:20:07  <GitHub135> bitcoin/0.11 04d0c27 Wladimir J. van der Laan: doc: Update release notes for 0.11.1
425 2015-10-09T13:20:59  <wumpus> preliminary release notes for 0.11: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md
426 2015-10-09T13:21:09  <wumpus> that is 0.11.1
427 2015-10-09T13:27:53  <GitHub74> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/1bf6ac62abc2faad8af76aebfa0887c073e2c9b4
428 2015-10-09T13:27:53  <GitHub74> bitcoin/0.10 1bf6ac6 Wladimir J. van der Laan: doc: Update release notes for 0.10.3
429 2015-10-09T13:27:59  <wumpus> and for 0.10.3: https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md
430 2015-10-09T13:32:24  <GitHub18> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/d7d87a1db1b90094a0dd517b89ef1c40eaedf14c
431 2015-10-09T13:32:24  <GitHub18> bitcoin/0.11 d7d87a1 Wladimir J. van der Laan: qt: Update translations before 0.11.1
432 2015-10-09T13:33:33  <wumpus> ready to tag
433 2015-10-09T13:33:42  <GitHub86> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/44d6bc85285f2cbbee0a7b94924975d3e9d84875
434 2015-10-09T13:33:42  <GitHub86> bitcoin/0.10 44d6bc8 Wladimir J. van der Laan: qt: Translations update before 0.10.3
435 2015-10-09T13:35:40  <wumpus>  * [new tag]         v0.10.3rc1 -> v0.10.3rc1                                                                                                     │·············································
436 2015-10-09T13:37:39  <wumpus>  * [new tag]         v0.11.1rc1 -> v0.11.1rc1
437 2015-10-09T13:37:47  <sipa> reviewing 0.111.1
438 2015-10-09T13:37:52  <sipa> ah, too late
439 2015-10-09T13:38:07  <wumpus> no, not too late, you can review while building rc1 :p
440 2015-10-09T13:38:28  <wumpus> if there's anything wrong we can always do a rc2 immediately
441 2015-10-09T13:38:43  <sipa> the release notes mention bc484ef8db02715e283e4cddd2c972316c0688dd., which was reverted
442 2015-10-09T13:39:44  <wumpus> ok, removing that one
443 2015-10-09T13:41:16  <GitHub102> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/17ea542aa6323715d22cf6661e9705b3e940e3d1
444 2015-10-09T13:41:16  <GitHub102> bitcoin/0.11 17ea542 Wladimir J. van der Laan: doc: #6077 was reverted, don't mention in release notes...
445 2015-10-09T13:49:39  *** CodeShark has quit IRC
446 2015-10-09T13:49:59  *** CodeShark has joined #bitcoin-core-dev
447 2015-10-09T13:51:30  *** CodeShark has quit IRC
448 2015-10-09T13:53:06  <morcos> wumpus: did you raise minrelaytxfee?
449 2015-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
450 2015-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?
451 2015-10-09T14:00:28  *** fanquake has quit IRC
452 2015-10-09T14:04:40  <michagogo> hm, `make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common` is erroring
453 2015-10-09T14:04:46  <michagogo> or, well
454 2015-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`
455 2015-10-09T14:05:04  <michagogo> and now it seems to be redownloading qt
456 2015-10-09T14:05:25  <wumpus> morcos: that was not done
457 2015-10-09T14:05:35  <wumpus> maybe for the release end of this month
458 2015-10-09T14:05:37  <cfields> michagogo: that's harmless, you can ignore it
459 2015-10-09T14:05:49  <michagogo> Hm, did qt get bumped since 0.11.0?
460 2015-10-09T14:08:20  <wumpus> #6471 92401c2 Depends: bump to qt 5.5   yes - I remember this was for the TLS1.0+ requirement
461 2015-10-09T14:10:54  <michagogo> Oh, I just realized my script for a complete gitian build probably won't work for 0.10
462 2015-10-09T14:11:04  <michagogo> I guess I'll do that one manually tomorrow night
463 2015-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
464 2015-10-09T14:26:00  *** CodeShark has joined #bitcoin-core-dev
465 2015-10-09T14:35:32  <michagogo> cfields: btw, looks like the mirror on bitcoincore.org isn't up to date
466 2015-10-09T14:35:49  <cfields> ugh, i keep meaning to setup a cronjob for that
467 2015-10-09T14:35:52  <cfields> what's missing?
468 2015-10-09T14:35:56  <michagogo> qt
469 2015-10-09T14:35:59  <michagogo> Also, argh
470 2015-10-09T14:36:09  <cfields> ok, pulling it in
471 2015-10-09T14:36:17  <michagogo> apparently if one component errors out it doesn't keep everything else that was fetched
472 2015-10-09T14:37:00  <michagogo> That's really bad
473 2015-10-09T14:37:24  <cfields> yea, the multi-sources are a corner-case and kinda handled hammer-style
474 2015-10-09T14:37:48  <michagogo> Hm
475 2015-10-09T14:38:00  <michagogo> I think this might mean I won't be able to kick the build off before I go offline
476 2015-10-09T14:38:09  <michagogo> a 60MB download, took a long time
477 2015-10-09T14:38:28  <michagogo> and is now going to have to rerun because a <3 MB file failed to download
478 2015-10-09T14:40:05  <michagogo> Is dependency download from within gitian working atm?
479 2015-10-09T14:41:04  <cfields> depends on the config. I think it's only an issue with lxc
480 2015-10-09T14:41:27  <michagogo> Im using lxc :-(
481 2015-10-09T14:42:04  <cfields> ok, links should be good now
482 2015-10-09T14:42:11  <cfields> setting up a cronjob
483 2015-10-09T14:48:51  *** Cocodude has joined #bitcoin-core-dev
484 2015-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?
485 2015-10-09T14:50:29  *** treehug88 has joined #bitcoin-core-dev
486 2015-10-09T14:50:30  <paveljanik> Cocodude, #bitcoin please.
487 2015-10-09T14:51:33  *** PaulCape_ has joined #bitcoin-core-dev
488 2015-10-09T14:53:46  *** PaulCapestany has quit IRC
489 2015-10-09T14:54:24  *** rubensayshi has quit IRC
490 2015-10-09T14:58:32  <michagogo> Okay, I *think* I got the build kicked off now.
491 2015-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.
492 2015-10-09T14:59:28  <michagogo> שבת שלום
493 2015-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
494 2015-10-09T15:01:40  *** challisto has joined #bitcoin-core-dev
495 2015-10-09T15:01:40  *** challisto has joined #bitcoin-core-dev
496 2015-10-09T15:03:47  *** Cocodude has left #bitcoin-core-dev
497 2015-10-09T15:20:51  *** d_t has joined #bitcoin-core-dev
498 2015-10-09T15:25:58  <cfields> michagogo: cronjob installed. Should require very minimal manual intervention from now on
499 2015-10-09T15:27:08  *** n0n0__ has joined #bitcoin-core-dev
500 2015-10-09T15:33:02  *** n0n0__ has quit IRC
501 2015-10-09T15:45:17  *** randy-waterhouse has quit IRC
502 2015-10-09T15:47:20  <cfields> wumpus: whoops, looks like version bumps were missed for 0.10/0.11 ?
503 2015-10-09T15:50:30  <wumpus> yes
504 2015-10-09T15:51:15  <wumpus> we'll leave that for rc2
505 2015-10-09T15:58:24  <wumpus> my gitian build spends a lot of time in "Upgrading system...". Does making new images avoid that?
506 2015-10-09T15:58:40  <wumpus> (KVM build)
507 2015-10-09T16:14:28  <GitHub129> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/cf5bf5542a6aba6b97fb69e0d2c11c2cd47f406d
508 2015-10-09T16:14:28  <GitHub129> bitcoin/0.10 cf5bf55 Wladimir J. van der Laan: Bump version to 0.10.3
509 2015-10-09T16:18:41  <GitHub52> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/717152ccba2a31ceaf7d0e02f6c9ad82843f2176
510 2015-10-09T16:18:41  <GitHub52> bitcoin/0.11 717152c Wladimir J. van der Laan: Bump version to 0.11.1
511 2015-10-09T16:19:59  <cfields> wumpus: unsure
512 2015-10-09T16:38:39  *** randy-waterhouse has joined #bitcoin-core-dev
513 2015-10-09T16:55:51  *** d_t has quit IRC
514 2015-10-09T16:59:04  *** d_t has joined #bitcoin-core-dev
515 2015-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
516 2015-10-09T17:29:19  *** ghtdak has joined #bitcoin-core-dev
517 2015-10-09T17:31:42  *** randy-waterhouse has quit IRC
518 2015-10-09T17:41:04  <gmaxwell> I continue to be unhappy with the miniupnp codebase. At least shutting it off more often will help. :)
519 2015-10-09T17:41:59  *** CodeShark has quit IRC
520 2015-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
521 2015-10-09T17:42:39  <wumpus> we all are
522 2015-10-09T17:42:45  *** CodeShark has joined #bitcoin-core-dev
523 2015-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
524 2015-10-09T17:43:34  <wumpus> (too bad we don't really have a way to measure)
525 2015-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.
526 2015-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
527 2015-10-09T17:44:12  <petertodd> wumpus: removing miniupnpc while adding automatic tor hidden service support would be a decent compromise...
528 2015-10-09T17:44:32  <wumpus> petertodd: it's the better way of hole-punching :)
529 2015-10-09T17:44:51  <petertodd> wumpus: yup!
530 2015-10-09T17:44:56  <gmaxwell> petertodd: not quite a replacement unless we were getting more nodes to come along with a tor client though.
531 2015-10-09T17:45:33  <wumpus> it should be able to interface with the TBB that the user has installed
532 2015-10-09T17:45:38  <petertodd> gmaxwell: yeah, easiest to do in the context of things like ubuntu packages which can depend on tor
533 2015-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?
534 2015-10-09T17:47:15  <wumpus> alternatively we could switch to an UDP-based protocol and use UDP hole punching on the router *ducks*
535 2015-10-09T17:47:29  <wumpus> I really don't like that solution gmaxwell, having anything depend on UI-or-not
536 2015-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.
537 2015-10-09T17:48:31  <wumpus> on average, UI users are generally the most vulnerable to all kinds of attacks
538 2015-10-09T17:48:42  <wumpus> so giving them the libupnp burden is wrong
539 2015-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?
540 2015-10-09T17:49:09  <wumpus> (also UI users are most likely to have the wallet enabled)
541 2015-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.
542 2015-10-09T17:49:59  <gmaxwell> wumpus: at the same time UI users are less likely to be subject to heroic attack efforts.
543 2015-10-09T17:50:06  <wumpus> I'd just like to make the decision to turn it off
544 2015-10-09T17:50:13  <gmaxwell> Also UI users are more likely to have worse vulnerabilities on their system.
545 2015-10-09T17:50:33  <wumpus> yes, I want to remove miniupnpc completely
546 2015-10-09T17:50:48  <gmaxwell> How about we default it to off in the update?
547 2015-10-09T17:51:02  <wumpus> fine with me too
548 2015-10-09T17:51:17  <petertodd> gmaxwell: AC
549 2015-10-09T17:51:20  <petertodd> gmaxwell: ACK
550 2015-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.
551 2015-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
552 2015-10-09T17:52:40  <gmaxwell> Absolutely, I was just speaking in terms of averages.
553 2015-10-09T17:52:48  <wumpus> well I like the torrent solution... pressure people to add a port forward by showing an ugly icon :-)
554 2015-10-09T17:53:05  <petertodd> gmaxwell: what % of reachable nodes correspond to residential ip addrs?
555 2015-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'
556 2015-10-09T17:54:33  <wumpus> anyhow, yes let's default upnp to no
557 2015-10-09T17:56:15  *** PaulCape_ has quit IRC
558 2015-10-09T17:59:14  *** PaulCapestany has joined #bitcoin-core-dev
559 2015-10-09T18:00:14  *** d_t has quit IRC
560 2015-10-09T18:01:38  *** d_t has joined #bitcoin-core-dev
561 2015-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
562 2015-10-09T18:03:19  * wumpus tries to understand the autotools magic of --[enable|disable]-upnp-default 
563 2015-10-09T18:03:26  <wumpus> oh, you got it already gmaxwell?
564 2015-10-09T18:04:08  <gmaxwell> ah, well I missed that autotools had magic there.
565 2015-10-09T18:04:10  <wumpus> no, you changed the source code instead of the build system default
566 2015-10-09T18:04:25  <gmaxwell> I think we should rip that out. Opinion?
567 2015-10-09T18:04:31  <gmaxwell> (the autotools part)
568 2015-10-09T18:04:42  <gmaxwell> (also the message handling was wrong, incidentally.)
569 2015-10-09T18:05:02  <wumpus> I don't get it.
570 2015-10-09T18:05:28  <gmaxwell> well not wrong, but redundant with the code.
571 2015-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"
572 2015-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. :)
573 2015-10-09T18:06:03  <gmaxwell> Yea, thats the original makefile behavior.
574 2015-10-09T18:06:07  <petertodd> away .
575 2015-10-09T18:06:40  <wumpus>    -upnp       Use UPnP to map the listening port (default: 0)
576 2015-10-09T18:07:37  <wumpus> it already defaults to 0?
577 2015-10-09T18:07:43  <gmaxwell> no.
578 2015-10-09T18:07:53  <gmaxwell> see the twisty mase of IFdefs my patch removes.
579 2015-10-09T18:08:01  <wumpus> then why do I get that?
580 2015-10-09T18:08:16  <gmaxwell> !
581 2015-10-09T18:08:31  <sipa> it's default on for qt, default off for bitcoind, no?
582 2015-10-09T18:08:34  <wumpus> (yes, I have installed the library and dev headers)
583 2015-10-09T18:08:37  <wumpus> no, it's not sipa
584 2015-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.
585 2015-10-09T18:09:04  <wumpus> configure:27112: checking whether to build with UPnP enabled by default
586 2015-10-09T18:09:04  <wumpus> configure:27120: result: no
587 2015-10-09T18:09:05  <sipa> oh really...?
588 2015-10-09T18:09:13  <wumpus> anyone get something else in config.log?
589 2015-10-09T18:09:27  <sipa> ah, maybe it's off by default, but we turn it on in release builds?
590 2015-10-09T18:09:39  <wumpus> (I haven't overridden it)
591 2015-10-09T18:09:46  <wumpus> that might be it, let's see
592 2015-10-09T18:09:48  <gmaxwell> my system is too weird a test point.
593 2015-10-09T18:10:13  <wumpus> sipa: you're right
594 2015-10-09T18:10:26  <wumpus> so only the gitian builds enable it by default
595 2015-10-09T18:10:46  <gmaxwell> Okay, gonna close that second pull.
596 2015-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
597 2015-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.
598 2015-10-09T18:11:54  <sipa> i do think we need to get rid of that confusing logic...
599 2015-10-09T18:12:22  <gmaxwell> well we could rip out all that stuff that lets you default it to on.
600 2015-10-09T18:13:13  <wumpus> fine with me
601 2015-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
602 2015-10-09T18:32:55  *** fkhan has quit IRC
603 2015-10-09T18:32:59  *** ParadoxSpiral_ has joined #bitcoin-core-dev
604 2015-10-09T18:36:37  *** ParadoxSpiral has quit IRC
605 2015-10-09T18:41:34  *** Thireus has joined #bitcoin-core-dev
606 2015-10-09T18:42:08  <Luke-Jr> wumpus: what is the purpose in removing the --[enable|disable]-upnp-default
607 2015-10-09T18:43:10  <wumpus> Luke-Jr: we don't have --XXX-default options for other settings either
608 2015-10-09T18:43:47  <Luke-Jr> wumpus: is there any similar option? particularly, that enables a compile-time feature disabled by default
609 2015-10-09T18:43:58  <wumpus> I don't think so
610 2015-10-09T18:44:17  <Luke-Jr> it only makes sense to remove this one, if the default is always ON
611 2015-10-09T18:44:31  <wumpus> "set this at runtime instead"
612 2015-10-09T18:45:01  <wumpus> come on, do you really care about this?
613 2015-10-09T18:45:10  <Luke-Jr> wumpus: yes, because I will now have to support a patch to do it
614 2015-10-09T18:45:30  <wumpus> why not just set it in bitcoin.conf instead?
615 2015-10-09T18:45:44  <Luke-Jr> that involves manipulating bitcoin.conf
616 2015-10-09T18:45:57  <wumpus> yeh it does...
617 2015-10-09T18:46:24  <Luke-Jr> people who install bitcoin-qt[upnp] shouldn't need to take additional steps to enable UPnP
618 2015-10-09T18:46:35  <Luke-Jr> people who don't want UPnP would disable it at compile-time
619 2015-10-09T18:46:46  <wumpus> with qt it's even simpler, you can enable it in the options
620 2015-10-09T18:47:04  <Luke-Jr> that's not simpler
621 2015-10-09T18:47:05  <wumpus> --with-upnp *adds the feature* it doesn't enable it
622 2015-10-09T18:47:16  <wumpus> it never did
623 2015-10-09T18:47:23  <Luke-Jr> exactly why the separate option is needed
624 2015-10-09T18:47:30  *** fkhan has joined #bitcoin-core-dev
625 2015-10-09T18:47:36  <wumpus> zmq is exactly the same
626 2015-10-09T18:47:50  <wumpus> --with-zmq builds with libzmq, it doesn't *enable* it
627 2015-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
628 2015-10-09T18:48:07  <wumpus> if you want it, enable it in your config
629 2015-10-09T18:48:11  <Luke-Jr> nobody uses ZMQ though; whereas UPnP *should* be used
630 2015-10-09T18:48:23  <wumpus> no, UPnP should not be used, it's a grave risk
631 2015-10-09T18:48:40  <wumpus> this isn't the first vulnerability in it
632 2015-10-09T18:48:45  <Luke-Jr> it's a grave risk to disable it too
633 2015-10-09T18:48:54  <wumpus> well at least not a remote code execution...
634 2015-10-09T18:49:16  <Luke-Jr> sipa: so we should distribute binaries with it disabled by default, I agree with that
635 2015-10-09T18:49:22  <btcdrak> so we just need to point users to instructions on how to port forward.
636 2015-10-09T18:49:37  <btcdrak> there must be plenty tutorials already out there
637 2015-10-09T18:49:40  <wumpus> btcdrak: agreed, same as torrent clients have done for years, upnp is unreliable at best
638 2015-10-09T18:49:43  <paveljanik> btcdrak, +1
639 2015-10-09T18:49:48  <Luke-Jr> but if someone is explicitly compiling a build with UPnP, they shouldn't need extra steps
640 2015-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
641 2015-10-09T18:50:18  <btcdrak> wumpus: we should just pull upnp out. I mean, this is people's money we're talking about potentially
642 2015-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
643 2015-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.
644 2015-10-09T18:51:08  <wumpus> Luke-Jr: as said, it's the same for the other optional features, apart from the wallet
645 2015-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
646 2015-10-09T18:51:51  <Luke-Jr> …
647 2015-10-09T18:52:14  <btcdrak> Let me go find some port forwarding tutorials
648 2015-10-09T18:52:26  <wumpus> why do you want to expose users to the risk of upnp on gentoo by default?
649 2015-10-09T18:52:31  <Luke-Jr> btcdrak: you're assuming the user even has access to the router
650 2015-10-09T18:52:35  * Eliel wonders how much work it'd be to implement just the subset of upnp that bitcoin needs.
651 2015-10-09T18:52:36  <Luke-Jr> wumpus: it's not by default
652 2015-10-09T18:52:45  <Luke-Jr> wumpus: by default, it won't even be built with UPnP support
653 2015-10-09T18:53:00  <sipa> Luke-Jr: then why do you need a compile-time option for it?
654 2015-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.
655 2015-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
656 2015-10-09T18:53:11  <Luke-Jr> sipa: so when users enable it, they actually get it
657 2015-10-09T18:53:23  <sipa> Luke-Jr: they can enable it by enabling it!
658 2015-10-09T18:53:26  <Luke-Jr> gmaxwell: huh? the binaries have always had it on by default, no?
659 2015-10-09T18:53:33  <gmaxwell> Luke-Jr: they do get it, by enabling it in the config! making it compile time is kinda psycho!
660 2015-10-09T18:53:44  <Luke-Jr> sipa: they enable it system-wide by setting USE=upnp and recompiling
661 2015-10-09T18:53:57  <gmaxwell> Luke-Jr: no bitcoin-qt did but bitcoind didn't until the switch off of makefiles, AFAIK.
662 2015-10-09T18:54:06  <Luke-Jr> wumpus: UPnP just fixes a bug in NAT
663 2015-10-09T18:54:27  <Luke-Jr> gmaxwell: but Bitcoin-Qt is what end users use
664 2015-10-09T18:55:00  <Luke-Jr> obviously servers (the target for bitcoind) do not need UPnP
665 2015-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.
666 2015-10-09T18:58:27  <wumpus> the trinary option USE_UPNP confuses me every time, but apart from that, you're probably right...
667 2015-10-09T18:59:47  *** Thireus has quit IRC
668 2015-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...
669 2015-10-09T19:00:31  <sipa> --reindex-default would be useful for systems with crappy disks
670 2015-10-09T19:01:26  <wumpus> heh
671 2015-10-09T19:02:11  <Luke-Jr> meh
672 2015-10-09T19:02:56  <Luke-Jr> IF it is going to be removed in master, can we at least keep it around in backports?
673 2015-10-09T19:07:11  <wumpus> I think the point of this is to backport it
674 2015-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
675 2015-10-09T19:11:19  *** skyraider has joined #bitcoin-core-dev
676 2015-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.
677 2015-10-09T19:11:51  <wumpus> someone that cares enough could still remove the --upnp-default setting in master
678 2015-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.
679 2015-10-09T19:12:23  <wumpus> skyraider: questions about BIPs are really off topic here
680 2015-10-09T19:12:40  <skyraider> ok sorry
681 2015-10-09T19:12:47  <sipa> skyraider: read BIP32, it clearly specifies what master means
682 2015-10-09T19:12:47  <skyraider> correct channel?
683 2015-10-09T19:12:50  <Luke-Jr> #bitcoin-dev
684 2015-10-09T19:13:04  <wumpus> #bitcoin or #bitcoin-dev
685 2015-10-09T19:13:24  <sipa> oh, it calls it seed
686 2015-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.
687 2015-10-09T19:17:45  <gmaxwell> which doesn't seem totally nutty. But the fact that supporting this craps up our code base, is .. unfortunate.
688 2015-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 :)
689 2015-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.
690 2015-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'
691 2015-10-09T19:20:54  <gmaxwell> E.g. I'd also be fine with UPNP_DEFAULT = false being overridable with a UPNP_DEFAULT_ON  ifdef.
692 2015-10-09T19:21:02  <gmaxwell> and then gentoo need not even SED.
693 2015-10-09T19:21:09  <gmaxwell> could just set a cflag.
694 2015-10-09T19:21:14  <Luke-Jr> CXXFLAGS="-DUPNP_DEFAULT_ON" would also be fairly simple
695 2015-10-09T19:21:50  <Luke-Jr> not sure it's better than sed though, if it was a single well-defined location
696 2015-10-09T19:22:14  <wumpus> setting a cflag wouldn't work, the default is a constant, not a macro
697 2015-10-09T19:22:18  <gmaxwell> Luke-Jr: the sed is more likely to get disrupted by code motion.
698 2015-10-09T19:22:31  <gmaxwell> wumpus: I mean having a macro that changes the constant.
699 2015-10-09T19:22:32  <Luke-Jr> gmaxwell: true
700 2015-10-09T19:22:42  <wumpus> ugh, if you're going with a macro anyway, then you may just as well keep the configure option
701 2015-10-09T19:22:57  <wumpus> as we have a macro for that now: USE_UPNP
702 2015-10-09T19:23:13  <wumpus> but ok, I'm done with this, not going to spend anymore time on it
703 2015-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
704 2015-10-09T19:23:37  <sipa> i don't care
705 2015-10-09T19:23:38  <wumpus> yeah...
706 2015-10-09T19:23:57  <Luke-Jr> >_<
707 2015-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.
708 2015-10-09T19:24:14  <gmaxwell> It's a few more bytes and not an unreasonable ask.
709 2015-10-09T19:24:44  <gmaxwell> And it's nice to get rid of the crazy overload of the define value.
710 2015-10-09T19:24:53  <gmaxwell> and make this simpler.
711 2015-10-09T19:24:53  <wumpus> please just keep it as it is now
712 2015-10-09T19:24:59  <wumpus> I'm sure you have something more serious to do
713 2015-10-09T19:25:56  <wumpus> can we make a decision about mempool limiting? :p
714 2015-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
715 2015-10-09T19:27:27  <wumpus> kanzure: read back, sipa already answered that a while back
716 2015-10-09T19:27:45  <sipa> kanzure: it should be called seed
717 2015-10-09T19:27:50  <kanzure> i was looking at wrong channel, sorry
718 2015-10-09T19:28:07  <kanzure> sipa is not in -dev so i was confused
719 2015-10-09T19:29:53  <kanzure> i am not sure that "master (hex)" is clearly defined.
720 2015-10-09T19:30:09  *** Thireus has joined #bitcoin-core-dev
721 2015-10-09T19:32:09  <sipa> kanzure: it isn't, it should be called seed :)
722 2015-10-09T19:35:16  <wumpus> should we add that to the topic? we keep getting that question :p
723 2015-10-09T19:35:43  <kanzure> was asked in other channel, sipa wasn't around, question kept getting misinterpreted, seems natural to hunt down author
724 2015-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 ;)
725 2015-10-09T19:40:24  <CodeShark> btw, we should update one of the links on that page
726 2015-10-09T19:40:34  <CodeShark> going to submit a PR
727 2015-10-09T19:41:30  <kanzure> https://github.com/bitcoin/bips/pull/217
728 2015-10-09T19:42:22  <CodeShark> yeah, it should be called seed ;)
729 2015-10-09T19:45:32  *** CodeShark has quit IRC
730 2015-10-09T19:45:38  *** fkhan has quit IRC
731 2015-10-09T19:45:42  *** CodeShark has joined #bitcoin-core-dev
732 2015-10-09T19:46:00  <wumpus> yes, it should...
733 2015-10-09T19:48:04  <CodeShark> hey! I'm not in the acknowledgements for BIP32
734 2015-10-09T19:48:17  <CodeShark> I believe I added support for it before anyone else :p
735 2015-10-09T19:48:43  <CodeShark> and I also fixed up the text and wrote the test vector code
736 2015-10-09T19:48:48  <CodeShark> ;)
737 2015-10-09T19:50:05  <CodeShark> then everyone else copied my whole parallel tree implementation
738 2015-10-09T19:50:07  <CodeShark> for multisig
739 2015-10-09T19:50:12  <CodeShark> but bah :p
740 2015-10-09T19:50:48  <sipa> so add yourself
741 2015-10-09T19:50:59  <wumpus> this is not really on topic here
742 2015-10-09T19:51:23  <wumpus> but yes, go add yourself
743 2015-10-09T19:59:41  <CodeShark> https://github.com/bitcoin/bips/pull/218
744 2015-10-09T20:00:29  *** fkhan has joined #bitcoin-core-dev
745 2015-10-09T20:02:26  <CodeShark> is the bips repo offtopic here?
746 2015-10-09T20:04:01  <wumpus> well, BIPs are on topic when it relates to implementing them in Bitcoin Core, but not on their own
747 2015-10-09T20:05:37  *** treehug88 has quit IRC
748 2015-10-09T20:16:33  *** belcher has joined #bitcoin-core-dev
749 2015-10-09T20:18:44  <paveljanik> wumpus, 0.10 doesn't contain 649f5d9c1100bb3cbace724900f035939df5ea11. It was backported to 0.11 only. OK?
750 2015-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
751 2015-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
752 2015-10-09T20:21:07  <morcos> any pre-0.12 nodes will just miss out on txs unnecessarily
753 2015-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
754 2015-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?
755 2015-10-09T20:22:30  <morcos> i'm commenting here instead of pull, b/c i'm just brainstorming what makes sense
756 2015-10-09T20:23:54  *** Thireus1 has joined #bitcoin-core-dev
757 2015-10-09T20:24:44  *** Thireus has quit IRC
758 2015-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
759 2015-10-09T21:30:59  *** paveljanik has quit IRC
760 2015-10-09T21:51:29  *** Thireus1 has quit IRC
761 2015-10-09T23:00:29  *** BashCo_ has joined #bitcoin-core-dev
762 2015-10-09T23:02:24  *** BashCo has quit IRC
763 2015-10-09T23:22:06  *** d_t has quit IRC
764 2015-10-09T23:52:09  *** skyraider has quit IRC