1 2015-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
  2 2015-11-29T00:10:01  <GitHub27> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/61457c29d735...c894fbbb1dc0
  3 2015-11-29T00:10:01  <GitHub27> bitcoin/master a9f3d3d Pieter Wuille: Fix and improve relay from whitelisted peers...
  4 2015-11-29T00:10:02  <GitHub27> bitcoin/master c894fbb Gregory Maxwell: Merge pull request #7106...
  5 2015-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
  6 2015-11-29T00:19:01  *** michagogo has quit IRC
  7 2015-11-29T01:44:31  *** Ylbam has quit IRC
  8 2015-11-29T01:45:09  *** jtimon has joined #bitcoin-core-dev
  9 2015-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
 10 2015-11-29T02:10:16  *** raedah has quit IRC
 11 2015-11-29T02:56:10  *** PaulCapestany has quit IRC
 12 2015-11-29T02:56:38  *** PaulCapestany has joined #bitcoin-core-dev
 13 2015-11-29T03:14:22  *** guest234234 has joined #bitcoin-core-dev
 14 2015-11-29T03:23:25  *** PaulCapestany has quit IRC
 15 2015-11-29T03:23:55  *** PaulCapestany has joined #bitcoin-core-dev
 16 2015-11-29T03:24:22  *** PaulCapestany has quit IRC
 17 2015-11-29T03:25:14  *** Thireus has quit IRC
 18 2015-11-29T03:25:40  *** PaulCapestany has joined #bitcoin-core-dev
 19 2015-11-29T03:36:35  *** Thireus has joined #bitcoin-core-dev
 20 2015-11-29T05:05:20  *** Dyanisus has joined #bitcoin-core-dev
 21 2015-11-29T06:07:44  *** zookolaptop has joined #bitcoin-core-dev
 22 2015-11-29T06:11:02  *** guest234234 has quit IRC
 23 2015-11-29T06:33:42  *** tulip has joined #bitcoin-core-dev
 24 2015-11-29T06:34:34  *** tulip has quit IRC
 25 2015-11-29T06:34:45  *** tulip has joined #bitcoin-core-dev
 26 2015-11-29T06:48:11  *** zookolaptop has quit IRC
 27 2015-11-29T07:03:44  *** randy-waterhouse has joined #bitcoin-core-dev
 28 2015-11-29T07:13:10  *** CodeShark_ has quit IRC
 29 2015-11-29T07:27:58  *** guest234234 has joined #bitcoin-core-dev
 30 2015-11-29T07:47:51  *** tulip has quit IRC
 31 2015-11-29T07:52:26  *** tulip has joined #bitcoin-core-dev
 32 2015-11-29T07:57:24  *** ParadoxSpiral has joined #bitcoin-core-dev
 33 2015-11-29T08:12:48  *** challisto has quit IRC
 34 2015-11-29T08:21:40  *** Guyver2 has joined #bitcoin-core-dev
 35 2015-11-29T08:25:42  *** challisto has joined #bitcoin-core-dev
 36 2015-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?
 37 2015-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.
 38 2015-11-29T08:58:26  <gmaxwell> Not the actual data, but set reconcile the TXids and then getdata the bodies you need.
 39 2015-11-29T08:58:50  *** Ylbam has joined #bitcoin-core-dev
 40 2015-11-29T08:59:05  <phantomcircuit> gmaxwell, yes long term goal for sure
 41 2015-11-29T08:59:12  <phantomcircuit> but i can do this version like
 42 2015-11-29T08:59:13  <phantomcircuit> today
 43 2015-11-29T09:02:06  <phantomcircuit> gmaxwell, can you rename setInventoryKnown to filterInventoryKnown
 44 2015-11-29T09:02:20  <phantomcircuit> there's a bunch of those now that are a bit confusing because of not changing the name
 45 2015-11-29T09:18:40  *** Guyver2 has quit IRC
 46 2015-11-29T09:29:23  <phantomcircuit> gmaxwell, im pretty sure there's a bug in 7100
 47 2015-11-29T09:29:40  <phantomcircuit> it looks like you can get a false positive inv for blocks
 48 2015-11-29T09:31:45  <gmaxwell> phantomcircuit: where?
 49 2015-11-29T09:33:17  <phantomcircuit> gmaxwell, "getblocks" calls pfrom->PushInventory which uses setInventoryKnown to decide whether to actually do that
 50 2015-11-29T09:33:37  <phantomcircuit> so a false positive could prevent a block inv as well as tx inv
 51 2015-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
 52 2015-11-29T09:33:59  <gmaxwell> agreed.
 53 2015-11-29T09:34:20  <phantomcircuit> so im thinking there needs to be a setInventoryKnownBlocks and filterInventoryKnownTransactions
 54 2015-11-29T09:39:05  <sipa> with 6494 we can just drop the known blocks
 55 2015-11-29T09:39:28  <sipa> as we keep track much more efficiently what peers know
 56 2015-11-29T09:44:06  <phantomcircuit> sipa, yes i agree that's a better solution
 57 2015-11-29T09:44:43  <phantomcircuit> except it's optional so we would still need the setInventoryKnownBlocks
 58 2015-11-29T09:44:58  <phantomcircuit> (or maybe we simply always send block invs ?)
 59 2015-11-29T09:45:49  <sipa> yes, we should always send them
 60 2015-11-29T09:47:10  <sipa> i'll rebase #6494; it's overdue for merging
 61 2015-11-29T09:57:51  <phantomcircuit> gmaxwell, https://github.com/gmaxwell/bitcoin/pull/2
 62 2015-11-29T09:57:52  *** Thireus has quit IRC
 63 2015-11-29T09:59:26  *** Thireus has joined #bitcoin-core-dev
 64 2015-11-29T10:03:57  <gmaxwell> woot, managed to apply that without loading the webpage.
 65 2015-11-29T10:05:44  <sipa> you have now passed the entry exam for the school for git wizardry and magic
 66 2015-11-29T10:06:26  <gmaxwell> well the git part was never a problem, just the github part. :P
 67 2015-11-29T10:07:48  <phantomcircuit> just gotta know the special pulls refspec
 68 2015-11-29T10:11:21  <phantomcircuit> sipa, in 7113 you calculate the optimal number of hash functions and then restrict it to 1-50
 69 2015-11-29T10:11:22  <phantomcircuit> why?
 70 2015-11-29T10:14:22  <phantomcircuit> an fp rate of 1/10^15 would get you nHashFuncs ~= 50
 71 2015-11-29T10:14:40  <phantomcircuit> i dont see this being an issue
 72 2015-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 :)
 73 2015-11-29T10:18:59  <sipa> functions, depended
 74 2015-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
 75 2015-11-29T10:31:57  <sipa> phantomcircuit: do that on top of morcos' rewrite then :)
 76 2015-11-29T10:32:22  <phantomcircuit> sipa, it's a trivial 1 line change so i was mostly just wondering about the concept
 77 2015-11-29T10:32:32  <sipa> ok
 78 2015-11-29T10:32:51  <phantomcircuit> it seems like a good idea to me but i just thought of it soo
 79 2015-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
 80 2015-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. :(
 81 2015-11-29T10:35:40  <sipa> should be trivial now that we remember time-in-mempool
 82 2015-11-29T10:36:00  <gmaxwell> hm. actually yea, you'd just skip them, so it doesn't change the sort.
 83 2015-11-29T10:36:16  <sipa> indeed
 84 2015-11-29T10:36:24  <phantomcircuit> sipa, it's been a trivial 1 loc patch for about a year now
 85 2015-11-29T10:36:45  <sipa> orly?
 86 2015-11-29T10:37:01  <phantomcircuit> actually more than that
 87 2015-11-29T10:37:09  <phantomcircuit> Date:   Mon Nov 11 17:35:14 2013 +1000
 88 2015-11-29T10:37:16  <sipa> ha, wow
 89 2015-11-29T10:37:38  <phantomcircuit> on a related note
 90 2015-11-29T10:37:55  <phantomcircuit> we want to maximally prime the sigcache for receiving a block
 91 2015-11-29T10:38:00  <phantomcircuit> while also limiting the mempool
 92 2015-11-29T10:38:11  <phantomcircuit> these are kind of at odds at the moment
 93 2015-11-29T10:38:29  <gmaxwell> I tried to have sipa verify rejects and it polluted the crap out of his cache.
 94 2015-11-29T10:38:33  <phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
 95 2015-11-29T10:38:42  <gmaxwell> it actually makes sense to verify rejects for several reasons.
 96 2015-11-29T10:38:52  <gmaxwell> but I think we have to improve cache management first.
 97 2015-11-29T10:38:56  <phantomcircuit> gmaxwell, well for a miner you can just run with a huge sigcache
 98 2015-11-29T10:39:01  <phantomcircuit> i've got mine set to 4GB...
 99 2015-11-29T10:39:28  <gmaxwell> Sipa found it was polluting it even with a stupidly big one. (but not that stupidly big)
100 2015-11-29T10:39:53  <phantomcircuit> yeah the definition of stupidly big varies here :)
101 2015-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
102 2015-11-29T10:40:21  <sipa> hey let's use a rolling bloom filter for tue sigcache!!!
103 2015-11-29T10:40:23  <sipa> *ducks*
104 2015-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.
105 2015-11-29T10:41:06  <phantomcircuit> the cache doesn't evict when a block is found does it?
106 2015-11-29T10:41:10  <phantomcircuit> that would be an easy win
107 2015-11-29T10:41:11  <sipa> it does
108 2015-11-29T10:41:12  <gmaxwell> e.g. attach feerate and "tip change counter" to entries in the cache, and evict using them.
109 2015-11-29T10:41:14  <phantomcircuit> oh
110 2015-11-29T10:41:15  <phantomcircuit> nvm
111 2015-11-29T10:41:16  <phantomcircuit> :|
112 2015-11-29T10:41:40  <sipa> phantomcircuit: well, it evicts after use in a block
113 2015-11-29T10:41:41  <gmaxwell> e.g. so on full it evits the lowest feerate that went into the cache the most blocks ago.
114 2015-11-29T10:41:47  <sipa> but not after use in mempool
115 2015-11-29T10:42:18  <phantomcircuit> so there is also the issue that processing transactions into the mempool acquires cs_main
116 2015-11-29T10:42:25  <phantomcircuit> which is bad for latency of gbt calls
117 2015-11-29T10:42:25  <gmaxwell> (by lowest I don't mean a sort, I mean a N random draw...)
118 2015-11-29T10:42:38  <phantomcircuit> soooo rpc "addsigcachentries"
119 2015-11-29T10:42:53  * phantomcircuit runs away
120 2015-11-29T10:44:10  <gmaxwell> die
121 2015-11-29T10:45:08  <sipa> rpc "pollutecache"
122 2015-11-29T10:47:00  <gmaxwell> should just hash random items in memory and add them, some might be signatures.
123 2015-11-29T10:47:02  <phantomcircuit> :)
124 2015-11-29T10:47:34  <phantomcircuit> <phantomcircuit> i've got a few ideas of how to deal with this but they are admittedly mostly insane
125 2015-11-29T10:47:36  <phantomcircuit> i wasn't lying
126 2015-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.
127 2015-11-29T10:48:59  <sipa> phantomcircuit: when you say insane, i should probably start worrying
128 2015-11-29T10:49:15  <gmaxwell> (or over 0.95 * that)
129 2015-11-29T10:49:46  <gmaxwell> sipa: dude, not like he's suggesting turning the G/2 nonce into a cryptosystem.
130 2015-11-29T10:49:49  <tulip> would having two isolated sigcache (rejects, accepts) do roughly the same job?
131 2015-11-29T10:50:29  <gmaxwell> tulip: probably no, because the rejects would get polluted and then not be useful (why have it)
132 2015-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.
133 2015-11-29T10:50:35  <sipa> we don't have a negative cache now
134 2015-11-29T10:51:42  <tulip> gmaxwell: suppose.
135 2015-11-29T10:53:55  <sipa> gmaxwell: European Momputer Manufacturers Organization minimum feerate (sorry, google was slow in telling me what ECMA stood for)
136 2015-11-29T10:54:05  <sipa> Womputer, of course
137 2015-11-29T10:54:23  <gmaxwell> exponentially weighed moving average.
138 2015-11-29T10:59:49  <sipa> ah, of course
139 2015-11-29T11:00:30  <phantomcircuit> gmaxwell, EWMA ?
140 2015-11-29T11:01:08  <sipa> phantomcircuit: European Momputer Manufacturers Organization.
141 2015-11-29T11:03:29  <phantomcircuit> oh
142 2015-11-29T11:03:31  <phantomcircuit> lol derp
143 2015-11-29T11:03:38  <phantomcircuit> i should have continued reading before asking :)
144 2015-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
145 2015-11-29T11:11:28  *** MarcoFalke has joined #bitcoin-core-dev
146 2015-11-29T11:14:48  <gmaxwell> "that isn't merged yet"
147 2015-11-29T11:15:41  <gmaxwell> "?"
148 2015-11-29T11:16:21  <sipa> gmaxwell: i'll merge upon happy travis (though maybe someone should proofread my docs)
149 2015-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?
150 2015-11-29T11:19:09  <sipa> perhaps yes
151 2015-11-29T11:19:10  <tulip> sipa: the docs read fine.
152 2015-11-29T11:21:00  <phantomcircuit> gmaxwell, probably
153 2015-11-29T11:21:10  <phantomcircuit> i actually like tulip's suggestion of having two sigcaches
154 2015-11-29T11:21:24  <phantomcircuit> it handles the "i have lots of memory and dont care" case pretty well
155 2015-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.
156 2015-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
157 2015-11-29T11:29:15  <sipa> and then skynet
158 2015-11-29T11:29:25  <sipa> and a genisys block
159 2015-11-29T11:31:48  <phantomcircuit> gmaxwell, hr
160 2015-11-29T11:31:50  <phantomcircuit> har har
161 2015-11-29T11:32:13  <phantomcircuit> but in all seriousness it's potentially a large win for miners and just annoying for everybody else
162 2015-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...
163 2015-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.
164 2015-11-29T11:33:01  <gmaxwell> Better to spend effort on optimizations that don't need that.
165 2015-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?
166 2015-11-29T11:35:19  <gmaxwell> I think it's fine already.
167 2015-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...
168 2015-11-29T11:37:16  <phantomcircuit> gmaxwell, miners are hosed if their index is corrupt even without pruning
169 2015-11-29T11:37:38  <phantomcircuit> hmm i seem to remember asking someone and getting a "wat dont do dat" response recently
170 2015-11-29T11:37:39  <gmaxwell> it just means a three hour outage vs ... more.
171 2015-11-29T11:37:51  <gmaxwell> I don't think you got that from me.
172 2015-11-29T11:37:57  *** d_t has quit IRC
173 2015-11-29T11:38:14  <sipa> you can always make a backup of the block chain data
174 2015-11-29T11:38:15  <gmaxwell> like... half the reason I care about pruning is to try to rescue p2pool.
175 2015-11-29T11:38:19  <phantomcircuit> gmaxwell, yes but it might mean running 5 nodes instead of 1
176 2015-11-29T11:38:20  <sipa> and use that to recover a mining node
177 2015-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.
178 2015-11-29T11:39:41  <gmaxwell> (or at least if there is a 288 block reorg, manual intervention is.. least of the worries)
179 2015-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.
180 2015-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.
181 2015-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.
182 2015-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.
183 2015-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.
184 2015-11-29T11:46:06  <sipa> checking whether it extends the current tip would need a lock
185 2015-11-29T11:46:08  <phantomcircuit> gmaxwell, what happens generally if you try a reorg past the pruning depth?
186 2015-11-29T11:46:17  <phantomcircuit> it should probably pull those blocks from peers
187 2015-11-29T11:46:26  <gmaxwell> phantomcircuit: it can't. :( :(
188 2015-11-29T11:46:30  <gmaxwell> undo data is gone too.
189 2015-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
190 2015-11-29T11:46:57  <gmaxwell> someday we could make undo data normative and commit to it, perhaps and then you could pull it.
191 2015-11-29T11:47:02  <sipa> gmaxwell: i think the biggest bottleneck is the fact that message processing is single threaded
192 2015-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.
193 2015-11-29T11:47:27  <gmaxwell> sipa: doesn't happen that all our messaging hashes the data...
194 2015-11-29T11:47:49  <sipa> gmaxwell: parse error
195 2015-11-29T11:48:06  <gmaxwell> I'm just saying that message handling is computationally expensive.
196 2015-11-29T11:48:16  <sipa> gmaxwell: so?
197 2015-11-29T11:48:29  <phantomcircuit> gmaxwell, iirc the undo data is much smaller than the blocks
198 2015-11-29T11:48:35  <sipa> phantomcircuit: a factor of 9
199 2015-11-29T11:48:53  <phantomcircuit> ok so probably we should keep it going back 9x deeper than we do blocks
200 2015-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.
201 2015-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
202 2015-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.
203 2015-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
204 2015-11-29T11:50:37  <gmaxwell> ... and bring MRU sets back to track what transactions we've sent a peer? :P
205 2015-11-29T11:51:06  <gmaxwell> phantomcircuit: it's really important to not hand unvalidated blocks to spv clients.
206 2015-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.
207 2015-11-29T11:54:06  <tulip> (two minutes of grinding SHA256, then you find you have to reject it)
208 2015-11-29T11:54:41  <phantomcircuit> gmaxwell, iirc the message hashing is done in the networking thread so it's at least partially threaded
209 2015-11-29T11:55:18  <sipa> phantomcircuit: no
210 2015-11-29T11:55:25  <sipa> only the checksum
211 2015-11-29T11:55:29  <sipa> i think?
212 2015-11-29T11:55:35  <sipa> yes
213 2015-11-29T11:55:41  <phantomcircuit> i thought that's what he was talking about
214 2015-11-29T11:56:11  <sipa> not the txid's, for example
215 2015-11-29T11:56:26  <sipa> or sighashes which are even more work
216 2015-11-29T11:56:28  <tulip> me? I was talking about sighash hashing.
217 2015-11-29T11:57:33  <phantomcircuit> tulip, no i was talking about what gmaxwell said
218 2015-11-29T11:57:56  <tulip> right.
219 2015-11-29T11:58:38  <sipa> message handling is of course expensive; it's where block validation (and a part of signature validation even) happens
220 2015-11-29T11:58:52  <sipa> doesn't mean it needs to be done single threadedly
221 2015-11-29T12:05:51  *** randy-waterhouse has quit IRC
222 2015-11-29T12:06:37  <GitHub182> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c894fbbb1dc0...5d5ef3a4cf8e
223 2015-11-29T12:06:38  <GitHub182> bitcoin/master 50262d8 Suhas Daftuar: Allow block announcements with headers...
224 2015-11-29T12:06:38  <GitHub182> bitcoin/master 49fb8e8 Pieter Wuille: Documentation updates for BIP 130
225 2015-11-29T12:06:39  <GitHub182> bitcoin/master 5d5ef3a Pieter Wuille: Merge pull request #7129...
226 2015-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
227 2015-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
228 2015-11-29T13:11:21  *** Thireus has quit IRC
229 2015-11-29T13:14:57  *** Thireus has joined #bitcoin-core-dev
230 2015-11-29T13:17:37  *** Thireus has joined #bitcoin-core-dev
231 2015-11-29T13:19:46  *** Thireus has quit IRC
232 2015-11-29T13:31:22  *** Thireus has joined #bitcoin-core-dev
233 2015-11-29T14:08:11  *** morcos_ has quit IRC
234 2015-11-29T14:08:43  *** sdaftuar_ has quit IRC
235 2015-11-29T14:09:22  *** morcos has joined #bitcoin-core-dev
236 2015-11-29T14:09:32  *** sdaftuar has joined #bitcoin-core-dev
237 2015-11-29T14:29:15  *** [b__b] has joined #bitcoin-core-dev
238 2015-11-29T14:38:18  *** tulip has quit IRC
239 2015-11-29T14:42:25  *** BashCo has joined #bitcoin-core-dev
240 2015-11-29T15:35:24  *** MarcoFalke has quit IRC
241 2015-11-29T15:36:55  *** guest234234 has quit IRC
242 2015-11-29T16:15:31  *** dgenr8 has joined #bitcoin-core-dev
243 2015-11-29T16:18:28  *** zookolaptop has joined #bitcoin-core-dev
244 2015-11-29T16:19:41  *** dgenr8 has quit IRC
245 2015-11-29T16:27:47  *** dermoth has quit IRC
246 2015-11-29T16:34:21  *** dermoth has joined #bitcoin-core-dev
247 2015-11-29T16:34:31  *** Ylbam has quit IRC
248 2015-11-29T16:37:12  *** JackH has joined #bitcoin-core-dev
249 2015-11-29T16:53:52  *** pkthebud has quit IRC
250 2015-11-29T16:54:38  *** moli has joined #bitcoin-core-dev
251 2015-11-29T16:54:51  *** instagibbs has quit IRC
252 2015-11-29T16:57:11  *** molly has quit IRC
253 2015-11-29T16:59:15  *** zookolaptop has quit IRC
254 2015-11-29T17:04:52  *** PaulCape_ has joined #bitcoin-core-dev
255 2015-11-29T17:05:20  *** jgarzik has quit IRC
256 2015-11-29T17:06:03  *** jgarzik has joined #bitcoin-core-dev
257 2015-11-29T17:07:30  *** PaulCapestany has quit IRC
258 2015-11-29T17:08:39  *** instagibbs has joined #bitcoin-core-dev
259 2015-11-29T17:40:06  <phantomcircuit> morcos, when a block is invalidated are we updating CTxMempoolEntry::hadNoDependencies properly?
260 2015-11-29T17:46:15  *** ParadoxSpiral_ has joined #bitcoin-core-dev
261 2015-11-29T17:49:17  *** ParadoxSpiral has quit IRC
262 2015-11-29T17:50:05  *** zookolaptop has joined #bitcoin-core-dev
263 2015-11-29T17:53:30  *** Ylbam has joined #bitcoin-core-dev
264 2015-11-29T18:15:39  *** d_t has joined #bitcoin-core-dev
265 2015-11-29T18:21:11  *** davec has quit IRC
266 2015-11-29T18:24:11  *** zookolaptop has quit IRC
267 2015-11-29T18:31:08  *** davec has joined #bitcoin-core-dev
268 2015-11-29T18:43:07  *** arubi has quit IRC
269 2015-11-29T18:43:25  *** arubi has joined #bitcoin-core-dev
270 2015-11-29T18:48:52  *** dgenr8 has joined #bitcoin-core-dev
271 2015-11-29T19:04:28  *** d_t has quit IRC
272 2015-11-29T19:09:02  *** d_t has joined #bitcoin-core-dev
273 2015-11-29T19:33:43  *** zookolaptop has joined #bitcoin-core-dev
274 2015-11-29T19:51:10  *** Guyver2 has joined #bitcoin-core-dev
275 2015-11-29T20:24:15  *** raedah has joined #bitcoin-core-dev
276 2015-11-29T20:32:00  *** cocoBTC has joined #bitcoin-core-dev
277 2015-11-29T20:32:55  *** zookolaptop has quit IRC
278 2015-11-29T20:36:20  *** instagibbs has quit IRC
279 2015-11-29T20:37:36  *** instagibbs has joined #bitcoin-core-dev
280 2015-11-29T20:38:56  *** helo has quit IRC
281 2015-11-29T20:39:37  *** helo has joined #bitcoin-core-dev
282 2015-11-29T20:40:25  *** PaulCapestany has joined #bitcoin-core-dev
283 2015-11-29T20:42:48  *** davec has quit IRC
284 2015-11-29T20:43:24  *** raedah has quit IRC
285 2015-11-29T20:43:24  *** PaulCape_ has quit IRC
286 2015-11-29T21:11:03  *** helo has quit IRC
287 2015-11-29T21:11:04  *** d_t has quit IRC
288 2015-11-29T21:11:04  *** ParadoxSpiral_ has quit IRC
289 2015-11-29T21:11:06  *** teward has quit IRC
290 2015-11-29T21:11:08  *** Apocalyptic has quit IRC
291 2015-11-29T21:11:08  *** crescend1 has quit IRC
292 2015-11-29T21:11:08  *** Taek has quit IRC
293 2015-11-29T21:11:09  *** PRab has quit IRC
294 2015-11-29T21:11:09  *** pigeons has quit IRC
295 2015-11-29T21:11:19  *** helo has joined #bitcoin-core-dev
296 2015-11-29T21:11:45  *** crescendo has joined #bitcoin-core-dev
297 2015-11-29T21:12:08  *** PRab has joined #bitcoin-core-dev
298 2015-11-29T21:17:25  *** d_t has joined #bitcoin-core-dev
299 2015-11-29T21:20:01  *** teward has joined #bitcoin-core-dev
300 2015-11-29T21:24:50  *** Ylbam has quit IRC
301 2015-11-29T21:25:54  *** Taek has joined #bitcoin-core-dev
302 2015-11-29T21:33:16  *** Ylbam has joined #bitcoin-core-dev
303 2015-11-29T21:34:07  *** davec has joined #bitcoin-core-dev
304 2015-11-29T21:35:19  *** ghtdak has quit IRC
305 2015-11-29T21:37:32  *** Apocalyptic has joined #bitcoin-core-dev
306 2015-11-29T21:37:54  *** ghtdak has joined #bitcoin-core-dev
307 2015-11-29T21:40:26  *** pigeons has joined #bitcoin-core-dev
308 2015-11-29T21:40:49  *** pigeons is now known as Guest23613
309 2015-11-29T21:43:01  *** luke-jr_ has joined #bitcoin-core-dev
310 2015-11-29T21:43:17  *** Luke-Jr has quit IRC
311 2015-11-29T21:46:53  *** luke-jr_ has quit IRC
312 2015-11-29T21:48:50  *** jonasschnelli has quit IRC
313 2015-11-29T21:51:24  *** paveljanik has quit IRC
314 2015-11-29T21:55:56  *** jonasschnelli has joined #bitcoin-core-dev
315 2015-11-29T22:02:42  *** Guest23613 is now known as pigeons
316 2015-11-29T22:11:33  *** tripleslash_u has joined #bitcoin-core-dev
317 2015-11-29T22:11:36  *** Taek42 has joined #bitcoin-core-dev
318 2015-11-29T22:12:01  *** Arnavion has quit IRC
319 2015-11-29T22:12:05  *** Arnavion3 has joined #bitcoin-core-dev
320 2015-11-29T22:12:09  *** Arnavion3 is now known as Arnavion
321 2015-11-29T22:12:28  *** lecusemb1e has joined #bitcoin-core-dev
322 2015-11-29T22:12:44  *** harding_ has joined #bitcoin-core-dev
323 2015-11-29T22:12:44  *** wangchun_ has joined #bitcoin-core-dev
324 2015-11-29T22:12:52  *** gribble has quit IRC
325 2015-11-29T22:15:27  *** Ylbam has quit IRC
326 2015-11-29T22:18:05  *** Apocalyptic has quit IRC
327 2015-11-29T22:18:06  *** davec has quit IRC
328 2015-11-29T22:18:10  *** Taek has quit IRC
329 2015-11-29T22:18:16  *** Guyver2 has quit IRC
330 2015-11-29T22:18:17  *** challisto has quit IRC
331 2015-11-29T22:18:19  *** droark has quit IRC
332 2015-11-29T22:18:20  *** AtashiCon has quit IRC
333 2015-11-29T22:18:20  *** bsm117532 has quit IRC
334 2015-11-29T22:18:20  *** berndj has quit IRC
335 2015-11-29T22:18:20  *** nanotube has quit IRC
336 2015-11-29T22:18:21  *** jcorgan has quit IRC
337 2015-11-29T22:18:22  *** harding has quit IRC
338 2015-11-29T22:18:22  *** warren has quit IRC
339 2015-11-29T22:18:23  *** BlueMatt has quit IRC
340 2015-11-29T22:18:23  *** tripleslash has quit IRC
341 2015-11-29T22:18:23  *** lecusemble has quit IRC
342 2015-11-29T22:18:23  *** Eliel has quit IRC
343 2015-11-29T22:18:24  *** Guest1235 has quit IRC
344 2015-11-29T22:18:24  *** wangchun has quit IRC
345 2015-11-29T22:18:25  *** isis has quit IRC
346 2015-11-29T22:18:26  *** da2ce7_ has quit IRC
347 2015-11-29T22:18:26  *** kanzure has quit IRC
348 2015-11-29T22:18:27  *** gmaxwell has quit IRC
349 2015-11-29T22:18:28  *** BananaLotus has quit IRC
350 2015-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.
351 2015-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
352 2015-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
353 2015-11-29T22:24:03  *** therealnanotube has joined #bitcoin-core-dev
354 2015-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
355 2015-11-29T22:25:37  <morcos> Well nothing is critical for consensus, but for not wasting hashpower mining blocks only to discover they are invalid
356 2015-11-29T22:26:48  <sipa> i guess the categories are 1) for maintaining mempool consistency 2) for mining 3) for fee estimation
357 2015-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.
358 2015-11-29T22:28:42  <morcos> s/ancestor//
359 2015-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
360 2015-11-29T22:32:53  <sipa> right
361 2015-11-29T22:37:37  *** Guest1234 has joined #bitcoin-core-dev
362 2015-11-29T22:39:49  *** teward has quit IRC
363 2015-11-29T22:39:50  *** AtashiCon has joined #bitcoin-core-dev
364 2015-11-29T22:39:54  <phantomcircuit> morcos, i believe your cnb replacement incorrectly calculates which transactions are optimal because it's got the connections backwards
365 2015-11-29T22:40:04  <phantomcircuit> we care about the ancestors not the dependents
366 2015-11-29T22:40:17  <morcos> what? seriously?
367 2015-11-29T22:40:29  *** tulip has joined #bitcoin-core-dev
368 2015-11-29T22:40:42  *** BlueMatt has joined #bitcoin-core-dev
369 2015-11-29T22:41:19  *** warren has joined #bitcoin-core-dev
370 2015-11-29T22:41:21  <phantomcircuit> morcos, yeah i know we've talked about this before
371 2015-11-29T22:41:29  <phantomcircuit> but i realized today that it's backwards from the mempool limiting stuff
372 2015-11-29T22:41:34  <morcos> phantomcircuit: maybe we're talking about different things
373 2015-11-29T22:41:56  <morcos> the rewrite of CNB does not try to incorporate a CPFP optimal mining strategy
374 2015-11-29T22:42:05  *** challisto has joined #bitcoin-core-dev
375 2015-11-29T22:42:06  *** challisto has joined #bitcoin-core-dev
376 2015-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
377 2015-11-29T22:42:20  <morcos> i just checked and the code is write
378 2015-11-29T22:42:32  *** bsm117532 has joined #bitcoin-core-dev
379 2015-11-29T22:42:33  <morcos> all it cares about are dependencies for being able to be included in a block
380 2015-11-29T22:42:45  <morcos> its functionally identical (almost) to the existing algorithm
381 2015-11-29T22:42:54  <morcos> checked by producing the same blocks
382 2015-11-29T22:42:54  <phantomcircuit> morcos, yes i know, im saying i dont think it implements any optimal strategy :P
383 2015-11-29T22:42:57  *** BananaLotus has joined #bitcoin-core-dev
384 2015-11-29T22:43:10  <morcos> yeah its not meant to, its just a speed up
385 2015-11-29T22:43:18  <phantomcircuit> morcos, ah ok then
386 2015-11-29T22:43:34  *** teward has joined #bitcoin-core-dev
387 2015-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
388 2015-11-29T22:43:47  *** davec has joined #bitcoin-core-dev
389 2015-11-29T22:43:52  <morcos> s/optimal/hopefully better/
390 2015-11-29T22:44:07  *** Apocalyptic has joined #bitcoin-core-dev
391 2015-11-29T22:44:12  *** Eliel has joined #bitcoin-core-dev
392 2015-11-29T22:44:27  *** kanzure has joined #bitcoin-core-dev
393 2015-11-29T22:45:41  *** Luke-Jr has joined #bitcoin-core-dev
394 2015-11-29T22:45:58  *** isis has joined #bitcoin-core-dev
395 2015-11-29T22:46:17  <phantomcircuit> morcos, optimal is probably very hard
396 2015-11-29T22:46:18  *** Ylbam has joined #bitcoin-core-dev
397 2015-11-29T22:46:52  *** jcorgan has joined #bitcoin-core-dev
398 2015-11-29T22:46:53  *** jcorgan has quit IRC
399 2015-11-29T22:46:53  *** jcorgan has joined #bitcoin-core-dev
400 2015-11-29T22:47:03  <phantomcircuit> morcos, knapsack problem with at least two optimization variables :|
401 2015-11-29T22:47:16  <sipa> s/optimal/an approximation of optimal with reasonable conputational limits/
402 2015-11-29T22:51:47  *** da2ce7 has joined #bitcoin-core-dev
403 2015-11-29T22:53:41  *** Anduck_ has joined #bitcoin-core-dev
404 2015-11-29T22:54:06  *** Guest76338 has joined #bitcoin-core-dev
405 2015-11-29T22:54:18  *** Guest76338 has quit IRC
406 2015-11-29T22:55:21  *** gribble has joined #bitcoin-core-dev
407 2015-11-29T22:55:48  *** Anduck__ has joined #bitcoin-core-dev
408 2015-11-29T22:56:51  *** gmaxwell has joined #bitcoin-core-dev
409 2015-11-29T22:56:52  *** Anduck__ has quit IRC
410 2015-11-29T22:57:12  *** jonasschnelli has quit IRC
411 2015-11-29T22:57:15  *** gmaxwell is now known as Guest19298
412 2015-11-29T22:57:20  *** Anduck__ has joined #bitcoin-core-dev
413 2015-11-29T22:59:05  *** Anduck has quit IRC
414 2015-11-29T22:59:11  *** Anduck__ is now known as Anduck
415 2015-11-29T23:04:54  *** Guest19298 has quit IRC
416 2015-11-29T23:04:54  *** Guest19298 has joined #bitcoin-core-dev
417 2015-11-29T23:05:03  *** Guest19298 is now known as gmaxwell
418 2015-11-29T23:08:29  *** moli has quit IRC
419 2015-11-29T23:11:33  *** BashCo has quit IRC
420 2015-11-29T23:12:34  *** jonasschnelli has joined #bitcoin-core-dev
421 2015-11-29T23:18:06  *** guest234234 has joined #bitcoin-core-dev
422 2015-11-29T23:24:19  *** molly has joined #bitcoin-core-dev
423 2015-11-29T23:25:10  *** berndj has joined #bitcoin-core-dev
424 2015-11-29T23:32:00  *** jonasschnelli has quit IRC
425 2015-11-29T23:32:46  *** cocoBTC has quit IRC
426 2015-11-29T23:34:26  *** jonasschnelli has joined #bitcoin-core-dev
427 2015-11-29T23:57:12  *** Ylbam has quit IRC
428 2015-11-29T23:59:10  *** randy-waterhouse has joined #bitcoin-core-dev