12015-12-02T00:06:47 <GitHub81> [bitcoin] gmaxwell closed pull request #7100: Replace setInventoryKnown with a rolling bloom filter. (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7100
22015-12-02T00:31:19 *** Guest46010 has quit IRC
32015-12-02T00:31:20 *** Guest46010 has joined #bitcoin-core-dev
42015-12-02T00:31:20 *** Guest46010 is now known as amiller
52015-12-02T01:27:58 *** JackH has quit IRC
62015-12-02T01:44:33 *** Ylbam has quit IRC
72015-12-02T01:49:03 *** randy-waterhouse has joined #bitcoin-core-dev
82015-12-02T01:51:59 *** dcousens has joined #bitcoin-core-dev
92015-12-02T02:37:40 *** calibre720 has joined #bitcoin-core-dev
102015-12-02T02:56:07 *** belcher has quit IRC
112015-12-02T02:58:31 *** calibre720 has quit IRC
122015-12-02T03:03:08 *** CodeShark_ has joined #bitcoin-core-dev
132015-12-02T03:04:38 <GitHub159> [bitcoin] gmaxwell closed pull request #7037: Move the blocknotify callback ahead of peer announcement. (master...notify_early) https://github.com/bitcoin/bitcoin/pull/7037
142015-12-02T03:40:18 *** calibre720 has joined #bitcoin-core-dev
152015-12-02T03:57:39 *** CodeShark_ has quit IRC
162015-12-02T04:52:14 *** jtimon has quit IRC
172015-12-02T05:00:50 *** CodeShark_ has joined #bitcoin-core-dev
182015-12-02T05:11:58 *** CodeShark_ has quit IRC
192015-12-02T05:32:07 <Luke-Jr> dcousens: there is no consensus, when reasonable dissent remains.
202015-12-02T05:32:56 <dcousens> Luke-Jr: well, this is a policy based thing isn't it?
212015-12-02T05:33:15 <Luke-Jr> dcousens: yes, it doesn't strictly *need* consensus. Just saying.
222015-12-02T05:33:20 <dcousens> and my point was, at least the impression from those IRC logs, was, that reasonable dissent didn't exist beyond your concerns
232015-12-02T05:33:24 <gmaxwell> Luke-Jr: lets try to be productive and figure out something that works for everyone.
242015-12-02T05:33:40 <dcousens> (not to down play your concerns at all, fwiw)
252015-12-02T05:33:49 <Luke-Jr> dcousens: "reasonable dissent didn't exist beyond reasonable dissent" does not make sense.
262015-12-02T05:34:12 <Luke-Jr> gmaxwell: I see no benefit whatsoever to changing the default policy in a way that is clearly harmful to Bitcoin.
272015-12-02T05:34:24 <gmaxwell> Luke-Jr: right now with the mempool behavior, inserting priority back into the process has an astronomical performance hit that directly drives people shortcutting validation. That fact remains, as does the fact that priority is useful too.
282015-12-02T05:34:38 <dcousens> well, I'm not in the position to say whether it was reasonable or not,
292015-12-02T05:34:57 <gmaxwell> Luke-Jr: slow block generation is clearly harmful to Bitcoin, in a way which I think is worse than loss of priority.
302015-12-02T05:35:03 <Luke-Jr> gmaxwell: that fact does not remain. The CNB rewrite fixed it.
312015-12-02T05:35:19 <Luke-Jr> gmaxwell: priority no longer has any significant performance penalty
322015-12-02T05:35:49 <gmaxwell> Luke-Jr: I thought you were also trying to undo the only compute priority at mempool entry change too?
332015-12-02T05:36:17 <Luke-Jr> gmaxwell: that also is insignificant, but less concerning (other than the fact that it requires miners to apply code patches to fix)
342015-12-02T05:36:46 <Luke-Jr> (I mean, fixing that also would not have a notable performance penalty)
352015-12-02T05:37:58 <gmaxwell> Luke-Jr: 'accurate' priority requires traversing every free transaction in the mempool to build the block, even if only a few are included.
362015-12-02T05:38:58 <gmaxwell> Luke-Jr: what is your view of the argument that priority is effectively only available to very few users; because most people don't have a stack of year old txouts stiting around?
372015-12-02T05:40:04 <Luke-Jr> gmaxwell: specifically, https://github.com/bitcoin/bitcoin/pull/7149 fixes the priority calculation without adding any such loop to CNB
382015-12-02T05:40:55 <jgarzik> how many tx per day get confirmed solely due to priority - measure field use
392015-12-02T05:40:56 <Luke-Jr> gmaxwell: "Bitcoin only works for users with lots of bitcoins during spam attacks" is much better than "Bitcoin doesn't work during spam attacks period"
402015-12-02T05:41:38 <gmaxwell> Luke-Jr: okay, I hadn't seen that PR. it might change my opinion. I think if we can prevent there from being bad performance or memory usage effects we should preserve it.
412015-12-02T05:42:12 <Luke-Jr> it adds a dobule + unsigned int per mempooltx
422015-12-02T05:42:15 <Luke-Jr> double*
432015-12-02T05:42:22 <gmaxwell> Luke-Jr: Thus far, spending one or two _cents_ for an ordinary sized transaction has been more than enough to get it past all the spam attacks that I've looked at.
442015-12-02T05:42:55 <gmaxwell> so I think the "doesn't work" is hyperbole, especially with the belief that most users simply don't have access to priority in the way that you or I do.
452015-12-02T05:43:50 <dcousens> Luke-Jr: "doesn't work"? just add a higher fee?
462015-12-02T05:43:58 <Luke-Jr> jgarzik: gmaxwell: that is the same kind of argument for skipping validation. the rate of attempted bogus blocks is zero, so why check them?
472015-12-02T05:44:35 <Luke-Jr> dcousens: many people cannot add higher fees yet
482015-12-02T05:44:44 <dcousens> Luke-Jr: why not?
492015-12-02T05:44:45 <Luke-Jr> maybe in some post-RBF-wallet world, priority can safely be removed
502015-12-02T05:44:50 <gmaxwell> Luke-Jr: I don't think it is; because the kind of harm caused is different. If there is no priority than no one has a strong assumption that there will be priority.
512015-12-02T05:45:13 <dcousens> Luke-Jr: isn't that we're moving towards?
522015-12-02T05:45:20 <Luke-Jr> dcousens: yes, but we're not there.
532015-12-02T05:45:28 <gmaxwell> Luke-Jr: good argument. So you would point out that priority can rescue transactions which would otherwise be massively delayed absent the ability to revise their fees.
542015-12-02T05:46:14 <gmaxwell> This sounds like something we could actually check. like how many transactions in blocks now (even ones cherry picked to be not-spam) would have been priority eligible at all; or would become eligible within 24-36 hours.
552015-12-02T05:46:21 <dcousens> gmaxwell: indeed
562015-12-02T05:46:40 <dcousens> morcos: ? :P
572015-12-02T05:46:50 <gmaxwell> pfft; morcos is not our stats monkey. :)
582015-12-02T05:46:57 <dcousens> haha
592015-12-02T05:47:00 <Luke-Jr> we have a stats monkey? :o
602015-12-02T05:47:03 <gmaxwell> (except for his own PRs :) )
612015-12-02T05:47:07 <gmaxwell> No, but perhaps we should.
622015-12-02T05:47:22 <gmaxwell> but where will we get the suit?
632015-12-02T05:48:48 <gmaxwell> in any case, I think if we can make an objective case that it has a use for people other than me and you, and we can prefer a performance hit.. then great. It would considerable extra work to maintain the functionality. (though this is my view; and wumpus is not around to kick my ass for it right now)
642015-12-02T05:49:11 <gmaxwell> But if either of these things are not true; then we might have to swallow the pill.
652015-12-02T05:53:19 <Luke-Jr> gmaxwell: I was not able to fully parse your longest line.
662015-12-02T05:54:34 <gmaxwell> it would be worth performing extra work to maintain priority if the above two conditions (can do it without breaking performance; can show that it would be helpful for existing users under hypothetical attack conditions)
672015-12-02T05:57:56 <tulip> I'm not sure I've seen any wallet software which actually takes priority into account when making a transaction.
682015-12-02T05:58:34 *** calibre720 has quit IRC
692015-12-02T06:00:42 <Luke-Jr> tulip: it doesn't need to
702015-12-02T06:01:08 <Luke-Jr> and at least my Bitcoin LJR wallet does (although I understand 0.12 won't)
712015-12-02T06:02:13 <dcousens> Luke-Jr: I think tulip's point is, if the wallet doesn't account for it, then, likely, it'll probably just assume it needs to pay a higher fee under attack conditions anyway
722015-12-02T06:02:34 <Luke-Jr> dcousens: there are no wallets that correctly figure the right fee :/
732015-12-02T06:02:46 <dcousens> Luke-Jr: what is the "right" fee?
742015-12-02T06:02:57 <dcousens> its just something high enough, right?
752015-12-02T06:04:06 <Luke-Jr> dcousens: more or less
762015-12-02T06:04:32 <dcousens> well, the wallets I use usually have a 4c fee
772015-12-02T06:04:35 <Luke-Jr> dcousens: most wallets just assume it's some fixed rate per kB, and can't take spam conditions into account at all
782015-12-02T06:04:38 <dcousens> and I've never had an issue
792015-12-02T06:05:11 <dcousens> Luke-Jr: eh, the ones I use `estimatefee`
802015-12-02T06:05:11 <Luke-Jr> dcousens: this is tangent
812015-12-02T06:05:14 <dcousens> agreed
822015-12-02T06:05:49 * Luke-Jr ponders if there's any way to parallelize git bisect
832015-12-02T06:11:47 *** guest234234 has joined #bitcoin-core-dev
842015-12-02T06:12:22 <tulip> Luke-Jr: I think at least one popular wallet has a proxy for Bitcoin Cores estimatefee built in.
852015-12-02T06:13:17 <Luke-Jr> estimatefee is not accurate during spam attacks
862015-12-02T06:16:49 <tulip> then I suppose no wallet estimates fees correctly.
872015-12-02T06:20:31 <gmaxwell> If an attack begins, the estimate may have been too low (though you need to overestimate if you are unable to replace); and then maybe priority saves you.
882015-12-02T06:21:04 <dcousens> gmaxwell: so maybe we need a mempool reactive estimatefee?
892015-12-02T06:22:43 <Luke-Jr> dcousens: that won't work if the spam starts after you send
902015-12-02T06:22:55 <Luke-Jr> RBF is the only way to really fix this
912015-12-02T06:23:02 <gmaxwell> estimatefee is mempool reactive, but it can't predict the future.
922015-12-02T06:23:36 <dcousens> seems we were answering two different questions, I'm talking about: "what should my fee be right now"
932015-12-02T06:24:04 <dcousens> you're talking about "what should my fee be to ensure no matter what happens, I get in the next block"
942015-12-02T06:24:18 <dcousens> the latter isn't possible in market, so, the most you can do is "right now" + RBF
952015-12-02T06:24:39 <Luke-Jr> dcousens: s/next block/next day/ or even next week
962015-12-02T06:24:57 <Luke-Jr> "what should my fee be right now" makes no sense alone
972015-12-02T06:25:15 <dcousens> "given the mempool"
982015-12-02T06:25:21 <Luke-Jr> still
992015-12-02T06:25:24 <dcousens> obviously your mempool is also subjective
1002015-12-02T06:25:24 <Luke-Jr> you need a *goal*
1012015-12-02T06:25:29 <dcousens> why?
1022015-12-02T06:25:38 <Luke-Jr> because without a goal, there is no "should be" at all
1032015-12-02T06:25:54 <Luke-Jr> might as well just do no fee, and wait for some generous miner to pick it up
1042015-12-02T06:25:56 *** calibre720 has joined #bitcoin-core-dev
1052015-12-02T06:26:32 <dcousens> Luke-Jr: but you can't really reason about anything other than competing with other txs for the current block
1062015-12-02T06:26:46 <dcousens> if you say my goal is "within 3 blocks", its irrelevant
1072015-12-02T06:26:50 <Luke-Jr> â¦
1082015-12-02T06:27:08 <dcousens> its still always going to be within "the next block"
1092015-12-02T06:27:09 <Luke-Jr> sounds like you just defined your goal as "next block"
1102015-12-02T06:27:24 <dcousens> IMHO, that can be the only role of a fee
1112015-12-02T06:27:26 <Luke-Jr> â¦
1122015-12-02T06:28:04 *** guest234234 has quit IRC
1132015-12-02T06:28:06 <aj> dcousens: "one of the next dozen blocks" is perfectly reasonable. if you want to parse that as "the next block, or else the next block, or else the next block, ..." i guess that's equivalent...
1142015-12-02T06:28:27 <dcousens> "one of the next dozen blocks", but thats implying you can predict the future
1152015-12-02T06:28:39 <dcousens> which is to say, at some point, if not the next, the market is going to be less competetive
1162015-12-02T06:29:02 <gmaxwell> dcousens: the point is that you could target 6 blocks, then twelve blocks of higher paying spam suddenly show up.
1172015-12-02T06:29:19 <dcousens> gmaxwell: thats my point, saying I target 6 blocks makes no sense IMHO
1182015-12-02T06:29:22 <aj> dcousens: if a block is found in 2 minutes, there'll be less competition than for a block that's found after 1h30m
1192015-12-02T06:29:34 <dcousens> because, all that really matters is whats competeting for a block right now
1202015-12-02T06:29:42 <gmaxwell> dcousens: even if you target _now_ the next second 12 blocks worth of spam shows up.
1212015-12-02T06:29:55 <dcousens> gmaxwell: exactly
1222015-12-02T06:29:58 <gmaxwell> The estimator measures that competition retrospectively.
1232015-12-02T06:30:06 <dcousens> gmaxwell: which is why "right now" + RBF is the only solution
1242015-12-02T06:30:17 <dcousens> having a target other than "right now" is implying you can predict the future
1252015-12-02T06:30:22 <gmaxwell> it doesn't just say "how do I get N blocks into the pool" it says "transactions paying this much too how long?"
1262015-12-02T06:30:28 <gmaxwell> s/too/took/
1272015-12-02T06:30:48 <gmaxwell> You can predict the future if the future is like the past; which is usually true.
1282015-12-02T06:30:51 *** calibre720 has quit IRC
1292015-12-02T06:30:58 <gmaxwell> But you can't predict the black swans.
1302015-12-02T06:31:02 <dcousens> gmaxwell: until something like a spam attack happens
1312015-12-02T06:31:08 <dcousens> which is exactly why we're talking about this
1322015-12-02T06:31:39 <dcousens> and hence, if we're talking about how to 'correctly' estimate a fee, then, "right now" + RBF is your only true best chance
1332015-12-02T06:31:54 <gmaxwell> In any case, luke believes that priority is actually a useful backstop. It's certantly something that is hard for attacks to abuse, at least.
1342015-12-02T06:32:27 <gmaxwell> dcousens: even N blocks + RBF is fine. N blocks, assuming nothing changes; and RBF for those times when it does.
1352015-12-02T06:33:00 <gmaxwell> (keep in mind that mining is a posson process; as is new transaction entry. N blocks really does make sense statistically)
1362015-12-02T06:33:39 <dcousens> gmaxwell: only if transaction priority/age matters
1372015-12-02T06:33:46 <gmaxwell> No.
1382015-12-02T06:34:18 <gmaxwell> Paying for block N, N>0 is making a bet on the rate of block finding and/or the rate of new transactions showing up.
1392015-12-02T06:34:46 <dcousens> if 6 blocks have even competition, aka, the mempool is consistently full, they'll just continually skim the top of the pile, if you fail to make it over that threshold, no matter what your prediction was originally, you won't make it in?
1402015-12-02T06:35:07 <dcousens> N blocks only makes sense if the system wasn't changing after your entry?
1412015-12-02T06:35:50 <gmaxwell> Thats why the estimator is based on past performance.
1422015-12-02T06:36:11 <dcousens> gmaxwell: which is why its a prediction, and not necessarily a 'correct' estimate :)
1432015-12-02T06:36:45 <gmaxwell> You can look at it as the question, because of variance in tx entry and block findinging; mining goes deeper into the mempool with declining probablity the deeper it goes.
1442015-12-02T06:37:04 <Luke-Jr> dcousens: right now, to get the next block, you need a fee like 0.88 mBTC; but if you're okay with up to 25 blocks, 0.01 mBTC is probably fine
1452015-12-02T06:37:16 <gmaxwell> Yes, and thats where the RBF and CPFP come in. They let you use a prediction without grave outcomes.
1462015-12-02T06:37:25 <Luke-Jr> and these are just small numbers
1472015-12-02T06:37:57 <Luke-Jr> it makes a lot more sense to target 1, 144 (24 hours), or 1008 (1 week) blocks
1482015-12-02T06:38:00 <Luke-Jr> IMO
1492015-12-02T06:38:25 <Luke-Jr> the difference is fees needed for those is likely to be even more pronounced
1502015-12-02T06:38:27 <gmaxwell> well 1008 is unfortunately incompatible with current mempool policy but I hope we improve that in the future. (e.g. be being able to save the mempool to disk)
1512015-12-02T06:38:48 <Luke-Jr> yes, I'm just saying ideally
1522015-12-02T06:38:53 <gmaxwell> (and by changing the 72 hour timeout to 1week for RBF transactions)
1532015-12-02T06:39:21 <Luke-Jr> also once there's RBF for continually re-estimating fees needed, estimates can be a lot less accurate
1542015-12-02T06:39:26 <Luke-Jr> can afford to be*
1552015-12-02T06:39:42 <gmaxwell> As I've pointed out before, if the load has a cycle with period Q, then you cannot make efficient use of the system without at least Q worth of storage... and there clearly is a weekly cycle in load.
1562015-12-02T06:40:35 <Luke-Jr> 1 GB of storage just for the mempool, with 1 MB blocks.. :x
1572015-12-02T06:40:58 <Luke-Jr> maybe I should be trying to solve this in my mempool work
1582015-12-02T06:41:11 <Luke-Jr> s/solve/make this reasonably possible without RAM/
1592015-12-02T06:41:24 <gmaxwell> well I think thats not really a big deal; mempool shouldn't be in ram.
1602015-12-02T06:41:34 <Luke-Jr> right.. that's what I mean
1612015-12-02T06:41:42 <dcousens> gmaxwell: the rational miner algorithm is just: mempoolTxs.sort(byFee).takeAtMost(marketDerivedN) (with size in there somewhere), therefore, if you want to get in the blockchain, you just need to be in that cut, why would a miner care about how long a transaction has been waiting for?
1622015-12-02T06:41:51 <Luke-Jr> maybe I should restart my mempool changes, and this time move it to disk in the proces
1632015-12-02T06:42:33 <gmaxwell> dcousens: it doesn't. But reality cares. More time means greater odds that there were a number of fast blocks that cleared out the backlog.
1642015-12-02T06:42:50 <gmaxwell> (faster than new high fee tx arrived)
1652015-12-02T06:43:22 *** calibre720 has joined #bitcoin-core-dev
1662015-12-02T06:43:26 <dcousens> gmaxwell: assuming a constant tx rate
1672015-12-02T06:44:01 <gmaxwell> e.g. you want to get in within 25 blocks, what you end up paying would put you (say) 4 blocks deep in the mempool, but given new tx coming in, it was 12 blocks out before miners got lucky enough that you were in the top $blocksize.
1682015-12-02T06:44:21 <dcousens> which still puts it as a prediction, versus just persistently watching the pool and instead competeting the entire time (no guarantee still, obv, but, its probably the most 'correct')
1692015-12-02T06:44:22 <gmaxwell> or 12 blocks out before the rate of tx coming in hit a slump, or a mixture of the two.
1702015-12-02T06:44:51 <gmaxwell> yes, indeed. well replacements have a cost with RBF... as you must increment by at least the entry amount.
1712015-12-02T06:44:58 <gmaxwell> and you lose privacy when you use it.
1722015-12-02T06:45:19 <gmaxwell> (it identifies your change)
1732015-12-02T06:45:32 <dcousens> what's the privacy lost?
1742015-12-02T06:45:39 <dcousens> nvm
1752015-12-02T06:46:44 <gmaxwell> so I think being somewhat forward looking still make sense even with RBF.
1762015-12-02T06:47:07 <dcousens> gmaxwell: indeed, its probably your best bet
1772015-12-02T06:47:11 <dcousens> uh, a good bet*
1782015-12-02T06:47:17 <dcousens> but you're best bet would be alternative
1792015-12-02T06:47:39 <dcousens> but obviously it'll probably cost you more etc
1802015-12-02T06:48:56 <gmaxwell> I mean, many things are possible including the possiblity of having an totally different unconfirmed transaction market mechenism. Like some server over tor that people connect to and do a great big auction to agree on fees and make a great big coinjoin to subit to the miners as a unit. :P
1812015-12-02T06:49:13 <dcousens> haha, that'll be the day
1822015-12-02T06:49:26 <dcousens> and yeah, the coinjoin would subvert the orthogonal issue of privacy loss during RBF
1832015-12-02T06:49:38 <dcousens> at least, the loss of privacy to the network
1842015-12-02T06:49:43 <gmaxwell> also the fact that you'd agree on .. right.
1852015-12-02T06:49:56 <gmaxwell> I mean, this is effectively what joinmarket is... well joinmarket is the MVP version of that.
1862015-12-02T06:50:01 <aj> gmaxwell: oh, wow, a bitcoin user's union putting the screws into the Big Business of corporate mining!
1872015-12-02T06:50:14 <gmaxwell> aj: the word is "buyers cartel"
1882015-12-02T06:50:18 <dcousens> haha
1892015-12-02T06:50:32 <aj> gmaxwell: maybe in the literature, but that's not how you market it man!
1902015-12-02T06:51:03 <gmaxwell> my earliest posts on bitcoin talk were worrying about mining cartels driving up fee prices, then I realized buyers cartels were possible too and worried less about that. :P
1912015-12-02T06:52:21 <gmaxwell> an interesting thing you can do is do the bidding for fees and then round robin distribute them to transactions, so that the miners just see N transactions which each page the average feerate, and can't cherrypick the higer paying bidders.
1922015-12-02T06:53:36 <GitHub195> [bitcoin] posita opened pull request #7152: Add missing automake package to deb-based UNIX install instructions. (master...posita/fix-doc-build-unix) https://github.com/bitcoin/bitcoin/pull/7152
1932015-12-02T06:55:56 <GitHub77> [bitcoin] jonasschnelli closed pull request #6997: Don't use hard-coded AllowFree, as this is usually far too low. (master...no-default-free-priority) https://github.com/bitcoin/bitcoin/pull/6997
1942015-12-02T07:20:21 *** MarcoFalke has joined #bitcoin-core-dev
1952015-12-02T07:27:46 *** calibre720 has quit IRC
1962015-12-02T07:32:39 *** dcousens has quit IRC
1972015-12-02T07:34:49 *** paveljanik has joined #bitcoin-core-dev
1982015-12-02T07:37:47 <GitHub128> [bitcoin] jonasschnelli opened pull request #7153: [Tests] Add mempool_limit.py test (master...2015/12/mempool-test) https://github.com/bitcoin/bitcoin/pull/7153
1992015-12-02T07:39:31 *** Ylbam has joined #bitcoin-core-dev
2002015-12-02T07:40:17 <GitHub61> [bitcoin] jonasschnelli opened pull request #7154: [Qt] add InMempool() info to transaction details (master...2015/12/qt_conflicts) https://github.com/bitcoin/bitcoin/pull/7154
2012015-12-02T07:41:47 *** tripleslash has quit IRC
2022015-12-02T08:00:18 *** tripleslash has joined #bitcoin-core-dev
2032015-12-02T08:07:20 *** tripleslash has quit IRC
2042015-12-02T08:16:15 *** CodeShark_ has joined #bitcoin-core-dev
2052015-12-02T08:40:17 *** MarcoFalke has quit IRC
2062015-12-02T08:43:29 <GitHub147> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4077ad20d03f...4a63f9467606
2072015-12-02T08:43:30 <GitHub147> bitcoin/master b171c69 Michael Ford: [doc] Update OS X build notes for new qt5 configure...
2082015-12-02T08:43:30 <GitHub147> bitcoin/master 4a63f94 Jonas Schnelli: Merge pull request #7040...
2092015-12-02T08:43:37 <GitHub44> [bitcoin] jonasschnelli closed pull request #7040: [doc] Update OS X build notes for new qt5 configure (master...patch-4) https://github.com/bitcoin/bitcoin/pull/7040
2102015-12-02T08:51:32 *** tripleslash has joined #bitcoin-core-dev
2112015-12-02T08:53:08 *** tulip has quit IRC
2122015-12-02T09:04:30 *** BashCo has quit IRC
2132015-12-02T09:12:12 *** dcousens has joined #bitcoin-core-dev
2142015-12-02T09:17:42 *** Guyver2 has joined #bitcoin-core-dev
2152015-12-02T09:18:16 <GitHub36> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a63f9467606...bdda4d567eed
2162015-12-02T09:18:17 <GitHub36> bitcoin/master 74d0f90 Matt Corallo: Add method to remove a tx from CCoinsViewCache if it is unchanged
2172015-12-02T09:18:17 <GitHub36> bitcoin/master b2e74bd Matt Corallo: Get the set of now-uncacheable-txn from CTxMemPool::TrimToSize
2182015-12-02T09:18:18 <GitHub36> bitcoin/master 677aa3d Matt Corallo: Discard txn cache entries that were loaded for removed mempool txn
2192015-12-02T09:18:21 <GitHub195> [bitcoin] laanwj closed pull request #6872: Remove UTXO cache entries when the tx they were added for is removed/does not enter mempool (master...limitucache) https://github.com/bitcoin/bitcoin/pull/6872
2202015-12-02T09:18:41 <GitHub34> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bdda4d567eed...1b0241fcec3e
2212015-12-02T09:18:42 <GitHub34> bitcoin/master 8f0d79e Wladimir J. van der Laan: test: Disable scheduler test manythreads...
2222015-12-02T09:18:42 <GitHub34> bitcoin/master 1b0241f Wladimir J. van der Laan: Merge pull request #7144...
2232015-12-02T09:18:44 <GitHub130> [bitcoin] laanwj closed pull request #7144: test: Disable scheduler test manythreads (master...2015_12_disable_schedulertest) https://github.com/bitcoin/bitcoin/pull/7144
2242015-12-02T09:29:51 *** BashCo has joined #bitcoin-core-dev
2252015-12-02T09:31:57 *** rubensayshi has joined #bitcoin-core-dev
2262015-12-02T09:33:48 *** guest234234 has joined #bitcoin-core-dev
2272015-12-02T09:35:15 <jonasschnelli> Would changing the github bitcoin identity avatar image makes sense?
2282015-12-02T09:35:29 <jonasschnelli> from https://avatars0.githubusercontent.com/u/528860?v=3&s=200 to https://raw.githubusercontent.com/bitcoin/bitcoin/master/src/qt/res/icons/bitcoin.png
2292015-12-02T09:36:05 <jonasschnelli> the current icon looks like a biniki, which is nice,.. but...
2302015-12-02T09:36:17 <wumpus> yes I kinda like the current one
2312015-12-02T09:36:54 <gmaxwell> It's one of those mcdonalds ghosts.
2322015-12-02T09:36:58 <wumpus> I agree it may be more sensible to you know, put the logo there, but I don't know :-)
2332015-12-02T09:37:21 <gmaxwell> hehe.
2342015-12-02T09:39:51 <jonasschnelli> i think only wumpus and gavinandresen can change it
2352015-12-02T09:40:15 <jonasschnelli> but no strong opinion... I juts think it looks "unfinished".
2362015-12-02T09:41:23 <paveljanik> yay, we can change it weekly or per event - like google does with its logo 8)
2372015-12-02T09:41:25 <wumpus> which is somehwo appropriate
2382015-12-02T09:41:43 <paveljanik> lets scale the logo for today 8)
2392015-12-02T09:41:55 <wumpus> it IS far from finished :-)
2402015-12-02T09:42:09 <jonasschnelli> hah.. that true.
2412015-12-02T09:45:02 <gmaxwell> "What do you mean you want bigger blocks? Cant you already see the pixels? they're super chunky now!"
2422015-12-02T09:45:07 <wumpus> paveljanik: haha before you know you get requests to change the logo to a smaller denomination because that would sell more bitcoins *ducks*
2432015-12-02T09:46:04 <wumpus> it doesn't get blockier than this
2442015-12-02T09:47:14 <gmaxwell> "no no, bitcoin is deflationary; the logo must get smaller over time."
2452015-12-02T09:47:22 <wumpus> that 1024x1024 logo is so subpixel-perfectly round, there's no blocks and no block chain in it!
2462015-12-02T09:49:45 <wumpus> it also has no decentralization
2472015-12-02T09:50:14 <gmaxwell> well a couple seconds in gimp and it can be as decentered as you want.
2482015-12-02T09:50:57 <wumpus> but just moving the center is not decentralization!
2492015-12-02T09:52:47 <gmaxwell> You can also _erase_ the center!
2502015-12-02T09:55:10 <wumpus> ah yes a hole in the middle like some coins do have
2512015-12-02T09:55:55 <wumpus> also used to happen someties with the 1 and 2 euro coins which consist of two materials, where the center dropped out
2522015-12-02T09:56:04 <wumpus> not sure if symbolic
2532015-12-02T09:57:11 <paveljanik> our 50CZK (~2EUR) coin is still like this...
2542015-12-02T09:59:50 <Luke-Jr> just make it a QR code with a HD wallet seed that has 1 BTC in it, and see how long people take to notice
2552015-12-02T09:59:53 <Luke-Jr> <.<
2562015-12-02T10:00:47 <Luke-Jr> of course, since I just said that here, there's probably 10 people writing bots to automatically check it..
2572015-12-02T10:01:32 *** tulip has joined #bitcoin-core-dev
2582015-12-02T10:01:36 <wumpus> right, from now on everyone checks our images very carefully for hidden QR codes and steganography
2592015-12-02T10:03:41 <gmaxwell> I've probably mentioned it before; but there was some troll group ("GNAA") that started contributing illustrations to wikipedia that secretly coded "GNAA" in them. I knew about them all over the place, but the illustrationwere so useful we just let them keep on doing it.
2602015-12-02T10:04:05 <Luke-Jr> lol
2612015-12-02T10:04:42 <Luke-Jr> gmaxwell: someone checked they weren't copyrighted by other, right?
2622015-12-02T10:05:29 <gmaxwell> Luke-Jr: yea, we were pretty sure they were drawing them.
2632015-12-02T10:06:03 <wumpus> haha reminds me of http://blogoscoped.com/archive/2009-07-16-n41.html
2642015-12-02T10:06:05 <Luke-Jr> if only our trolls were that dedicated :<
2652015-12-02T10:06:46 <gmaxwell> https://en.wikipedia.org/wiki/Perpendicular_recording#Technology < this was one (someone since might have fixed it, I didn't check.. but you can see the example is 32 bits long...)
2662015-12-02T10:08:40 <wumpus> (or, more like the idea of blog post spammers that give such useful answers that they're almost excused adding a hidden spam link)
2672015-12-02T10:09:28 <wumpus> gmaxwell: hah, that's so obscure and harmless
2682015-12-02T10:10:40 <wumpus> yes definitely another class of troll than our trolls Luke-Jr
2692015-12-02T10:25:38 *** MarcoFalke has joined #bitcoin-core-dev
2702015-12-02T10:27:19 <MarcoFalke> wumpus, So I update to pull from https://github.com/bitcoin/univalue now
2712015-12-02T10:27:32 <wumpus> MarcoFalke: sure!
2722015-12-02T10:28:56 <GitHub125> [bitcoin] petertodd opened pull request #7155: Remove old replace-by-fee tests (master...2015-12-remove-old-rbf-tests) https://github.com/bitcoin/bitcoin/pull/7155
2732015-12-02T10:32:05 <sipa> wumpus: there is some annoying github logic if you just clone
2742015-12-02T10:32:36 <wumpus> sipa: hm?
2752015-12-02T10:32:50 <sipa> wumpus: as it will keep showing here and in all existing forks that jgarzik/univalue is upstream
2762015-12-02T10:32:58 <sipa> or is that the intention?
2772015-12-02T10:33:01 <wumpus> that's the intent
2782015-12-02T10:33:10 <sipa> ok, no problem then
2792015-12-02T10:33:49 <wumpus> I've updated the description for it "ork for bitcoin changes to univalue, upstream is https://github.com/jgarzik/univalue" my idea is that it's similar to the leveldb one
2802015-12-02T10:34:02 <sipa> ok
2812015-12-02T10:37:47 <wumpus> but I agree on the annoying logic, there's AFAIK no way to 'unparent' a project so that it is no longer seen as a subsidiary fork
2822015-12-02T10:37:56 <sipa> it is
2832015-12-02T10:38:10 <sipa> you can move the repo to another project
2842015-12-02T10:38:29 <sipa> which is what i should have done for secp
2852015-12-02T10:39:29 <sipa> instead i just deleted & recreated
2862015-12-02T10:42:12 <gmaxwell> speaking of secp256k1, you need to blank your personal repo again.
2872015-12-02T10:44:48 <sipa> uh
2882015-12-02T10:47:18 <gmaxwell> sipa: force push the master branch of mine onto yours, you overwrote it.
2892015-12-02T11:01:15 <btcdrak> wumpus: alternatively jgarzik could push his repo to the bitcoin org
2902015-12-02T11:01:25 <btcdrak> *transfer
2912015-12-02T11:02:51 <wumpus> btcdrak: right
2922015-12-02T11:05:59 <wumpus> btcdrak: although in this specific case I'd prefer not to, part of the reason of splitting off subtrees is that they can have their own maintenance, it's just that in this case we want this patch in for 0.12 ASAP so have to act on our own a bit
2932015-12-02T11:06:49 <btcdrak> wumpus: fair, but it would be better to have a few maintainers (ie people with push access) to repositories we rely on.
2942015-12-02T11:07:35 <btcdrak> I see there's only 1 PR left in the 0.12 milestone! \o/
2952015-12-02T11:08:08 <wumpus> yep the univalue is the last critical one
2962015-12-02T11:09:48 <MarcoFalke> wumpus, #14 didn't get merged because unit tests fail?
2972015-12-02T11:10:23 <wumpus> hm?
2982015-12-02T11:10:42 <MarcoFalke> Expression: f != NULL
2992015-12-02T11:10:42 <MarcoFalke> abnormal program termination
3002015-12-02T11:10:42 <MarcoFalke> FAIL: test/unitester.exe
3012015-12-02T11:10:42 <MarcoFalke> ====================================================
3022015-12-02T11:10:42 <MarcoFalke> 1 of 1 test failed
3032015-12-02T11:10:42 <MarcoFalke> Please report to http://github.com/jgarzik/univalue/
3042015-12-02T11:10:42 <MarcoFalke> ====================================================
3052015-12-02T11:10:45 <wumpus> where do you see that?
3062015-12-02T11:10:50 <MarcoFalke> travis
3072015-12-02T11:11:03 <wumpus> ============================================================================
3082015-12-02T11:11:03 <wumpus> Testsuite summary for univalue 1.0.1
3092015-12-02T11:11:03 <wumpus> ============================================================================
3102015-12-02T11:11:03 <wumpus> # TOTAL: 1
3112015-12-02T11:11:03 <wumpus> # PASS: 1
3122015-12-02T11:11:12 <wumpus> no problems here
3132015-12-02T11:11:51 <wumpus> also travis on https://github.com/jgarzik/univalue/pull/14 shows "all checks have passed"
3142015-12-02T11:12:06 <wumpus> so I'm not sure where you get that reasoning from, no one is saying that in the pull either
3152015-12-02T11:13:26 <wumpus> strange, I see bitcoin's travis does report that
3162015-12-02T11:14:29 <wumpus> cannot reproduce it locally
3172015-12-02T11:14:48 *** calibre720 has joined #bitcoin-core-dev
3182015-12-02T11:16:39 <wumpus> MarcoFalke: I guess I know the problem, the new test files added aren't part of Makefile.am's listing, and univalue's travis build doesn't do a 'make dist'
3192015-12-02T11:22:42 <wumpus> (would be better to have a proper error in the tests that a file is missing instead of having to divine it from an assertion message)
3202015-12-02T11:22:55 <MarcoFalke> Indeed.
3212015-12-02T11:23:25 <MarcoFalke> Accidentally triggered https://travis-ci.org/bitcoin/bitcoin/builds/94375864 . Mind to cancel?
3222015-12-02T11:23:42 <wumpus> done
3232015-12-02T11:43:18 <GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b0241fcec3e...3fd3b8617f2d
3242015-12-02T11:43:19 <GitHub191> bitcoin/master 092e9ad Peter Todd: Remove old replace-by-fee tests...
3252015-12-02T11:43:19 <GitHub191> bitcoin/master 3fd3b86 Wladimir J. van der Laan: Merge pull request #7155...
3262015-12-02T11:43:22 <GitHub104> [bitcoin] laanwj closed pull request #7155: Remove old replace-by-fee tests (master...2015-12-remove-old-rbf-tests) https://github.com/bitcoin/bitcoin/pull/7155
3272015-12-02T11:44:24 <GitHub184> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fd3b8617f2d...8e598dc4ea1d
3282015-12-02T11:44:25 <GitHub184> bitcoin/master b212f94 Pavel JanÃk: Describe maxmempool and mempoolminfee in the getmempoolinfo RPC help.
3292015-12-02T11:44:25 <GitHub184> bitcoin/master 8e598dc Wladimir J. van der Laan: Merge pull request #7118...
3302015-12-02T11:44:32 <GitHub194> [bitcoin] laanwj closed pull request #7118: [Trivial, Doc] Describe maxmempool and mempoolminfee in the getmempoolinfo RPC help. (master...20151127_getmempoolinfo_fixes) https://github.com/bitcoin/bitcoin/pull/7118
3312015-12-02T11:58:47 <GitHub143> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8e598dc4ea1d...0dd194c917db
3322015-12-02T11:58:47 <GitHub143> bitcoin/master 1812de9 Pavel JanÃk: Name union to prevent compiler warning
3332015-12-02T11:58:48 <GitHub143> bitcoin/master 0dd194c Wladimir J. van der Laan: Merge pull request #7146...
3342015-12-02T11:58:52 <GitHub87> [bitcoin] laanwj closed pull request #7146: Name union to prevent compiler warning (master...20151201_prevector_name_union) https://github.com/bitcoin/bitcoin/pull/7146
3352015-12-02T11:59:22 *** dcousens has quit IRC
3362015-12-02T12:03:34 *** calibre720 has quit IRC
3372015-12-02T12:16:39 *** rubensayshi has quit IRC
3382015-12-02T12:21:16 *** tulip has quit IRC
3392015-12-02T12:26:09 *** tulip has joined #bitcoin-core-dev
3402015-12-02T12:27:12 <GitHub17> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0dd194c917db...7c7a05d27477
3412015-12-02T12:27:13 <GitHub17> bitcoin/master 9827091 MarcoFalke: Squashed 'src/univalue/' changes from 5839ac3..2740c4f...
3422015-12-02T12:27:13 <GitHub17> bitcoin/master fad4ea8 MarcoFalke: Merge commit '982709199f1b4e9e35211c419a81938f9f1dd4ed' into bitcoin
3432015-12-02T12:27:14 <GitHub17> bitcoin/master 7c7a05d Wladimir J. van der Laan: Merge pull request #7147...
3442015-12-02T12:27:22 <GitHub119> [bitcoin] laanwj closed pull request #7147: Univalue: Pull subtree (master...MarcoFalke-2015-univalueSync) https://github.com/bitcoin/bitcoin/pull/7147
3452015-12-02T12:30:05 *** rubensayshi has joined #bitcoin-core-dev
3462015-12-02T12:33:15 *** tulip has quit IRC
3472015-12-02T12:55:06 <GitHub194> [bitcoin] laanwj opened pull request #7156: rpc: remove cs_main lock from `createrawtransaction` (master...2015_12_createrawtransaction_nolock) https://github.com/bitcoin/bitcoin/pull/7156
3482015-12-02T12:56:17 <jgarzik> wumpus, MarcoFalke: Thanks - merged - ran it through the extended test suite in perl and found no problems there either
3492015-12-02T12:57:19 <GitHub11> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c7a05d27477...83f06ca93736
3502015-12-02T12:57:19 <GitHub11> bitcoin/master db6047d Peter Todd: Take the training wheels off anti-fee-sniping...
3512015-12-02T12:57:19 <GitHub9> [bitcoin] laanwj closed pull request #6216: Take the training wheels off anti-fee-sniping (master...take-training-wheels-off-fee-sniping) https://github.com/bitcoin/bitcoin/pull/6216
3522015-12-02T12:57:20 <GitHub11> bitcoin/master 83f06ca Wladimir J. van der Laan: Merge pull request #6216...
3532015-12-02T12:57:41 <wumpus> awesome
3542015-12-02T12:58:25 *** tulip has joined #bitcoin-core-dev
3552015-12-02T12:59:29 <GitHub103> [bitcoin] MarcoFalke opened pull request #7157: Fix typos and misc cleanup. (master...MarcoFalke-2015-trivial6) https://github.com/bitcoin/bitcoin/pull/7157
3562015-12-02T12:59:30 <MarcoFalke> Meh, trivial...
3572015-12-02T13:03:22 *** randy-waterhouse has quit IRC
3582015-12-02T13:05:17 <morcos> gmaxwell: re load of cycle Q: i don't think you really need to store Q's worth of txs b/c you only need to store the backlog. it seems somewhat unlikely that your load is going to present the entire weeks worth of tx's in the first 10 mins.
3592015-12-02T13:06:23 <morcos> i don't know what the right answer is and it's possibly more than the existing back log capacity which is less than 1 day
3602015-12-02T13:08:08 <morcos> Luke-Jr: agree with you that estimates for 1 to 25 are kind of useless. i wrote code to modify the fee estimator to "efficiently" calculate up to 1008 while maintaining backwards compatibilty and still providing 1 through 25, but it was a tad complicated, and i was discouraged myself from reviewing it for correctness, so never published it.
3612015-12-02T13:13:08 *** tulip has quit IRC
3622015-12-02T13:13:43 <sipa> 1 to 25 what?
3632015-12-02T13:13:54 <morcos> the target number of blocks
3642015-12-02T13:14:20 <sipa> i miss context
3652015-12-02T13:14:39 <sipa> ah, fee estimation?
3662015-12-02T13:14:44 <morcos> wumpus: 7062 should be tagged with 0.12 as well. i suppose its really a bug fix, and sdaftuar is going to add another commit to affect ATMP later today
3672015-12-02T13:14:58 <wumpus> ok
3682015-12-02T13:15:06 <morcos> sipa: yes, Luke-Jr was saying those are all small numbers and asking about 1, 144, and 1008 would be more meaningful
3692015-12-02T13:15:30 <morcos> I agree that some sort of doubling is more useful 1,2,4,8 ... 1024
3702015-12-02T13:15:46 <sipa> agree
3712015-12-02T13:15:49 <morcos> i can't imagine needing to distinguish between 17 and 18
3722015-12-02T13:16:06 <morcos> nor is possible
3732015-12-02T13:17:01 <morcos> perhaps i should just get rid of the bakcwards compatibility, and i think the code will be significantly cleaner
3742015-12-02T13:17:28 <morcos> but seems like it would be nice to take advantage of your old fee_estimates.dat
3752015-12-02T13:17:50 <morcos> what's the right way to convert that. build the converstion code into bitcoind or a standalone utility
3762015-12-02T13:18:21 <sipa> inside bitcoind is certainly simpler
3772015-12-02T13:18:32 <morcos> yeah just won't get used otherwise
3782015-12-02T13:18:46 <morcos> luckly it has version information. thanks gavin!
3792015-12-02T13:18:57 <sipa> indeed
3802015-12-02T13:27:43 *** MarcoFalke has quit IRC
3812015-12-02T13:34:12 <GitHub162> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/93236c0455ded01f1af5d28f8be0801120a18ff2
3822015-12-02T13:34:13 <GitHub162> bitcoin/master 93236c0 Wladimir J. van der Laan: qt: Final translation update before 0.12 fork...
3832015-12-02T13:39:02 <GitHub117> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/93236c0455de...df2ced5c8325
3842015-12-02T13:39:03 <GitHub117> bitcoin/master 02354c9 Luke Dashjr: Constrain rpcport default values to a single location in code
3852015-12-02T13:39:03 <GitHub117> bitcoin/master df2ced5 Wladimir J. van der Laan: Merge pull request #7128...
3862015-12-02T13:39:06 <GitHub83> [bitcoin] laanwj closed pull request #7128: Constrain rpcport default values to a single location in code (master...const_rpcport) https://github.com/bitcoin/bitcoin/pull/7128
3872015-12-02T14:00:31 *** MarcoFalke has joined #bitcoin-core-dev
3882015-12-02T14:06:26 *** MarcoFalke has quit IRC
3892015-12-02T14:19:17 *** MarcoFalke has joined #bitcoin-core-dev
3902015-12-02T14:23:56 *** molly has joined #bitcoin-core-dev
3912015-12-02T14:26:23 *** moli has quit IRC
3922015-12-02T14:31:31 *** guest234234 has quit IRC
3932015-12-02T14:39:15 <MarcoFalke> wumpus, translation missing for $ grep -r "Choose data directory on startup (default: %u" src/
3942015-12-02T14:39:16 <MarcoFalke> ?
3952015-12-02T14:41:20 <MarcoFalke> Can't find it in bitcoin/master nor transifex
3962015-12-02T14:42:12 *** jtimon has joined #bitcoin-core-dev
3972015-12-02T14:46:32 *** zookolaptop has joined #bitcoin-core-dev
3982015-12-02T14:47:51 *** mr_burdell has joined #bitcoin-core-dev
3992015-12-02T14:51:37 <wumpus> MarcoFalke: oh shit
4002015-12-02T14:52:13 <wumpus> MarcoFalke: when moving the option translations to qt, it was forgotten to change _ to tr()
4012015-12-02T14:52:22 <wumpus> now all those translations are lost
4022015-12-02T14:53:03 <MarcoFalke> trasifex saves them?
4032015-12-02T14:53:27 <wumpus> it removes them once they're out of the english (reference) translation
4042015-12-02T14:53:29 *** zookolaptop has quit IRC
4052015-12-02T14:53:52 *** calibre720 has joined #bitcoin-core-dev
4062015-12-02T14:56:07 <wumpus> they are still in old git but getting them back in transifex is not trivial
4072015-12-02T15:00:42 <GitHub115> [bitcoin] MarcoFalke opened pull request #7158: [qt] Use tr() instead of _() (master...MarcoFalke-2015-translations) https://github.com/bitcoin/bitcoin/pull/7158
4082015-12-02T15:01:28 <MarcoFalke> Trasifex should have them in "Suggestions" from .11?
4092015-12-02T15:03:51 <wumpus> possibly
4102015-12-02T15:05:10 <MarcoFalke> But still it's unclear how to get them back into .12 for all langs.
4112015-12-02T15:06:26 <wumpus> it's likely possible through the API
4122015-12-02T15:06:59 <jonasschnelli> what's the difference between tr() and _()?
4132015-12-02T15:07:11 <wumpus> _() is GNU gettext, tr() is Qt
4142015-12-02T15:07:24 <wumpus> we emulate _() for some files, but it does nothing in qt code
4152015-12-02T15:07:58 <jonasschnelli> Okay. I see.
4162015-12-02T15:09:33 <wumpus> i don't blame MarcoFalke though, I blame the person that moved those options to init.cpp in the first place :p
4172015-12-02T15:09:45 <wumpus> they used to be in the gui code, should never have happened
4182015-12-02T15:10:24 <MarcoFalke> Force pushed. https://travis-ci.org/bitcoin/bitcoin/builds/94414954 can be canceled again
4192015-12-02T15:10:55 <wumpus> done
4202015-12-02T15:28:20 *** PaulCape_ has quit IRC
4212015-12-02T15:28:31 <GitHub114> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/df2ced5c8325...aeedd8a53b2d
4222015-12-02T15:28:32 <GitHub114> bitcoin/master 8a03727 paveljanik: Fix various typos
4232015-12-02T15:28:33 <GitHub114> bitcoin/master e69bad1 MarcoFalke: [trivial] Fix typo in peertablemodel.cpp
4242015-12-02T15:28:33 <GitHub114> bitcoin/master 74f7341 antonio-fr: Update miner.cpp: Fix typo in comment
4252015-12-02T15:28:42 *** ParadoxSpiral has joined #bitcoin-core-dev
4262015-12-02T15:28:42 <GitHub115> [bitcoin] laanwj closed pull request #7157: Fix typos and misc cleanup. (master...MarcoFalke-2015-trivial6) https://github.com/bitcoin/bitcoin/pull/7157
4272015-12-02T15:29:47 *** PaulCapestany has joined #bitcoin-core-dev
4282015-12-02T15:30:06 *** MarcoFalke has quit IRC
4292015-12-02T15:34:55 *** tripleslash has quit IRC
4302015-12-02T15:34:55 *** CodeShark_ has quit IRC
4312015-12-02T15:34:55 *** Ylbam has quit IRC
4322015-12-02T15:34:56 *** bsm117532 has quit IRC
4332015-12-02T15:34:56 *** arubi_ has quit IRC
4342015-12-02T15:34:56 *** instagibbs has quit IRC
4352015-12-02T15:34:56 *** lecusemble has quit IRC
4362015-12-02T15:34:56 *** pmienk has quit IRC
4372015-12-02T15:34:56 *** da2ce7 has quit IRC
4382015-12-02T15:34:56 *** ghtdak has quit IRC
4392015-12-02T15:34:57 *** mr_burdell has quit IRC
4402015-12-02T15:34:57 *** go1111111 has quit IRC
4412015-12-02T15:34:57 *** warren has quit IRC
4422015-12-02T15:34:57 *** asoltys has quit IRC
4432015-12-02T15:34:58 *** phantomcircuit has quit IRC
4442015-12-02T15:34:58 *** cfields has quit IRC
4452015-12-02T15:34:58 *** Apocalyptic has quit IRC
4462015-12-02T15:34:58 *** gavinandresen has quit IRC
4472015-12-02T15:34:58 *** BlueMatt has quit IRC
4482015-12-02T15:34:58 *** jtimon has quit IRC
4492015-12-02T15:34:58 *** rubensayshi has quit IRC
4502015-12-02T15:34:59 *** Guyver2 has quit IRC
4512015-12-02T15:34:59 *** amiller has quit IRC
4522015-12-02T15:34:59 *** fkhan has quit IRC
4532015-12-02T15:34:59 *** jgarzik has quit IRC
4542015-12-02T15:34:59 *** arowser has quit IRC
4552015-12-02T15:35:00 *** berndj has quit IRC
4562015-12-02T15:35:01 *** gmaxwell has quit IRC
4572015-12-02T15:35:01 *** jcorgan has quit IRC
4582015-12-02T15:35:02 *** gribble has quit IRC
4592015-12-02T15:35:02 *** isis has quit IRC
4602015-12-02T15:35:02 *** Luke-Jr has quit IRC
4612015-12-02T15:35:02 *** kanzure has quit IRC
4622015-12-02T15:35:02 *** Eliel has quit IRC
4632015-12-02T15:35:02 *** davec has quit IRC
4642015-12-02T15:35:02 *** BananaLotus has quit IRC
4652015-12-02T15:35:03 *** Guest1234 has quit IRC
4662015-12-02T15:35:05 *** Anduck has quit IRC
4672015-12-02T15:35:05 *** dgenr8 has quit IRC
4682015-12-02T15:35:05 *** sdaftuar has quit IRC
4692015-12-02T15:35:05 *** morcos has quit IRC
4702015-12-02T15:35:05 *** Thireus has quit IRC
4712015-12-02T15:35:06 *** baldur has quit IRC
4722015-12-02T15:35:06 *** Squidicuz has quit IRC
4732015-12-02T15:35:06 *** AtashiCon has quit IRC
4742015-12-02T15:35:06 *** therealnanotube has quit IRC
4752015-12-02T15:35:06 *** harding has quit IRC
4762015-12-02T15:35:07 *** Arnavion has quit IRC
4772015-12-02T15:35:07 *** Taek has quit IRC
4782015-12-02T15:35:08 *** btcdrak has quit IRC
4792015-12-02T15:35:08 *** Amnez777 has quit IRC
4802015-12-02T15:35:08 *** lclc_ has quit IRC
4812015-12-02T15:35:08 *** CodeShark has quit IRC
4822015-12-02T15:35:09 *** evoskuil has quit IRC
4832015-12-02T15:35:09 *** blkdb has quit IRC
4842015-12-02T15:35:09 *** midnightmagic has quit IRC
4852015-12-02T15:35:09 *** sipa has quit IRC
4862015-12-02T15:35:10 *** zmanian_ has quit IRC
4872015-12-02T15:35:11 *** calibre720 has quit IRC
4882015-12-02T15:35:11 *** paveljanik has quit IRC
4892015-12-02T15:35:11 *** [b__b] has quit IRC
4902015-12-02T15:35:12 *** pigeons has quit IRC
4912015-12-02T15:35:13 *** petertodd has quit IRC
4922015-12-02T15:35:13 *** wumpus has quit IRC
4932015-12-02T15:35:13 *** jouke has quit IRC
4942015-12-02T15:35:13 *** jl2012 has quit IRC
4952015-12-02T15:35:14 *** andytoshi has quit IRC
4962015-12-02T15:35:14 *** neha has quit IRC
4972015-12-02T15:35:14 *** mm_1 has quit IRC
4982015-12-02T15:35:14 *** aj has quit IRC
4992015-12-02T15:35:14 *** bsm1175322 has quit IRC
5002015-12-02T15:35:16 *** PRab has quit IRC
5012015-12-02T15:35:16 *** helo has quit IRC
5022015-12-02T15:35:17 *** guruvan has quit IRC
5032015-12-02T15:35:17 *** zxzzt has quit IRC
5042015-12-02T15:35:17 *** murr4y has quit IRC
5052015-12-02T15:35:18 *** nkuttler has quit IRC
5062015-12-02T15:35:20 *** Guest40360 has quit IRC
5072015-12-02T15:37:21 *** Guest1234 has joined #bitcoin-core-dev
5082015-12-02T15:39:28 *** Amnez777 has joined #bitcoin-core-dev
5092015-12-02T15:39:31 *** mr_burdell has joined #bitcoin-core-dev
5102015-12-02T15:39:32 *** tripleslash has joined #bitcoin-core-dev
5112015-12-02T15:39:32 *** CodeShark_ has joined #bitcoin-core-dev
5122015-12-02T15:39:32 *** Ylbam has joined #bitcoin-core-dev
5132015-12-02T15:39:32 *** bsm117532 has joined #bitcoin-core-dev
5142015-12-02T15:39:32 *** arubi_ has joined #bitcoin-core-dev
5152015-12-02T15:39:32 *** instagibbs has joined #bitcoin-core-dev
5162015-12-02T15:39:32 *** lecusemble has joined #bitcoin-core-dev
5172015-12-02T15:39:32 *** pmienk has joined #bitcoin-core-dev
5182015-12-02T15:39:32 *** da2ce7 has joined #bitcoin-core-dev
5192015-12-02T15:39:32 *** ghtdak has joined #bitcoin-core-dev
5202015-12-02T15:39:32 *** go1111111 has joined #bitcoin-core-dev
5212015-12-02T15:39:32 *** warren has joined #bitcoin-core-dev
5222015-12-02T15:39:32 *** asoltys has joined #bitcoin-core-dev
5232015-12-02T15:39:32 *** phantomcircuit has joined #bitcoin-core-dev
5242015-12-02T15:39:32 *** cfields has joined #bitcoin-core-dev
5252015-12-02T15:39:32 *** Apocalyptic has joined #bitcoin-core-dev
5262015-12-02T15:39:32 *** gavinandresen has joined #bitcoin-core-dev
5272015-12-02T15:39:32 *** BlueMatt has joined #bitcoin-core-dev
5282015-12-02T15:39:35 *** AtashiCon has joined #bitcoin-core-dev
5292015-12-02T15:39:35 *** therealnanotube has joined #bitcoin-core-dev
5302015-12-02T15:39:35 *** harding has joined #bitcoin-core-dev
5312015-12-02T15:39:35 *** Arnavion has joined #bitcoin-core-dev
5322015-12-02T15:39:35 *** Taek has joined #bitcoin-core-dev
5332015-12-02T15:39:35 *** btcdrak has joined #bitcoin-core-dev
5342015-12-02T15:39:35 *** lclc_ has joined #bitcoin-core-dev
5352015-12-02T15:39:35 *** CodeShark has joined #bitcoin-core-dev
5362015-12-02T15:39:35 *** evoskuil has joined #bitcoin-core-dev
5372015-12-02T15:39:35 *** blkdb has joined #bitcoin-core-dev
5382015-12-02T15:40:52 *** PRab has joined #bitcoin-core-dev
5392015-12-02T15:40:52 *** helo has joined #bitcoin-core-dev
5402015-12-02T15:40:52 *** zxzzt has joined #bitcoin-core-dev
5412015-12-02T15:40:52 *** murr4y has joined #bitcoin-core-dev
5422015-12-02T15:40:52 *** nkuttler has joined #bitcoin-core-dev
5432015-12-02T15:42:35 *** Anduck has joined #bitcoin-core-dev
5442015-12-02T15:42:35 *** dgenr8 has joined #bitcoin-core-dev
5452015-12-02T15:42:35 *** sdaftuar has joined #bitcoin-core-dev
5462015-12-02T15:42:35 *** morcos has joined #bitcoin-core-dev
5472015-12-02T15:42:35 *** Thireus has joined #bitcoin-core-dev
5482015-12-02T15:42:35 *** baldur has joined #bitcoin-core-dev
5492015-12-02T15:42:35 *** Squidicuz has joined #bitcoin-core-dev
5502015-12-02T15:42:56 *** midnightmagic has joined #bitcoin-core-dev
5512015-12-02T15:42:57 *** sipa has joined #bitcoin-core-dev
5522015-12-02T15:42:57 *** zmanian_ has joined #bitcoin-core-dev
5532015-12-02T15:44:18 *** ParadoxSpiral has quit IRC
5542015-12-02T15:44:20 *** Guest40360 has joined #bitcoin-core-dev
5552015-12-02T15:45:45 *** CodeShark_ has quit IRC
5562015-12-02T15:47:37 *** ParadoxSpiral has joined #bitcoin-core-dev
5572015-12-02T15:58:38 *** MarcoFalke has joined #bitcoin-core-dev
5582015-12-02T15:58:54 <morcos> wumpus: turns out due to the GetMinRelayFee function, the default block priority size change completely eliminated the ability to send free txs (at least it looks like it would have)
5592015-12-02T15:59:17 *** jtimon has joined #bitcoin-core-dev
5602015-12-02T15:59:17 *** Guyver2 has joined #bitcoin-core-dev
5612015-12-02T15:59:17 *** amiller has joined #bitcoin-core-dev
5622015-12-02T15:59:17 *** fkhan has joined #bitcoin-core-dev
5632015-12-02T15:59:17 *** jgarzik has joined #bitcoin-core-dev
5642015-12-02T15:59:17 *** arowser has joined #bitcoin-core-dev
5652015-12-02T15:59:17 *** gmaxwell has joined #bitcoin-core-dev
5662015-12-02T15:59:17 *** jcorgan has joined #bitcoin-core-dev
5672015-12-02T15:59:17 *** isis has joined #bitcoin-core-dev
5682015-12-02T15:59:17 *** kanzure has joined #bitcoin-core-dev
5692015-12-02T15:59:17 *** Eliel has joined #bitcoin-core-dev
5702015-12-02T15:59:17 *** davec has joined #bitcoin-core-dev
5712015-12-02T15:59:17 *** BananaLotus has joined #bitcoin-core-dev
5722015-12-02T15:59:25 <morcos> this will also be addressed in 7062 by just eliminating the GetMinRelayFee function altogether
5732015-12-02T15:59:51 <morcos> i'm not sure how much it matters since sending free txs is basically useless anyway
5742015-12-02T16:00:01 <morcos> if you're running with a limited mempool
5752015-12-02T16:00:09 <morcos> s/useless/unusable/
5762015-12-02T16:01:16 <morcos> just pointing this out to understand that master has slightly unintended behavior right now and another reason 7062 is important
5772015-12-02T16:01:25 *** zookolaptop has joined #bitcoin-core-dev
5782015-12-02T16:01:50 <morcos> of course this wasn't caught in rpc tests because we changed them all to have a default block priority size
5792015-12-02T16:03:03 <morcos> i'd view this as further evidence that in order to get away from our unstable equilibrium with respect to priority in 0.12, we should just remove it completely for 0.13
5802015-12-02T16:03:25 <morcos> its too hard to properly support at least in its current form
5812015-12-02T16:07:36 *** Amnez777 has quit IRC
5822015-12-02T16:09:03 *** Amnez777 has joined #bitcoin-core-dev
5832015-12-02T16:09:31 *** jtimon has quit IRC
5842015-12-02T16:09:32 *** Guyver2 has quit IRC
5852015-12-02T16:09:32 *** amiller has quit IRC
5862015-12-02T16:09:32 *** fkhan has quit IRC
5872015-12-02T16:09:32 *** jgarzik has quit IRC
5882015-12-02T16:09:32 *** arowser has quit IRC
5892015-12-02T16:09:34 *** gmaxwell has quit IRC
5902015-12-02T16:09:34 *** jcorgan has quit IRC
5912015-12-02T16:09:34 *** isis has quit IRC
5922015-12-02T16:09:34 *** kanzure has quit IRC
5932015-12-02T16:09:34 *** Eliel has quit IRC
5942015-12-02T16:09:35 *** davec has quit IRC
5952015-12-02T16:09:35 *** BananaLotus has quit IRC
5962015-12-02T16:10:22 *** Amnez777 has quit IRC
5972015-12-02T16:34:51 *** bsm1175322 has joined #bitcoin-core-dev
5982015-12-02T16:34:51 *** aj has joined #bitcoin-core-dev
5992015-12-02T16:34:51 *** neha has joined #bitcoin-core-dev
6002015-12-02T16:34:51 *** andytoshi has joined #bitcoin-core-dev
6012015-12-02T16:34:51 *** wumpus has joined #bitcoin-core-dev
6022015-12-02T16:34:51 *** petertodd has joined #bitcoin-core-dev
6032015-12-02T16:34:51 *** jouke has joined #bitcoin-core-dev
6042015-12-02T16:34:51 *** pigeons has joined #bitcoin-core-dev
6052015-12-02T16:34:51 *** [b__b] has joined #bitcoin-core-dev
6062015-12-02T16:34:51 *** calibre720 has joined #bitcoin-core-dev
6072015-12-02T16:34:51 *** mm_1 has joined #bitcoin-core-dev
6082015-12-02T16:34:51 *** jl2012 has joined #bitcoin-core-dev
6092015-12-02T16:34:51 *** berndj has joined #bitcoin-core-dev
6102015-12-02T16:34:51 *** jtimon has joined #bitcoin-core-dev
6112015-12-02T16:34:51 *** Guyver2 has joined #bitcoin-core-dev
6122015-12-02T16:34:51 *** amiller has joined #bitcoin-core-dev
6132015-12-02T16:34:51 *** fkhan has joined #bitcoin-core-dev
6142015-12-02T16:34:51 *** jgarzik has joined #bitcoin-core-dev
6152015-12-02T16:34:51 *** arowser has joined #bitcoin-core-dev
6162015-12-02T16:34:51 *** gmaxwell has joined #bitcoin-core-dev
6172015-12-02T16:34:51 *** jcorgan has joined #bitcoin-core-dev
6182015-12-02T16:34:51 *** isis has joined #bitcoin-core-dev
6192015-12-02T16:34:52 *** kanzure has joined #bitcoin-core-dev
6202015-12-02T16:34:52 *** Eliel has joined #bitcoin-core-dev
6212015-12-02T16:34:52 *** davec has joined #bitcoin-core-dev
6222015-12-02T16:34:52 *** BananaLotus has joined #bitcoin-core-dev
6232015-12-02T16:45:01 *** jtimon has quit IRC
6242015-12-02T16:45:02 *** Guyver2 has quit IRC
6252015-12-02T16:45:02 *** amiller has quit IRC
6262015-12-02T16:45:02 *** fkhan has quit IRC
6272015-12-02T16:45:02 *** jgarzik has quit IRC
6282015-12-02T16:45:03 *** arowser has quit IRC
6292015-12-02T16:45:04 *** gmaxwell has quit IRC
6302015-12-02T16:45:04 *** jcorgan has quit IRC
6312015-12-02T16:45:04 *** isis has quit IRC
6322015-12-02T16:45:04 *** kanzure has quit IRC
6332015-12-02T16:45:05 *** Eliel has quit IRC
6342015-12-02T16:45:05 *** davec has quit IRC
6352015-12-02T16:45:05 *** BananaLotus has quit IRC
6362015-12-02T16:45:06 *** berndj has quit IRC
6372015-12-02T16:45:06 *** jl2012 has quit IRC
6382015-12-02T16:45:06 *** mm_1 has quit IRC
6392015-12-02T16:45:06 *** calibre720 has quit IRC
6402015-12-02T16:45:07 *** [b__b] has quit IRC
6412015-12-02T16:45:08 *** pigeons has quit IRC
6422015-12-02T16:45:08 *** petertodd has quit IRC
6432015-12-02T16:45:08 *** wumpus has quit IRC
6442015-12-02T16:45:08 *** jouke has quit IRC
6452015-12-02T16:45:09 *** andytoshi has quit IRC
6462015-12-02T16:45:09 *** neha has quit IRC
6472015-12-02T16:45:10 *** aj has quit IRC
6482015-12-02T16:45:10 *** bsm1175322 has quit IRC
6492015-12-02T16:46:42 *** BananaLotus has joined #bitcoin-core-dev
6502015-12-02T16:46:42 *** davec has joined #bitcoin-core-dev
6512015-12-02T16:46:42 *** Eliel has joined #bitcoin-core-dev
6522015-12-02T16:46:42 *** kanzure has joined #bitcoin-core-dev
6532015-12-02T16:46:42 *** isis has joined #bitcoin-core-dev
6542015-12-02T16:46:42 *** jcorgan has joined #bitcoin-core-dev
6552015-12-02T16:46:42 *** gmaxwell has joined #bitcoin-core-dev
6562015-12-02T16:46:42 *** arowser has joined #bitcoin-core-dev
6572015-12-02T16:46:42 *** jgarzik has joined #bitcoin-core-dev
6582015-12-02T16:46:42 *** fkhan has joined #bitcoin-core-dev
6592015-12-02T16:46:42 *** amiller has joined #bitcoin-core-dev
6602015-12-02T16:46:42 *** Guyver2 has joined #bitcoin-core-dev
6612015-12-02T16:46:42 *** jtimon has joined #bitcoin-core-dev
6622015-12-02T16:46:42 *** berndj has joined #bitcoin-core-dev
6632015-12-02T16:46:42 *** jl2012 has joined #bitcoin-core-dev
6642015-12-02T16:46:42 *** mm_1 has joined #bitcoin-core-dev
6652015-12-02T16:46:42 *** calibre720 has joined #bitcoin-core-dev
6662015-12-02T16:46:42 *** [b__b] has joined #bitcoin-core-dev
6672015-12-02T16:46:42 *** pigeons has joined #bitcoin-core-dev
6682015-12-02T16:46:42 *** jouke has joined #bitcoin-core-dev
6692015-12-02T16:46:42 *** petertodd has joined #bitcoin-core-dev
6702015-12-02T16:46:42 *** wumpus has joined #bitcoin-core-dev
6712015-12-02T16:46:42 *** andytoshi has joined #bitcoin-core-dev
6722015-12-02T16:46:42 *** neha has joined #bitcoin-core-dev
6732015-12-02T16:46:42 *** aj has joined #bitcoin-core-dev
6742015-12-02T16:46:42 *** bsm1175322 has joined #bitcoin-core-dev
6752015-12-02T16:48:52 *** MarcoFalke has quit IRC
6762015-12-02T16:48:52 *** MarcoFalke has joined #bitcoin-core-dev
6772015-12-02T16:53:05 *** Eliel has quit IRC
6782015-12-02T17:01:58 *** Eliel has joined #bitcoin-core-dev
6792015-12-02T17:05:22 *** Luke-Jr has joined #bitcoin-core-dev
6802015-12-02T17:05:42 *** ParadoxSpiral is now known as Guest43675
6812015-12-02T17:06:16 *** guruvan has joined #bitcoin-core-dev
6822015-12-02T17:08:41 *** gribble has joined #bitcoin-core-dev
6832015-12-02T17:21:02 *** Amnez777 has joined #bitcoin-core-dev
6842015-12-02T17:21:03 *** Amnez777 has quit IRC
6852015-12-02T17:21:35 *** Amnez777 has joined #bitcoin-core-dev
6862015-12-02T17:21:35 *** Amnez777 has quit IRC
6872015-12-02T17:21:35 *** Amnez777 has joined #bitcoin-core-dev
6882015-12-02T17:26:40 *** BashCo has quit IRC
6892015-12-02T17:44:52 *** afk11 has joined #bitcoin-core-dev
6902015-12-02T17:46:39 *** ParadoxSpiral_ has joined #bitcoin-core-dev
6912015-12-02T17:49:50 *** Guest43675 has quit IRC
6922015-12-02T17:54:39 *** BashCo has joined #bitcoin-core-dev
6932015-12-02T18:32:54 <btcdrak> wow, today has been a bullrun on PR merges!
6942015-12-02T18:33:08 <sipa> almost there
6952015-12-02T18:54:42 *** zookolaptop has quit IRC
6962015-12-02T18:56:48 *** afk11 has quit IRC
6972015-12-02T18:58:42 <btcdrak> sdaftaur: #6312 has been rebased,
6982015-12-02T18:59:13 *** afk11 has joined #bitcoin-core-dev
6992015-12-02T19:00:33 <morcos> sipa: i have some questions about #6312
7002015-12-02T19:00:50 <morcos> in thinking about how to store height and time txs are valid at
7012015-12-02T19:01:13 <morcos> are we going to be ok with passing output height/time arguments through CheckLockTime to LockTime to get populated?
7022015-12-02T19:01:29 <morcos> The int64_t that LockTime returns is useless as far as I can tell, it should just be a bool
7032015-12-02T19:02:22 <phantomcircuit> morcos, there are way too many knobs for that stuff
7042015-12-02T19:02:38 <morcos> phantomcircuit: how do you mean?
7052015-12-02T19:02:39 <sipa> hmm, i thought it was used for determining time until confirmation
7062015-12-02T19:02:50 <phantomcircuit> i was going through and trying to change mining knobs yesterday and had to go and read the source to make sense of them
7072015-12-02T19:03:28 <sipa> but the semantics are a bit weird; you need to call twice, once with zero time and once with zero height to get actual data
7082015-12-02T19:03:31 <morcos> sipa: i didn't double check that it wasn't used anywhere but how could it be. you have a height and which you could be valid and a time, its only returning one
7092015-12-02T19:04:18 <morcos> phantomcircuit: i'm not talking about knobs, i'm talking about caching calculations to save time on reorgs and mining
7102015-12-02T19:04:20 <sipa> if that is not the case, reverting to just a bool seems appropriate
7112015-12-02T19:04:25 <morcos> which knobs were you turning
7122015-12-02T19:04:40 <phantomcircuit> ok im talking about what you said like 3 hours ago :)
7132015-12-02T19:04:41 <morcos> sipa: that's secondary to my question though of is it ok to pass in output arguments?
7142015-12-02T19:04:48 <phantomcircuit> the priority space things
7152015-12-02T19:05:02 <morcos> phantomcircuit: ok, agreed there
7162015-12-02T19:05:15 *** treehug88 has joined #bitcoin-core-dev
7172015-12-02T19:05:20 <sipa> morcos: will look at the code in a few days, other things now first
7182015-12-02T19:05:40 <morcos> sipa: we don't need to change that for #6312 to merge, but i just want to have some idea that we'll be able to solve the performance degradation
7192015-12-02T19:05:58 <morcos> since i think solving it should hold up releasing #6312 based code in a point release
7202015-12-02T19:06:04 *** cocoBTC has joined #bitcoin-core-dev
7212015-12-02T19:06:13 <morcos> sipa: ok sure
7222015-12-02T19:06:33 <morcos> releasing BIP68 soft fork i mean
7232015-12-02T19:07:45 <morcos> phantomcircuit: checkout sdaftuars 4th commit in 7062. it just makes me happy!
7242015-12-02T19:08:42 *** afk11 has quit IRC
7252015-12-02T19:11:28 <morcos> sigh.. i guess the return value of LockTime is used for GUI and tests.. doesn't seem very valuable to me though since it's just one of the possible times you could be waiting for
7262015-12-02T19:11:54 <sipa> maybe it should return a pair instead
7272015-12-02T19:12:00 <sipa> with height and time both
7282015-12-02T19:17:57 <morcos> yeah, thats' what i'd like to get out of it, except only the BIP68 valid height and time
7292015-12-02T19:18:06 <morcos> we already have the locktime handy
7302015-12-02T19:33:31 *** Thireus has quit IRC
7312015-12-02T19:54:01 *** Ylbam has quit IRC
7322015-12-02T19:54:28 <morcos> i hope this isn't a really stupid question, but the code in the GUI that shows how long a locked transaciton is "open" for
7332015-12-02T19:54:45 <morcos> how does one get a locked transacion in the wallet in the first place?
7342015-12-02T19:55:13 <MarcoFalke> reindex
7352015-12-02T19:56:08 <morcos> so it'll be temporarily locked while the chain catches up?
7362015-12-02T19:57:58 <MarcoFalke> Can't test anymore :(
7372015-12-02T19:57:59 <MarcoFalke> $ src/qt/bitcoin-qt -regtest -reindex
7382015-12-02T19:57:59 <MarcoFalke> bitcoin-qt: wallet/wallet.cpp:776: void CWallet::MarkConflicted(const uint256&, const uint256&): Assertion `mapBlockIndex.count(hashBlock)' failed.
7392015-12-02T19:57:59 <MarcoFalke> Aborted (core dumped)
7402015-12-02T19:59:13 <morcos> MarcoFalke: Not sure if your talking to me? but that seems like a larger problem than having no real way to show a locked tx!
7412015-12-02T20:01:48 <MarcoFalke> morcos, reindex was for you. The other was for me. ;)
7422015-12-02T20:02:00 <MarcoFalke> Just a note for me test this tomorrow.
7432015-12-02T20:02:06 <MarcoFalke> Don't have time right now
7442015-12-02T20:07:41 *** MarcoFalke has quit IRC
7452015-12-02T20:09:05 *** lclc_ is now known as lclc
7462015-12-02T20:34:28 *** guest234234 has joined #bitcoin-core-dev
7472015-12-02T20:38:43 *** Luke-Jr has quit IRC
7482015-12-02T20:39:04 *** Luke-Jr has joined #bitcoin-core-dev
7492015-12-02T20:59:47 *** guest234234 has quit IRC
7502015-12-02T21:08:05 *** Thireus has joined #bitcoin-core-dev
7512015-12-02T21:38:37 *** go1111111 has quit IRC
7522015-12-02T21:53:55 *** ParadoxSpiral_ has quit IRC
7532015-12-02T21:53:58 *** treehug88 has quit IRC
7542015-12-02T22:05:02 *** zookolaptop has joined #bitcoin-core-dev
7552015-12-02T22:06:00 *** arubi_ is now known as arubi
7562015-12-02T22:22:35 *** Ylbam has joined #bitcoin-core-dev
7572015-12-02T22:35:35 *** fkhan has quit IRC
7582015-12-02T22:36:38 *** Guyver2 has quit IRC
7592015-12-02T22:42:37 *** zookolaptop has quit IRC
7602015-12-02T22:49:49 *** cocoBTC has quit IRC
7612015-12-02T22:50:10 *** fkhan has joined #bitcoin-core-dev
7622015-12-02T23:07:42 *** zookolaptop has joined #bitcoin-core-dev
7632015-12-02T23:47:00 *** go1111111 has joined #bitcoin-core-dev