12015-10-29T00:04:03  <aj> what's the status of BIP62 (malleability)? is there something documenting what's stopping it from being ready to be deployed, at least for third-party malleability?
  22015-10-29T00:07:20  <gmaxwell> aj: the fix for nussance third party malleability is already deployed, in 0.11.1 and 0.10.3, but most hashpower isn't running it yet.
  32015-10-29T00:08:14  <gmaxwell> BIP62 which also protects against miners creating malleability for a subset of transactions likely has issues still, and needs to be rewritten... fortunately the parts of it that don't have issues are flowing in.
  42015-10-29T00:12:24  <gmaxwell> aj: the downside is that some wallets with absentee maintance are going to get their transactions blocked; but a couple years of nagging is all we could do and with active attacks going on it didn't make sense to wait any longer and let everyone continue to get disrupted just to avoid disrupting wallets responsible for only a couple percent of transactions.
  52015-10-29T00:15:46  <aj> gmaxwell: makes sense... is there an existing PR for bip 62 or something i can read?
  62015-10-29T00:17:12  <aj> gmaxwell: (the consensus change side, more than the already-deployed isStandard changes i mean)
  72015-10-29T00:27:06  <gmaxwell> aj: well they're one in the same in Bitcoin Core; these changes are accomplished via validation flags. To make them non-standard we add the new restrictions to the set of flags used to verify transactions going into the mempool.
  82015-10-29T00:27:21  <gmaxwell> To add them to consensus, the softfork negoiates turning them on for block validation.
  92015-10-29T00:29:40  <aj> gmaxwell: hmm, i guess i'm confused as to what are the parts that have issues and need rewriting before it can softfork and protect from miners too then?
 102015-10-29T00:33:11  *** deepcore has quit IRC
 112015-10-29T00:37:00  <gmaxwell> aj: there are more sources of malleability for transactions generally (but not ordinary p2pkh and multisig) than this addresses; at the same time, fancy contract usage -- like swaps and refunds need #9 (and perhaps #8) to be addressed, and CLTV addresses their needs better.
 122015-10-29T00:38:49  <gmaxwell> aj: as far as softforking it, it really need to be comprehensively non-standard first before we can do that; and softforking to prevent nussance mallability from miners is probably of pretty low value since miners have no reason to create it, so it's a lower priority especially considering how complex and invasive the changes are.
 132015-10-29T00:39:04  <gmaxwell> (and because every time we've picked up BIP62 again we've found more cases that weren't covered. :( )
 142015-10-29T00:39:13  <gmaxwell> (again, related to less common usage)
 152015-10-29T00:40:57  <aj> gmaxwell: oh, hmm. that sounds more complicated than i was hoping :)
 162015-10-29T00:41:21  *** dcousens has joined #bitcoin-core-dev
 172015-10-29T00:42:18  <gmaxwell> aj: rethinking this resulted in coming up with the seggregated witness approach thats in elements alpha, and which may be possible to soft-fork into bitcoin.
 182015-10-29T00:42:35  <gmaxwell> So personally thats the route I'd like to go down.
 192015-10-29T00:42:39  <aj> gmaxwell: i was assuming that was a lot further off than bip62 though?
 202015-10-29T00:42:55  <sipa> bip62 can be simplified a lot now, if we want just that
 212015-10-29T00:43:00  *** zooko has joined #bitcoin-core-dev
 222015-10-29T00:43:07  <sipa> all of bip62's rules are already nonstandard in 0.10.3 and 0.11.1
 232015-10-29T00:43:32  <gmaxwell> BIP62 is infintely far off right now, no one is working on it. And I don't think the approach is likely to be very successful; except for blocking malleability in a few narrow cases (which we've already been breaking out)
 242015-10-29T00:43:35  <sipa> so if the network accepts those rules, we don't even need v2 transactions in bip62... just unconditionally make violations of its rules fatal
 252015-10-29T00:44:08  <gmaxwell> For the nussance things, non-standardness is sufficient. For contracts BIP62 is insufficient, but CLTV covers a lot of them.
 262015-10-29T00:44:18  <gmaxwell> (CLTV and CSV)
 272015-10-29T00:46:26  *** dcousens has quit IRC
 282015-10-29T00:48:05  <aj> gmaxwell: so how far off is segregated witness? it doesn't have a bip, and needs a block size increase, i think?
 292015-10-29T00:51:12  <sipa> what does the block size have to do with it...?
 302015-10-29T00:51:32  <sipa> the complication is mostly that it needs a change in the p2p relay protocol for blocks and transactions
 312015-10-29T00:52:10  *** jgarzik has joined #bitcoin-core-dev
 322015-10-29T00:53:10  <aj> sipa: i thought i just read that segregated witness increased tx size by a bunch
 332015-10-29T00:53:31  <sipa> i thibk you're confusing with confidential transactions
 342015-10-29T00:53:46  <aj> sipa: aha; "In fact, this witnessing occupies 2/3rd of the blockchain." https://bitcointalk.org/index.php?topic=1210235.0
 352015-10-29T00:53:52  <aj> sipa: could be
 362015-10-29T00:54:01  <sipa> seggregated witness just moves scriptSig out of transactions
 372015-10-29T00:54:21  <sipa> in alpha, the seggregation is scriptSig AND the range proofs
 382015-10-29T00:54:37  <aj> sipa: aha, that makes more sense
 392015-10-29T00:57:03  *** PaulCapestany has quit IRC
 402015-10-29T00:57:11  <morcos> sipa: that idea i mentioned about scanning the feerate sort for "hot hashes" (txins likely to be redeemed in the next few blocks) and then not deleting those from the cache on a flush
 412015-10-29T00:58:02  <morcos> it has some promise, i just coded up a rough version, takes about 30ms to generate the set of txins from the top 10MB worth of txs
 422015-10-29T00:58:54  <morcos> its hard for me to calculate exactly how well its working b/c it totally screwed up the cache size accounting unless i get a bit smarter
 432015-10-29T00:58:54  *** PaulCapestany has joined #bitcoin-core-dev
 442015-10-29T01:00:14  *** dcousens has joined #bitcoin-core-dev
 452015-10-29T01:00:31  <morcos> that 30ms is out of a flush time thats usually in the 300ms range, but then causes validation times to get a bit faster.  anyway, i'll play around with it some more.
 462015-10-29T01:01:15  <gmaxwell> aj: ... uh, ... thats saying that _currently_ it's 2/3rd of the blockchain, which is all bandwidth that could be _saved_ by a synchronizing node that isn't checking historic signatures.
 472015-10-29T01:01:33  <gmaxwell> aj: so its the opposite, and one of the reasons that that approach is so much more attractive.
 482015-10-29T01:02:05  <gmaxwell> (though until a week or so ago I didn't believe it was soft-forkable, but luke appears to have more or less solved that design question)
 492015-10-29T01:03:57  <sipa> gmaxwell: i haven't heard luke's idea, but I think it's simple enough? use "<reedeemscripthash> OP_NOP7" as scriptPubKey, "" as scriptSig, and define an auxiliary data structure with "<scriptSig> <redeemScript>" in it
 502015-10-29T01:11:56  <gmaxwell> sipa: yes sir. And require the scrippubkey in the original datastructure to be empty for OP_SEGWITNESS scripts.
 512015-10-29T01:12:33  <gmaxwell> er original scriptsig.
 522015-10-29T01:12:37  *** d_t has quit IRC
 532015-10-29T01:12:41  <sipa> as i said :)
 542015-10-29T01:13:44  <gmaxwell> lol "" didn't take up enough space on the screen.
 552015-10-29T01:34:49  *** zooko has quit IRC
 562015-10-29T01:38:21  *** zooko has joined #bitcoin-core-dev
 572015-10-29T01:42:00  *** daniel____ has joined #bitcoin-core-dev
 582015-10-29T01:44:21  *** Ylbam has quit IRC
 592015-10-29T01:49:04  *** Arnavion has quit IRC
 602015-10-29T01:55:22  *** bsm117532 has joined #bitcoin-core-dev
 612015-10-29T01:55:32  <bsm117532> Why is leveldb in the core in the first place?
 622015-10-29T01:57:07  <sipa> because we want to have control over its changes
 632015-10-29T01:57:36  <bsm117532> By not changing it...
 642015-10-29T01:57:37  <sipa> and we have local modifications to it (win env, disable compression, and we've had other ones before)
 652015-10-29T01:57:47  <bsm117532> Ref https://github.com/bitcoin/bitcoin/pull/6899
 662015-10-29T01:57:54  <sipa> if a bug were to be found in leveldb, fixing it may cause a consensus failure
 672015-10-29T01:58:10  <sipa> and bugs like that have happened
 682015-10-29T01:58:20  <sipa> (before we were using leveldb, to be clear)
 692015-10-29T02:01:54  <gmaxwell> bsm117532: leveldb has (prior to our use of it) fixed 'bugs' that would have broken network consensus.
 702015-10-29T02:02:06  <gmaxwell> oh jinx, sorry.
 712015-10-29T02:02:31  <bsm117532> That's yucky on so many levels.
 722015-10-29T02:02:39  <sipa> how do you mean?
 732015-10-29T02:02:45  <bsm117532> FWIW I'd have put it in a separate repo under bitcoin, rather than import the code directly.
 742015-10-29T02:03:04  <sipa> bsm117532: https://github.com/bitcoin/leveldb
 752015-10-29T02:03:09  <bsm117532> Yeah, like that ;-)
 762015-10-29T02:03:15  <sipa> not like that; that
 772015-10-29T02:03:24  <gmaxwell> It is.
 782015-10-29T02:03:28  <bsm117532> The github repo should have a reference to it, rather than have the code imported.
 792015-10-29T02:03:44  <sipa> that is how git subtree works
 802015-10-29T02:03:57  <sipa> subtrees are ugly
 812015-10-29T02:04:00  <bsm117532> checking...
 822015-10-29T02:04:16  <sipa> but the only alternative is submodules, which are even more ugly
 832015-10-29T02:04:37  <bsm117532> Yeah that's what I mean, a submodule.
 842015-10-29T02:05:14  *** belcher has quit IRC
 852015-10-29T02:05:14  <sipa> well we're using subtrees
 862015-10-29T02:05:39  <sipa> i don't feel like reiterating the advantages of one over the other in either direction; you can find enough discussion about that on the internet :)
 872015-10-29T02:06:04  <bsm117532> AFAICT, when I clone bitcoin, I don't get the bitcoin/leveldb repo.  I get bitcoin/src/leveldb which is entirely separate.  Am I wrong about that?
 882015-10-29T02:06:32  <sipa> correct, though a script is included to verify their correspondence
 892015-10-29T02:07:16  <bsm117532> I see.  Egad that's ugly.  Well then you'll just have to deal with spurious patches to leveldb.  :-P
 902015-10-29T02:08:05  <sipa> if we need to change something to our leveldb tree, the correct way is submit it as a PR to the bitcoin/leveldb repo, and then bitcoin core can update to a new version
 912015-10-29T02:08:53  <bsm117532> That makes sense.  It's the other direction that is generating a problem here.  (modifying src/leveldb...)
 922015-10-29T02:09:11  <sipa> we don't ever accept changes directly to that directory
 932015-10-29T02:11:53  <bsm117532> Well we're going to replace leveldb with sqlite, right?!?!  ;-)
 942015-10-29T02:12:08  <sipa> maybe.
 952015-10-29T02:12:21  <CodeShark> is sqlite performant enough?
 962015-10-29T02:12:29  <bsm117532> Also replace Berkeley db with /dev/null...
 972015-10-29T02:12:46  <sipa> bsm117532: already possible, use --disable-wallet at compile time :)
 982015-10-29T02:12:54  <sipa> CodeShark: doubtful
 992015-10-29T02:13:11  <bsm117532> sipa: I'm well aware, always do.
