12015-11-29T00:06:34  <GitHub107> [bitcoin] gmaxwell closed pull request #7123: [WIP] Make trickle logic useful again, delay trickle when past upload limit. (master...actually_trickle) https://github.com/bitcoin/bitcoin/pull/7123
  22015-11-29T00:10:01  <GitHub27> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/61457c29d735...c894fbbb1dc0
  32015-11-29T00:10:01  <GitHub27> bitcoin/master a9f3d3d Pieter Wuille: Fix and improve relay from whitelisted peers...
  42015-11-29T00:10:02  <GitHub27> bitcoin/master c894fbb Gregory Maxwell: Merge pull request #7106...
  52015-11-29T00:10:09  <GitHub63> [bitcoin] gmaxwell closed pull request #7106: Fix and improve relay from whitelisted peers (master...realwhiterelay) https://github.com/bitcoin/bitcoin/pull/7106
  62015-11-29T00:19:01  *** michagogo has quit IRC
  72015-11-29T01:44:31  *** Ylbam has quit IRC
  82015-11-29T01:45:09  *** jtimon has joined #bitcoin-core-dev
  92015-11-29T01:59:34  <GitHub12> [bitcoin] gmaxwell closed pull request #7119: Add option to opt into full-RBF when sending funds (master...2015-11-opt-into-full-rbf-option) https://github.com/bitcoin/bitcoin/pull/7119
 102015-11-29T02:10:16  *** raedah has quit IRC
 112015-11-29T02:56:10  *** PaulCapestany has quit IRC
 122015-11-29T02:56:38  *** PaulCapestany has joined #bitcoin-core-dev
 132015-11-29T03:14:22  *** guest234234 has joined #bitcoin-core-dev
 142015-11-29T03:23:25  *** PaulCapestany has quit IRC
 152015-11-29T03:23:55  *** PaulCapestany has joined #bitcoin-core-dev
 162015-11-29T03:24:22  *** PaulCapestany has quit IRC
 172015-11-29T03:25:14  *** Thireus has quit IRC
 182015-11-29T03:25:40  *** PaulCapestany has joined #bitcoin-core-dev
 192015-11-29T03:36:35  *** Thireus has joined #bitcoin-core-dev
 202015-11-29T05:05:20  *** Dyanisus has joined #bitcoin-core-dev
 212015-11-29T06:07:44  *** zookolaptop has joined #bitcoin-core-dev
 222015-11-29T06:11:02  *** guest234234 has quit IRC
 232015-11-29T06:33:42  *** tulip has joined #bitcoin-core-dev
 242015-11-29T06:34:34  *** tulip has quit IRC
 252015-11-29T06:34:45  *** tulip has joined #bitcoin-core-dev
 262015-11-29T06:48:11  *** zookolaptop has quit IRC
 272015-11-29T07:03:44  *** randy-waterhouse has joined #bitcoin-core-dev
 282015-11-29T07:13:10  *** CodeShark_ has quit IRC
 292015-11-29T07:27:58  *** guest234234 has joined #bitcoin-core-dev
 302015-11-29T07:47:51  *** tulip has quit IRC
 312015-11-29T07:52:26  *** tulip has joined #bitcoin-core-dev
 322015-11-29T07:57:24  *** ParadoxSpiral has joined #bitcoin-core-dev
 332015-11-29T08:12:48  *** challisto has quit IRC
 342015-11-29T08:21:40  *** Guyver2 has joined #bitcoin-core-dev
 352015-11-29T08:25:42  *** challisto has joined #bitcoin-core-dev
 362015-11-29T08:57:10  <phantomcircuit> gmaxwell, what do you think about removing RelayTransaction entirely and simply sending the top n MB of the mempool every m seconds?
 372015-11-29T08:58:10  <gmaxwell> phantomcircuit: I want to try a protocol which does an efficient set reconcillation of the top N mb of mempool. Which is like the pro version of what you're thinking.
 382015-11-29T08:58:26  <gmaxwell> Not the actual data, but set reconcile the TXids and then getdata the bodies you need.
 392015-11-29T08:58:50  *** Ylbam has joined #bitcoin-core-dev
 402015-11-29T08:59:05  <phantomcircuit> gmaxwell, yes long term goal for sure
 412015-11-29T08:59:12  <phantomcircuit> but i can do this version like
 422015-11-29T08:59:13  <phantomcircuit> today
 432015-11-29T09:02:06  <phantomcircuit> gmaxwell, can you rename setInventoryKnown to filterInventoryKnown
 442015-11-29T09:02:20  <phantomcircuit> there's a bunch of those now that are a bit confusing because of not changing the name
 452015-11-29T09:18:40  *** Guyver2 has quit IRC
 462015-11-29T09:29:23  <phantomcircuit> gmaxwell, im pretty sure there's a bug in 7100
 472015-11-29T09:29:40  <phantomcircuit> it looks like you can get a false positive inv for blocks
 482015-11-29T09:31:45  <gmaxwell> phantomcircuit: where?
 492015-11-29T09:33:17  <phantomcircuit> gmaxwell, "getblocks" calls pfrom->PushInventory which uses setInventoryKnown to decide whether to actually do that
 502015-11-29T09:33:37  <phantomcircuit> so a false positive could prevent a block inv as well as tx inv
 512015-11-29T09:33:51  <phantomcircuit> i dont much care about tx inv's getting droped but it would be bad for block inv's to be also
 522015-11-29T09:33:59  <gmaxwell> agreed.
 532015-11-29T09:34:20  <phantomcircuit> so im thinking there needs to be a setInventoryKnownBlocks and filterInventoryKnownTransactions
 542015-11-29T09:39:05  <sipa> with 6494 we can just drop the known blocks
 552015-11-29T09:39:28  <sipa> as we keep track much more efficiently what peers know
 562015-11-29T09:44:06  <phantomcircuit> sipa, yes i agree that's a better solution
 572015-11-29T09:44:43  <phantomcircuit> except it's optional so we would still need the setInventoryKnownBlocks
 582015-11-29T09:44:58  <phantomcircuit> (or maybe we simply always send block invs ?)
 592015-11-29T09:45:49  <sipa> yes, we should always send them
 602015-11-29T09:47:10  <sipa> i'll rebase #6494; it's overdue for merging
 612015-11-29T09:57:51  <phantomcircuit> gmaxwell, https://github.com/gmaxwell/bitcoin/pull/2
 622015-11-29T09:57:52  *** Thireus has quit IRC
 632015-11-29T09:59:26  *** Thireus has joined #bitcoin-core-dev
 642015-11-29T10:03:57  <gmaxwell> woot, managed to apply that without loading the webpage.
 652015-11-29T10:05:44  <sipa> you have now passed the entry exam for the school for git wizardry and magic
 662015-11-29T10:06:26  <gmaxwell> well the git part was never a problem, just the github part. :P
 672015-11-29T10:07:48  <phantomcircuit> just gotta know the special pulls refspec
 682015-11-29T10:11:21  <phantomcircuit> sipa, in 7113 you calculate the optimal number of hash functions and then restrict it to 1-50
 692015-11-29T10:11:22  <phantomcircuit> why?
 702015-11-29T10:14:22  <phantomcircuit> an fp rate of 1/10^15 would get you nHashFuncs ~= 50
 712015-11-29T10:14:40  <phantomcircuit> i dont see this being an issue
 722015-11-29T10:18:13  <sipa> eh, i guess i wrote that part before realizing that the number of hash finctions only dependee on the fprate :)
 732015-11-29T10:18:59  <sipa> functions, depended
 742015-11-29T10:31:18  <phantomcircuit> anybody have an opinion of changing gbt to default not mine a transaction until it's been in the mempool for more than a few seconds
 752015-11-29T10:31:57  <sipa> phantomcircuit: do that on top of morcos' rewrite then :)
 762015-11-29T10:32:22  <phantomcircuit> sipa, it's a trivial 1 line change so i was mostly just wondering about the concept
 772015-11-29T10:32:32  <sipa> ok
 782015-11-29T10:32:51  <phantomcircuit> it seems like a good idea to me but i just thought of it soo
 792015-11-29T10:33:43  <sipa> among miners who are not in a position to exploit high hashrate or fast relay to a majority, that should improve their relay
 802015-11-29T10:35:19  <gmaxwell> phantomcircuit: I think it's a good idea. I thought of it before but figured it would screw up the recent improvements. :(
 812015-11-29T10:35:40  <sipa> should be trivial now that we remember time-in-mempool
 822015-11-29T10:36:00  <gmaxwell> hm. actually yea, you'd just skip them, so it doesn't change the sort.
 832015-11-29T10:36:16  <sipa> indeed
 842015-11-29T10:36:24  <phantomcircuit> sipa, it's been a trivial 1 loc patch for about a year now
 852015-11-29T10:36:45  <sipa> orly?
 862015-11-29T10:37:01  <phantomcircuit> actually more than that
 872015-11-29T10:37:09  <phantomcircuit> Date:   Mon Nov 11 17:35:14 2013 +1000
 882015-11-29T10:37:16  <sipa> ha, wow
 892015-11-29T10:37:38  <phantomcircuit> on a related note
 902015-11-29T10:37:55  <phantomcircuit> we want to maximally prime the sigcache for receiving a block
 912015-11-29T10:38:00  <phantomcircuit> while also limiting the mempool
 922015-11-29T10:38:11  <phantomcircuit> these are kind of at odds at the moment
 932015-11-29T10:38:29  <gmaxwell> I tried to have sipa verify rejects and it polluted the crap out of his cache.
 942015-11-29T10:38:33  <phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
 952015-11-29T10:38:42  <gmaxwell> it actually makes sense to verify rejects for several reasons.
 962015-11-29T10:38:52  <gmaxwell> but I think we have to improve cache management first.
 972015-11-29T10:38:56  <phantomcircuit> gmaxwell, well for a miner you can just run with a huge sigcache
 982015-11-29T10:39:01  <phantomcircuit> i've got mine set to 4GB...
 992015-11-29T10:39:28  <gmaxwell> Sipa found it was polluting it even with a stupidly big one. (but not that stupidly big)
