12015-12-13T00:18:52  *** phantomcircuit has quit IRC
  22015-12-13T00:21:19  <gmaxwell> sipa: I think your latest update to 7125 is wrong.
  32015-12-13T00:21:32  <sipa> oh?
  42015-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);
  52015-12-13T00:22:27  <gmaxwell> I think thats returning microseconds, not ms. And I think the now units are .. oh nevermind!
  62015-12-13T00:22:45  <sipa> getrand returns a result in [0, 1-1/2^48]
  72015-12-13T00:22:54  <sipa> ok
  82015-12-13T00:23:02  <sipa> it's in the comments even, i think :)
  92015-12-13T00:23:58  <sipa> i've tested it by adding a LogPrintf that writes out the new timestamp
 102015-12-13T00:24:13  <sipa> the results looks reasonably random around 5s
 112015-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.
 122015-12-13T00:24:58  <gmaxwell> but thats because for some reason I thought it was using ms not microseconds. :)
 132015-12-13T00:28:07  *** randy-waterhouse has joined #bitcoin-core-dev
 142015-12-13T00:31:19  *** phantomcircuit has joined #bitcoin-core-dev
 152015-12-13T00:39:16  *** bawong has joined #bitcoin-core-dev
 162015-12-13T00:42:04  *** Tera2342 has joined #bitcoin-core-dev
 172015-12-13T01:02:46  *** bawong has quit IRC
 182015-12-13T01:03:47  *** raedah has joined #bitcoin-core-dev
 192015-12-13T01:38:35  *** bawong has joined #bitcoin-core-dev
 202015-12-13T01:41:28  *** Ylbam has quit IRC
 212015-12-13T02:05:09  *** andytoshi has quit IRC
 222015-12-13T02:17:35  *** andytoshi has joined #bitcoin-core-dev
 232015-12-13T02:50:07  <morcos> gmaxwell: i'm trying to understand what you were talking about yesterday with the tiered fee behavior
 242015-12-13T02:50:26  <morcos> are you talking about this is how mempools would behave?
 252015-12-13T02:51:04  <morcos> and the target size is how big you wanted to limit your mempool to?
 262015-12-13T02:51:17  <morcos> or are you talking about something to do with block assembly?
 272015-12-13T02:51:26  <gmaxwell> The latter-- block assembly.
 282015-12-13T02:52:05  *** molz has joined #bitcoin-core-dev
 292015-12-13T02:52:34  <morcos> I'm not quite understanding the purpose
 302015-12-13T02:52:48  <morcos> you still suggest to add in a fee sorted manner
 312015-12-13T02:53:18  <morcos> but you want to have the min fee which is required start going up as the block gets bigger?
 322015-12-13T02:53:36  *** moli has quit IRC
 332015-12-13T02:53:36  *** Tera2342 has quit IRC
 342015-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.
 352015-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?
 362015-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?
 372015-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.
 382015-12-13T02:56:51  <morcos> but i'm hesitant to jump to the conclusion that we've been that far off.
 392015-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.
 402015-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?
 412015-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.
 422015-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?
 432015-12-13T02:59:15  <gmaxwell> morcos: yes, there should be.
 442015-12-13T02:59:53  <phantomcircuit> morcos, orphan rate is roughly proportional to the size of the transactions weighted by transaction age
 452015-12-13T03:00:07  <phantomcircuit> ie newer transactions are likely to take longer to validate and thus increase orphan rate
 462015-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.
 472015-12-13T03:00:41  <morcos> seems like even more accurate would be to look at number of differet txs in the prevouts
 482015-12-13T03:00:50  <phantomcircuit> gmaxwell, the effect is marginal at the moment because of gbt latency
 492015-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.
 502015-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.
 512015-12-13T03:02:18  <morcos> so actual bandwidth is a limiting factor then
 522015-12-13T03:03:03  <phantomcircuit> gmaxwell, yes
 532015-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. :)
 542015-12-13T03:03:46  <morcos> ha.. maybe, or maybe you don't want your block reward lost in a reorg.  :)
 552015-12-13T03:04:14  <gmaxwell> hah, okay 100 is a bit high for that example.
 562015-12-13T03:04:22  <morcos> i think spending some time thinking about this is a good idea
 572015-12-13T03:04:27  <morcos> maybe we don't find any serious concerns
 582015-12-13T03:04:51  <morcos> but with the halvening coming up..  it might make things matter that didn't use to
 592015-12-13T03:05:34  <phantomcircuit> gmaxwell, yes but that's slightly harder to calculate :)
 602015-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.
 612015-12-13T03:06:05  <morcos> yeah i guess thats what i'm not following
 622015-12-13T03:06:16  <morcos> i think that maybe thats true looking at a very short time frame
 632015-12-13T03:06:45  <morcos> but the whole point is the block time variability is what lets you pay less for slower confirmation
 642015-12-13T03:06:57  <morcos> or are you thinking with respect to block size limits
 652015-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
 662015-12-13T03:07:55  <morcos> i guess thats hard to do by consensus
 672015-12-13T03:08:07  <phantomcircuit> gmaxwell, unfortunately the way to fix that is convoluted and a hard fork
 682015-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.
 692015-12-13T03:08:24  <phantomcircuit> adjust the max block size based on the timestamp (oh and can/will be manipulated by miners)
 702015-12-13T03:09:18  <morcos> i guess the way i imagine the system is we should assume that blocks will always be 100% full
 712015-12-13T03:09:23  <gmaxwell> in a way that was more gradual that "is load currently over limit yes/no"?
 722015-12-13T03:09:32  <gmaxwell> morcos: yes, we should. I agree, long run.
 732015-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.
 742015-12-13T03:10:36  <gmaxwell> Maybe it's just short term and we shouldn't worry about it.
 752015-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.
 762015-12-13T03:12:05  <gmaxwell> (and, ultimately, some later dynamic blocksize maximum could make that stability promoting behavior also the income maximizing one)
 772015-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.
 782015-12-13T03:12:31  <gmaxwell> Okay, I agree with that.
 792015-12-13T03:12:32  <morcos> but maybe i'm not understanding stability of what
 802015-12-13T03:13:14  <morcos> hmm
 812015-12-13T03:13:19  <morcos> yeah so if you're a miner
 822015-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!"
 832015-12-13T03:13:49  <phantomcircuit> gmaxwell, what's the formula you were saying governs the maximum feerate a miner should include?
 842015-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
 852015-12-13T03:15:02  <morcos> i'm very curious to see if your stratum timings change by much after 0.12
 862015-12-13T03:15:06  *** bawong has quit IRC
 872015-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 ...
 882015-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
 892015-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
 902015-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
 912015-12-13T03:16:59  <gmaxwell> dth assuming 600s blocks)
 922015-12-13T03:17:02  <gmaxwell> 16:04 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Quit: ZNC - http://znc.sourceforge.net]
 932015-12-13T03:17:05  <gmaxwell> 16:07 < gmaxwell> (thats for btc per 1000 bytes, which is usually the unit we use for fees)
 942015-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.
 952015-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.
 962015-12-13T03:17:50  <gmaxwell> and taking the derivative of it.
 972015-12-13T03:18:35  <morcos> when you say block found before you, what does that mean
 982015-12-13T03:18:35  <phantomcircuit> and of course if you s/25/0/ it's "build infinite blocks"
 992015-12-13T03:18:42  <morcos> that you would have lost the orphan race?
