1 2015-12-13T00:18:52  *** phantomcircuit has quit IRC
  2 2015-12-13T00:21:19  <gmaxwell> sipa: I think your latest update to 7125 is wrong.
  3 2015-12-13T00:21:32  <sipa> oh?
  4 2015-12-13T00:21:38  <gmaxwell> +    return nNow + (int64_t)(log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 /* -1/2^48 */) * average_interval_seconds * -1000000.0 + 0.5);
  5 2015-12-13T00:22:27  <gmaxwell> I think thats returning microseconds, not ms. And I think the now units are .. oh nevermind!
  6 2015-12-13T00:22:45  <sipa> getrand returns a result in [0, 1-1/2^48]
  7 2015-12-13T00:22:54  <sipa> ok
  8 2015-12-13T00:23:02  <sipa> it's in the comments even, i think :)
  9 2015-12-13T00:23:58  <sipa> i've tested it by adding a LogPrintf that writes out the new timestamp
 10 2015-12-13T00:24:13  <sipa> the results looks reasonably random around 5s
 11 2015-12-13T00:24:27  <gmaxwell> sipa: yea, in the header. I'd just gone to look to see what the longest number it would return, and got something that was much larger than I expected.
 12 2015-12-13T00:24:58  <gmaxwell> but thats because for some reason I thought it was using ms not microseconds. :)
 13 2015-12-13T00:28:07  *** randy-waterhouse has joined #bitcoin-core-dev
 14 2015-12-13T00:31:19  *** phantomcircuit has joined #bitcoin-core-dev
 15 2015-12-13T00:39:16  *** bawong has joined #bitcoin-core-dev
 16 2015-12-13T00:42:04  *** Tera2342 has joined #bitcoin-core-dev
 17 2015-12-13T01:02:46  *** bawong has quit IRC
 18 2015-12-13T01:03:47  *** raedah has joined #bitcoin-core-dev
 19 2015-12-13T01:38:35  *** bawong has joined #bitcoin-core-dev
 20 2015-12-13T01:41:28  *** Ylbam has quit IRC
 21 2015-12-13T02:05:09  *** andytoshi has quit IRC
 22 2015-12-13T02:17:35  *** andytoshi has joined #bitcoin-core-dev
 23 2015-12-13T02:50:07  <morcos> gmaxwell: i'm trying to understand what you were talking about yesterday with the tiered fee behavior
 24 2015-12-13T02:50:26  <morcos> are you talking about this is how mempools would behave?
 25 2015-12-13T02:51:04  <morcos> and the target size is how big you wanted to limit your mempool to?
 26 2015-12-13T02:51:17  <morcos> or are you talking about something to do with block assembly?
 27 2015-12-13T02:51:26  <gmaxwell> The latter-- block assembly.
 28 2015-12-13T02:52:05  *** molz has joined #bitcoin-core-dev
 29 2015-12-13T02:52:34  <morcos> I'm not quite understanding the purpose
 30 2015-12-13T02:52:48  <morcos> you still suggest to add in a fee sorted manner
 31 2015-12-13T02:53:18  <morcos> but you want to have the min fee which is required start going up as the block gets bigger?
 32 2015-12-13T02:53:36  *** moli has quit IRC
 33 2015-12-13T02:53:36  *** Tera2342 has quit IRC
 34 2015-12-13T02:54:10  <gmaxwell> Thats what Bitcoin did in 2012 and before, and I think the actual implementation wasn't a good path. It's weird to have such a huge amount of statefulness regarding when transactions come in.
 35 2015-12-13T02:54:11  <morcos> the idea being that before the block has decent size that from a long term perspective you need to be adding at least some txs or bitcoin is useless, but once it gets of a decent size, then you need to worry more about what the profit maximizing strategy is?
 36 2015-12-13T02:55:20  <morcos> well i just don't understand why the min fee would ever go above what the orphan risk equilibrium rate is though?
 37 2015-12-13T02:56:26  <morcos> i think you have a point that we may not have properly been considering the importance of that.   and it might make sense to for example add a separate configurable parameter which is the min mining fee rate.
 38 2015-12-13T02:56:51  <morcos> but i'm hesitant to jump to the conclusion that we've been that far off.
 39 2015-12-13T02:57:03  <gmaxwell> Consider, right now imagine we get 4 blocks in a row in 5 minutes.  We'd end up with 4 750k (or 1MB blocks) that dig deep into the mempool and mine a bunch of low fee transactions (including maliciously created spam attack crap). The result is that the fee behavior is fairly unpredictable.
 40 2015-12-13T02:57:30  <morcos> does the orphan rate really depend on block size, or is it validation cose for which block size is a semi decent proxy?
 41 2015-12-13T02:57:51  <gmaxwell> morcos: I don't think most people mining have done the math. At least the amounts involved right now are below the threshold where it probably matters; and doubly so w/ pools where the pool operator is mostly not eating the cost of their decision.
 42 2015-12-13T02:58:58  <morcos> yes, but shouldn't there just be a single cut-off point for where its no longer profitable to add txs..  and who cares if you get down closer to that sometimes when there are quick blocks in succession.  as long as you're not ever going below that?
 43 2015-12-13T02:59:15  <gmaxwell> morcos: yes, there should be.
 44 2015-12-13T02:59:53  <phantomcircuit> morcos, orphan rate is roughly proportional to the size of the transactions weighted by transaction age
 45 2015-12-13T03:00:07  <phantomcircuit> ie newer transactions are likely to take longer to validate and thus increase orphan rate
 46 2015-12-13T03:00:19  <gmaxwell> phantomcircuit: I've not seen data to support that (though it's plausable), I don't know how to factor it in.
 47 2015-12-13T03:00:41  <morcos> seems like even more accurate would be to look at number of differet txs in the prevouts
 48 2015-12-13T03:00:50  <phantomcircuit> gmaxwell, the effect is marginal at the moment because of gbt latency
 49 2015-12-13T03:01:33  <gmaxwell> morcos: relay network is responsable for carrying most blocks between miners and its hitrate probably makes a much bigger difference than UTXO cache hitrate.
 50 2015-12-13T03:02:17  <gmaxwell> phantomcircuit: I think it wouldn't be imprudent to just skip any transaciton you've known about for less than a few seconds while constructing a block, and doing so would probably eliminate the effect you're talking about.
 51 2015-12-13T03:02:18  <morcos> so actual bandwidth is a limiting factor then
 52 2015-12-13T03:03:03  <phantomcircuit> gmaxwell, yes
 53 2015-12-13T03:03:19  <gmaxwell> phantomcircuit: though a more intelligent approach would adjust the minimum fee based on how long you've know about it.. the 100BTC fee transaction you take right away. :)
 54 2015-12-13T03:03:46  <morcos> ha.. maybe, or maybe you don't want your block reward lost in a reorg.  :)
 55 2015-12-13T03:04:14  <gmaxwell> hah, okay 100 is a bit high for that example.
 56 2015-12-13T03:04:22  <morcos> i think spending some time thinking about this is a good idea
 57 2015-12-13T03:04:27  <morcos> maybe we don't find any serious concerns
 58 2015-12-13T03:04:51  <morcos> but with the halvening coming up..  it might make things matter that didn't use to
 59 2015-12-13T03:05:34  <phantomcircuit> gmaxwell, yes but that's slightly harder to calculate :)
 60 2015-12-13T03:05:38  <gmaxwell> morcos: the direction I was more thinking in terms was "control stability"; we have variable fees coming in, variable block times.  And then just a max block size wall. It doesn't make for very stable control of the system.
 61 2015-12-13T03:06:05  <morcos> yeah i guess thats what i'm not following
 62 2015-12-13T03:06:16  <morcos> i think that maybe thats true looking at a very short time frame
 63 2015-12-13T03:06:45  <morcos> but the whole point is the block time variability is what lets you pay less for slower confirmation
 64 2015-12-13T03:06:57  <morcos> or are you thinking with respect to block size limits
 65 2015-12-13T03:07:20  <morcos> like if we were to increase them, maybe we don't either by consensus or default inrease them as much when they are in quick succession
 66 2015-12-13T03:07:55  <morcos> i guess thats hard to do by consensus
 67 2015-12-13T03:08:07  <phantomcircuit> gmaxwell, unfortunately the way to fix that is convoluted and a hard fork
 68 2015-12-13T03:08:11  <gmaxwell> My thoughts really aren't clear on where to go from this; but the observation is that the old fee scheme provided backpressure.
 69 2015-12-13T03:08:24  <phantomcircuit> adjust the max block size based on the timestamp (oh and can/will be manipulated by miners)
 70 2015-12-13T03:09:18  <morcos> i guess the way i imagine the system is we should assume that blocks will always be 100% full
 71 2015-12-13T03:09:23  <gmaxwell> in a way that was more gradual that "is load currently over limit yes/no"?
 72 2015-12-13T03:09:32  <gmaxwell> morcos: yes, we should. I agree, long run.
 73 2015-12-13T03:10:19  <gmaxwell> but at the region where we don't quite have enough transaction load paying fees which are high enough to discourage abuse or even high enough to be rational to mine, I think there is a stability problem.
 74 2015-12-13T03:10:36  <gmaxwell> Maybe it's just short term and we shouldn't worry about it.
 75 2015-12-13T03:11:42  <gmaxwell> Part of why I brought up that miners now widely mine txn that are almost certantly irrational to mine was basically to make an argument that we probably could do something that lowered incomes slightly but improved stability.
 76 2015-12-13T03:12:05  <gmaxwell> (and, ultimately, some later dynamic blocksize maximum could make that stability promoting behavior also the income maximizing one)
 77 2015-12-13T03:12:07  <morcos> yeah thats the way i'd look at it, the instability is in the super low fee/free tx region which are essentially bonus anyway.  for fee payign txs, they are super stable now.
 78 2015-12-13T03:12:31  <gmaxwell> Okay, I agree with that.
 79 2015-12-13T03:12:32  <morcos> but maybe i'm not understanding stability of what
 80 2015-12-13T03:13:14  <morcos> hmm
 81 2015-12-13T03:13:19  <morcos> yeah so if you're a miner
 82 2015-12-13T03:13:29  <gmaxwell> Basically the system currently encourages you to play block arrival time chicken. Pay massively low fees, get mined fast. hurray!  ... next time, mined slowly "Boo bitcoin is broken!"
 83 2015-12-13T03:13:49  <phantomcircuit> gmaxwell, what's the formula you were saying governs the maximum feerate a miner should include?
 84 2015-12-13T03:14:02  <morcos> you could sabotage other miners by feeding them and only them a bunch of txs which will make their blocks slower to mine..  but i guess they'd relay those txs themselves
 85 2015-12-13T03:15:02  <morcos> i'm very curious to see if your stratum timings change by much after 0.12
 86 2015-12-13T03:15:06  *** bawong has quit IRC
 87 2015-12-13T03:16:46  <gmaxwell> phantomcircuit: assuming all miners, all transactions are equal.  marginal cost in btc/kb for byte N in a block is ...
 88 2015-12-13T03:16:50  <gmaxwell> 16:03 < gmaxwell> In any case, formula for marginal feerate in order to overcome subsidy loss; there are an infinite numbe
 89 2015-12-13T03:16:53  <gmaxwell> r of tiny miners who all have the same constant and size sensitive delays is (41.6623*e^(((-0.00166649*size)/bytes_per_sec
 90 2015-12-13T03:16:56  <gmaxwell> )-0.00166649*delay_sec))/bytes_per_sec    (this is just the derivative of the orphaning cost for a given size/delay/bandwi
 91 2015-12-13T03:16:59  <gmaxwell> dth assuming 600s blocks)
 92 2015-12-13T03:17:02  <gmaxwell> 16:04 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Quit: ZNC - http://znc.sourceforge.net]
 93 2015-12-13T03:17:05  <gmaxwell> 16:07 < gmaxwell> (thats for btc per 1000 bytes, which is usually the unit we use for fees)
 94 2015-12-13T03:17:08  <gmaxwell> 16:08 < gmaxwell> For 2.491s/90415 bytes/s which were the straum observed measurements; this function is nearly linear in the domain 0-1mb, 0.0004588 to 0.000450 BTC/kb.
 95 2015-12-13T03:17:32  <gmaxwell> phantomcircuit: it's jut taking the probablity that a block was found before you, given an amount of dealy * 25 btc.
 96 2015-12-13T03:17:50  <gmaxwell> and taking the derivative of it.
 97 2015-12-13T03:18:35  <morcos> when you say block found before you, what does that mean
 98 2015-12-13T03:18:35  <phantomcircuit> and of course if you s/25/0/ it's "build infinite blocks"
 99 2015-12-13T03:18:42  <morcos> that you would have lost the orphan race?