1002015-11-29T10:39:53  <phantomcircuit> yeah the definition of stupidly big varies here :)
1012015-11-29T10:39:54  <gmaxwell> phantomcircuit: we'd like to uh.. not centeralize mining "you can mine but if you want a low orphan rate you'll have to dedicate 16GB ram to it.. not great. :P
1022015-11-29T10:40:21  <sipa> hey let's use a rolling bloom filter for tue sigcache!!!
1032015-11-29T10:40:23  <sipa> *ducks*
1042015-11-29T10:40:34  <gmaxwell> but I think ultimately thats the best thing to do, we could try to estimate "reject but still likely to get mined soon based on recent history" but I'd rather spend the complexity on making the cache smarter.
1052015-11-29T10:41:06  <phantomcircuit> the cache doesn't evict when a block is found does it?
1062015-11-29T10:41:10  <phantomcircuit> that would be an easy win
1072015-11-29T10:41:11  <sipa> it does
1082015-11-29T10:41:12  <gmaxwell> e.g. attach feerate and "tip change counter" to entries in the cache, and evict using them.
1092015-11-29T10:41:14  <phantomcircuit> oh
1102015-11-29T10:41:15  <phantomcircuit> nvm
1112015-11-29T10:41:16  <phantomcircuit> :|
1122015-11-29T10:41:40  <sipa> phantomcircuit: well, it evicts after use in a block
1132015-11-29T10:41:41  <gmaxwell> e.g. so on full it evits the lowest feerate that went into the cache the most blocks ago.
1142015-11-29T10:41:47  <sipa> but not after use in mempool
1152015-11-29T10:42:18  <phantomcircuit> so there is also the issue that processing transactions into the mempool acquires cs_main
1162015-11-29T10:42:25  <phantomcircuit> which is bad for latency of gbt calls
1172015-11-29T10:42:25  <gmaxwell> (by lowest I don't mean a sort, I mean a N random draw...)
1182015-11-29T10:42:38  <phantomcircuit> soooo rpc "addsigcachentries"
1192015-11-29T10:42:53  * phantomcircuit runs away
1202015-11-29T10:44:10  <gmaxwell> die
1212015-11-29T10:45:08  <sipa> rpc "pollutecache"
1222015-11-29T10:47:00  <gmaxwell> should just hash random items in memory and add them, some might be signatures.
1232015-11-29T10:47:02  <phantomcircuit> :)
1242015-11-29T10:47:34  <phantomcircuit> <phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
1252015-11-29T10:47:36  <phantomcircuit> i wasn't lying
1262015-11-29T10:48:14  <gmaxwell> phantomcircuit: the obvious thing to do is to just have a EWMA minimum feerate for blocks, and any transaction over that, you verify even if its rejected.
1272015-11-29T10:48:59  <sipa> phantomcircuit: when you say insane, i should probably start worrying
1282015-11-29T10:49:15  <gmaxwell> (or over 0.95 * that)
1292015-11-29T10:49:46  <gmaxwell> sipa: dude, not like he's suggesting turning the G/2 nonce into a cryptosystem.
1302015-11-29T10:49:49  <tulip> would having two isolated sigcache (rejects, accepts) do roughly the same job?
1312015-11-29T10:50:29  <gmaxwell> tulip: probably no, because the rejects would get polluted and then not be useful (why have it)
1322015-11-29T10:50:32  <tulip> people can perform an eviction attack against the rejects cache of course, but that doesn't completely destroy your validation time.
1332015-11-29T10:50:35  <sipa> we don't have a negative cache now
1342015-11-29T10:51:42  <tulip> gmaxwell: suppose.
1352015-11-29T10:53:55  <sipa> gmaxwell: European Momputer Manufacturers Organization minimum feerate (sorry, google was slow in telling me what ECMA stood for)
1362015-11-29T10:54:05  <sipa> Womputer, of course
1372015-11-29T10:54:23  <gmaxwell> exponentially weighed moving average.
1382015-11-29T10:59:49  <sipa> ah, of course
1392015-11-29T11:00:30  <phantomcircuit> gmaxwell, EWMA ?
1402015-11-29T11:01:08  <sipa> phantomcircuit: European Momputer Manufacturers Organization.
1412015-11-29T11:03:29  <phantomcircuit> oh
1422015-11-29T11:03:31  <phantomcircuit> lol derp
1432015-11-29T11:03:38  <phantomcircuit> i should have continued reading before asking :)
1442015-11-29T11:10:25  <GitHub47> [bitcoin] sipa opened pull request #7129: Direct headers announcement (rebase of #6494) (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/7129
1452015-11-29T11:11:28  *** MarcoFalke has joined #bitcoin-core-dev
1462015-11-29T11:14:48  <gmaxwell> "that isn't merged yet"
1472015-11-29T11:15:41  <gmaxwell> "?"
1482015-11-29T11:16:21  <sipa> gmaxwell: i'll merge upon happy travis (though maybe someone should proofread my docs)
1492015-11-29T11:18:54  <gmaxwell> hm. so I wonder if the sigcache rejects stuff will have less pollution problems once limited mempool is more common?
1502015-11-29T11:19:09  <sipa> perhaps yes
1512015-11-29T11:19:10  <tulip> sipa: the docs read fine.
1522015-11-29T11:21:00  <phantomcircuit> gmaxwell, probably
1532015-11-29T11:21:10  <phantomcircuit> i actually like tulip's suggestion of having two sigcaches
1542015-11-29T11:21:24  <phantomcircuit> it handles the "i have lots of memory and dont care" case pretty well
1552015-11-29T11:27:57  <gmaxwell> why not have a seperate sigcache for each band of feerate? :P and if the highest feerate cache is full it evits to a lower feerate cache.
1562015-11-29T11:28:41  <gmaxwell> oh you could also put a neural network in it, and it could do unsupervised classification to decide which transactions will get confirmed... and ... :P
1572015-11-29T11:29:15  <sipa> and then skynet
1582015-11-29T11:29:25  <sipa> and a genisys block
1592015-11-29T11:31:48  <phantomcircuit> gmaxwell, hr
1602015-11-29T11:31:50  <phantomcircuit> har har
1612015-11-29T11:32:13  <phantomcircuit> but in all seriousness it's potentially a large win for miners and just annoying for everybody else
1622015-11-29T11:32:18  <gmaxwell> oh, and if your cache gets too big you can sign chunks of it and ship it off to peers, and they can send it back if you need it later...
1632015-11-29T11:32:47  <gmaxwell> phantomcircuit: not the kind of wins we should be hunting, because it presumes a more centeralized world of mining where running a mining node takes a lot of resources.
1642015-11-29T11:33:01  <gmaxwell> Better to spend effort on optimizations that don't need that.
1652015-11-29T11:35:05  <phantomcircuit> gmaxwell, which reminds me, what kind of work would you want to see before revising the advise on mining with a pruned node?
1662015-11-29T11:35:19  <gmaxwell> I think it's fine already.
1672015-11-29T11:35:55  <gmaxwell> "You mean you don't mine exclusively on pruned nodes?"  ... really the worse problem is that you're hosed in index corruption...
1682015-11-29T11:37:16  <phantomcircuit> gmaxwell, miners are hosed if their index is corrupt even without pruning
1692015-11-29T11:37:38  <phantomcircuit> hmm i seem to remember asking someone and getting a "wat dont do dat" response recently
1702015-11-29T11:37:39  <gmaxwell> it just means a three hour outage vs ... more.
1712015-11-29T11:37:51  <gmaxwell> I don't think you got that from me.
1722015-11-29T11:37:57  *** d_t has quit IRC
1732015-11-29T11:38:14  <sipa> you can always make a backup of the block chain data
1742015-11-29T11:38:15  <gmaxwell> like... half the reason I care about pruning is to try to rescue p2pool.
1752015-11-29T11:38:19  <phantomcircuit> gmaxwell, yes but it might mean running 5 nodes instead of 1
1762015-11-29T11:38:20  <sipa> and use that to recover a mining node
1772015-11-29T11:39:27  <gmaxwell> the main risk from pruning + mining is that you can't reorg past some depth, which means consensus fault; but we won't let you prune shallower than 288 blocks back to make that not much of a pratical concern.
1782015-11-29T11:39:41  <gmaxwell> (or at least if there is a 288 block reorg, manual intervention is.. least of the worries)
1792015-11-29T11:40:07  <gmaxwell> though we should make sure that that it cleanly fails (And importantly stops mining) if it tries a reorg beyond pruning.
1802015-11-29T11:42:47  <gmaxwell> phantomcircuit: if you're looking for mining related improvments; bringing back the old lukejr patch to forward unverified blocks would be an obvious candidate.
1812015-11-29T11:44:16  <gmaxwell> E.g. a new proto messages activated like sendheaders where you can say "here is a block, I haven't verified it"; you're allowed to relay it to others (as non-validated block) without validatiting long as the hash and headers checkout, and so long as it extends the current tip.
1822015-11-29T11:44:35  <gmaxwell> when luke did it before, it didn't speed anything up, but that was presumably because of all the dumb sleeps in networking.
1832015-11-29T11:45:22  <gmaxwell> I think this would reduce your mining complex by one node, since those relays wouldn't need to lock the chainstate, and so they wouldn't compete with create new block.
1842015-11-29T11:46:06  <sipa> checking whether it extends the current tip would need a lock
1852015-11-29T11:46:08  <phantomcircuit> gmaxwell, what happens generally if you try a reorg past the pruning depth?
1862015-11-29T11:46:17  <phantomcircuit> it should probably pull those blocks from peers
1872015-11-29T11:46:26  <gmaxwell> phantomcircuit: it can't. :( :(
1882015-11-29T11:46:30  <gmaxwell> undo data is gone too.
1892015-11-29T11:46:45  <sipa> though i guess you could have a pindexTipCopy which has an R/W lock, and is updated by the normal sync, but can be read (and used for verification) by other things
1902015-11-29T11:46:57  <gmaxwell> someday we could make undo data normative and commit to it, perhaps and then you could pull it.
1912015-11-29T11:47:02  <sipa> gmaxwell: i think the biggest bottleneck is the fact that message processing is single threaded
1922015-11-29T11:47:16  <tulip> phantomcircuit: 288 blocks is the minimum, if you reorg that far all of your peers have pinged out as well, it gets super messy and everything is likely on fire anyway.
1932015-11-29T11:47:27  <gmaxwell> sipa: doesn't happen that all our messaging hashes the data...
1942015-11-29T11:47:49  <sipa> gmaxwell: parse error
1952015-11-29T11:48:06  <gmaxwell> I'm just saying that message handling is computationally expensive.
1962015-11-29T11:48:16  <sipa> gmaxwell: so?
1972015-11-29T11:48:29  <phantomcircuit> gmaxwell, iirc the undo data is much smaller than the blocks
1982015-11-29T11:48:35  <sipa> phantomcircuit: a factor of 9
1992015-11-29T11:48:53  <phantomcircuit> ok so probably we should keep it going back 9x deeper than we do blocks
2002015-11-29T11:48:54  <gmaxwell> phantomcircuit: yes, and we could prune it to different depths, but keeping it all removes a lot of the pruning gains.
2012015-11-29T11:49:21  <sipa> gmaxwell: the fact that we're processing a new incoming block for half a second is no reason why we couldn't respond to a ping from another peer
2022015-11-29T11:50:19  <gmaxwell> On earlier; though I guess if we introduced a new p2p message for block relay, it should do RNC like compression.
2032015-11-29T11:50:34  <phantomcircuit> gmaxwell, for the average pool i suspect relaying before validating anything but the header would be a win even without the new p2p message to prevent getting banned
2042015-11-29T11:50:37  <gmaxwell> ... and bring MRU sets back to track what transactions we've sent a peer? :P
2052015-11-29T11:51:06  <gmaxwell> phantomcircuit: it's really important to not hand unvalidated blocks to spv clients.
2062015-11-29T11:53:36  <tulip> how do you prevent unvalidated blocks from becoming a DoS vector? 25BTC is expensive, but if I can make a block which takes you 2 minutes to validate it when you see it that could be a problem.
2072015-11-29T11:54:06  <tulip> (two minutes of grinding SHA256, then you find you have to reject it)
2082015-11-29T11:54:41  <phantomcircuit> gmaxwell, iirc the message hashing is done in the networking thread so it's at least partially threaded
2092015-11-29T11:55:18  <sipa> phantomcircuit: no
2102015-11-29T11:55:25  <sipa> only the checksum
2112015-11-29T11:55:29  <sipa> i think?
2122015-11-29T11:55:35  <sipa> yes
2132015-11-29T11:55:41  <phantomcircuit> i thought that's what he was talking about
2142015-11-29T11:56:11  <sipa> not the txid's, for example
2152015-11-29T11:56:26  <sipa> or sighashes which are even more work
2162015-11-29T11:56:28  <tulip> me? I was talking about sighash hashing.
2172015-11-29T11:57:33  <phantomcircuit> tulip, no i was talking about what gmaxwell said
2182015-11-29T11:57:56  <tulip> right.
2192015-11-29T11:58:38  <sipa> message handling is of course expensive; it's where block validation (and a part of signature validation even) happens
2202015-11-29T11:58:52  <sipa> doesn't mean it needs to be done single threadedly
2212015-11-29T12:05:51  *** randy-waterhouse has quit IRC
2222015-11-29T12:06:37  <GitHub182> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c894fbbb1dc0...5d5ef3a4cf8e
2232015-11-29T12:06:38  <GitHub182> bitcoin/master 50262d8 Suhas Daftuar: Allow block announcements with headers...
2242015-11-29T12:06:38  <GitHub182> bitcoin/master 49fb8e8 Pieter Wuille: Documentation updates for BIP 130
2252015-11-29T12:06:39  <GitHub182> bitcoin/master 5d5ef3a Pieter Wuille: Merge pull request #7129...
2262015-11-29T12:06:47  <GitHub38> [bitcoin] sipa closed pull request #7129: Direct headers announcement (rebase of #6494) (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/7129
2272015-11-29T12:07:02  <GitHub105> [bitcoin] sipa closed pull request #6494: Allow block announcements with headers (master...direct-headers-announcement) https://github.com/bitcoin/bitcoin/pull/6494
2282015-11-29T13:11:21  *** Thireus has quit IRC
2292015-11-29T13:14:57  *** Thireus has joined #bitcoin-core-dev
2302015-11-29T13:17:37  *** Thireus has joined #bitcoin-core-dev
2312015-11-29T13:19:46  *** Thireus has quit IRC
2322015-11-29T13:31:22  *** Thireus has joined #bitcoin-core-dev
2332015-11-29T14:08:11  *** morcos_ has quit IRC
2342015-11-29T14:08:43  *** sdaftuar_ has quit IRC
2352015-11-29T14:09:22  *** morcos has joined #bitcoin-core-dev
2362015-11-29T14:09:32  *** sdaftuar has joined #bitcoin-core-dev
2372015-11-29T14:29:15  *** [b__b] has joined #bitcoin-core-dev
2382015-11-29T14:38:18  *** tulip has quit IRC
2392015-11-29T14:42:25  *** BashCo has joined #bitcoin-core-dev
2402015-11-29T15:35:24  *** MarcoFalke has quit IRC
2412015-11-29T15:36:55  *** guest234234 has quit IRC
2422015-11-29T16:15:31  *** dgenr8 has joined #bitcoin-core-dev
2432015-11-29T16:18:28  *** zookolaptop has joined #bitcoin-core-dev
2442015-11-29T16:19:41  *** dgenr8 has quit IRC
2452015-11-29T16:27:47  *** dermoth has quit IRC
2462015-11-29T16:34:21  *** dermoth has joined #bitcoin-core-dev
2472015-11-29T16:34:31  *** Ylbam has quit IRC
2482015-11-29T16:37:12  *** JackH has joined #bitcoin-core-dev
2492015-11-29T16:53:52  *** pkthebud has quit IRC
2502015-11-29T16:54:38  *** moli has joined #bitcoin-core-dev
2512015-11-29T16:54:51  *** instagibbs has quit IRC
2522015-11-29T16:57:11  *** molly has quit IRC
2532015-11-29T16:59:15  *** zookolaptop has quit IRC
2542015-11-29T17:04:52  *** PaulCape_ has joined #bitcoin-core-dev
2552015-11-29T17:05:20  *** jgarzik has quit IRC
2562015-11-29T17:06:03  *** jgarzik has joined #bitcoin-core-dev
2572015-11-29T17:07:30  *** PaulCapestany has quit IRC
2582015-11-29T17:08:39  *** instagibbs has joined #bitcoin-core-dev
2592015-11-29T17:40:06  <phantomcircuit> morcos, when a block is invalidated are we updating CTxMempoolEntry::hadNoDependencies properly?
2602015-11-29T17:46:15  *** ParadoxSpiral_ has joined #bitcoin-core-dev
2612015-11-29T17:49:17  *** ParadoxSpiral has quit IRC
2622015-11-29T17:50:05  *** zookolaptop has joined #bitcoin-core-dev
2632015-11-29T17:53:30  *** Ylbam has joined #bitcoin-core-dev
2642015-11-29T18:15:39  *** d_t has joined #bitcoin-core-dev
2652015-11-29T18:21:11  *** davec has quit IRC
2662015-11-29T18:24:11  *** zookolaptop has quit IRC
2672015-11-29T18:31:08  *** davec has joined #bitcoin-core-dev
2682015-11-29T18:43:07  *** arubi has quit IRC
2692015-11-29T18:43:25  *** arubi has joined #bitcoin-core-dev
2702015-11-29T18:48:52  *** dgenr8 has joined #bitcoin-core-dev
2712015-11-29T19:04:28  *** d_t has quit IRC
2722015-11-29T19:09:02  *** d_t has joined #bitcoin-core-dev
2732015-11-29T19:33:43  *** zookolaptop has joined #bitcoin-core-dev
2742015-11-29T19:51:10  *** Guyver2 has joined #bitcoin-core-dev
2752015-11-29T20:24:15  *** raedah has joined #bitcoin-core-dev
2762015-11-29T20:32:00  *** cocoBTC has joined #bitcoin-core-dev
2772015-11-29T20:32:55  *** zookolaptop has quit IRC
2782015-11-29T20:36:20  *** instagibbs has quit IRC
2792015-11-29T20:37:36  *** instagibbs has joined #bitcoin-core-dev
2802015-11-29T20:38:56  *** helo has quit IRC
2812015-11-29T20:39:37  *** helo has joined #bitcoin-core-dev
2822015-11-29T20:40:25  *** PaulCapestany has joined #bitcoin-core-dev
2832015-11-29T20:42:48  *** davec has quit IRC
2842015-11-29T20:43:24  *** raedah has quit IRC
2852015-11-29T20:43:24  *** PaulCape_ has quit IRC
2862015-11-29T21:11:03  *** helo has quit IRC
2872015-11-29T21:11:04  *** d_t has quit IRC
2882015-11-29T21:11:04  *** ParadoxSpiral_ has quit IRC
2892015-11-29T21:11:06  *** teward has quit IRC
2902015-11-29T21:11:08  *** Apocalyptic has quit IRC
2912015-11-29T21:11:08  *** crescend1 has quit IRC
2922015-11-29T21:11:08  *** Taek has quit IRC
2932015-11-29T21:11:09  *** PRab has quit IRC
2942015-11-29T21:11:09  *** pigeons has quit IRC
2952015-11-29T21:11:19  *** helo has joined #bitcoin-core-dev
2962015-11-29T21:11:45  *** crescendo has joined #bitcoin-core-dev
2972015-11-29T21:12:08  *** PRab has joined #bitcoin-core-dev
2982015-11-29T21:17:25  *** d_t has joined #bitcoin-core-dev
2992015-11-29T21:20:01  *** teward has joined #bitcoin-core-dev
3002015-11-29T21:24:50  *** Ylbam has quit IRC
3012015-11-29T21:25:54  *** Taek has joined #bitcoin-core-dev
3022015-11-29T21:33:16  *** Ylbam has joined #bitcoin-core-dev
3032015-11-29T21:34:07  *** davec has joined #bitcoin-core-dev
3042015-11-29T21:35:19  *** ghtdak has quit IRC
3052015-11-29T21:37:32  *** Apocalyptic has joined #bitcoin-core-dev
3062015-11-29T21:37:54  *** ghtdak has joined #bitcoin-core-dev
3072015-11-29T21:40:26  *** pigeons has joined #bitcoin-core-dev
3082015-11-29T21:40:49  *** pigeons is now known as Guest23613
3092015-11-29T21:43:01  *** luke-jr_ has joined #bitcoin-core-dev
3102015-11-29T21:43:17  *** Luke-Jr has quit IRC
3112015-11-29T21:46:53  *** luke-jr_ has quit IRC
3122015-11-29T21:48:50  *** jonasschnelli has quit IRC
3132015-11-29T21:51:24  *** paveljanik has quit IRC
3142015-11-29T21:55:56  *** jonasschnelli has joined #bitcoin-core-dev
3152015-11-29T22:02:42  *** Guest23613 is now known as pigeons
3162015-11-29T22:11:33  *** tripleslash_u has joined #bitcoin-core-dev
3172015-11-29T22:11:36  *** Taek42 has joined #bitcoin-core-dev
3182015-11-29T22:12:01  *** Arnavion has quit IRC
3192015-11-29T22:12:05  *** Arnavion3 has joined #bitcoin-core-dev
3202015-11-29T22:12:09  *** Arnavion3 is now known as Arnavion
3212015-11-29T22:12:28  *** lecusemb1e has joined #bitcoin-core-dev
3222015-11-29T22:12:44  *** harding_ has joined #bitcoin-core-dev
3232015-11-29T22:12:44  *** wangchun_ has joined #bitcoin-core-dev
3242015-11-29T22:12:52  *** gribble has quit IRC
3252015-11-29T22:15:27  *** Ylbam has quit IRC
3262015-11-29T22:18:05  *** Apocalyptic has quit IRC
3272015-11-29T22:18:06  *** davec has quit IRC
3282015-11-29T22:18:10  *** Taek has quit IRC
3292015-11-29T22:18:16  *** Guyver2 has quit IRC
3302015-11-29T22:18:17  *** challisto has quit IRC
3312015-11-29T22:18:19  *** droark has quit IRC
3322015-11-29T22:18:20  *** AtashiCon has quit IRC
3332015-11-29T22:18:20  *** bsm117532 has quit IRC
3342015-11-29T22:18:20  *** berndj has quit IRC
3352015-11-29T22:18:20  *** nanotube has quit IRC
3362015-11-29T22:18:21  *** jcorgan has quit IRC
3372015-11-29T22:18:22  *** harding has quit IRC
3382015-11-29T22:18:22  *** warren has quit IRC
3392015-11-29T22:18:23  *** BlueMatt has quit IRC
3402015-11-29T22:18:23  *** tripleslash has quit IRC
3412015-11-29T22:18:23  *** lecusemble has quit IRC
3422015-11-29T22:18:23  *** Eliel has quit IRC
3432015-11-29T22:18:24  *** Guest1235 has quit IRC
3442015-11-29T22:18:24  *** wangchun has quit IRC
3452015-11-29T22:18:25  *** isis has quit IRC
3462015-11-29T22:18:26  *** da2ce7_ has quit IRC
3472015-11-29T22:18:26  *** kanzure has quit IRC
3482015-11-29T22:18:27  *** gmaxwell has quit IRC
3492015-11-29T22:18:28  *** BananaLotus has quit IRC
3502015-11-29T22:22:27  <morcos> phantomcircuit: i think its the same any time a block is disconnected (for instance reorg) and i believe the answer is no.
3512015-11-29T22:23:11  <morcos> I think that variable is only used for fee estimation though, so worst case is it makes you think a potentially high fee paying tx isn't getting confirmed
3522015-11-29T22:23:58  <morcos> Maybe its worth thinking about fixing that in some way just in case there is some degeneracy or attack which causes estiamtes to get too high, but i suspect in practice it has a neglible effect
3532015-11-29T22:24:03  *** therealnanotube has joined #bitcoin-core-dev
3542015-11-29T22:24:49  <morcos> We should probably also think about more clearly delineating which attributes of CTxMemPoolEntry are critical to be correct for a) consenus and b) other reasons
3552015-11-29T22:25:37  <morcos> Well nothing is critical for consensus, but for not wasting hashpower mining blocks only to discover they are invalid
3562015-11-29T22:26:48  <sipa> i guess the categories are 1) for maintaining mempool consistency 2) for mining 3) for fee estimation
3572015-11-29T22:28:13  <morcos> sipa: yes mempool consistency is a bit of a vague term though.   we should be more aware of what other code depends on some of the ancestor package information (mempool parents and children) being accurate to work properly.
3582015-11-29T22:28:42  <morcos> s/ancestor//
3592015-11-29T22:30:50  <morcos> a lot of code would be much simpler without reorgs, we should just change the rules to say the first block always wins
3602015-11-29T22:32:53  <sipa> right
3612015-11-29T22:37:37  *** Guest1234 has joined #bitcoin-core-dev
3622015-11-29T22:39:49  *** teward has quit IRC
3632015-11-29T22:39:50  *** AtashiCon has joined #bitcoin-core-dev
3642015-11-29T22:39:54  <phantomcircuit> morcos, i believe your cnb replacement incorrectly calculates which transactions are optimal because it's got the connections backwards
3652015-11-29T22:40:04  <phantomcircuit> we care about the ancestors not the dependents
3662015-11-29T22:40:17  <morcos> what? seriously?
3672015-11-29T22:40:29  *** tulip has joined #bitcoin-core-dev
3682015-11-29T22:40:42  *** BlueMatt has joined #bitcoin-core-dev
3692015-11-29T22:41:19  *** warren has joined #bitcoin-core-dev
3702015-11-29T22:41:21  <phantomcircuit> morcos, yeah i know we've talked about this before
3712015-11-29T22:41:29  <phantomcircuit> but i realized today that it's backwards from the mempool limiting stuff
3722015-11-29T22:41:34  <morcos> phantomcircuit: maybe we're talking about different things
3732015-11-29T22:41:56  <morcos> the rewrite of CNB does not try to incorporate a CPFP optimal mining strategy
3742015-11-29T22:42:05  *** challisto has joined #bitcoin-core-dev
3752015-11-29T22:42:06  *** challisto has joined #bitcoin-core-dev
3762015-11-29T22:42:14  <morcos> we talked about doing that, but i decided that was too much for 0.12 and wanted to get this huge speed up in
3772015-11-29T22:42:20  <morcos> i just checked and the code is write
3782015-11-29T22:42:32  *** bsm117532 has joined #bitcoin-core-dev
3792015-11-29T22:42:33  <morcos> all it cares about are dependencies for being able to be included in a block
3802015-11-29T22:42:45  <morcos> its functionally identical (almost) to the existing algorithm
3812015-11-29T22:42:54  <morcos> checked by producing the same blocks
3822015-11-29T22:42:54  <phantomcircuit> morcos, yes i know, im saying i dont think it implements any optimal strategy :P
3832015-11-29T22:42:57  *** BananaLotus has joined #bitcoin-core-dev
3842015-11-29T22:43:10  <morcos> yeah its not meant to, its just a speed up
3852015-11-29T22:43:18  <phantomcircuit> morcos, ah ok then
3862015-11-29T22:43:34  *** teward has joined #bitcoin-core-dev
3872015-11-29T22:43:40  <morcos> the ancestor package tracking thats necessary for otpimal blocks has already be writted by sdafuar, but there was no reason to merge it yet
3882015-11-29T22:43:47  *** davec has joined #bitcoin-core-dev
3892015-11-29T22:43:52  <morcos> s/optimal/hopefully better/
3902015-11-29T22:44:07  *** Apocalyptic has joined #bitcoin-core-dev
3912015-11-29T22:44:12  *** Eliel has joined #bitcoin-core-dev
3922015-11-29T22:44:27  *** kanzure has joined #bitcoin-core-dev
3932015-11-29T22:45:41  *** Luke-Jr has joined #bitcoin-core-dev
3942015-11-29T22:45:58  *** isis has joined #bitcoin-core-dev
3952015-11-29T22:46:17  <phantomcircuit> morcos, optimal is probably very hard
3962015-11-29T22:46:18  *** Ylbam has joined #bitcoin-core-dev
3972015-11-29T22:46:52  *** jcorgan has joined #bitcoin-core-dev
3982015-11-29T22:46:53  *** jcorgan has quit IRC
3992015-11-29T22:46:53  *** jcorgan has joined #bitcoin-core-dev
4002015-11-29T22:47:03  <phantomcircuit> morcos, knapsack problem with at least two optimization variables :|
4012015-11-29T22:47:16  <sipa> s/optimal/an approximation of optimal with reasonable conputational limits/
4022015-11-29T22:51:47  *** da2ce7 has joined #bitcoin-core-dev
4032015-11-29T22:53:41  *** Anduck_ has joined #bitcoin-core-dev
4042015-11-29T22:54:06  *** Guest76338 has joined #bitcoin-core-dev
4052015-11-29T22:54:18  *** Guest76338 has quit IRC
4062015-11-29T22:55:21  *** gribble has joined #bitcoin-core-dev
4072015-11-29T22:55:48  *** Anduck__ has joined #bitcoin-core-dev
4082015-11-29T22:56:51  *** gmaxwell has joined #bitcoin-core-dev
4092015-11-29T22:56:52  *** Anduck__ has quit IRC
4102015-11-29T22:57:12  *** jonasschnelli has quit IRC
4112015-11-29T22:57:15  *** gmaxwell is now known as Guest19298
4122015-11-29T22:57:20  *** Anduck__ has joined #bitcoin-core-dev
4132015-11-29T22:59:05  *** Anduck has quit IRC
4142015-11-29T22:59:11  *** Anduck__ is now known as Anduck
4152015-11-29T23:04:54  *** Guest19298 has quit IRC
4162015-11-29T23:04:54  *** Guest19298 has joined #bitcoin-core-dev
4172015-11-29T23:05:03  *** Guest19298 is now known as gmaxwell
4182015-11-29T23:08:29  *** moli has quit IRC
4192015-11-29T23:11:33  *** BashCo has quit IRC
4202015-11-29T23:12:34  *** jonasschnelli has joined #bitcoin-core-dev
4212015-11-29T23:18:06  *** guest234234 has joined #bitcoin-core-dev
4222015-11-29T23:24:19  *** molly has joined #bitcoin-core-dev
4232015-11-29T23:25:10  *** berndj has joined #bitcoin-core-dev
4242015-11-29T23:32:00  *** jonasschnelli has quit IRC
4252015-11-29T23:32:46  *** cocoBTC has quit IRC
4262015-11-29T23:34:26  *** jonasschnelli has joined #bitcoin-core-dev
4272015-11-29T23:57:12  *** Ylbam has quit IRC
4282015-11-29T23:59:10  *** randy-waterhouse has joined #bitcoin-core-dev