1002015-12-13T03:18:52  <morcos> or are you not taking that into account
1012015-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.
1022015-12-13T03:19:20  <gmaxwell> morcos: that you would have lost an orphan race.
1032015-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.
1042015-12-13T03:20:18  <phantomcircuit> gmaxwell, it's roughly the same speed when run with the "empty blocks first" patch
1052015-12-13T03:20:30  <morcos> 2.5 sec seems like so many
1062015-12-13T03:20:40  <phantomcircuit> i mean 0.11.2 is
1072015-12-13T03:20:45  <phantomcircuit> forgot words there
1082015-12-13T03:21:29  <morcos> if you're somehow aware another block has been found in less than that
1092015-12-13T03:21:30  <morcos> oh
1102015-12-13T03:21:32  <morcos> interesting
1112015-12-13T03:21:45  <morcos> nvm, i guess invs tell you it was a block, i was thinking you didn't know that
1122015-12-13T03:22:08  <phantomcircuit> warmcache rpc + empty blocks results in basically instantly returning a new template
1132015-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
1142015-12-13T03:22:31  <morcos> until you at least have th headers or block to build off of for the next one
1152015-12-13T03:22:44  <morcos> that way if you happen to find a block you might beat out the other guy
1162015-12-13T03:22:57  <phantomcircuit> morcos, the empty block patch isn't spv/stratum "verification"
1172015-12-13T03:23:14  <morcos> yeah i'm suggesting a different kind of empty block
1182015-12-13T03:23:15  <phantomcircuit> you actually verify the previous block and then simply short circuit getblocktemplate to return an empty transactions list
1192015-12-13T03:23:27  <morcos> you're aware a block has been found, but not even the headers for it yet
1202015-12-13T03:23:38  <phantomcircuit> i can think of at least a few reasons that doing that is a bad idea :)
1212015-12-13T03:23:38  <morcos> you mine empty block on the old tip, so if you happen to find one
1222015-12-13T03:23:47  <morcos> you have a chance of winning the orphan race
1232015-12-13T03:23:52  <phantomcircuit> "hey morcor i found a new block!"
1242015-12-13T03:24:01  <morcos> yes yea
1252015-12-13T03:24:17  <phantomcircuit> repeat every 1 second
1262015-12-13T03:24:20  <morcos> but worst case is you give up fees which are small anyway
1272015-12-13T03:24:32  <morcos> anyway, in direct headers announcement
1282015-12-13T03:24:44  <morcos> you'll have the header so they coudln't do that
1292015-12-13T03:24:57  <morcos> and if you don't want to validationless mine
1302015-12-13T03:25:05  <morcos> whatever its an over optimization
1312015-12-13T03:25:08  <morcos> but 2.5 seconds!
1322015-12-13T03:25:13  <morcos> just craz
1332015-12-13T03:25:14  <morcos> y
1342015-12-13T03:25:40  <phantomcircuit> morcos, huh?
1352015-12-13T03:25:55  <gmaxwell> Yea, it's surprisingly high but there are many sources of latency.
1362015-12-13T03:25:58  <phantomcircuit> morcos, without fully optimizing im currently 1 second behind f2pool
1372015-12-13T03:26:19  <morcos> ok so help me understand that
1382015-12-13T03:26:21  <phantomcircuit> im certain i can reduce that more
1392015-12-13T03:26:27  <morcos> why?
1402015-12-13T03:26:48  <morcos> f2pool is mining on top of a valid PoW header as soon as they have it?
1412015-12-13T03:26:49  <phantomcircuit> speed of light beijing to montreal for one
1422015-12-13T03:27:03  <morcos> lot less than 1 sec!
1432015-12-13T03:27:17  <phantomcircuit> another few hundred ms for TestBlockValidity
1442015-12-13T03:27:31  <phantomcircuit> (less with the empty blocks patch)
1452015-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.
1462015-12-13T03:27:41  <morcos> ah, right two validations, you have to validate the new block, and your template
1472015-12-13T03:27:50  <gmaxwell> yea, f2pool will mine without validating at all.
1482015-12-13T03:28:17  <phantomcircuit> gmaxwell, afaik there's no good reason for the switching time to be so high
1492015-12-13T03:28:23  <morcos> i think whoever was trying to patch to move TBV out of path has a good idea
1502015-12-13T03:28:37  <gmaxwell> I agree.
1512015-12-13T03:28:37  <phantomcircuit> the only hardware i ever directly wrote drivers for switched in 40ms max
1522015-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
1532015-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.
1542015-12-13T03:29:27  <phantomcircuit> morcos, huh? if TBV fails you're not screwed
1552015-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)
1562015-12-13T03:29:52  <morcos> phantomcircuit: i've been trying to understand how that works in practice
1572015-12-13T03:30:21  <phantomcircuit> morcos, any competently written pool software gets block templates from multiple bitcoind nodes
1582015-12-13T03:30:30  <morcos> right ok
1592015-12-13T03:30:41  <morcos> and they are presumably running different code? (they should!)
1602015-12-13T03:30:55  <tulip> most seem to share code to some degree.
1612015-12-13T03:30:59  <phantomcircuit> i'd bet 99% of people are running identical code
1622015-12-13T03:31:02  <morcos> and if one fails then it just fails over to using the other one?
1632015-12-13T03:31:02  <gmaxwell> he means the different nodes.
1642015-12-13T03:31:16  <morcos> right, i mean .11.2 and .12.0
1652015-12-13T03:31:22  <tulip> what's a failure?
1662015-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.
1672015-12-13T03:31:43  <phantomcircuit> morcos, i cant answer that definitely but they should be
1682015-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.
1692015-12-13T03:31:54  <gmaxwell> Our software reliablity is greater than their planning horizon. :)
1702015-12-13T03:32:01  <phantomcircuit> (which is also a good reason for soft forks to be backported btw)
1712015-12-13T03:32:23  <gmaxwell> Luke added the block proposal support so he could test daemon's block templates against each other.
1722015-12-13T03:32:30  <phantomcircuit> tulip, a TBV failure is 99% a mempool problem
1732015-12-13T03:32:36  <gmaxwell> But I'm not aware of any other pools using it.
1742015-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
1752015-12-13T03:33:18  *** moli has joined #bitcoin-core-dev
1762015-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?
1772015-12-13T03:33:54  <morcos> i guess maybe .11.2 could just be failover
1782015-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.
1792015-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
1802015-12-13T03:35:03  <gmaxwell> We've had consistency bugs in the past.
1812015-12-13T03:35:04  <morcos> hopefully one thats unlikely to be hit
1822015-12-13T03:36:30  *** molz has quit IRC
1832015-12-13T03:37:44  <gmaxwell> Perhaps we should have all full nodes doing a createnewblock every once in a while.
1842015-12-13T03:38:12  <gmaxwell> We're probably much less likely to get reports because so few users (and developers) mine.
1852015-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.
1862015-12-13T03:40:27  <morcos> but having developers running at least one full node calling CNB all the time is worthwhile
1872015-12-13T03:40:35  <morcos> i've been doing that for a couple months now
1882015-12-13T03:40:37  <phantomcircuit> morcos, probably not since different maxmempool sizes
1892015-12-13T03:40:57  <phantomcircuit> even with the index usage in cnb in 0.12 i'd still have nodes with tiered max mempools
1902015-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.
1912015-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.
1922015-12-13T03:41:29  <phantomcircuit> gmaxwell, that could be part of making CNB run in a background thread continuously
1932015-12-13T03:42:00  <phantomcircuit> the gbt longpoll stuff does a good job of only running cnb when it's necessary
1942015-12-13T03:42:02  <morcos> i have a request, i'll direct if at gmaxwell since he runs the project now according to hearn
1952015-12-13T03:42:11  <phantomcircuit> (although there's a bug there around timing out normal http libs...)
1962015-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.
1972015-12-13T03:42:34  <morcos> before we can really make CNB run all the time and do many other improvements to the code
1982015-12-13T03:42:41  <phantomcircuit> gmaxwell, nah you just run it when there's a new block
1992015-12-13T03:42:45  <morcos> we need to rework the entire locking strategy
2002015-12-13T03:42:58  <gmaxwell> the locking train wreak you mean? :(
2012015-12-13T03:43:02  *** arowser has quit IRC
2022015-12-13T03:43:10  <morcos> exactly
2032015-12-13T03:43:22  <phantomcircuit> morcos, i suspect that's much more complicated than it initially sounds :P
2042015-12-13T03:43:32  *** arowser has joined #bitcoin-core-dev
2052015-12-13T03:43:33  <morcos> we don't have to go to the perfect solution
2062015-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).
2072015-12-13T03:43:50  <morcos> but someone who is a better developer than i should draw up a road map for us
2082015-12-13T03:44:26  <morcos> sipa had some good ideas for it, but maybe its not fair to give him every hard project
2092015-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.
2102015-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.
2112015-12-13T03:46:17  <morcos> i'm happy to take direction
2122015-12-13T03:46:33  <morcos> maybe thats always hard to accomplish with open source
2132015-12-13T03:46:52  <phantomcircuit> gmaxwell, example?
2142015-12-13T03:47:40  <gmaxwell> phantomcircuit: look how the headers first, download tracking stuff works.
2152015-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
2162015-12-13T03:47:55  <morcos> s/right/write/
2172015-12-13T03:47:59  <gmaxwell> "No please tell us what to do!"
2182015-12-13T03:48:04  <morcos> :)
2192015-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
2202015-12-13T03:48:21  <phantomcircuit> im not sure if that's worth it or not
2212015-12-13T03:48:36  <gmaxwell> I currently have code blocked on "need to fix locking".
2222015-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
2232015-12-13T03:49:46  <phantomcircuit> createnewblock being the most obvious
2242015-12-13T03:50:00  <phantomcircuit> there's also the wallet code but that's harder to reason aboue
2252015-12-13T03:50:02  <phantomcircuit> about*
2262015-12-13T03:50:13  <morcos> even just connecting a new block
2272015-12-13T03:50:19  * phantomcircuit goes to look at CNB in master
2282015-12-13T03:50:40  <phantomcircuit> morcos, lots of things devolve into "make chainstate an mvcc db"
2292015-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
2302015-12-13T03:50:46  <phantomcircuit> but complexity kills
2312015-12-13T03:50:53  <morcos> if the tip changed int he meantime, abort
2322015-12-13T03:51:04  <phantomcircuit> well there's things where copying the state is more expensive than the operation itself
2332015-12-13T03:51:42  <morcos> but connect block already grabs all the state it needs for the script verification threads
2342015-12-13T03:52:05  <morcos> it just waits for them to complete before flushing the new coinsview back to pcoinstip
2352015-12-13T03:52:18  <phantomcircuit> morcos, the particular case of the script verification queues is interesting
2362015-12-13T03:52:26  <morcos> there is no reason not to be accepting txs to your mempool during that time
2372015-12-13T03:52:48  <phantomcircuit> it should be easy to add another validation state
2382015-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
2392015-12-13T03:53:06  <phantomcircuit> i tried but haven't touched that code enough to be confident it would work
2402015-12-13T03:53:27  <morcos> what do you mean another validation state?
2412015-12-13T03:53:39  <phantomcircuit> if we acquire the same lock twice in the same thread is that going to context switch?
2422015-12-13T03:53:44  <phantomcircuit> or deadlock?
2432015-12-13T03:54:00  <phantomcircuit> actually it's going to deadlock since they're not reentrant
2442015-12-13T03:54:09  <morcos> they are, which locks?
2452015-12-13T03:54:11  <phantomcircuit> morcos, "i've validated everything except the scripts"
2462015-12-13T03:54:39  <phantomcircuit> oh is cs_main reentrant?
2472015-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
2482015-12-13T03:54:59  <phantomcircuit> oh they are
2492015-12-13T03:55:17  <morcos> ha, yeah, its pretty rare people bother to do assert_lock_held instead of just calling LOCK again
2502015-12-13T04:01:03  <phantomcircuit> do you need cs_main to use a CBlockIndex*
2512015-12-13T04:01:16  <phantomcircuit> ie chainActive.Tip() ?
2522015-12-13T04:03:19  <phantomcircuit> (im going to assume yes)
2532015-12-13T04:04:31  <morcos> thats the interesting question
2542015-12-13T04:04:34  <morcos> for the most part no
2552015-12-13T04:05:04  <phantomcircuit> morcos, it mostly doesn't matter actually
2562015-12-13T04:05:23  <phantomcircuit> it looks like you only need chainActive.Tip() for a small fraction of CNB runtime
2572015-12-13T04:05:40  <phantomcircuit> gmaxwell, do you know off hand the rough latency of LOCK(cs_main) ?
2582015-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
2592015-12-13T04:07:11  <phantomcircuit> morcos, im going to change fBuildEmptyBlock to fNewBlock
2602015-12-13T04:07:22  <phantomcircuit> and change the locking strategy based on that
2612015-12-13T04:07:41  <morcos> are you referring to some existing PR
2622015-12-13T04:08:49  <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/7104
2632015-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
2642015-12-13T04:11:35  <phantomcircuit> right now there's a problem where CNB can stall validating a new tip
2652015-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
2662015-12-13T04:12:44  <phantomcircuit> divide*
2672015-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.
2682015-12-13T04:16:32  <phantomcircuit> morcos, we could run TBV without signature checking but everything being checked has is probably in sigcache
2692015-12-13T04:16:39  <phantomcircuit> so i dont see that making a huge difference
2702015-12-13T04:17:35  <Luke-Jr> TBV shouldn't be slow..
2712015-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
2722015-12-13T04:21:32  <phantomcircuit> (note i haven't tested that PR like at all)
2732015-12-13T04:26:51  *** laurentmt has joined #bitcoin-core-dev
2742015-12-13T04:27:02  *** laurentmt has quit IRC
2752015-12-13T04:46:33  <morcos> phantomcircuit: ha, just thought of this.  when we call ConnectBlock from TBV we call it with fJustCheck.
2762015-12-13T04:46:58  <morcos> We should be able to release cs_main before control.Wait()
2772015-12-13T04:47:15  <morcos> so we don't have to wait for script verificaiton threads to finish with cs_main locked
2782015-12-13T04:47:31  <morcos> not sure exactly how much time that would save in general, but seems like a super easy win
2792015-12-13T04:51:30  <phantomcircuit> morcos, probably not much, remember that all the transactions being checked are already in sigcache
2802015-12-13T04:59:36  *** tripleslash has joined #bitcoin-core-dev
2812015-12-13T05:07:36  <sipa> phantomcircuit: not guaranteed :)
2822015-12-13T05:10:19  <phantomcircuit> sipa, it is when you run with the sigcache size i do :P
2832015-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?
2842015-12-13T05:37:21  *** bawong has joined #bitcoin-core-dev
2852015-12-13T05:42:35  *** bawong has quit IRC
2862015-12-13T06:04:57  <Luke-Jr> blah, gitian needs trusty now and that needs a vmbuilder upgrade :<
2872015-12-13T06:15:26  <tulip> that's weird, somehow my node has got into a state where it has fallen behind the chain.
2882015-12-13T06:15:42  <Luke-Jr> tulip: debug.log?
2892015-12-13T06:15:45  <tulip> "chain":"main","blocks":388132,"headers":388135
2902015-12-13T06:16:16  <tulip> Luke-Jr: nothing interesting, no rejects or invalid blocks, it's just chilling.
2912015-12-13T06:16:32  <Luke-Jr> tulip: for how long?
2922015-12-13T06:16:41  <phantomcircuit> tulip, getpeerinfo
2932015-12-13T06:16:49  <phantomcircuit> i bet you're waiting for a peer to send you a block
2942015-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.
2952015-12-13T06:18:23  <phantomcircuit> tulip, and that's why my gbt nodes connect to trusted nodes and the relaynetwork only
2962015-12-13T06:18:32  <tulip> sorry, an hour and 3 minutes behind.
2972015-12-13T06:19:13  <CodeShark>  it takes over an hour to timeout a block request?!?!
2982015-12-13T06:19:28  <gmaxwell> no, it takes 20 minutes.
2992015-12-13T06:19:39  <gmaxwell> but if you have multiple screwball peers you might time out more than once.
3002015-12-13T06:19:53  <gmaxwell> I know how to make it safely dynamic but haven't had a chance to implement it.
3012015-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.
3022015-12-13T06:21:46  <gmaxwell> Any time you kick a peer off for timing out, increase the timeout (1.5x?).
3032015-12-13T06:22:11  <gmaxwell> This should be safe and result in quite low timeouts for most peers most of the time.
3042015-12-13T06:22:25  <Luke-Jr> sounds gameable by hostile peers
3052015-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.
3062015-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
3072015-12-13T06:24:01  <gmaxwell> Luke-Jr: Explain, because I think it's not usefully gamable (except by constant factors)
3082015-12-13T06:24:15  <gmaxwell> Luke-Jr: oh I assumed the timeout would still be capped at 20 minutes.
3092015-12-13T06:24:21  <Luke-Jr> oh, ok then
3102015-12-13T06:24:24  <gmaxwell> Beyond that, if you're actually that slow, you have no hope of keeping up with the network.
3112015-12-13T06:24:54  <CodeShark> in that case, shouldn't 10 min be the cap?
3122015-12-13T06:25:09  <Luke-Jr> CodeShark: nah, your connection might be bursty
3132015-12-13T06:25:14  <gmaxwell> CodeShark: No, because ^
3142015-12-13T06:25:22  <gmaxwell> there should be some headroom.
3152015-12-13T06:25:57  <Luke-Jr> might be reasonable to do some magic before the calibration though
3162015-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
3172015-12-13T06:26:31  <CodeShark> that's what I was sorta thinking
3182015-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
3192015-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.
3202015-12-13T06:27:31  <Luke-Jr> tulip: yeah
3212015-12-13T06:27:35  <gmaxwell> Yea, that requires low level visibility that we don't really have right now.
3222015-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
3232015-12-13T06:28:09  <gmaxwell> CodeShark: requires having a concept of what 'slow' means, _and_ having sub-message visibility, .
3242015-12-13T06:28:39  <CodeShark> yes, we could check the buffer before we complete the download to get an estimate of the datarate
3252015-12-13T06:28:48  <gmaxwell> When we start the block fetch, there is always only one available (the first).
3262015-12-13T06:29:21  <CodeShark> we could also download multiple blocks in parallel from different peers when measuring download rate to not waste bandwidth
3272015-12-13T06:30:48  <Luke-Jr> CodeShark: fancy!
3282015-12-13T06:31:06  <Luke-Jr> but definitely more complicated to implement:P
3292015-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?
3302015-12-13T06:31:17  <gmaxwell> well there is only one block on the tip!
3312015-12-13T06:31:31  <phantomcircuit> i guess you'd see headers
3322015-12-13T06:46:12  <tulip> do nodes actually forward headers like that?
3332015-12-13T06:46:34  <CodeShark> sync on core is headers-first
3342015-12-13T06:46:50  <CodeShark> which means you can validate PoW before downloading any actual blocks
3352015-12-13T06:47:13  <tulip> sure, but do nodes actively forward headers of blocks they don't believe to be the main chain
3362015-12-13T06:47:33  <CodeShark> oh, not that I'm aware of ;)
3372015-12-13T06:47:34  <CodeShark> not yet
3382015-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)
3392015-12-13T06:48:49  <Luke-Jr> tulip: if those nodes are attacking you, they do :D
3402015-12-13T06:49:07  <tulip> not invalid, just not best
3412015-12-13T06:49:29  <CodeShark> such chains tend to die quickly
3422015-12-13T06:50:21  <CodeShark> the main threat with headers sync is the isolation attack
3432015-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
3442015-12-13T06:53:20  <CodeShark> which means something is fundamentally broken ;)
3452015-12-13T06:53:48  <tulip> forwarding all headers, always would be nice.
3462015-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.
3472015-12-13T06:57:15  <CodeShark> wasn't it suggested before that we stop inving blocks and just send block headers?
3482015-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.
3492015-12-13T06:57:40  <gmaxwell> CodeShark: yes, we do that now. but then the header is just the inv. :)
3502015-12-13T07:01:58  <CodeShark> we could just add a flag to the headers message
3512015-12-13T07:02:04  *** davec_ has quit IRC
3522015-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 :)
3532015-12-13T07:04:02  <CodeShark> and to stop treating blocks as subclasses of block headers ;)
3542015-12-13T07:04:45  <gmaxwell> Versioning suggests linear progressions. :)
3552015-12-13T07:05:13  <CodeShark> versionbits for p2p? ;)
3562015-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
3572015-12-13T07:09:41  <CodeShark> better fork detection would be a wonderful thing, though
3582015-12-13T07:11:39  <Luke-Jr> uh so
3592015-12-13T07:11:43  <Luke-Jr> I can no longer gitian-build :/
3602015-12-13T07:11:48  <Luke-Jr> vmbuilder fails on trusty
3612015-12-13T07:11:58  <Luke-Jr> what vmbuilder did other people here use?
3622015-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"
3632015-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:
3642015-12-13T07:13:20  <gmaxwell> gavinandresen: https://www.reddit.com/r/btc/comments/3wj0du/gavin_we_want_to_donated_to_you/cxwx4hx
3652015-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
3662015-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
3672015-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
3682015-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
3692015-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
3702015-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
3712015-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
3722015-12-13T07:18:38  * Luke-Jr pokes phantomcircuit
3732015-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
3742015-12-13T07:18:52  <Luke-Jr> …
3752015-12-13T07:19:13  <Luke-Jr> phantomcircuit: you really think Core is going to become non-free software?
3762015-12-13T07:19:42  <phantomcircuit> Luke-Jr, no but i can certainly stop contributing
3772015-12-13T07:20:11  <Luke-Jr> phantomcircuit: you can, but all it's going to do is increase everyone else's workload :/
3782015-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
3792015-12-13T07:20:51  <Luke-Jr> what's the point in making an ultimatum that you know cannot be met?
3802015-12-13T07:21:35  *** Tera2342 has joined #bitcoin-core-dev
3812015-12-13T07:21:54  <phantomcircuit> Luke-Jr, the license can be changed to prevent specific people from using the code
3822015-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.
3832015-12-13T07:22:14  <gmaxwell> er take care of it. :)
3842015-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.
3852015-12-13T07:22:32  <btcdrak> gmaxwell: it's time we boot gavinandresen
3862015-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.
3872015-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.
3882015-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.
3892015-12-13T07:27:10  <gmaxwell> s/out/our/
3902015-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
3912015-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.
3922015-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
3932015-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.
3942015-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.
3952015-12-13T07:32:05  <midnightmagic> what is bitcoin's licence anyway.. mit/bsd?
3962015-12-13T07:32:09  <Luke-Jr> midnightmagic: yes
3972015-12-13T07:32:44  <midnightmagic> in magical parallel universe able-to-contact-everyone land, you could change it to gplv3
3982015-12-13T07:33:05  <Luke-Jr> midnightmagic: we could change it easily. MIT is relicensable to GPLv3
3992015-12-13T07:33:14  <Luke-Jr> but that wouldn't do what phantomcircuit is asking
4002015-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.
4012015-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.
4022015-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.
4032015-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)
4042015-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
4052015-12-13T07:35:13  <Luke-Jr> aj: it would need to be over p2p, not RPC
4062015-12-13T07:35:23  <Luke-Jr> aj: Eloipool uses it
4072015-12-13T07:35:28  <aj> Luke-Jr: quite right
4082015-12-13T07:35:36  <Luke-Jr> (and will dump its code over stratum or HTTP)
4092015-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.
4102015-12-13T07:36:04  <aj> Luke-Jr: easier to get at source for a python program than a c++ one too
4112015-12-13T07:36:27  <Luke-Jr> we could rename the project and enforce it as a trademark..
4122015-12-13T07:37:18  <btcdrak> Luke-Jr: "Bitcoin Core" as a phrase is probably trademarkable, but I really dont see the benefit.
4132015-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
4142015-12-13T07:37:33  <Luke-Jr> btcdrak: but Hearn coined it
4152015-12-13T07:37:47  <Luke-Jr> in fact, is that a risk to us?
4162015-12-13T07:37:51  <gmaxwell> No.
4172015-12-13T07:37:54  <btcdrak> Luke-Jr: no
4182015-12-13T07:38:32  <midnightmagic> Does the U.S. have a pre-existing trademark exception rule too?
4192015-12-13T07:38:40  <midnightmagic> I know Canada does.
4202015-12-13T07:38:43  <Luke-Jr> midnightmagic: I think the GPL would be a bad choice for node software.
4212015-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 >.>
4222015-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.
4232015-12-13T07:39:44  <midnightmagic> btcdrak: I'm listening now. Can you link me?
4242015-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.
4252015-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.
4262015-12-13T07:42:03  <midnightmagic> Well that was ideally what the BCF was supposed to do. :-/
4272015-12-13T07:42:04  <btcdrak> (because they would be used by gavin against us)
4282015-12-13T07:42:25  <btcdrak> The BCF is a useless train wreck.
4292015-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.
4302015-12-13T07:42:58  <Luke-Jr> problem: we are understaffed technically already..
4312015-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.
4322015-12-13T07:44:40  <randy-waterhouse> btcdrak: did you specific companies in mind, or some examples?
4332015-12-13T07:44:51  <randy-waterhouse> s/did you have/
4342015-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.
4352015-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"
4362015-12-13T07:48:21  <Luke-Jr> ?
4372015-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.
4382015-12-13T07:49:54  <Luke-Jr> btcdrak: a letter is easier than a presentation, is what I mean.
4392015-12-13T07:50:06  <btcdrak> Luke-Jr: it's a good start,
4402015-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.
4412015-12-13T07:51:46  <Luke-Jr> btcdrak: hope your health improves :|
4422015-12-13T07:52:15  <btcdrak> Luje-Jr: yeah ditto! I wish they would find a diagnosis at least.
4432015-12-13T08:07:54  *** Ylbam has joined #bitcoin-core-dev
4442015-12-13T08:30:39  *** molz has joined #bitcoin-core-dev
4452015-12-13T08:32:35  *** moli has quit IRC
4462015-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
4472015-12-13T09:02:49  *** moli has joined #bitcoin-core-dev
4482015-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.
4492015-12-13T09:04:15  *** molz has quit IRC
4502015-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
4512015-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
4522015-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.
4532015-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.
4542015-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)
4552015-12-13T09:19:40  <btcdrak> trial as in see how it goes for expanding to more maintainers
4562015-12-13T09:20:42  <btcdrak> maintainer here means people with push access and authority to merge PRs.
4572015-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
4582015-12-13T09:25:13  <btcdrak> Luke-Jr: yes I know, that's well explained in the referenced document.
4592015-12-13T09:26:14  <Luke-Jr> btcdrak: on another note, did you manage to do the trusty gitian update?
4602015-12-13T09:26:30  <btcdrak> Luke-Jr: I dont think English has the right words for this, haha.
4612015-12-13T09:26:38  <btcdrak> Luke-Jr: ut oh. my mind is blank.
4622015-12-13T09:26:54  <btcdrak> Luke-Jr: can you refresh my memory?
4632015-12-13T09:27:13  <Luke-Jr> btcdrak: in the past ~week or so, master upgraded the version of Ubuntu used by gitian to "trusty"
4642015-12-13T09:27:20  <Luke-Jr> I can't get the base image to build
4652015-12-13T09:27:38  <btcdrak> Luke-Jr: OK, let me have a go from scratch
4662015-12-13T09:28:49  <Luke-Jr> worse: it appears to be trying to touch my MBR :|
4672015-12-13T09:29:30  <Luke-Jr> maybe I'm just being paranoid
4682015-12-13T09:42:51  <Luke-Jr> hmm https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1037607
4692015-12-13T10:04:09  <Luke-Jr> seems upgrading gitian-builder fixes it
4702015-12-13T10:06:06  *** Tera2342 has quit IRC
4712015-12-13T10:20:54  <btcdrak> Luke-Jr: still setting up my VM. what version of gitian-builder did you use?
4722015-12-13T10:21:18  <Luke-Jr> before, it was 9d46e26
4732015-12-13T10:21:24  <Luke-Jr> now f9ab587
4742015-12-13T10:22:07  *** tripleslash has quit IRC
4752015-12-13T10:24:55  *** btcdrak has quit IRC
4762015-12-13T10:25:07  *** corb is now known as JackH
4772015-12-13T10:26:05  *** zmanian_ has quit IRC
4782015-12-13T10:27:30  *** CodeShark has quit IRC
4792015-12-13T10:29:07  *** michagogo has quit IRC
4802015-12-13T10:40:50  *** tripleslash has joined #bitcoin-core-dev
4812015-12-13T10:45:10  *** michagogo has joined #bitcoin-core-dev
4822015-12-13T10:45:38  *** tripleslash has quit IRC
4832015-12-13T10:46:46  *** CodeShark_ has joined #bitcoin-core-dev
4842015-12-13T10:47:20  *** CodeShark has joined #bitcoin-core-dev
4852015-12-13T10:50:01  *** zmanian_ has joined #bitcoin-core-dev
4862015-12-13T10:50:35  *** btcdrak has joined #bitcoin-core-dev
4872015-12-13T10:53:19  *** tripleslash has joined #bitcoin-core-dev
4882015-12-13T10:53:38  *** btcdrak_ has joined #bitcoin-core-dev
4892015-12-13T10:53:44  *** btcdrak has quit IRC
4902015-12-13T10:53:45  *** btcdrak_ is now known as btcdrak
4912015-12-13T10:56:45  *** btcdrak has joined #bitcoin-core-dev
4922015-12-13T11:34:44  *** s1w- has quit IRC
4932015-12-13T11:34:44  *** s1w- has joined #bitcoin-core-dev
4942015-12-13T11:34:53  *** s1w- is now known as s1w
4952015-12-13T11:55:20  *** randy-waterhouse has quit IRC
4962015-12-13T12:03:06  *** Tera2342 has joined #bitcoin-core-dev
4972015-12-13T12:20:09  *** tulip has quit IRC
4982015-12-13T12:24:26  *** tripleslash has quit IRC
4992015-12-13T12:32:09  *** tripleslash has joined #bitcoin-core-dev
5002015-12-13T13:17:30  *** fkhan has quit IRC
5012015-12-13T13:20:11  *** laurentmt has joined #bitcoin-core-dev
5022015-12-13T13:22:55  *** laurentmt has quit IRC
5032015-12-13T13:36:48  *** ParadoxSpiral_ has joined #bitcoin-core-dev
5042015-12-13T13:40:10  *** ParadoxSpiral has quit IRC
5052015-12-13T13:57:24  *** Guyver2 has joined #bitcoin-core-dev
5062015-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
5072015-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)
5082015-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.
5092015-12-13T14:10:12  *** Tera2342 has quit IRC
5102015-12-13T14:12:00  <btcdrak> Luke-Jr: 9d46e26 is really old too I see.
5112015-12-13T14:14:06  *** tripleslash has quit IRC
5122015-12-13T14:20:00  *** CodeShark has quit IRC
5132015-12-13T14:20:01  *** CodeShark_ is now known as CodeShark
5142015-12-13T14:26:37  *** fkhan has joined #bitcoin-core-dev
5152015-12-13T14:46:15  *** moli has quit IRC
5162015-12-13T14:49:55  *** moli has joined #bitcoin-core-dev
5172015-12-13T14:58:29  *** davec has joined #bitcoin-core-dev
5182015-12-13T15:27:58  *** laurentmt has joined #bitcoin-core-dev
5192015-12-13T15:31:55  <GitHub92> [bitcoin] smenglish closed pull request #7201: Update hmac_sha256.cpp (master...master) https://github.com/bitcoin/bitcoin/pull/7201
5202015-12-13T15:46:00  *** jcorgan|away is now known as jcorgan
5212015-12-13T16:32:08  *** afk11 has joined #bitcoin-core-dev
5222015-12-13T16:44:57  *** molz has joined #bitcoin-core-dev
5232015-12-13T16:47:15  *** moli has quit IRC
5242015-12-13T17:05:22  *** moli has joined #bitcoin-core-dev
5252015-12-13T17:06:26  *** ParadoxSpiral_ has quit IRC
5262015-12-13T17:07:35  *** molz has quit IRC
5272015-12-13T17:08:34  *** molz has joined #bitcoin-core-dev
5282015-12-13T17:09:55  *** moli has quit IRC
5292015-12-13T17:17:32  *** MarcoFalke has joined #bitcoin-core-dev
5302015-12-13T17:24:54  *** bawong has joined #bitcoin-core-dev
5312015-12-13T17:34:08  *** molz has quit IRC
5322015-12-13T17:36:38  *** laurentmt has quit IRC
5332015-12-13T17:44:52  *** moli has joined #bitcoin-core-dev
5342015-12-13T17:46:24  *** wangchun has quit IRC
5352015-12-13T18:00:58  *** wangchun has joined #bitcoin-core-dev
5362015-12-13T18:06:06  *** Ylbam has quit IRC
5372015-12-13T18:06:33  *** Ylbam has joined #bitcoin-core-dev
5382015-12-13T18:11:45  *** CodeShark_ has joined #bitcoin-core-dev
5392015-12-13T18:12:26  *** wangchun_ has joined #bitcoin-core-dev
5402015-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)
5412015-12-13T18:13:28  *** CodeShark has quit IRC
5422015-12-13T18:13:28  *** s1w has quit IRC
5432015-12-13T18:13:29  *** phantomcircuit has quit IRC
5442015-12-13T18:13:29  *** JackH has quit IRC
5452015-12-13T18:13:29  *** evoskuil has quit IRC
5462015-12-13T18:13:29  *** wangchun has quit IRC
5472015-12-13T18:13:30  *** s1w has joined #bitcoin-core-dev
5482015-12-13T18:13:30  *** evoskuil has joined #bitcoin-core-dev
5492015-12-13T18:13:33  <BlueMatt> gmaxwell: so...you can go log that if you want
5502015-12-13T18:13:40  *** CodeShark_ is now known as CodeShark
5512015-12-13T18:14:22  *** JackH_ has joined #bitcoin-core-dev
5522015-12-13T18:17:19  *** phantomcircuit has joined #bitcoin-core-dev
5532015-12-13T18:20:29  *** evoskuil has quit IRC
5542015-12-13T18:20:30  *** s1w has quit IRC
5552015-12-13T18:20:30  *** evoskuil has joined #bitcoin-core-dev
5562015-12-13T18:20:59  *** s1w- has joined #bitcoin-core-dev
5572015-12-13T18:26:32  *** evoskuil has quit IRC
5582015-12-13T18:26:34  *** evoskuil has joined #bitcoin-core-dev
5592015-12-13T18:35:02  *** laurentmt has joined #bitcoin-core-dev
5602015-12-13T18:38:37  *** laurentmt has quit IRC
5612015-12-13T19:12:37  *** raedah has quit IRC
5622015-12-13T19:13:33  *** raedah has joined #bitcoin-core-dev
5632015-12-13T19:18:38  *** bawong has quit IRC
5642015-12-13T19:19:12  *** wangchun_ has quit IRC
5652015-12-13T19:19:32  *** laurentmt has joined #bitcoin-core-dev
5662015-12-13T19:19:39  *** wangchun has joined #bitcoin-core-dev
5672015-12-13T19:19:49  *** laurentmt has quit IRC
5682015-12-13T19:32:37  *** belcher has joined #bitcoin-core-dev
5692015-12-13T19:33:54  *** lclc has quit IRC
5702015-12-13T19:33:56  *** [b__b] has quit IRC
5712015-12-13T19:33:56  *** guruvan has quit IRC
5722015-12-13T19:33:56  *** mm_1 has quit IRC
5732015-12-13T19:33:56  *** pigeons has quit IRC
5742015-12-13T19:33:56  *** petertodd has quit IRC
5752015-12-13T19:33:57  *** wumpus has quit IRC
5762015-12-13T19:33:57  *** devrandom has quit IRC
5772015-12-13T19:33:58  *** Guyver2 has quit IRC
5782015-12-13T19:33:59  *** gribble has quit IRC
5792015-12-13T19:34:00  *** gmaxwell has quit IRC
5802015-12-13T19:34:01  *** isis has quit IRC
5812015-12-13T19:34:01  *** BananaLotus has quit IRC
5822015-12-13T19:34:01  *** roasbeef has quit IRC
5832015-12-13T19:34:21  *** Guyver2 has joined #bitcoin-core-dev
5842015-12-13T19:34:21  *** devrandom has joined #bitcoin-core-dev
5852015-12-13T19:34:21  *** lclc has joined #bitcoin-core-dev
5862015-12-13T19:34:21  *** roasbeef has joined #bitcoin-core-dev
5872015-12-13T19:34:21  *** [b__b] has joined #bitcoin-core-dev
5882015-12-13T19:34:21  *** guruvan has joined #bitcoin-core-dev
5892015-12-13T19:34:21  *** wumpus has joined #bitcoin-core-dev
5902015-12-13T19:34:21  *** petertodd has joined #bitcoin-core-dev
5912015-12-13T19:34:21  *** pigeons has joined #bitcoin-core-dev
5922015-12-13T19:34:21  *** mm_1 has joined #bitcoin-core-dev
5932015-12-13T19:34:21  *** gmaxwell has joined #bitcoin-core-dev
5942015-12-13T19:34:21  *** isis has joined #bitcoin-core-dev
5952015-12-13T19:34:21  *** BananaLotus has joined #bitcoin-core-dev
5962015-12-13T19:36:53  *** gribble has joined #bitcoin-core-dev
5972015-12-13T20:04:03  *** ParadoxSpiral has joined #bitcoin-core-dev
5982015-12-13T20:07:24  *** ParadoxSpiral has quit IRC
5992015-12-13T20:36:00  *** jtimon has quit IRC
6002015-12-13T20:37:20  *** jtimon has joined #bitcoin-core-dev
6012015-12-13T20:55:50  *** zookolaptop has joined #bitcoin-core-dev
6022015-12-13T21:26:42  *** Guyver2 has quit IRC
6032015-12-13T21:37:18  *** raedah has quit IRC
6042015-12-13T21:53:54  *** paveljanik has quit IRC
6052015-12-13T21:54:27  *** bawong has joined #bitcoin-core-dev
6062015-12-13T22:17:46  *** bawong has quit IRC
6072015-12-13T22:18:33  *** randy-waterhouse has joined #bitcoin-core-dev
6082015-12-13T23:20:56  *** PaulCapestany has quit IRC
6092015-12-13T23:22:31  *** PaulCapestany has joined #bitcoin-core-dev
6102015-12-13T23:27:19  *** davec has quit IRC
6112015-12-13T23:31:53  *** davec has joined #bitcoin-core-dev
6122015-12-13T23:55:18  *** tripleslash has joined #bitcoin-core-dev
6132015-12-13T23:58:41  *** dstrunin has joined #bitcoin-core-dev