100 2015-12-13T03:18:52  <morcos> or are you not taking that into account
101 2015-12-13T03:18:57  <gmaxwell> morcos: they should be; patrick has a stratum server running 0.12 and it's pretty much the fastest stratum server except f2pool mines a block.
102 2015-12-13T03:19:20  <gmaxwell> morcos: that you would have lost an orphan race.
103 2015-12-13T03:20:03  <gmaxwell> that figure ignores the fees taken so far; but I thought it was fine to do so consider how small they usually are.
104 2015-12-13T03:20:18  <phantomcircuit> gmaxwell, it's roughly the same speed when run with the "empty blocks first" patch
105 2015-12-13T03:20:30  <morcos> 2.5 sec seems like so many
106 2015-12-13T03:20:40  <phantomcircuit> i mean 0.11.2 is
107 2015-12-13T03:20:45  <phantomcircuit> forgot words there
108 2015-12-13T03:21:29  <morcos> if you're somehow aware another block has been found in less than that
109 2015-12-13T03:21:30  <morcos> oh
110 2015-12-13T03:21:32  <morcos> interesting
111 2015-12-13T03:21:45  <morcos> nvm, i guess invs tell you it was a block, i was thinking you didn't know that
112 2015-12-13T03:22:08  <phantomcircuit> warmcache rpc + empty blocks results in basically instantly returning a new template
113 2015-12-13T03:22:21  <morcos> yeah so you get a block inv.  for the next XX ms you should switch your mining hardware to mine an empty block
114 2015-12-13T03:22:31  <morcos> until you at least have th headers or block to build off of for the next one
115 2015-12-13T03:22:44  <morcos> that way if you happen to find a block you might beat out the other guy
116 2015-12-13T03:22:57  <phantomcircuit> morcos, the empty block patch isn't spv/stratum "verification"
117 2015-12-13T03:23:14  <morcos> yeah i'm suggesting a different kind of empty block
118 2015-12-13T03:23:15  <phantomcircuit> you actually verify the previous block and then simply short circuit getblocktemplate to return an empty transactions list
119 2015-12-13T03:23:27  <morcos> you're aware a block has been found, but not even the headers for it yet
120 2015-12-13T03:23:38  <phantomcircuit> i can think of at least a few reasons that doing that is a bad idea :)
121 2015-12-13T03:23:38  <morcos> you mine empty block on the old tip, so if you happen to find one
122 2015-12-13T03:23:47  <morcos> you have a chance of winning the orphan race
123 2015-12-13T03:23:52  <phantomcircuit> "hey morcor i found a new block!"
124 2015-12-13T03:24:01  <morcos> yes yea
125 2015-12-13T03:24:17  <phantomcircuit> repeat every 1 second
126 2015-12-13T03:24:20  <morcos> but worst case is you give up fees which are small anyway
127 2015-12-13T03:24:32  <morcos> anyway, in direct headers announcement
128 2015-12-13T03:24:44  <morcos> you'll have the header so they coudln't do that
129 2015-12-13T03:24:57  <morcos> and if you don't want to validationless mine
130 2015-12-13T03:25:05  <morcos> whatever its an over optimization
131 2015-12-13T03:25:08  <morcos> but 2.5 seconds!
132 2015-12-13T03:25:13  <morcos> just craz
133 2015-12-13T03:25:14  <morcos> y
134 2015-12-13T03:25:40  <phantomcircuit> morcos, huh?
135 2015-12-13T03:25:55  <gmaxwell> Yea, it's surprisingly high but there are many sources of latency.
136 2015-12-13T03:25:58  <phantomcircuit> morcos, without fully optimizing im currently 1 second behind f2pool
137 2015-12-13T03:26:19  <morcos> ok so help me understand that
138 2015-12-13T03:26:21  <phantomcircuit> im certain i can reduce that more
139 2015-12-13T03:26:27  <morcos> why?
140 2015-12-13T03:26:48  <morcos> f2pool is mining on top of a valid PoW header as soon as they have it?
141 2015-12-13T03:26:49  <phantomcircuit> speed of light beijing to montreal for one
142 2015-12-13T03:27:03  <morcos> lot less than 1 sec!
143 2015-12-13T03:27:17  <phantomcircuit> another few hundred ms for TestBlockValidity
144 2015-12-13T03:27:31  <phantomcircuit> (less with the empty blocks patch)
145 2015-12-13T03:27:33  <gmaxwell> The switch to empty blocks to optimize the race on the tip may not be so interesting just given how long it takes to retask hardware.
146 2015-12-13T03:27:41  <morcos> ah, right two validations, you have to validate the new block, and your template
147 2015-12-13T03:27:50  <gmaxwell> yea, f2pool will mine without validating at all.
148 2015-12-13T03:28:17  <phantomcircuit> gmaxwell, afaik there's no good reason for the switching time to be so high
149 2015-12-13T03:28:23  <morcos> i think whoever was trying to patch to move TBV out of path has a good idea
150 2015-12-13T03:28:37  <gmaxwell> I agree.
151 2015-12-13T03:28:37  <phantomcircuit> the only hardware i ever directly wrote drivers for switched in 40ms max
152 2015-12-13T03:28:38  <morcos> no reason for it to be in path, if it fails you're screwed anyway, might as well find out 30 sec later
153 2015-12-13T03:29:06  <gmaxwell> that was lightsword.  It does create a little more risk for other users of the network, but I think its acceptable.
154 2015-12-13T03:29:27  <phantomcircuit> morcos, huh? if TBV fails you're not screwed
155 2015-12-13T03:29:42  <gmaxwell> (because you might create an invalid block; and it might escape your infrastructure and get handed to a SPV client.. but .. oh well, hardware/software faults can do that)
156 2015-12-13T03:29:52  <morcos> phantomcircuit: i've been trying to understand how that works in practice
157 2015-12-13T03:30:21  <phantomcircuit> morcos, any competently written pool software gets block templates from multiple bitcoind nodes
158 2015-12-13T03:30:30  <morcos> right ok
159 2015-12-13T03:30:41  <morcos> and they are presumably running different code? (they should!)
160 2015-12-13T03:30:55  <tulip> most seem to share code to some degree.
161 2015-12-13T03:30:59  <phantomcircuit> i'd bet 99% of people are running identical code
162 2015-12-13T03:31:02  <morcos> and if one fails then it just fails over to using the other one?
163 2015-12-13T03:31:02  <gmaxwell> he means the different nodes.
164 2015-12-13T03:31:16  <morcos> right, i mean .11.2 and .12.0
165 2015-12-13T03:31:22  <tulip> what's a failure?
166 2015-12-13T03:31:35  <gmaxwell> Eligius has done that in the past, I'm not aware of anyone else doing that. Many large miners replicate their setup and upgrade in chunks but don't have smart failover.
167 2015-12-13T03:31:43  <phantomcircuit> morcos, i cant answer that definitely but they should be
168 2015-12-13T03:31:49  <tulip> if two software versions turn out to be consensus incompatible a failover is sort of hard to put into logic.
169 2015-12-13T03:31:54  <gmaxwell> Our software reliablity is greater than their planning horizon. :)
170 2015-12-13T03:32:01  <phantomcircuit> (which is also a good reason for soft forks to be backported btw)
171 2015-12-13T03:32:23  <gmaxwell> Luke added the block proposal support so he could test daemon's block templates against each other.
172 2015-12-13T03:32:30  <phantomcircuit> tulip, a TBV failure is 99% a mempool problem
173 2015-12-13T03:32:36  <gmaxwell> But I'm not aware of any other pools using it.
174 2015-12-13T03:32:55  <morcos> tulip: testblockvalidity failing means there is an error in block assembly logic, and its the fact that the consensus code is not borken that makes TBV say hey, this block is invalid
175 2015-12-13T03:33:18  *** moli has joined #bitcoin-core-dev
176 2015-12-13T03:33:46  <morcos> if your mining software connected to .11.2 and .12.0   would it be smart enough to always get the new tip fast ala the .12.0 node or would you lose some of the speed advantages by having multiple?
177 2015-12-13T03:33:54  <morcos> i guess maybe .11.2 could just be failover
178 2015-12-13T03:34:26  <gmaxwell> morcos: right, which requires the 0.12 to stop if it fails; rather than, e.g. continue giving bad results and whining in logs.
179 2015-12-13T03:34:51  <morcos> to be clear, i'm not particularly concerned that there is a bug in 0.12.0.  but i think that now we've changed the logic to require mempool consistency.  its inevitable that at some point in the future it'll have a bug
180 2015-12-13T03:35:03  <gmaxwell> We've had consistency bugs in the past.
181 2015-12-13T03:35:04  <morcos> hopefully one thats unlikely to be hit
182 2015-12-13T03:36:30  *** molz has quit IRC
183 2015-12-13T03:37:44  <gmaxwell> Perhaps we should have all full nodes doing a createnewblock every once in a while.
184 2015-12-13T03:38:12  <gmaxwell> We're probably much less likely to get reports because so few users (and developers) mine.
185 2015-12-13T03:39:28  <morcos> gmaxwell: i think the kind of bug that is most likely is a situation thats rare, such as a reorg that eliminated one sibling of a sequence locked tx whose fee rate was now too low and so would be evicted except RBF blah blah.  and when it happens its just going to happen to everyone.
186 2015-12-13T03:40:27  <morcos> but having developers running at least one full node calling CNB all the time is worthwhile
187 2015-12-13T03:40:35  <morcos> i've been doing that for a couple months now
188 2015-12-13T03:40:37  <phantomcircuit> morcos, probably not since different maxmempool sizes
189 2015-12-13T03:40:57  <phantomcircuit> even with the index usage in cnb in 0.12 i'd still have nodes with tiered max mempools
190 2015-12-13T03:41:00  <gmaxwell> right. but, for example, we discourage mining on git master.  Now I mine on git master (well, 0.12 branch right now); but if there is any system dependency in the bug, I may not see it.
191 2015-12-13T03:41:29  <gmaxwell> we've had bugs that were hit before only with debug options on, plausable we'll have one that is only hit with debug options off.
192 2015-12-13T03:41:29  <phantomcircuit> gmaxwell, that could be part of making CNB run in a background thread continuously
193 2015-12-13T03:42:00  <phantomcircuit> the gbt longpoll stuff does a good job of only running cnb when it's necessary
194 2015-12-13T03:42:02  <morcos> i have a request, i'll direct if at gmaxwell since he runs the project now according to hearn
195 2015-12-13T03:42:11  <phantomcircuit> (although there's a bug there around timing out normal http libs...)
196 2015-12-13T03:42:19  <gmaxwell> phantomcircuit: yea, I think it could just do that for everyone. if you never call getblocktemplate it could just run with a 10 minute timer or whatever.
197 2015-12-13T03:42:34  <morcos> before we can really make CNB run all the time and do many other improvements to the code
198 2015-12-13T03:42:41  <phantomcircuit> gmaxwell, nah you just run it when there's a new block
199 2015-12-13T03:42:45  <morcos> we need to rework the entire locking strategy
200 2015-12-13T03:42:58  <gmaxwell> the locking train wreak you mean? :(
201 2015-12-13T03:43:02  *** arowser has quit IRC
202 2015-12-13T03:43:10  <morcos> exactly
203 2015-12-13T03:43:22  <phantomcircuit> morcos, i suspect that's much more complicated than it initially sounds :P
204 2015-12-13T03:43:32  *** arowser has joined #bitcoin-core-dev
205 2015-12-13T03:43:33  <morcos> we don't have to go to the perfect solution
206 2015-12-13T03:43:43  <gmaxwell> Every time I go to add something where I need to add locking, I go to look to see how other things are locked.  And then I go looking for a bottle of stiff booze (well not really).
207 2015-12-13T03:43:50  <morcos> but someone who is a better developer than i should draw up a road map for us
208 2015-12-13T03:44:26  <morcos> sipa had some good ideas for it, but maybe its not fair to give him every hard project
209 2015-12-13T03:45:12  <gmaxwell> Sipa has been moving in a useful direction in new code, but I think he has not written down the principles that drives that direction enough to make it easy for the rest of us to predict the rest of the path for it.
210 2015-12-13T03:46:00  <morcos> yeah.  i think overall the project would benefit from people working in a team fashion a bit more so workload could be divided.
211 2015-12-13T03:46:17  <morcos> i'm happy to take direction
212 2015-12-13T03:46:33  <morcos> maybe thats always hard to accomplish with open source
213 2015-12-13T03:46:52  <phantomcircuit> gmaxwell, example?
214 2015-12-13T03:47:40  <gmaxwell> phantomcircuit: look how the headers first, download tracking stuff works.
215 2015-12-13T03:47:45  <morcos> i think there is a hesitation for sipa to right down those principles (or anyone else) b/c they don't want to be seen as telling everyone else that this is the way it is
216 2015-12-13T03:47:55  <morcos> s/right/write/
217 2015-12-13T03:47:59  <gmaxwell> "No please tell us what to do!"
218 2015-12-13T03:48:04  <morcos> :)
219 2015-12-13T03:48:13  <phantomcircuit> morcos, the cnb locking can be improved without too much hastle but requires acquiring cs_main and mempool.cs many many more times
220 2015-12-13T03:48:21  <phantomcircuit> im not sure if that's worth it or not
221 2015-12-13T03:48:36  <gmaxwell> I currently have code blocked on "need to fix locking".
222 2015-12-13T03:49:30  <phantomcircuit> there's lots of random stuff where you need partial bits of the chain state but dont actually care if it changes since you're just going to sync against the changes immediately afterwards
223 2015-12-13T03:49:46  <phantomcircuit> createnewblock being the most obvious
224 2015-12-13T03:50:00  <phantomcircuit> there's also the wallet code but that's harder to reason aboue
225 2015-12-13T03:50:02  <phantomcircuit> about*
226 2015-12-13T03:50:13  <morcos> even just connecting a new block
227 2015-12-13T03:50:19  * phantomcircuit goes to look at CNB in master
228 2015-12-13T03:50:40  <phantomcircuit> morcos, lots of things devolve into "make chainstate an mvcc db"
229 2015-12-13T03:50:44  <morcos> once you grab the state... you could release the lock to do all your validation..  and then grab it again to apply
230 2015-12-13T03:50:46  <phantomcircuit> but complexity kills
231 2015-12-13T03:50:53  <morcos> if the tip changed int he meantime, abort
232 2015-12-13T03:51:04  <phantomcircuit> well there's things where copying the state is more expensive than the operation itself
233 2015-12-13T03:51:42  <morcos> but connect block already grabs all the state it needs for the script verification threads
234 2015-12-13T03:52:05  <morcos> it just waits for them to complete before flushing the new coinsview back to pcoinstip
235 2015-12-13T03:52:18  <phantomcircuit> morcos, the particular case of the script verification queues is interesting
236 2015-12-13T03:52:26  <morcos> there is no reason not to be accepting txs to your mempool during that time
237 2015-12-13T03:52:48  <phantomcircuit> it should be easy to add another validation state
238 2015-12-13T03:52:57  <morcos> as you only care about the old state consistency until the new state is applied and then you clean out the mempool for things which can't be there at that time anyway
239 2015-12-13T03:53:06  <phantomcircuit> i tried but haven't touched that code enough to be confident it would work
240 2015-12-13T03:53:27  <morcos> what do you mean another validation state?
241 2015-12-13T03:53:39  <phantomcircuit> if we acquire the same lock twice in the same thread is that going to context switch?
242 2015-12-13T03:53:44  <phantomcircuit> or deadlock?
243 2015-12-13T03:54:00  <phantomcircuit> actually it's going to deadlock since they're not reentrant
244 2015-12-13T03:54:09  <morcos> they are, which locks?
245 2015-12-13T03:54:11  <phantomcircuit> morcos, "i've validated everything except the scripts"
246 2015-12-13T03:54:39  <phantomcircuit> oh is cs_main reentrant?
247 2015-12-13T03:54:43  <morcos> obviously to call ATMP and connect block concurrently you'd need to redesign the threads as well, since they're both almost always called by the same one
248 2015-12-13T03:54:59  <phantomcircuit> oh they are
249 2015-12-13T03:55:17  <morcos> ha, yeah, its pretty rare people bother to do assert_lock_held instead of just calling LOCK again
250 2015-12-13T04:01:03  <phantomcircuit> do you need cs_main to use a CBlockIndex*
251 2015-12-13T04:01:16  <phantomcircuit> ie chainActive.Tip() ?
252 2015-12-13T04:03:19  <phantomcircuit> (im going to assume yes)
253 2015-12-13T04:04:31  <morcos> thats the interesting question
254 2015-12-13T04:04:34  <morcos> for the most part no
255 2015-12-13T04:05:04  <phantomcircuit> morcos, it mostly doesn't matter actually
256 2015-12-13T04:05:23  <phantomcircuit> it looks like you only need chainActive.Tip() for a small fraction of CNB runtime
257 2015-12-13T04:05:40  <phantomcircuit> gmaxwell, do you know off hand the rough latency of LOCK(cs_main) ?
258 2015-12-13T04:06:15  <morcos> phantomcircuit: remember if you lock it multiple times you're going to slow down the function b/c it'll have to keep waiting on the locks
259 2015-12-13T04:07:11  <phantomcircuit> morcos, im going to change fBuildEmptyBlock to fNewBlock
260 2015-12-13T04:07:22  <phantomcircuit> and change the locking strategy based on that
261 2015-12-13T04:07:41  <morcos> are you referring to some existing PR
262 2015-12-13T04:08:49  <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/7104
263 2015-12-13T04:10:47  <phantomcircuit> morcos, in general though i think we should be willing to give up the lock in CNB to allow for a new tip
264 2015-12-13T04:11:35  <phantomcircuit> right now there's a problem where CNB can stall validating a new tip
265 2015-12-13T04:12:37  <phantomcircuit> although this isn't in practice a huge problem since you reduce the average latency by n if you run n nodes
266 2015-12-13T04:12:44  <phantomcircuit> divide*
267 2015-12-13T04:12:56  <morcos> phantomcircuit: agreed, thats a problem.  but for now the non TBV part of CNB is fast enough that if we just solve for TBV that would be enough.
268 2015-12-13T04:16:32  <phantomcircuit> morcos, we could run TBV without signature checking but everything being checked has is probably in sigcache
269 2015-12-13T04:16:39  <phantomcircuit> so i dont see that making a huge difference
270 2015-12-13T04:17:35  <Luke-Jr> TBV shouldn't be slow..
271 2015-12-13T04:21:24  <GitHub0> [bitcoin] pstratem opened pull request #7203: Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
272 2015-12-13T04:21:32  <phantomcircuit> (note i haven't tested that PR like at all)
273 2015-12-13T04:26:51  *** laurentmt has joined #bitcoin-core-dev
274 2015-12-13T04:27:02  *** laurentmt has quit IRC
275 2015-12-13T04:46:33  <morcos> phantomcircuit: ha, just thought of this.  when we call ConnectBlock from TBV we call it with fJustCheck.
276 2015-12-13T04:46:58  <morcos> We should be able to release cs_main before control.Wait()
277 2015-12-13T04:47:15  <morcos> so we don't have to wait for script verificaiton threads to finish with cs_main locked
278 2015-12-13T04:47:31  <morcos> not sure exactly how much time that would save in general, but seems like a super easy win
279 2015-12-13T04:51:30  <phantomcircuit> morcos, probably not much, remember that all the transactions being checked are already in sigcache
280 2015-12-13T04:59:36  *** tripleslash has joined #bitcoin-core-dev
281 2015-12-13T05:07:36  <sipa> phantomcircuit: not guaranteed :)
282 2015-12-13T05:10:19  <phantomcircuit> sipa, it is when you run with the sigcache size i do :P
283 2015-12-13T05:21:57  <gmaxwell> BlueMatt: have any way to estimate how long it takes for a transaction to reach all the relay node clients?
284 2015-12-13T05:37:21  *** bawong has joined #bitcoin-core-dev
285 2015-12-13T05:42:35  *** bawong has quit IRC
286 2015-12-13T06:04:57  <Luke-Jr> blah, gitian needs trusty now and that needs a vmbuilder upgrade :<
287 2015-12-13T06:15:26  <tulip> that's weird, somehow my node has got into a state where it has fallen behind the chain.
288 2015-12-13T06:15:42  <Luke-Jr> tulip: debug.log?
289 2015-12-13T06:15:45  <tulip> "chain":"main","blocks":388132,"headers":388135
290 2015-12-13T06:16:16  <tulip> Luke-Jr: nothing interesting, no rejects or invalid blocks, it's just chilling.
291 2015-12-13T06:16:32  <Luke-Jr> tulip: for how long?
292 2015-12-13T06:16:41  <phantomcircuit> tulip, getpeerinfo
293 2015-12-13T06:16:49  <phantomcircuit> i bet you're waiting for a peer to send you a block
294 2015-12-13T06:17:51  <tulip> phantomcircuit: woo, there we go. socket timed out, and suddenly we're back at the tip after 26 minutes behind.
295 2015-12-13T06:18:23  <phantomcircuit> tulip, and that's why my gbt nodes connect to trusted nodes and the relaynetwork only
296 2015-12-13T06:18:32  <tulip> sorry, an hour and 3 minutes behind.
297 2015-12-13T06:19:13  <CodeShark>  it takes over an hour to timeout a block request?!?!
298 2015-12-13T06:19:28  <gmaxwell> no, it takes 20 minutes.
299 2015-12-13T06:19:39  <gmaxwell> but if you have multiple screwball peers you might time out more than once.
300 2015-12-13T06:19:53  <gmaxwell> I know how to make it safely dynamic but haven't had a chance to implement it.
301 2015-12-13T06:21:06  <gmaxwell> My thought for making it dynamic: start with the 20m timeout. When you sucessfully fetch a block measure how long the getdata took, extrapolate that to 1MB *2. Set the timeout to that.
302 2015-12-13T06:21:46  <gmaxwell> Any time you kick a peer off for timing out, increase the timeout (1.5x?).
303 2015-12-13T06:22:11  <gmaxwell> This should be safe and result in quite low timeouts for most peers most of the time.
304 2015-12-13T06:22:25  <Luke-Jr> sounds gameable by hostile peers
305 2015-12-13T06:23:05  <tulip> screwy network conditions caused this one but with alarmingly high amount of time where it sat knowing headers it couldn't update to.
306 2015-12-13T06:23:49  <Luke-Jr> keep connecting to your victim, and try to increase the timeout to a few days.. then trap real blocks, as you feed competing ones over a separate connection
307 2015-12-13T06:24:01  <gmaxwell> Luke-Jr: Explain, because I think it's not usefully gamable (except by constant factors)
308 2015-12-13T06:24:15  <gmaxwell> Luke-Jr: oh I assumed the timeout would still be capped at 20 minutes.
309 2015-12-13T06:24:21  <Luke-Jr> oh, ok then
310 2015-12-13T06:24:24  <gmaxwell> Beyond that, if you're actually that slow, you have no hope of keeping up with the network.
311 2015-12-13T06:24:54  <CodeShark> in that case, shouldn't 10 min be the cap?
312 2015-12-13T06:25:09  <Luke-Jr> CodeShark: nah, your connection might be bursty
313 2015-12-13T06:25:14  <gmaxwell> CodeShark: No, because ^
314 2015-12-13T06:25:22  <gmaxwell> there should be some headroom.
315 2015-12-13T06:25:57  <Luke-Jr> might be reasonable to do some magic before the calibration though
316 2015-12-13T06:26:18  <Luke-Jr> eg, if you don't get any traffic on the block within ~30 seconds, start getting it from another peer too and kick one if both start sending
317 2015-12-13T06:26:31  <CodeShark> that's what I was sorta thinking
318 2015-12-13T06:26:53  <Luke-Jr> otoh, a hostile actor may try to trickle it to you just to keep you downloading as slow as possible
319 2015-12-13T06:26:57  <tulip> Luke-Jr: something is a bit ambiguous, if I want to slow you down I'll just send a byte a second.
320 2015-12-13T06:27:31  <Luke-Jr> tulip: yeah
321 2015-12-13T06:27:35  <gmaxwell> Yea, that requires low level visibility that we don't really have right now.
322 2015-12-13T06:27:38  <CodeShark> I was thinking we try from different peers and try to use the best one available - if one starts getting slow, we try others
323 2015-12-13T06:28:09  <gmaxwell> CodeShark: requires having a concept of what 'slow' means, _and_ having sub-message visibility, .
324 2015-12-13T06:28:39  <CodeShark> yes, we could check the buffer before we complete the download to get an estimate of the datarate
325 2015-12-13T06:28:48  <gmaxwell> When we start the block fetch, there is always only one available (the first).
326 2015-12-13T06:29:21  <CodeShark> we could also download multiple blocks in parallel from different peers when measuring download rate to not waste bandwidth
327 2015-12-13T06:30:48  <Luke-Jr> CodeShark: fancy!
328 2015-12-13T06:31:06  <Luke-Jr> but definitely more complicated to implement:P
329 2015-12-13T06:31:16  <phantomcircuit> gmaxwell, has anybody analyzed how restrictions in bandwidth effect the probability that there has been a fork that you've not seen?
330 2015-12-13T06:31:17  <gmaxwell> well there is only one block on the tip!
331 2015-12-13T06:31:31  <phantomcircuit> i guess you'd see headers
332 2015-12-13T06:46:12  <tulip> do nodes actually forward headers like that?
333 2015-12-13T06:46:34  <CodeShark> sync on core is headers-first
334 2015-12-13T06:46:50  <CodeShark> which means you can validate PoW before downloading any actual blocks
335 2015-12-13T06:47:13  <tulip> sure, but do nodes actively forward headers of blocks they don't believe to be the main chain
336 2015-12-13T06:47:33  <CodeShark> oh, not that I'm aware of ;)
337 2015-12-13T06:47:34  <CodeShark> not yet
338 2015-12-13T06:48:31  <CodeShark> it's really expensive to create a competing chain that is invalid...so chances of such a chain growing long are low (unless something is fundamentally broken)
339 2015-12-13T06:48:49  <Luke-Jr> tulip: if those nodes are attacking you, they do :D
340 2015-12-13T06:49:07  <tulip> not invalid, just not best
341 2015-12-13T06:49:29  <CodeShark> such chains tend to die quickly
342 2015-12-13T06:50:21  <CodeShark> the main threat with headers sync is the isolation attack
343 2015-12-13T06:52:56  <CodeShark> having said that, it would be nice to have better fork detection capabilities...as in knowing that hashrate has forked
344 2015-12-13T06:53:20  <CodeShark> which means something is fundamentally broken ;)
345 2015-12-13T06:53:48  <tulip> forwarding all headers, always would be nice.
346 2015-12-13T06:54:17  <tulip> that likely breaks assumptions though, I think the current p2p network assumes that if you inv a block you actually have it.
347 2015-12-13T06:57:15  <CodeShark> wasn't it suggested before that we stop inving blocks and just send block headers?
348 2015-12-13T06:57:25  <gmaxwell> We could add a message that says "here is a header, but I don't have the block" but then you have to send a "I have the block" later.
349 2015-12-13T06:57:40  <gmaxwell> CodeShark: yes, we do that now. but then the header is just the inv. :)
350 2015-12-13T07:01:58  <CodeShark> we could just add a flag to the headers message
351 2015-12-13T07:02:04  *** davec_ has quit IRC
352 2015-12-13T07:02:57  <CodeShark> might be a good idea to start versioning the p2p serialization structures separately from the client version and the consensus structure versions :)
353 2015-12-13T07:04:02  <CodeShark> and to stop treating blocks as subclasses of block headers ;)
354 2015-12-13T07:04:45  <gmaxwell> Versioning suggests linear progressions. :)
355 2015-12-13T07:05:13  <CodeShark> versionbits for p2p? ;)
356 2015-12-13T07:07:42  <CodeShark> the alternative is to just name the new p2p structures something else...which perhaps might be simpler in the end
357 2015-12-13T07:09:41  <CodeShark> better fork detection would be a wonderful thing, though
358 2015-12-13T07:11:39  <Luke-Jr> uh so
359 2015-12-13T07:11:43  <Luke-Jr> I can no longer gitian-build :/
360 2015-12-13T07:11:48  <Luke-Jr> vmbuilder fails on trusty
361 2015-12-13T07:11:58  <Luke-Jr> what vmbuilder did other people here use?
362 2015-12-13T07:13:01  <CodeShark> we could go beyond just "here is a header, but I don't have the block" - we could do "here's a header, I checked the block and it is invalid"
363 2015-12-13T07:13:08  <gmaxwell> gavinandresen: Hi. I'm concerned that I keep hearing reports of you taking actions on behalf of Bitcoin Core while not actually communicating with anyone involved in the project, or being involved yourself. I wasn't sure of how much of this was rumor or miscommunication, but this appears to be you directly confirming it:
364 2015-12-13T07:13:20  <gmaxwell> gavinandresen: https://www.reddit.com/r/btc/comments/3wj0du/gavin_we_want_to_donated_to_you/cxwx4hx
365 2015-12-13T07:17:58  <GitHub178> [bitcoin] pstratem closed pull request #7203: [WIP][Mining]Release cs_main in CreateNewBlock while selecting transactions from mempool. (master...2015-12-12-createnewblocklocks) https://github.com/bitcoin/bitcoin/pull/7203
366 2015-12-13T07:18:03  <GitHub101> [bitcoin] pstratem closed pull request #7150: Print size of pcoinsTip cache in AcceptToMemoryPool (master...2015-12-1-printcachesize) https://github.com/bitcoin/bitcoin/pull/7150
367 2015-12-13T07:18:04  <GitHub115> [bitcoin] pstratem closed pull request #7104: [Mining] Build empty block on when chainTip changes. (master...2015-11-26-gbt-latency) https://github.com/bitcoin/bitcoin/pull/7104
368 2015-12-13T07:18:09  <GitHub150> [bitcoin] pstratem closed pull request #7071: Wallet: Replace TxnAbort with assert. (master...2015-11-20-wallet-activetxn) https://github.com/bitcoin/bitcoin/pull/7071
369 2015-12-13T07:18:13  <GitHub44> [bitcoin] pstratem closed pull request #7064: [Wallet]Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
370 2015-12-13T07:18:15  <GitHub180> [bitcoin] pstratem closed pull request #7057: Wallet: Flush database to log files (master...2015-11-18-wallet-flush) https://github.com/bitcoin/bitcoin/pull/7057
371 2015-12-13T07:18:24  <GitHub101> [bitcoin] pstratem closed pull request #6874: Net: Cork socket send writes (master...msg_more) https://github.com/bitcoin/bitcoin/pull/6874
372 2015-12-13T07:18:38  * Luke-Jr pokes phantomcircuit
373 2015-12-13T07:18:39  <phantomcircuit> i wont be contributing to core anymore until the license is changed to prevent my work from being used by dickbags making backroom deals
374 2015-12-13T07:18:52  <Luke-Jr> …
375 2015-12-13T07:19:13  <Luke-Jr> phantomcircuit: you really think Core is going to become non-free software?
376 2015-12-13T07:19:42  <phantomcircuit> Luke-Jr, no but i can certainly stop contributing
377 2015-12-13T07:20:11  <Luke-Jr> phantomcircuit: you can, but all it's going to do is increase everyone else's workload :/
378 2015-12-13T07:20:39  <GitHub38> [bitcoin] pstratem closed pull request #6943: Wallet: Store hash for encrypted keys (master...ckey_hash) https://github.com/bitcoin/bitcoin/pull/6943
379 2015-12-13T07:20:51  <Luke-Jr> what's the point in making an ultimatum that you know cannot be met?
380 2015-12-13T07:21:35  *** Tera2342 has joined #bitcoin-core-dev
381 2015-12-13T07:21:54  <phantomcircuit> Luke-Jr, the license can be changed to prevent specific people from using the code
382 2015-12-13T07:22:10  <gmaxwell> phantomcircuit: I share your irritation, but you don't need to go pyrric on this; we'll take care about it.
383 2015-12-13T07:22:14  <gmaxwell> er take care of it. :)
384 2015-12-13T07:22:16  <Luke-Jr> phantomcircuit: not without it becoming non-free software, in which case I will have to quit Core and fork it.
385 2015-12-13T07:22:32  <btcdrak> gmaxwell: it's time we boot gavinandresen
386 2015-12-13T07:23:34  <btcdrak> gavinandresen: you dont contribute to Bitcoin Core just to creating chaos. While others might be more polite, I'm going right ahead and saying this, please go away, you are not wanted here.
387 2015-12-13T07:25:19  <gmaxwell> phantomcircuit: that people can take our work and use it in other projects is an important safty valve that guards against our own error, and frees us from having to accomidate every wish and desire; without creating lock in should we misstep.
388 2015-12-13T07:25:44  <gmaxwell> phantomcircuit: so I think precluding people from exploiting out work, as 'just' and satisifying as it would be is not a good forward path.
389 2015-12-13T07:27:10  <gmaxwell> s/out/our/
390 2015-12-13T07:28:22  <CodeShark> if phantomcircuit is specifically referring to actions taken by someone on "behalf" of Bitcoin Core, I think the policy needs to be specifically directed at that...and we need to come out with one voice saying that someone doesn't represent Bitcoin Core
391 2015-12-13T07:29:01  <Luke-Jr> I certainly wouldn't object to a joint statement. Changing the license to non-free is a big no-no IMO though.
392 2015-12-13T07:29:02  <CodeShark> as to what the action could be, I'll leave that open to interpretation for now in the interest of being slightly more diplomatic than btcdrak
393 2015-12-13T07:30:52  <gmaxwell> I really can't take the stress of the non-cooperative, backroom dealing, dram production and the attempts to undermine collaborative work anymore.
394 2015-12-13T07:31:21  <gmaxwell> To say that I'm fed up with it would be an understatement, and attempts to address it in private have failed.
395 2015-12-13T07:32:05  <midnightmagic> what is bitcoin's licence anyway.. mit/bsd?
396 2015-12-13T07:32:09  <Luke-Jr> midnightmagic: yes
397 2015-12-13T07:32:44  <midnightmagic> in magical parallel universe able-to-contact-everyone land, you could change it to gplv3
398 2015-12-13T07:33:05  <Luke-Jr> midnightmagic: we could change it easily. MIT is relicensable to GPLv3
399 2015-12-13T07:33:14  <Luke-Jr> but that wouldn't do what phantomcircuit is asking
400 2015-12-13T07:33:41  <midnightmagic> mm. I don't think it is. That is, the original copyright is not alterable: only the copyright of modifications going forward, and those of people whom you've contacts and who agree in writing.
401 2015-12-13T07:33:41  <gmaxwell> MIT is a reasonable choice for the basic infrastructure. Not having it that way would just encourage the creation of alternatives just for licensing sake, which would be preferable to avoid.
402 2015-12-13T07:34:44  <btcdrak> gmaxwell: I dont think relicensing is the solution. I also dont think gavinandresen has a hope in hell gaining traction. XT was total failure and adoption of a hostile fork has been ruled out by miners and most major exchanges.
403 2015-12-13T07:34:46  <aj> Luke-Jr: Affero GPL with code added to dump the running node's source via an RPC call could be hilarious though (iirc Affero GPL would prevent you from disabling/removing that feature)
404 2015-12-13T07:34:53  <Luke-Jr> midnightmagic: only the new code going forward can be relicensed in any case; even if the old code were offered under a new license, the MIT license remains valid for it
405 2015-12-13T07:35:13  <Luke-Jr> aj: it would need to be over p2p, not RPC
406 2015-12-13T07:35:23  <Luke-Jr> aj: Eloipool uses it
407 2015-12-13T07:35:28  <aj> Luke-Jr: quite right
408 2015-12-13T07:35:36  <Luke-Jr> (and will dump its code over stratum or HTTP)
409 2015-12-13T07:35:40  <gmaxwell> midnightmagic: phantomcircuit is unhappy that people who seem to be openly working against his own efforts trade on his work, and the name of the project. This is a downside of free software, but it's minor compared to the benefits.
410 2015-12-13T07:36:04  <aj> Luke-Jr: easier to get at source for a python program than a c++ one too
411 2015-12-13T07:36:27  <Luke-Jr> we could rename the project and enforce it as a trademark..
412 2015-12-13T07:37:18  <btcdrak> Luke-Jr: "Bitcoin Core" as a phrase is probably trademarkable, but I really dont see the benefit.
413 2015-12-13T07:37:23  <midnightmagic> gmaxwell: The number of netbsd core developers who have expressed raging bitterness just to me in private email that people like broadcomm make millions on their code and don't even contribute their modifications to the original source is more than I can count on one hand. And at the time they wrote me I was a nobody.. :-o
414 2015-12-13T07:37:33  <Luke-Jr> btcdrak: but Hearn coined it
415 2015-12-13T07:37:47  <Luke-Jr> in fact, is that a risk to us?
416 2015-12-13T07:37:51  <gmaxwell> No.
417 2015-12-13T07:37:54  <btcdrak> Luke-Jr: no
418 2015-12-13T07:38:32  <midnightmagic> Does the U.S. have a pre-existing trademark exception rule too?
419 2015-12-13T07:38:40  <midnightmagic> I know Canada does.
420 2015-12-13T07:38:43  <Luke-Jr> midnightmagic: I think the GPL would be a bad choice for node software.
421 2015-12-13T07:39:25  <btcdrak> The solution to gavin is what I said it was back in January when no-one would listen to me >.>
422 2015-12-13T07:39:32  <midnightmagic> Luke-Jr: it would hinder its deployment probably. But, ignoring all that I don't think it's realistic anyway. Mostly navel gazing I guess.
423 2015-12-13T07:39:44  <midnightmagic> btcdrak: I'm listening now. Can you link me?
424 2015-12-13T07:40:41  <midnightmagic> In Canada, if you run a shop with a name of something that was trademarked *after* your use of the term, for as long as you operate you are excepted from trademark infringement. Unless the law has changed. Which is possible, given our recent experiment in neo-fascism.
425 2015-12-13T07:41:05  <btcdrak> We need a technical lobbiest, someone who will go to companies and listen to them and discuss the technology with them. There are other things too, but I wont say them in public.
426 2015-12-13T07:42:03  <midnightmagic> Well that was ideally what the BCF was supposed to do. :-/
427 2015-12-13T07:42:04  <btcdrak> (because they would be used by gavin against us)
428 2015-12-13T07:42:25  <btcdrak> The BCF is a useless train wreck.
429 2015-12-13T07:42:55  <btcdrak> the BCF continues to prop up Gavin with the title "Chief Scientist" which gavin uses to mislead the companies he lobbies.
430 2015-12-13T07:42:58  <Luke-Jr> problem: we are understaffed technically already..
431 2015-12-13T07:43:17  <midnightmagic> I was optimistic (hope springs eternal) but I guess phantomcircuit pretty much called it ages ago when they first published the constitution.
432 2015-12-13T07:44:40  <randy-waterhouse> btcdrak: did you specific companies in mind, or some examples?
433 2015-12-13T07:44:51  <randy-waterhouse> s/did you have/
434 2015-12-13T07:46:50  <btcdrak> randy-waterhouse: no, everyone in general. gavin and mike have gone around telling lies, the only way to counter that is to give taregetted presentations etc.
435 2015-12-13T07:48:18  <Luke-Jr> btcdrak: not just a joint letter saying "you may have been told lies by <people>; we don't know what those lies are, so please take what was said with a grain of salt - we're here to clarify anything"
436 2015-12-13T07:48:21  <Luke-Jr> ?
437 2015-12-13T07:49:21  <btcdrak> Luke-Jr: Yes, we must actively say that. Bitcoin Core devs (as I have said repeatedly in private) are playing into the hands of disruption by being too politically correct and "nice". We need to be prepared to call a spade a spade.
438 2015-12-13T07:49:54  <Luke-Jr> btcdrak: a letter is easier than a presentation, is what I mean.
439 2015-12-13T07:50:06  <btcdrak> Luke-Jr: it's a good start,
440 2015-12-13T07:50:47  <btcdrak> Luke-Jr: if I was a little richer I would pay someone but I have to preserve my funds because of my health situation which is questionable at the moment.
441 2015-12-13T07:51:46  <Luke-Jr> btcdrak: hope your health improves :|
442 2015-12-13T07:52:15  <btcdrak> Luje-Jr: yeah ditto! I wish they would find a diagnosis at least.
443 2015-12-13T08:07:54  *** Ylbam has joined #bitcoin-core-dev
444 2015-12-13T08:30:39  *** molz has joined #bitcoin-core-dev
445 2015-12-13T08:32:35  *** moli has quit IRC
446 2015-12-13T09:02:45  <phantomcircuit> gmaxwell, to be clear i meant changing the license to specifically bar gavin from using the code for any purpose and only gavin
447 2015-12-13T09:02:49  *** moli has joined #bitcoin-core-dev
448 2015-12-13T09:04:10  <gmaxwell> phantomcircuit: pedantically, it would no longer be free software; and doing that would be imposing a huge analysis cost of anyone else using the software; not a good tradeoff.
449 2015-12-13T09:04:15  *** molz has quit IRC
450 2015-12-13T09:11:14  <Luke-Jr> so I rewatched the "poisonous people" talk (and concluded it doesn't seem to fit Gavin FWIW), and two recommendations that stood out as applicable would be 1) having well-defined and specific goals/todo lists leading up to 1.0; 2) we should [when possible] try to have multiple people familiar with each part of the code - so jgarzik's MAINTAINERS file probably should be laid out expecting multiple maintainers for each subsection
451 2015-12-13T09:12:57  <Luke-Jr> I'm not sure either of these are too practical for us, but it might be nice to keep them in the back of our minds
452 2015-12-13T09:17:27  <btcdrak> Luke-Jr: I know wumpus has been planning to slowly increase the number of maintainer for specific areas. The GUI maintainer is a trial. It's part of why https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md was written.
453 2015-12-13T09:19:25  <btcdrak> in the longer term as the goals of breaking Core into sub projects like wallet, consensus and full node, we'll already have the maintainer infrastructure in place.
454 2015-12-13T09:19:25  <Luke-Jr> not sure what you mean by a trial.. it's not the first maintainership thing (wumpus began as GUI maintainer, and I've been mining maintainer for a while; I imagine there are others too)
455 2015-12-13T09:19:40  <btcdrak> trial as in see how it goes for expanding to more maintainers
456 2015-12-13T09:20:42  <btcdrak> maintainer here means people with push access and authority to merge PRs.
457 2015-12-13T09:21:26  <Luke-Jr> that's not a matter of authority.. people with push access are supposed to merge only with appropriate ACKs/NACKs, not on personal decision
458 2015-12-13T09:25:13  <btcdrak> Luke-Jr: yes I know, that's well explained in the referenced document.
459 2015-12-13T09:26:14  <Luke-Jr> btcdrak: on another note, did you manage to do the trusty gitian update?
460 2015-12-13T09:26:30  <btcdrak> Luke-Jr: I dont think English has the right words for this, haha.
461 2015-12-13T09:26:38  <btcdrak> Luke-Jr: ut oh. my mind is blank.
462 2015-12-13T09:26:54  <btcdrak> Luke-Jr: can you refresh my memory?
463 2015-12-13T09:27:13  <Luke-Jr> btcdrak: in the past ~week or so, master upgraded the version of Ubuntu used by gitian to "trusty"
464 2015-12-13T09:27:20  <Luke-Jr> I can't get the base image to build
465 2015-12-13T09:27:38  <btcdrak> Luke-Jr: OK, let me have a go from scratch
466 2015-12-13T09:28:49  <Luke-Jr> worse: it appears to be trying to touch my MBR :|
467 2015-12-13T09:29:30  <Luke-Jr> maybe I'm just being paranoid
468 2015-12-13T09:42:51  <Luke-Jr> hmm https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1037607
469 2015-12-13T10:04:09  <Luke-Jr> seems upgrading gitian-builder fixes it
470 2015-12-13T10:06:06  *** Tera2342 has quit IRC
471 2015-12-13T10:20:54  <btcdrak> Luke-Jr: still setting up my VM. what version of gitian-builder did you use?
472 2015-12-13T10:21:18  <Luke-Jr> before, it was 9d46e26
473 2015-12-13T10:21:24  <Luke-Jr> now f9ab587
474 2015-12-13T10:22:07  *** tripleslash has quit IRC
475 2015-12-13T10:24:55  *** btcdrak has quit IRC
476 2015-12-13T10:25:07  *** corb is now known as JackH
477 2015-12-13T10:26:05  *** zmanian_ has quit IRC
478 2015-12-13T10:27:30  *** CodeShark has quit IRC
479 2015-12-13T10:29:07  *** michagogo has quit IRC
480 2015-12-13T10:40:50  *** tripleslash has joined #bitcoin-core-dev
481 2015-12-13T10:45:10  *** michagogo has joined #bitcoin-core-dev
482 2015-12-13T10:45:38  *** tripleslash has quit IRC
483 2015-12-13T10:46:46  *** CodeShark_ has joined #bitcoin-core-dev
484 2015-12-13T10:47:20  *** CodeShark has joined #bitcoin-core-dev
485 2015-12-13T10:50:01  *** zmanian_ has joined #bitcoin-core-dev
486 2015-12-13T10:50:35  *** btcdrak has joined #bitcoin-core-dev
487 2015-12-13T10:53:19  *** tripleslash has joined #bitcoin-core-dev
488 2015-12-13T10:53:38  *** btcdrak_ has joined #bitcoin-core-dev
489 2015-12-13T10:53:44  *** btcdrak has quit IRC
490 2015-12-13T10:53:45  *** btcdrak_ is now known as btcdrak
491 2015-12-13T10:56:45  *** btcdrak has joined #bitcoin-core-dev
492 2015-12-13T11:34:44  *** s1w- has quit IRC
493 2015-12-13T11:34:44  *** s1w- has joined #bitcoin-core-dev
494 2015-12-13T11:34:53  *** s1w- is now known as s1w
495 2015-12-13T11:55:20  *** randy-waterhouse has quit IRC
496 2015-12-13T12:03:06  *** Tera2342 has joined #bitcoin-core-dev
497 2015-12-13T12:20:09  *** tulip has quit IRC
498 2015-12-13T12:24:26  *** tripleslash has quit IRC
499 2015-12-13T12:32:09  *** tripleslash has joined #bitcoin-core-dev
500 2015-12-13T13:17:30  *** fkhan has quit IRC
501 2015-12-13T13:20:11  *** laurentmt has joined #bitcoin-core-dev
502 2015-12-13T13:22:55  *** laurentmt has quit IRC
503 2015-12-13T13:36:48  *** ParadoxSpiral_ has joined #bitcoin-core-dev
504 2015-12-13T13:40:10  *** ParadoxSpiral has quit IRC
505 2015-12-13T13:57:24  *** Guyver2 has joined #bitcoin-core-dev
506 2015-12-13T14:00:20  <GitHub166> [bitcoin] MarcoFalke opened pull request #7205: Update copyright headers to 2015 (master...MarcoFalke-2015-BumpHeaders-0.12) https://github.com/bitcoin/bitcoin/pull/7205
507 2015-12-13T14:07:02  <btcdrak> Luke-Jr: finally installed virtualbox and build the Gitian VM worked fine with f9ab587 (which is the HEAD when you clone gitian-builder freshly)
508 2015-12-13T14:09:52  <btcdrak> Luke-Jr: the only problem I had was sudo didnt work for me, I had to put a manual entry in the sudoers file for some reason.
509 2015-12-13T14:10:12  *** Tera2342 has quit IRC
510 2015-12-13T14:12:00  <btcdrak> Luke-Jr: 9d46e26 is really old too I see.
511 2015-12-13T14:14:06  *** tripleslash has quit IRC
512 2015-12-13T14:20:00  *** CodeShark has quit IRC
513 2015-12-13T14:20:01  *** CodeShark_ is now known as CodeShark
514 2015-12-13T14:26:37  *** fkhan has joined #bitcoin-core-dev
515 2015-12-13T14:46:15  *** moli has quit IRC
516 2015-12-13T14:49:55  *** moli has joined #bitcoin-core-dev
517 2015-12-13T14:58:29  *** davec has joined #bitcoin-core-dev
518 2015-12-13T15:27:58  *** laurentmt has joined #bitcoin-core-dev
519 2015-12-13T15:31:55  <GitHub92> [bitcoin] smenglish closed pull request #7201: Update hmac_sha256.cpp (master...master) https://github.com/bitcoin/bitcoin/pull/7201
520 2015-12-13T15:46:00  *** jcorgan|away is now known as jcorgan
521 2015-12-13T16:32:08  *** afk11 has joined #bitcoin-core-dev
522 2015-12-13T16:44:57  *** molz has joined #bitcoin-core-dev
523 2015-12-13T16:47:15  *** moli has quit IRC
524 2015-12-13T17:05:22  *** moli has joined #bitcoin-core-dev
525 2015-12-13T17:06:26  *** ParadoxSpiral_ has quit IRC
526 2015-12-13T17:07:35  *** molz has quit IRC
527 2015-12-13T17:08:34  *** molz has joined #bitcoin-core-dev
528 2015-12-13T17:09:55  *** moli has quit IRC
529 2015-12-13T17:17:32  *** MarcoFalke has joined #bitcoin-core-dev
530 2015-12-13T17:24:54  *** bawong has joined #bitcoin-core-dev
531 2015-12-13T17:34:08  *** molz has quit IRC
532 2015-12-13T17:36:38  *** laurentmt has quit IRC
533 2015-12-13T17:44:52  *** moli has joined #bitcoin-core-dev
534 2015-12-13T17:46:24  *** wangchun has quit IRC
535 2015-12-13T18:00:58  *** wangchun has joined #bitcoin-core-dev
536 2015-12-13T18:06:06  *** Ylbam has quit IRC
537 2015-12-13T18:06:33  *** Ylbam has joined #bitcoin-core-dev
538 2015-12-13T18:11:45  *** CodeShark_ has joined #bitcoin-core-dev
539 2015-12-13T18:12:26  *** wangchun_ has joined #bitcoin-core-dev
540 2015-12-13T18:13:27  <BlueMatt> gmaxwell: not really...the privacy policy on bitcoinrelaynetwork.org states no information about tx receive time will be logged, though clients of course are free to do so themselves (as I cant stop them)
541 2015-12-13T18:13:28  *** CodeShark has quit IRC
542 2015-12-13T18:13:28  *** s1w has quit IRC
543 2015-12-13T18:13:29  *** phantomcircuit has quit IRC
544 2015-12-13T18:13:29  *** JackH has quit IRC
545 2015-12-13T18:13:29  *** evoskuil has quit IRC
546 2015-12-13T18:13:29  *** wangchun has quit IRC
547 2015-12-13T18:13:30  *** s1w has joined #bitcoin-core-dev
548 2015-12-13T18:13:30  *** evoskuil has joined #bitcoin-core-dev
549 2015-12-13T18:13:33  <BlueMatt> gmaxwell: so...you can go log that if you want
550 2015-12-13T18:13:40  *** CodeShark_ is now known as CodeShark
551 2015-12-13T18:14:22  *** JackH_ has joined #bitcoin-core-dev
552 2015-12-13T18:17:19  *** phantomcircuit has joined #bitcoin-core-dev
553 2015-12-13T18:20:29  *** evoskuil has quit IRC
554 2015-12-13T18:20:30  *** s1w has quit IRC
555 2015-12-13T18:20:30  *** evoskuil has joined #bitcoin-core-dev
556 2015-12-13T18:20:59  *** s1w- has joined #bitcoin-core-dev
557 2015-12-13T18:26:32  *** evoskuil has quit IRC
558 2015-12-13T18:26:34  *** evoskuil has joined #bitcoin-core-dev
559 2015-12-13T18:35:02  *** laurentmt has joined #bitcoin-core-dev
560 2015-12-13T18:38:37  *** laurentmt has quit IRC
561 2015-12-13T19:12:37  *** raedah has quit IRC
562 2015-12-13T19:13:33  *** raedah has joined #bitcoin-core-dev
563 2015-12-13T19:18:38  *** bawong has quit IRC
564 2015-12-13T19:19:12  *** wangchun_ has quit IRC
565 2015-12-13T19:19:32  *** laurentmt has joined #bitcoin-core-dev
566 2015-12-13T19:19:39  *** wangchun has joined #bitcoin-core-dev
567 2015-12-13T19:19:49  *** laurentmt has quit IRC
568 2015-12-13T19:32:37  *** belcher has joined #bitcoin-core-dev
569 2015-12-13T19:33:54  *** lclc has quit IRC
570 2015-12-13T19:33:56  *** [b__b] has quit IRC
571 2015-12-13T19:33:56  *** guruvan has quit IRC
572 2015-12-13T19:33:56  *** mm_1 has quit IRC
573 2015-12-13T19:33:56  *** pigeons has quit IRC
574 2015-12-13T19:33:56  *** petertodd has quit IRC
575 2015-12-13T19:33:57  *** wumpus has quit IRC
576 2015-12-13T19:33:57  *** devrandom has quit IRC
577 2015-12-13T19:33:58  *** Guyver2 has quit IRC
578 2015-12-13T19:33:59  *** gribble has quit IRC
579 2015-12-13T19:34:00  *** gmaxwell has quit IRC
580 2015-12-13T19:34:01  *** isis has quit IRC
581 2015-12-13T19:34:01  *** BananaLotus has quit IRC
582 2015-12-13T19:34:01  *** roasbeef has quit IRC
583 2015-12-13T19:34:21  *** Guyver2 has joined #bitcoin-core-dev
584 2015-12-13T19:34:21  *** devrandom has joined #bitcoin-core-dev
585 2015-12-13T19:34:21  *** lclc has joined #bitcoin-core-dev
586 2015-12-13T19:34:21  *** roasbeef has joined #bitcoin-core-dev
587 2015-12-13T19:34:21  *** [b__b] has joined #bitcoin-core-dev
588 2015-12-13T19:34:21  *** guruvan has joined #bitcoin-core-dev
589 2015-12-13T19:34:21  *** wumpus has joined #bitcoin-core-dev
590 2015-12-13T19:34:21  *** petertodd has joined #bitcoin-core-dev
591 2015-12-13T19:34:21  *** pigeons has joined #bitcoin-core-dev
592 2015-12-13T19:34:21  *** mm_1 has joined #bitcoin-core-dev
593 2015-12-13T19:34:21  *** gmaxwell has joined #bitcoin-core-dev
594 2015-12-13T19:34:21  *** isis has joined #bitcoin-core-dev
595 2015-12-13T19:34:21  *** BananaLotus has joined #bitcoin-core-dev
596 2015-12-13T19:36:53  *** gribble has joined #bitcoin-core-dev
597 2015-12-13T20:04:03  *** ParadoxSpiral has joined #bitcoin-core-dev
598 2015-12-13T20:07:24  *** ParadoxSpiral has quit IRC
599 2015-12-13T20:36:00  *** jtimon has quit IRC
600 2015-12-13T20:37:20  *** jtimon has joined #bitcoin-core-dev
601 2015-12-13T20:55:50  *** zookolaptop has joined #bitcoin-core-dev
602 2015-12-13T21:26:42  *** Guyver2 has quit IRC
603 2015-12-13T21:37:18  *** raedah has quit IRC
604 2015-12-13T21:53:54  *** paveljanik has quit IRC
605 2015-12-13T21:54:27  *** bawong has joined #bitcoin-core-dev
606 2015-12-13T22:17:46  *** bawong has quit IRC
607 2015-12-13T22:18:33  *** randy-waterhouse has joined #bitcoin-core-dev
608 2015-12-13T23:20:56  *** PaulCapestany has quit IRC
609 2015-12-13T23:22:31  *** PaulCapestany has joined #bitcoin-core-dev
610 2015-12-13T23:27:19  *** davec has quit IRC
611 2015-12-13T23:31:53  *** davec has joined #bitcoin-core-dev
612 2015-12-13T23:55:18  *** tripleslash has joined #bitcoin-core-dev
613 2015-12-13T23:58:41  *** dstrunin has joined #bitcoin-core-dev