1002015-10-29T02:14:27  <CodeShark> we're pretty set on ditching leveldb, though, right?
1012015-10-29T02:14:30  <bsm117532> CodeShark: don't know.  I re-ran some benchmarks from an old article: https://gist.github.com/mcelrath/6952eab246a7c705a0fb
1022015-10-29T02:14:58  <sipa> CodeShark: only if a suitable replacement is found
1032015-10-29T02:15:21  <bsm117532> I think we need a more targeted leveldb vs. sqlite (or something else) comparison.
1042015-10-29T02:15:40  <sipa> bsm117532: jeff has a branch with bitcoin core running on sqlite3
1052015-10-29T02:15:50  <sipa> but there are problems with background checkpointing etc
1062015-10-29T02:16:00  <CodeShark> the main issues with leveldb are that it's no longer being maintained and that it doesn't guarantee consistency, right?
1072015-10-29T02:16:12  <bsm117532> Well he did that quickly...
1082015-10-29T02:16:23  <sipa> CodeShark: it does guarantee consistency; it just seems to fail on windows pretty often
1092015-10-29T02:16:41  <CodeShark> doesn't it rely on the OS queueing up writes in the correct order or something?
1102015-10-29T02:16:47  <sipa> no
1112015-10-29T02:16:57  <sipa> or at least, it doesn't intend to
1122015-10-29T02:17:19  <sipa> it relies on the OS behaviour properly when asked to do a synchronous write/flush, though
1132015-10-29T02:18:08  <bsm117532> Are we worried about db corruption on power failure?  Or something else generating inconsistencies?
1142015-10-29T02:18:39  <sipa> yes, that's what seems to happen
1152015-10-29T02:19:12  <CodeShark> I haven't looked at the actual study, but https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability
1162015-10-29T02:19:19  <bsm117532> That's a very hard problem that I don't think bitcoin can solve by choice of db.
1172015-10-29T02:19:36  <bsm117532> This is why Oracle charges big bucks for dedicated hardware.
1182015-10-29T02:19:51  <sipa> sqlite is well known for being very stable
1192015-10-29T02:20:24  <CodeShark> sqlite has worked very well for me in certain applications that don't require extremely frequent insertions
1202015-10-29T02:20:39  <dcousens> sipa: aye, the mere simplicity of sqlite is very attractive
1212015-10-29T02:20:50  <sipa> CodeShark: we have extremely infrequent insertions
1222015-10-29T02:21:03  <sipa> but they're very big batches
1232015-10-29T02:21:32  <bsm117532> I've had good luck with sqlite too.  But these are anecdotes.
1242015-10-29T02:22:18  <tripleslash> bsm117532, its not even power failure.  Windows gives very little time for apps to cleanly shutdown these days.
1252015-10-29T02:22:39  *** zooko has quit IRC
1262015-10-29T02:23:07  <sipa> lmdb seems to be a interesting candidate
1272015-10-29T02:23:33  <sipa> but it's mmap-based, so not usable on 32-bit systems for such large databases as we have
1282015-10-29T02:24:48  <dcousens> sipa: leveldb is just used for the txdb atm right?
1292015-10-29T02:24:58  <tripleslash> Pretty much any new pc today is shipping x64.  There comes a time where it will be time to just cut the cord on the X86 systems.
1302015-10-29T02:25:18  <sipa> dcousens: block index and chainstate
1312015-10-29T02:25:29  <sipa> tripleslash: yet ARM is becoming more and more relevant
1322015-10-29T02:26:29  <CodeShark> can't we create multiple databases all restricted to 4 gigs? :)
1332015-10-29T02:26:38  <tripleslash> sipa: true that
1342015-10-29T02:26:59  <sipa> CodeShark: we need atomic changes across databases then
1352015-10-29T02:27:03  <bsm117532> I vote that a 64 bit system as a requirement is a reasonable thing.  Bending over backwards to shoe-horn into 32 bits is not worth anyone's time.
1362015-10-29T02:27:30  <dcousens> sipa: right, the CBlockTree is defined in txdb.h haha
1372015-10-29T02:29:00  *** zooko has joined #bitcoin-core-dev
1382015-10-29T02:29:13  <CodeShark> we can always support mmap on 64-bit systems and fall back on leveldb for 32-bit systems
1392015-10-29T02:29:35  <CodeShark> although dunno what that might entail regarding consensus
1402015-10-29T02:30:19  <CodeShark> it only takes one "undocumented feature" to screw everything up
1412015-10-29T02:30:40  <sipa> having multiple databases is technically not hard; the database interface is pretty neatly abstracted
1422015-10-29T02:31:10  <sipa> but it's very unattractive to risk divergence between them, especially when testing mostly happens on one, and production mostly on another :)
1432015-10-29T02:31:54  <dcousens> sipa: production on 32-bit?
1442015-10-29T02:32:00  <bsm117532> Quick git question...I did a push -f to overwrite my previous commit, because I like having clean histories. I could have also made a second commit on this PR.  Does anyone care?  Would github have squashed them anyway?  (Re: https://github.com/bitcoin/bitcoin/pull/6899 )
1452015-10-29T02:32:29  <sipa> bsm117532: github won't squash for you
1462015-10-29T02:32:36  <sipa> reviewers may ask to squash things
1472015-10-29T02:32:40  * bsm117532 has spent too long being the only committer to his repo.
1482015-10-29T02:32:45  <bsm117532> Ok so I did the right thing.
1492015-10-29T02:33:14  <sipa> only reason to not squash is if it's a complicated commit that required lots of review (for example, big code movement commits)
1502015-10-29T02:33:24  <dcousens> sipa: is the squash op not deterministic?
1512015-10-29T02:33:55  <sipa> dcousens: the resulting tree of a squashed commit is identical to the resulting tree of the series of commits it derived from
1522015-10-29T02:33:56  <bsm117532> There is no squash op... rebase -i is very manual and not deterministic at all.
1532015-10-29T02:34:03  <dcousens> I know the rebase is, and hence verifiable
1542015-10-29T02:34:23  <sipa> dcousens: you're confusing commits with trees
1552015-10-29T02:34:39  <CodeShark> rebase is only not deterministic when you either change commit order or rebase off a different branch
1562015-10-29T02:34:48  <sipa> or if there were conflicts
1572015-10-29T02:35:00  <sipa> or merges within the commits you're rebasing
1582015-10-29T02:35:20  <sipa> rebase applies a merge resolution algorithm, and you can change that algorithm
1592015-10-29T02:35:31  <CodeShark> commit followed by squash is effectively the same as commit --amend
1602015-10-29T02:35:51  <sipa> which is also not deterministic :)
1612015-10-29T02:35:59  <sipa> (the resulting tree is, but the commit itself isn't)
1622015-10-29T02:36:11  <dcousens> sipa: interesting
1632015-10-29T02:36:35  <sipa> the reason it isn't is because a commit has a timestamp
1642015-10-29T02:36:51  <CodeShark> but that's a trivial source of nondeterminism ;)
1652015-10-29T02:37:10  <sipa> you can avoid it by specifying the timestamp on the command-line, though
1662015-10-29T02:37:18  <sipa> yeah
1672015-10-29T02:37:27  <sipa> but rebases are generally not verifiable
1682015-10-29T02:37:38  <sipa> and afaik nobody does that
1692015-10-29T02:43:26  <bsm117532> LMDB does look really interesting...
1702015-10-29T02:45:00  <bsm117532> Looks like it uses COW instead of sqlite's *.journal which I think is write-ahead logging.  So should be much faster than sqlite, probably a factor of 2.
1712015-10-29T02:45:14  *** zooko has quit IRC
1722015-10-29T02:45:15  <sipa> indeed
1732015-10-29T02:45:37  <bsm117532> It looks like an in-memory btrfs ;-)
1742015-10-29T02:46:06  <sipa> except it's not in-memory
1752015-10-29T02:46:21  <bsm117532> Yeah but mmapped, so it looks like it's in-memory.
1762015-10-29T02:50:27  <bsm117532> I've got one more tedious bug I want to fix, but maybe then I'll look at making an LMDB branch for comparison.  If it was so easy for jeff to rip out leveldb for sqlite...
1772015-10-29T02:53:55  *** arowser has left #bitcoin-core-dev
1782015-10-29T03:02:17  *** zooko has joined #bitcoin-core-dev
1792015-10-29T03:10:25  <jgarzik> COW is COW, somewhat like write-ahead logging.  :)
1802015-10-29T03:10:50  <jgarzik> If you order your writes properly, it's write-once
1812015-10-29T03:10:59  <sipa> ... i do wish we could just use LMDB
1822015-10-29T03:11:53  <jgarzik> It's quite easy to switch out.  I could do an LMDB patch.  Also working on a COW dbm myself.
1832015-10-29T03:12:13  <sipa> i'm sure it wouldn't be hard; but LMDB is a total no go on 32-bit systems
1842015-10-29T03:12:28  <jgarzik> the best performance should be COW + Kyoto Cabinet scheme
1852015-10-29T03:12:42  <jgarzik> (KC is worth a look too)
1862015-10-29T03:13:28  <jgarzik> COW practically guarantees no corruption (assuming write order is proper)
1872015-10-29T03:14:14  <sipa> but i would be interested in LMDB's performance...
1882015-10-29T03:14:36  <jgarzik> no idea if LMDB performs better than KC.  Worth benching, definitely.
1892015-10-29T03:15:21  <jgarzik> Google benching leveldb, sqlite, kyoto cabinet: http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
1902015-10-29T03:15:59  <phantomcircuit> jgarzik, COW without any delete? :P
1912015-10-29T03:16:31  <jgarzik> phantomcircuit, typical strategy is reclaim after X generations of the superblock
1922015-10-29T03:16:42  <jgarzik> assuming no stored snapshots
1932015-10-29T03:16:44  <sipa> http://symas.com/mdb/microbench/
1942015-10-29T03:18:04  *** daniel____ has quit IRC
1952015-10-29T03:18:30  *** daniel____ has joined #bitcoin-core-dev
1962015-10-29T03:18:35  *** daniel____ has quit IRC
1972015-10-29T03:18:44  <jgarzik> Useful link.  They should have benched the KC hash db and not btree.  ;p
1982015-10-29T03:19:20  <sipa> not a fair comparison, as lmdb/leveldb only do ordered maps
1992015-10-29T03:20:09  *** daniel____ has joined #bitcoin-core-dev
2002015-10-29T03:20:20  <gmaxwell> has anyone managed to complete a sync with jeff's sqllite attempt?
2012015-10-29T03:20:36  <gmaxwell> I think jcorgan said it was going on day 2 for him.
2022015-10-29T03:20:38  <tripleslash> if you build a win64 binary for me, I'll give it a go.
2032015-10-29T03:21:22  <jgarzik> bench'd BDB in b-tree mode too :(
2042015-10-29T03:21:30  *** daniel____ has quit IRC
2052015-10-29T03:21:45  <jgarzik> if we didn't need ordering, things could go really fast
2062015-10-29T03:21:59  <sipa> we don't really need ordering
2072015-10-29T03:22:19  <sipa> though it may end up being useful if we go from per-tx caching to per-txout caching
2082015-10-29T03:22:50  <sipa> and for normative utxo hashes
2092015-10-29T03:23:10  *** daniel____ has joined #bitcoin-core-dev
2102015-10-29T03:24:55  <phantomcircuit> jgarzik, more importantly we can significantly over provision the initial db to avoid resizing constantly
2112015-10-29T03:29:10  *** Arnavion has joined #bitcoin-core-dev
2122015-10-29T03:34:29  <jgarzik> LMDB could use a windowed mmap approach and support 32-bit systems, >2GB databases
2132015-10-29T03:34:49  <jgarzik> or we could just drop 32-bit support
2142015-10-29T03:35:09  <jgarzik> "full node = big database = big iron = no rPi"
2152015-10-29T03:41:13  <Luke-Jr> jgarzik: …
2162015-10-29T03:41:19  <Luke-Jr> I use 32-bit.
2172015-10-29T03:41:56  <tripleslash> Luke-Jr, you also use dialup.  At some point, people have to upgrade. ;-)
2182015-10-29T03:41:58  <Luke-Jr> except for Valgrind not supporting it, it's a more logical choice than 64-bit. especially x32, once more stuff works.
2192015-10-29T03:42:05  <Luke-Jr> tripleslash: I do not use dialup.
2202015-10-29T03:42:13  <tripleslash> my apologies.
2212015-10-29T03:42:33  <jgarzik> for large databases the address space helps a -lot-.  x32 useful but not in this case.
2222015-10-29T03:42:45  <Luke-Jr> tripleslash: also, I upgraded to 64-bit within a week of AMD releasing the first 64-bit capable CPU. I decided a year or two ago that CPUs were fast enough that 32-bit was the better option now.
2232015-10-29T03:43:08  <Luke-Jr> jgarzik: x32 is only useful if basically everything is x32; not so much if you have both x32 and amd64 programs
2242015-10-29T03:43:59  <jgarzik> not true (but off-topic so I'll stop)
2252015-10-29T04:01:56  *** zooko has quit IRC
2262015-10-29T04:06:30  *** zxzzt has quit IRC
2272015-10-29T04:07:08  *** sdaftuar has quit IRC
2282015-10-29T04:07:10  *** zxzzt has joined #bitcoin-core-dev
2292015-10-29T04:07:43  *** sdaftuar has joined #bitcoin-core-dev
2302015-10-29T04:32:20  <sipa> note: LMDB's on-disk format is platform dependent
2312015-10-29T04:32:31  <sipa> (byte order and word size)
2322015-10-29T05:35:19  *** molly has quit IRC
2332015-10-29T05:36:54  *** d_t has joined #bitcoin-core-dev
2342015-10-29T05:38:08  <phantomcircuit> jgarzik, unfortunately lmdb really isn't an option because of the trade offs they made
2352015-10-29T05:38:56  <sipa> phantomcircuit: any specifics, apart from intentionally no support for 32 bit systems?
2362015-10-29T05:44:46  <dcousens> Luke-Jr: "CPUs were fast enough that 32-bit was the better option
2372015-10-29T05:44:47  <gmaxwell> sipa: well no integrity checks iirc, and non-portable data (latter less of an issue); I think there was some other thing wumpus raised.
2382015-10-29T05:45:02  <dcousens> If its not relevant, could you PM what you mean by that, ooi
2392015-10-29T05:45:13  <Luke-Jr> dcousens: #bitcoin maybe?
2402015-10-29T05:45:26  <dcousens> Luke-Jr: sure
2412015-10-29T05:46:44  <gmaxwell> sipa: or we could just admit that we'll need a custom data structure to make any kind of commitment space/time efficient. :-/
2422015-10-29T06:08:07  *** Guest72716 has quit IRC
2432015-10-29T06:20:01  *** pigeons has joined #bitcoin-core-dev
2442015-10-29T06:20:23  *** pigeons is now known as Guest75176
2452015-10-29T06:27:23  *** deepcore has joined #bitcoin-core-dev
2462015-10-29T06:45:10  *** d_t has quit IRC
2472015-10-29T07:26:56  *** deepcore has quit IRC
2482015-10-29T07:41:39  *** Ylbam has joined #bitcoin-core-dev
2492015-10-29T07:51:35  <wumpus> -1 for dropping 32 bit support, I want to support 32-bit ARM
2502015-10-29T07:52:05  <wumpus> leveldb works well enough I see no need for any kind of desperate measures
2512015-10-29T07:53:01  <wumpus> experimenting with other databases, fine, but I don't like this talk of dropping support for platforms just to accomodate a library
2522015-10-29T08:00:30  <CodeShark> I agree with not removing leveldb support - but other than the fact we have close to zero tolerance for differences in consensus behavior, I think supporting multiple databases is generally a good idea
2532015-10-29T08:01:46  <wumpus> we've made it very easy to switch the database, but not looking forward to maintaining and testing multiple db backends in the upstream repository
2542015-10-29T08:02:59  <gmaxwell> it's very easy to use another one, though most alternatives have performance so poor they're just unusable.
2552015-10-29T08:03:14  <wumpus> I can't say this enough, the database is not an external interface, it's just an implementation detail of bitcoind. There should be zero reason for users to switch it.
2562015-10-29T08:03:36  <CodeShark> apparently corruption is not that infrequent on windows
2572015-10-29T08:03:50  <wumpus> then fix it on windows! it's not magic or rocket science
2582015-10-29T08:03:56  <wumpus> I'm tired of this complaining
2592015-10-29T08:04:01  <CodeShark> ?
2602015-10-29T08:04:04  <gmaxwell> CodeShark: sure, so go fix it!  it's likely the same issue that existed on OSX or similar.
2612015-10-29T08:04:05  <wumpus> can we pool a bounty or something like that
2622015-10-29T08:04:25  <CodeShark> you mean fix leveldb itself?
2632015-10-29T08:04:27  <gmaxwell> (where fsync didn't work for writes via mmaps)
2642015-10-29T08:04:55  <wumpus> I don't want to hear "leveldb is broken on windows" every day, this is not tea time with bitcoin-dev, we should be constructive here
2652015-10-29T08:04:55  <gmaxwell> CodeShark: leveldb's FS access is abstracted, the windows interface we use is probably only used by us and nothing else.
2662015-10-29T08:04:56  <wumpus> yes
2672015-10-29T08:05:51  <gmaxwell> In chrome, for example, all the FS access is via some totally chrome specific layer and doesn't touch any of the FS access code we use.
2682015-10-29T08:06:13  <CodeShark> I don't really fricking care, personally - I don't really run a bunch of bitcoin core instances on windows - I'm just repeating what I've heard from others
2692015-10-29T08:06:58  <gmaxwell> CodeShark: you actually run windows though, none of the other people who would normally fix something like this do.. and we don't even have an archive of a reproduction.
2702015-10-29T08:08:06  <Luke-Jr> (tomorrow we find out CodeShark stopped running Windows :p)
2712015-10-29T08:08:33  <wumpus> I do care but I don't have access to a remotely recent windows machine at the moment, and know very little about windows internals or debugging. I generally use wine when I need to do that but it's no help here.
2722015-10-29T08:09:16  <CodeShark> my windows development at present consists almost 100% of crossbuilds from linux
2732015-10-29T08:10:16  <CodeShark> windows is just the way I access VMs and servers ;)
2742015-10-29T08:10:31  <CodeShark> from one machine
2752015-10-29T08:10:42  <CodeShark> none of my other machines run windows
2762015-10-29T08:11:58  <CodeShark> http://research.cs.wisc.edu/adsl/Publications/alc-hotdep13.pdf
2772015-10-29T08:29:45  <GitHub14> [bitcoin] laanwj opened pull request #6900: gitian: build on ubuntu 14.04 (master...2015_10_gitian_trusty) https://github.com/bitcoin/bitcoin/pull/6900
2782015-10-29T08:50:58  <wumpus> an easy to implement robustness option would be to auto-back up the utxo database once in a while. This can be done in a similar fashion to gettxoutsetinfo, on a snapshot inthe background. Then if unrecoverable database issues happen, restore that
2792015-10-29T08:52:46  <wumpus> (not meant as a substitute for solving the leveldb issue on windows, but what I like is that it helps for both known and unknown issues)
2802015-10-29T09:03:35  *** [1]evoskuil has joined #bitcoin-core-dev
2812015-10-29T09:04:31  *** evoskuil has quit IRC
2822015-10-29T09:04:31  *** [1]evoskuil is now known as evoskuil
2832015-10-29T09:23:23  *** zander has joined #bitcoin-core-dev
2842015-10-29T09:24:19  <zander> I'm wondering about the process of removing stuff from the mempool when a new block comes in.  So transactions from the block naturally are remove from the mempool. Is that mallaeble safe?
2852015-10-29T09:24:33  <zander> Is the txid used for that removal?
2862015-10-29T09:24:43  <zander> Or is it smarter that that.
2872015-10-29T09:24:48  <zander> ?
2882015-10-29T09:25:06  <phantomcircuit> zander, any transactions which conflicts with the new block is removed
2892015-10-29T09:25:29  <zander> ah, ok. Thanks!
2902015-10-29T09:28:11  *** rubensayshi has joined #bitcoin-core-dev
2912015-10-29T09:29:50  *** davec has quit IRC
2922015-10-29T09:30:27  *** davec has joined #bitcoin-core-dev
2932015-10-29T09:54:02  *** BashCo has joined #bitcoin-core-dev
2942015-10-29T09:56:06  *** max777555 has joined #bitcoin-core-dev
2952015-10-29T09:56:12  <max777555> Friends start a new cloud of mining https://cldmine.com/account/registration/4075 Very similar to when registering RDPmain dogikoin 1500 bonus on you buying power and immediately start earning a great opportunity to earn at the very beginning to invite many partners and earn a passive join !!!
2962015-10-29T09:58:18  *** max777555 has quit IRC
2972015-10-29T10:02:00  <phantomcircuit> wumpus, sipa ^
2982015-10-29T10:07:28  *** ChanServ sets mode: +o wumpus
2992015-10-29T10:07:40  *** wumpus sets mode: +b *!*@gateway/web/freenode/ip.37.195.202.198
3002015-10-29T10:07:43  *** ChanServ sets mode: -o wumpus
3012015-10-29T11:11:58  *** PRab_ has joined #bitcoin-core-dev
3022015-10-29T11:13:39  *** PRab has quit IRC
3032015-10-29T11:13:43  *** PRab_ is now known as PRab
3042015-10-29T11:18:01  *** jgarzik has quit IRC
3052015-10-29T11:41:43  *** danielsocials has joined #bitcoin-core-dev
3062015-10-29T11:42:58  *** fanquake has joined #bitcoin-core-dev
3072015-10-29T11:46:29  <GitHub195> [bitcoin] laanwj closed pull request #6781: [QT] pretty print (indent) multiline html output (master...2015/10/qt_rpcconsole_pp) https://github.com/bitcoin/bitcoin/pull/6781
3082015-10-29T11:51:33  *** CodeShark has quit IRC
3092015-10-29T12:05:53  *** danielsocials has quit IRC
3102015-10-29T12:07:44  *** danielsocials has joined #bitcoin-core-dev
3112015-10-29T12:11:06  *** jgarzik has joined #bitcoin-core-dev
3122015-10-29T12:11:06  *** jgarzik has quit IRC
3132015-10-29T12:11:06  *** jgarzik has joined #bitcoin-core-dev
3142015-10-29T12:13:16  <GitHub111> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8daffe227bc6...26752767df45
3152015-10-29T12:13:17  <GitHub111> bitcoin/master 3e187f2 Suhas Daftuar: Fix BIP65 p2p test...
3162015-10-29T12:13:17  <GitHub111> bitcoin/master 2675276 Wladimir J. van der Laan: Merge pull request #6894...
3172015-10-29T12:13:21  <GitHub96> [bitcoin] laanwj closed pull request #6894: [Tests] Fix BIP65 p2p test (master...fix-bip65-p2p-test) https://github.com/bitcoin/bitcoin/pull/6894
3182015-10-29T12:14:12  <bsm117532> We need a test case on windows that generates leveldb corruption, so as to evaluate other db alternatives.  Anecdotes that it happens with leveldb and might not with some other db are unsatisfactory.  What can we do to "pull the rug out from under bitcoind" and test this?
3192015-10-29T12:14:33  <bsm117532> Questions about performance are a lot easier to be quantitative about...
3202015-10-29T12:15:07  <wumpus> reproduction should be simple: run it on a windows pc, crashhe computer or disconnect the power
3212015-10-29T12:15:48  <wumpus> it appears that no one remotely capapble and willing to troubleshoot this issue has no windows PC to check though
3222015-10-29T12:15:55  <bsm117532> That's pretty tedious.  :-/
3232015-10-29T12:16:01  <bsm117532> I don't have a windows pc either...
3242015-10-29T12:16:15  <wumpus> well from what I understand it *always* happens, so it's not that bad
3252015-10-29T12:16:27  <bsm117532> I was thinking like kill -9 on a remote windows vm, or something like that.
3262015-10-29T12:16:33  *** molly has joined #bitcoin-core-dev
3272015-10-29T12:16:50  *** danielsocials has quit IRC
3282015-10-29T12:16:52  <wumpus> well a VM could work, I don't know - couldn't reproduce it with wine at least last time I tried
3292015-10-29T12:18:47  <wumpus> but a full VM is closer to the real thing. I don't have any windows licenses for a VM either, though.
3302015-10-29T12:22:26  <bsm117532> We should be able to get a windows VM through Azure
3312015-10-29T12:23:13  *** danielsocials has joined #bitcoin-core-dev
3322015-10-29T12:31:04  <GitHub178> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/26752767df45...b2ce2c1f0fb1
3332015-10-29T12:31:05  <GitHub178> bitcoin/master 95f4291 MarcoFalke: [trivial] Rewrite help text for feature enabled by default...
3342015-10-29T12:31:06  <GitHub178> bitcoin/master bf68191 MarcoFalke: [trivial] rpcnet: fix typo
3352015-10-29T12:31:06  <GitHub178> bitcoin/master 6782f58 MarcoFalke: [trivial] Latest config.guess...
3362015-10-29T12:31:09  <GitHub152> [bitcoin] laanwj closed pull request #6870: [trivial] Misc cleanup and translations (master...MarcoFalke-2015-trivial3) https://github.com/bitcoin/bitcoin/pull/6870
3372015-10-29T12:40:12  <GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2ce2c1f0fb1...b28c229324d0
3382015-10-29T12:40:12  <GitHub57> bitcoin/master a83f3c2 Bob McElrath: Add explicit shared_ptr constructor due to C++11 error
3392015-10-29T12:40:13  <GitHub57> bitcoin/master b28c229 Wladimir J. van der Laan: Merge pull request #6899...
3402015-10-29T12:40:22  <GitHub144> [bitcoin] laanwj closed pull request #6899: Add explicit shared_ptr constructor due to C++11 error (master...cpp11) https://github.com/bitcoin/bitcoin/pull/6899
3412015-10-29T12:40:48  <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b28c229324d0...725539ea0376
3422015-10-29T12:40:48  <GitHub189> bitcoin/master 0be387a Daniel Kraft: unittest: fix test for null tx input...
3432015-10-29T12:40:49  <GitHub189> bitcoin/master 725539e Wladimir J. van der Laan: Merge pull request #6863...
3442015-10-29T12:40:59  <GitHub146> [bitcoin] laanwj closed pull request #6863: [Test Suite] Fix test for null tx input (master...null-txin-test) https://github.com/bitcoin/bitcoin/pull/6863
3452015-10-29T12:42:36  *** daniel____ has quit IRC
3462015-10-29T12:43:10  *** daniel___ has joined #bitcoin-core-dev
3472015-10-29T12:52:26  *** danielsocials has quit IRC
3482015-10-29T12:53:12  <dcousens> wumpus: for the windows box, would I need a complete chain?
3492015-10-29T12:53:43  <dcousens> I can put bitcoin-qt on a old gaming rig if necessary, have to dust it off a little but, if its worth it
3502015-10-29T12:56:41  <bsm117532> It would be good to know quantitatively if we're actually fixing something by changing the db or just making a mess.
3512015-10-29T12:58:22  *** bsm117532 is now known as mcelrath
3522015-10-29T12:58:30  <dcousens> mcelrath: would I need to build latest?
3532015-10-29T12:59:17  <dcousens> I'd assume so if the aim was to actually fix it haha
3542015-10-29T12:59:19  <mcelrath> build latest bitcoind?  Yes, I mean we'd want to take jgarzik's sqlite branch and a lmdb branch and violently kill them and see what happens to their db's too.
3552015-10-29T13:00:58  <mcelrath> It's kind of an involved test :-/
3562015-10-29T13:01:46  <dcousens> mcelrath: well, I'll see what I can set up tomorrow.  Midnight here so I won't go about messing with setting up a dev-env
3572015-10-29T13:01:56  <mcelrath> But writing a shell script to kill things in a tight loop sounds like an appropriate thing to do to Windows.  ;-)
3582015-10-29T13:02:07  <mcelrath> Cool, thanks!
3592015-10-29T13:02:40  *** fanquake has quit IRC
3602015-10-29T13:02:45  <mcelrath> I'm pretty sure we (or lots of people) can get an azure instance.  But I've never used a remote windows vm.
3612015-10-29T13:08:24  <wumpus> dcousens: I don't think so, I think you just have to kill it while it's syncing
3622015-10-29T13:09:10  <dcousens> wumpus: likely that the shutdown time itself will be dependent on how many writeops are waiting
3632015-10-29T13:09:17  <dcousens> Perhaps worth doing on a HDD, not a SSD?
3642015-10-29T13:09:18  <dcousens>  :P
3652015-10-29T13:14:24  *** treehug88 has joined #bitcoin-core-dev
3662015-10-29T13:25:48  <mcelrath> Is bitcoin anymore consensus-dependent on leveldb?  If we swap it out with sqlite or lmdb, will it still be consensus critical? (and can it be made non-consensus critical?)
3672015-10-29T13:29:36  <wumpus> everything that is called by the consensus code is, in principle, consensus critical
3682015-10-29T13:30:37  <wumpus> so is the database, the file system, the OS. But all that should be important is that they behave correctly.
3692015-10-29T13:31:48  <wumpus> if there are silent bugs it is problematic. For example, if leveldb would ignoring keys with certain properties, using a database without that erratic behavior would fork off from nodes using leveldb
3702015-10-29T13:31:56  <mcelrath> IOW if the verification code (erroneously) can't look up a txid or utxo, it causes a block to be rejected, no?
3712015-10-29T13:33:14  <wumpus> not if it is reported as a database error and simply crashes the node. It is a problem if a record is reported to be present when it is not, or the other way around, or the data is corrupted
3722015-10-29T13:34:01  <wumpus> (which is why leveldb's checksums on everything are nice to have, it provides added assurance that if something is returned it's at least correct)
3732015-10-29T13:36:18  <mcelrath> I'm pretty seriously worried about silent bit flips or hash computation errors causing nodes to fail, and how to detect it.  But spurious errors like that won't cause a majority of nodes to reject blocks.
3742015-10-29T13:38:22  <wumpus> majority plays no role in bitcoin - if *your* node forks from the block chain, that's a risk to you
3752015-10-29T13:40:05  <mcelrath> Exactly.  But having a majority of miners screw up is a bigger problem than little 'ol me.  ;-)
3762015-10-29T13:42:56  *** danielsocials has joined #bitcoin-core-dev
3772015-10-29T13:46:25  <wumpus> but yes the most dangerous bugs are consistent ones - note that an database-OS bug could be dangerous in that way, for example forking off all MacOSX nodes
3782015-10-29T13:57:48  *** jgarzik has joined #bitcoin-core-dev
3792015-10-29T14:12:35  <GitHub33> [bitcoin] dajohi opened pull request #6902: policy:  Add new constant MAX_STANDARD_MULTISIG_KEYS (master...multisig_keys) https://github.com/bitcoin/bitcoin/pull/6902
3802015-10-29T14:32:09  *** jgarzik has quit IRC
3812015-10-29T14:46:28  *** zooko has joined #bitcoin-core-dev
3822015-10-29T14:48:16  *** mcelrath has quit IRC
3832015-10-29T14:48:22  *** bsm1175321 is now known as mcelrath
3842015-10-29T14:48:23  <morcos> sipa: what does the 25-50% of the cache number that's used for nCoinDBCache represent?
3852015-10-29T14:49:12  *** bsm117532 has joined #bitcoin-core-dev
3862015-10-29T14:53:17  *** testing-tape has joined #bitcoin-core-dev
3872015-10-29T15:01:09  <mcelrath> Hmm I can't assign this to myself: https://github.com/bitcoin/bitcoin/issues/6903
3882015-10-29T15:02:47  *** zooko has quit IRC
3892015-10-29T15:03:14  <sipa> morcos: leveldb cache
3902015-10-29T15:03:46  <morcos> sipa: you mean its internal caching?
3912015-10-29T15:03:59  <sipa> yes
3922015-10-29T15:04:24  <morcos> oh i see, ha, i thought that local variable wasn't used anywhere, i didn't think to look in init
3932015-10-29T15:08:06  <GitHub195> [bitcoin] LordOfTheCoin opened pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
3942015-10-29T15:09:49  <mcelrath> Why is someone other than jgarzik making PR's from his repo?
3952015-10-29T15:12:00  <sipa> heh, i didn't even realize that by seeing github's email
3962015-10-29T15:22:19  *** ParadoxSpiral has joined #bitcoin-core-dev
3972015-10-29T15:22:20  <mcelrath> FYI, replacing auto_ptr -> unique_ptr (C++11) in the 5 places it appears does not introduce any new compiler errors or warnings due to the slightly different assignment semantics.  So making this replacement should be fine to switch to C++11.
3982015-10-29T15:27:45  *** randy-waterhouse has joined #bitcoin-core-dev
3992015-10-29T15:30:18  *** testing-tape has quit IRC
4002015-10-29T15:30:36  *** testing-tape has joined #bitcoin-core-dev
4012015-10-29T15:34:05  *** testing-tape has quit IRC
4022015-10-29T15:40:58  *** mcelrath has quit IRC
4032015-10-29T15:46:53  *** danielsocials has quit IRC
4042015-10-29T15:48:09  *** bsm1175321 has joined #bitcoin-core-dev
4052015-10-29T15:48:23  *** bsm1175321 is now known as mcelrath
4062015-10-29T15:57:36  *** paveljanik has joined #bitcoin-core-dev
4072015-10-29T15:57:36  *** paveljanik has joined #bitcoin-core-dev
4082015-10-29T16:10:01  <GitHub101> [bitcoin] LordOfTheCoin closed pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
4092015-10-29T16:10:02  <GitHub8> [bitcoin] LordOfTheCoin reopened pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
4102015-10-29T16:10:11  <GitHub5> [bitcoin] LordOfTheCoin closed pull request #6904: LevelDB Fixes and Enhancements (master...2015_sqlite) https://github.com/bitcoin/bitcoin/pull/6904
4112015-10-29T16:20:18  *** testing-tape has joined #bitcoin-core-dev
4122015-10-29T16:22:35  *** MarcoFalke has joined #bitcoin-core-dev
4132015-10-29T16:25:32  *** MarcoFalke has quit IRC
4142015-10-29T16:26:09  *** MarcoFalke has joined #bitcoin-core-dev
4152015-10-29T16:40:08  *** ParadoxSpiral has quit IRC
4162015-10-29T16:50:43  *** d_t has joined #bitcoin-core-dev
4172015-10-29T16:54:19  *** testing-tape has quit IRC
4182015-10-29T16:54:32  *** randy-waterhouse has quit IRC
4192015-10-29T17:14:11  <morcos> sipa: ok this might be a bit obscure, so i'll just look into if you have no idea off the top off your head.  but if I have a bunch of entries cached in a pcoinsTip and then I call TestBlockValidity on a block that accesses only those entries
4202015-10-29T17:15:06  <morcos> TBV will build a CCoinsViewCache on top of pcoinsTip, which cache will be passed to ConnectBlock which will build yet another on top.  modify the top most cache, and flush to the intermediate cache, then return to TBV which will just dump the intermediate cache on the ground
4212015-10-29T17:15:36  <morcos> any reason that would be FASTER if some of the entries in the pcoinsTip cache had FRESH or DIRTY flags as opposed to if they all had no flags.
4222015-10-29T17:24:48  <sipa> so pcoinsTip > TBV-Cache > ConnectBlock-Cache
4232015-10-29T17:25:01  <sipa> and it's in pcoinsTip that pre-existing flags would matter?
4242015-10-29T17:28:22  *** BashCo has quit IRC
4252015-10-29T18:02:19  *** testing-tape has joined #bitcoin-core-dev
4262015-10-29T18:04:54  <MarcoFalke> cfields, would you mind if I rebase trivial-next?
4272015-10-29T18:06:40  <cfields> MarcoFalke: sorry i missed your pm the other day. you could, but it's kinda a pain. i'd prefer to take care of it this week. I think the separate repo turned out to not make things any easier.
4282015-10-29T18:08:27  <MarcoFalke> Ok, then. I will leave it to you to take care of it.
4292015-10-29T18:19:21  *** testing-tape has quit IRC
4302015-10-29T18:19:34  *** testing-tape has joined #bitcoin-core-dev
4312015-10-29T18:28:09  *** zander has left #bitcoin-core-dev
4322015-10-29T18:28:35  *** rubensayshi has quit IRC
4332015-10-29T18:28:46  <GitHub129> [bitcoin] MarcoFalke opened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
4342015-10-29T18:29:29  <GitHub81> [bitcoin] gmaxwell opened pull request #6906: Reject invalid pubkeys when reading ckey items from the wallet. (master...ckey_pubkey_check) https://github.com/bitcoin/bitcoin/pull/6906
4352015-10-29T18:31:39  *** BashCo has joined #bitcoin-core-dev
4362015-10-29T18:33:59  *** BashCo_ has joined #bitcoin-core-dev
4372015-10-29T18:35:57  *** BashCo has quit IRC
4382015-10-29T18:42:22  <morcos> sipa: yeah thats what i meant, but maybe thats not the issue.  i'll dig into it.  but i really like this idea of keeping the hot items in the cache.  then you can flush it much more regularly and don't have to worry about it growing too big.
4392015-10-29T18:53:03  <GitHub171> [bitcoin] MarcoFalke closed pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
4402015-10-29T18:53:27  *** evoskuil has quit IRC
4412015-10-29T18:58:33  *** jgarzik has joined #bitcoin-core-dev
4422015-10-29T19:02:17  *** evoskuil has joined #bitcoin-core-dev
4432015-10-29T19:03:30  <morcos> sipa: oh i lied about that anywya,  there is no extra cache in ConnectBlock.  it just uses the TBV cache, or in the normal case the cache on pcoinsTip is added in ConnectTip before ConnectBlock
4442015-10-29T19:04:06  *** zooko has joined #bitcoin-core-dev
4452015-10-29T19:04:35  *** paveljanik has quit IRC
4462015-10-29T19:04:53  *** paveljanik has joined #bitcoin-core-dev
4472015-10-29T19:44:36  *** belcher has joined #bitcoin-core-dev
4482015-10-29T19:44:41  *** d_t has quit IRC
4492015-10-29T19:53:44  *** testing-tape has quit IRC
4502015-10-29T19:53:59  *** testing-tape has joined #bitcoin-core-dev
4512015-10-29T19:56:30  *** zooko has quit IRC
4522015-10-29T20:00:55  <MarcoFalke> Any thoughts on the clang-format thing?
4532015-10-29T20:01:04  <mcelrath> FYI: https://github.com/andrewseidl/githook-clang-format "Warning: Do not use this on an existing codebase that isn't already in your desired style. Doing so will lead to a string a dirty commits where your code changes are intermixed with clang-format's formatting changes. Furthermore, every developer will need to install this hook. If they don't, you will again end up with commits with a mixture of code and formatting changes."
4542015-10-29T20:01:11  *** testing-tape has quit IRC
4552015-10-29T20:01:12  <jgarzik> already covered in #bitcoin-dev meeting
4562015-10-29T20:01:28  *** testing-tape has joined #bitcoin-core-dev
4572015-10-29T20:02:51  <MarcoFalke> Do those channels have different scopes? I remember bitcoin-dev is deprecated?
4582015-10-29T20:11:46  *** jgarzik has quit IRC
4592015-10-29T20:19:27  <wumpus> this channel has a very narrow scope: code changes to the bitcoin core project
4602015-10-29T20:20:08  <sipa> clang format discussion would be very ontopic here IMHO
4612015-10-29T20:20:24  <sipa> but it was somehow part of the wider bitcoin irc meeting, which took place in #bitcoin-dev an hour ago
4622015-10-29T20:28:43  <davec> Is it intentional that the "minRelayTxFee" is not actually a minimum?  I suspect the answer is yes and the variable simply wasn't renamed.
4632015-10-29T20:29:53  <MarcoFalke> It's a minimum per node basis to get into that nodes mempool.
4642015-10-29T20:30:23  <davec> Well, the code is doing https://github.com/bitcoin/bitcoin/blob/master/src/amount.cpp#L22-L27
4652015-10-29T20:31:14  <davec> so if you have a tx of say 250 bytes, the will result in 250 * 1000 (the default "minRelayTxFee") / 1000 = 250 which is clearly < 1000
4662015-10-29T20:31:40  <MarcoFalke> yes, it's per kB
4672015-10-29T20:33:50  <wumpus> right it's the minimum *per KB*, all fees in bitcoin core are per kB
4682015-10-29T20:34:26  <wumpus> all fee settings at least
4692015-10-29T20:34:47  <MarcoFalke> wumpus, not paytxfee ;)
4702015-10-29T20:34:53  <MarcoFalke> not yet at least
4712015-10-29T20:36:32  <davec> alright thanks for confirming.  The naming and description made it seem like it was an absolute minumum, so I wanted to confirm.
4722015-10-29T20:36:45  <davec> because that's obviously not what the code is doing
4732015-10-29T20:37:01  <wumpus> MarcoFalke: hmm
4742015-10-29T20:47:54  *** zooko has joined #bitcoin-core-dev
4752015-10-29T20:54:19  *** zooko has quit IRC
4762015-10-29T20:58:20  *** treehug88 has quit IRC
4772015-10-29T20:58:40  *** zooko has joined #bitcoin-core-dev
4782015-10-29T20:59:30  <MarcoFalke> Does src/qt require a different .clang-format style file?
4792015-10-29T21:09:20  *** CodeShark has joined #bitcoin-core-dev
4802015-10-29T21:11:15  <GitHub71> [bitcoin] jtimon opened pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
4812015-10-29T21:23:22  *** zooko has quit IRC
4822015-10-29T21:25:56  <GitHub107> [bitcoin] jtimon opened pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
4832015-10-29T21:30:50  <sipa> heh, a rebase with master jumps to 300-600% CPU usage immediately
4842015-10-29T21:30:53  <sipa> *reindex
4852015-10-29T21:31:07  <gmaxwell> thats because reindex checks all the signatures.
4862015-10-29T21:31:16  <sipa> not historical ones?
4872015-10-29T21:31:25  <gmaxwell> yes, historical ones.
4882015-10-29T21:32:49  <sipa> oh, because we don't have the header yet for the chainpoint it is an ancestor of
4892015-10-29T21:36:05  *** daniel___ has quit IRC
4902015-10-29T21:36:27  *** daniel___ has joined #bitcoin-core-dev
4912015-10-29T23:25:34  <GitHub7> [bitcoin] MarcoFalke reopened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
4922015-10-29T23:27:32  <phantomcircuit> sipa, :)
4932015-10-29T23:27:46  *** BashCo_ has quit IRC
4942015-10-29T23:28:18  *** BashCo has joined #bitcoin-core-dev
4952015-10-29T23:38:27  *** MarcoFalke has quit IRC
4962015-10-29T23:53:47  <gmaxwell> Can someone build me windows binaries for https://github.com/bitcoin/bitcoin/pull/6906 ?   (oh I miss the testers that produced binaries as a side effect...)