1 2015-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?
  2 2015-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.
  3 2015-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.
  4 2015-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.
  5 2015-10-29T00:15:46  <aj> gmaxwell: makes sense... is there an existing PR for bip 62 or something i can read?
  6 2015-10-29T00:17:12  <aj> gmaxwell: (the consensus change side, more than the already-deployed isStandard changes i mean)
  7 2015-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.
  8 2015-10-29T00:27:21  <gmaxwell> To add them to consensus, the softfork negoiates turning them on for block validation.
  9 2015-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?
 10 2015-10-29T00:33:11  *** deepcore has quit IRC
 11 2015-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.
 12 2015-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.
 13 2015-10-29T00:39:04  <gmaxwell> (and because every time we've picked up BIP62 again we've found more cases that weren't covered. :( )
 14 2015-10-29T00:39:13  <gmaxwell> (again, related to less common usage)
 15 2015-10-29T00:40:57  <aj> gmaxwell: oh, hmm. that sounds more complicated than i was hoping :)
 16 2015-10-29T00:41:21  *** dcousens has joined #bitcoin-core-dev
 17 2015-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.
 18 2015-10-29T00:42:35  <gmaxwell> So personally thats the route I'd like to go down.
 19 2015-10-29T00:42:39  <aj> gmaxwell: i was assuming that was a lot further off than bip62 though?
 20 2015-10-29T00:42:55  <sipa> bip62 can be simplified a lot now, if we want just that
 21 2015-10-29T00:43:00  *** zooko has joined #bitcoin-core-dev
 22 2015-10-29T00:43:07  <sipa> all of bip62's rules are already nonstandard in 0.10.3 and 0.11.1
 23 2015-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)
 24 2015-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
 25 2015-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.
 26 2015-10-29T00:44:18  <gmaxwell> (CLTV and CSV)
 27 2015-10-29T00:46:26  *** dcousens has quit IRC
 28 2015-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?
 29 2015-10-29T00:51:12  <sipa> what does the block size have to do with it...?
 30 2015-10-29T00:51:32  <sipa> the complication is mostly that it needs a change in the p2p relay protocol for blocks and transactions
 31 2015-10-29T00:52:10  *** jgarzik has joined #bitcoin-core-dev
 32 2015-10-29T00:53:10  <aj> sipa: i thought i just read that segregated witness increased tx size by a bunch
 33 2015-10-29T00:53:31  <sipa> i thibk you're confusing with confidential transactions
 34 2015-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
 35 2015-10-29T00:53:52  <aj> sipa: could be
 36 2015-10-29T00:54:01  <sipa> seggregated witness just moves scriptSig out of transactions
 37 2015-10-29T00:54:21  <sipa> in alpha, the seggregation is scriptSig AND the range proofs
 38 2015-10-29T00:54:37  <aj> sipa: aha, that makes more sense
 39 2015-10-29T00:57:03  *** PaulCapestany has quit IRC
 40 2015-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
 41 2015-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
 42 2015-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
 43 2015-10-29T00:58:54  *** PaulCapestany has joined #bitcoin-core-dev
 44 2015-10-29T01:00:14  *** dcousens has joined #bitcoin-core-dev
 45 2015-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.
 46 2015-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.
 47 2015-10-29T01:01:33  <gmaxwell> aj: so its the opposite, and one of the reasons that that approach is so much more attractive.
 48 2015-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)
 49 2015-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
 50 2015-10-29T01:11:56  <gmaxwell> sipa: yes sir. And require the scrippubkey in the original datastructure to be empty for OP_SEGWITNESS scripts.
 51 2015-10-29T01:12:33  <gmaxwell> er original scriptsig.
 52 2015-10-29T01:12:37  *** d_t has quit IRC
 53 2015-10-29T01:12:41  <sipa> as i said :)
 54 2015-10-29T01:13:44  <gmaxwell> lol "" didn't take up enough space on the screen.
 55 2015-10-29T01:34:49  *** zooko has quit IRC
 56 2015-10-29T01:38:21  *** zooko has joined #bitcoin-core-dev
 57 2015-10-29T01:42:00  *** daniel____ has joined #bitcoin-core-dev
 58 2015-10-29T01:44:21  *** Ylbam has quit IRC
 59 2015-10-29T01:49:04  *** Arnavion has quit IRC
 60 2015-10-29T01:55:22  *** bsm117532 has joined #bitcoin-core-dev
 61 2015-10-29T01:55:32  <bsm117532> Why is leveldb in the core in the first place?
 62 2015-10-29T01:57:07  <sipa> because we want to have control over its changes
 63 2015-10-29T01:57:36  <bsm117532> By not changing it...
 64 2015-10-29T01:57:37  <sipa> and we have local modifications to it (win env, disable compression, and we've had other ones before)
 65 2015-10-29T01:57:47  <bsm117532> Ref https://github.com/bitcoin/bitcoin/pull/6899
 66 2015-10-29T01:57:54  <sipa> if a bug were to be found in leveldb, fixing it may cause a consensus failure
 67 2015-10-29T01:58:10  <sipa> and bugs like that have happened
 68 2015-10-29T01:58:20  <sipa> (before we were using leveldb, to be clear)
 69 2015-10-29T02:01:54  <gmaxwell> bsm117532: leveldb has (prior to our use of it) fixed 'bugs' that would have broken network consensus.
 70 2015-10-29T02:02:06  <gmaxwell> oh jinx, sorry.
 71 2015-10-29T02:02:31  <bsm117532> That's yucky on so many levels.
 72 2015-10-29T02:02:39  <sipa> how do you mean?
 73 2015-10-29T02:02:45  <bsm117532> FWIW I'd have put it in a separate repo under bitcoin, rather than import the code directly.
 74 2015-10-29T02:03:04  <sipa> bsm117532: https://github.com/bitcoin/leveldb
 75 2015-10-29T02:03:09  <bsm117532> Yeah, like that ;-)
 76 2015-10-29T02:03:15  <sipa> not like that; that
 77 2015-10-29T02:03:24  <gmaxwell> It is.
 78 2015-10-29T02:03:28  <bsm117532> The github repo should have a reference to it, rather than have the code imported.
 79 2015-10-29T02:03:44  <sipa> that is how git subtree works
 80 2015-10-29T02:03:57  <sipa> subtrees are ugly
 81 2015-10-29T02:04:00  <bsm117532> checking...
 82 2015-10-29T02:04:16  <sipa> but the only alternative is submodules, which are even more ugly
 83 2015-10-29T02:04:37  <bsm117532> Yeah that's what I mean, a submodule.
 84 2015-10-29T02:05:14  *** belcher has quit IRC
 85 2015-10-29T02:05:14  <sipa> well we're using subtrees
 86 2015-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 :)
 87 2015-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?
 88 2015-10-29T02:06:32  <sipa> correct, though a script is included to verify their correspondence
 89 2015-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
 90 2015-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
 91 2015-10-29T02:08:53  <bsm117532> That makes sense.  It's the other direction that is generating a problem here.  (modifying src/leveldb...)
 92 2015-10-29T02:09:11  <sipa> we don't ever accept changes directly to that directory
 93 2015-10-29T02:11:53  <bsm117532> Well we're going to replace leveldb with sqlite, right?!?!  ;-)
 94 2015-10-29T02:12:08  <sipa> maybe.
 95 2015-10-29T02:12:21  <CodeShark> is sqlite performant enough?
 96 2015-10-29T02:12:29  <bsm117532> Also replace Berkeley db with /dev/null...
 97 2015-10-29T02:12:46  <sipa> bsm117532: already possible, use --disable-wallet at compile time :)
 98 2015-10-29T02:12:54  <sipa> CodeShark: doubtful
 99 2015-10-29T02:13:11  <bsm117532> sipa: I'm well aware, always do.
100 2015-10-29T02:14:27  <CodeShark> we're pretty set on ditching leveldb, though, right?
101 2015-10-29T02:14:30  <bsm117532> CodeShark: don't know.  I re-ran some benchmarks from an old article: https://gist.github.com/mcelrath/6952eab246a7c705a0fb
102 2015-10-29T02:14:58  <sipa> CodeShark: only if a suitable replacement is found
103 2015-10-29T02:15:21  <bsm117532> I think we need a more targeted leveldb vs. sqlite (or something else) comparison.
104 2015-10-29T02:15:40  <sipa> bsm117532: jeff has a branch with bitcoin core running on sqlite3
105 2015-10-29T02:15:50  <sipa> but there are problems with background checkpointing etc
106 2015-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?
107 2015-10-29T02:16:12  <bsm117532> Well he did that quickly...
108 2015-10-29T02:16:23  <sipa> CodeShark: it does guarantee consistency; it just seems to fail on windows pretty often
109 2015-10-29T02:16:41  <CodeShark> doesn't it rely on the OS queueing up writes in the correct order or something?
110 2015-10-29T02:16:47  <sipa> no
111 2015-10-29T02:16:57  <sipa> or at least, it doesn't intend to
112 2015-10-29T02:17:19  <sipa> it relies on the OS behaviour properly when asked to do a synchronous write/flush, though
113 2015-10-29T02:18:08  <bsm117532> Are we worried about db corruption on power failure?  Or something else generating inconsistencies?
114 2015-10-29T02:18:39  <sipa> yes, that's what seems to happen
115 2015-10-29T02:19:12  <CodeShark> I haven't looked at the actual study, but https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability
116 2015-10-29T02:19:19  <bsm117532> That's a very hard problem that I don't think bitcoin can solve by choice of db.
117 2015-10-29T02:19:36  <bsm117532> This is why Oracle charges big bucks for dedicated hardware.
118 2015-10-29T02:19:51  <sipa> sqlite is well known for being very stable
119 2015-10-29T02:20:24  <CodeShark> sqlite has worked very well for me in certain applications that don't require extremely frequent insertions
120 2015-10-29T02:20:39  <dcousens> sipa: aye, the mere simplicity of sqlite is very attractive
121 2015-10-29T02:20:50  <sipa> CodeShark: we have extremely infrequent insertions
122 2015-10-29T02:21:03  <sipa> but they're very big batches
123 2015-10-29T02:21:32  <bsm117532> I've had good luck with sqlite too.  But these are anecdotes.
124 2015-10-29T02:22:18  <tripleslash> bsm117532, its not even power failure.  Windows gives very little time for apps to cleanly shutdown these days.
125 2015-10-29T02:22:39  *** zooko has quit IRC
126 2015-10-29T02:23:07  <sipa> lmdb seems to be a interesting candidate
127 2015-10-29T02:23:33  <sipa> but it's mmap-based, so not usable on 32-bit systems for such large databases as we have
128 2015-10-29T02:24:48  <dcousens> sipa: leveldb is just used for the txdb atm right?
129 2015-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.
130 2015-10-29T02:25:18  <sipa> dcousens: block index and chainstate
131 2015-10-29T02:25:29  <sipa> tripleslash: yet ARM is becoming more and more relevant
132 2015-10-29T02:26:29  <CodeShark> can't we create multiple databases all restricted to 4 gigs? :)
133 2015-10-29T02:26:38  <tripleslash> sipa: true that
134 2015-10-29T02:26:59  <sipa> CodeShark: we need atomic changes across databases then
135 2015-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.
136 2015-10-29T02:27:30  <dcousens> sipa: right, the CBlockTree is defined in txdb.h haha
137 2015-10-29T02:29:00  *** zooko has joined #bitcoin-core-dev
138 2015-10-29T02:29:13  <CodeShark> we can always support mmap on 64-bit systems and fall back on leveldb for 32-bit systems
139 2015-10-29T02:29:35  <CodeShark> although dunno what that might entail regarding consensus
140 2015-10-29T02:30:19  <CodeShark> it only takes one "undocumented feature" to screw everything up
141 2015-10-29T02:30:40  <sipa> having multiple databases is technically not hard; the database interface is pretty neatly abstracted
142 2015-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 :)
143 2015-10-29T02:31:54  <dcousens> sipa: production on 32-bit?
144 2015-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 )
145 2015-10-29T02:32:29  <sipa> bsm117532: github won't squash for you
146 2015-10-29T02:32:36  <sipa> reviewers may ask to squash things
147 2015-10-29T02:32:40  * bsm117532 has spent too long being the only committer to his repo.
148 2015-10-29T02:32:45  <bsm117532> Ok so I did the right thing.
149 2015-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)
150 2015-10-29T02:33:24  <dcousens> sipa: is the squash op not deterministic?
151 2015-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
152 2015-10-29T02:33:56  <bsm117532> There is no squash op... rebase -i is very manual and not deterministic at all.
153 2015-10-29T02:34:03  <dcousens> I know the rebase is, and hence verifiable
154 2015-10-29T02:34:23  <sipa> dcousens: you're confusing commits with trees
155 2015-10-29T02:34:39  <CodeShark> rebase is only not deterministic when you either change commit order or rebase off a different branch
156 2015-10-29T02:34:48  <sipa> or if there were conflicts
157 2015-10-29T02:35:00  <sipa> or merges within the commits you're rebasing
158 2015-10-29T02:35:20  <sipa> rebase applies a merge resolution algorithm, and you can change that algorithm
159 2015-10-29T02:35:31  <CodeShark> commit followed by squash is effectively the same as commit --amend
160 2015-10-29T02:35:51  <sipa> which is also not deterministic :)
161 2015-10-29T02:35:59  <sipa> (the resulting tree is, but the commit itself isn't)
162 2015-10-29T02:36:11  <dcousens> sipa: interesting
163 2015-10-29T02:36:35  <sipa> the reason it isn't is because a commit has a timestamp
164 2015-10-29T02:36:51  <CodeShark> but that's a trivial source of nondeterminism ;)
165 2015-10-29T02:37:10  <sipa> you can avoid it by specifying the timestamp on the command-line, though
166 2015-10-29T02:37:18  <sipa> yeah
167 2015-10-29T02:37:27  <sipa> but rebases are generally not verifiable
168 2015-10-29T02:37:38  <sipa> and afaik nobody does that
169 2015-10-29T02:43:26  <bsm117532> LMDB does look really interesting...
170 2015-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.
171 2015-10-29T02:45:14  *** zooko has quit IRC
172 2015-10-29T02:45:15  <sipa> indeed
173 2015-10-29T02:45:37  <bsm117532> It looks like an in-memory btrfs ;-)
174 2015-10-29T02:46:06  <sipa> except it's not in-memory
175 2015-10-29T02:46:21  <bsm117532> Yeah but mmapped, so it looks like it's in-memory.
176 2015-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...
177 2015-10-29T02:53:55  *** arowser has left #bitcoin-core-dev
178 2015-10-29T03:02:17  *** zooko has joined #bitcoin-core-dev
179 2015-10-29T03:10:25  <jgarzik> COW is COW, somewhat like write-ahead logging.  :)
180 2015-10-29T03:10:50  <jgarzik> If you order your writes properly, it's write-once
181 2015-10-29T03:10:59  <sipa> ... i do wish we could just use LMDB
182 2015-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.
183 2015-10-29T03:12:13  <sipa> i'm sure it wouldn't be hard; but LMDB is a total no go on 32-bit systems
184 2015-10-29T03:12:28  <jgarzik> the best performance should be COW + Kyoto Cabinet scheme
185 2015-10-29T03:12:42  <jgarzik> (KC is worth a look too)
186 2015-10-29T03:13:28  <jgarzik> COW practically guarantees no corruption (assuming write order is proper)
187 2015-10-29T03:14:14  <sipa> but i would be interested in LMDB's performance...
188 2015-10-29T03:14:36  <jgarzik> no idea if LMDB performs better than KC.  Worth benching, definitely.
189 2015-10-29T03:15:21  <jgarzik> Google benching leveldb, sqlite, kyoto cabinet: http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
190 2015-10-29T03:15:59  <phantomcircuit> jgarzik, COW without any delete? :P
191 2015-10-29T03:16:31  <jgarzik> phantomcircuit, typical strategy is reclaim after X generations of the superblock
192 2015-10-29T03:16:42  <jgarzik> assuming no stored snapshots
193 2015-10-29T03:16:44  <sipa> http://symas.com/mdb/microbench/
194 2015-10-29T03:18:04  *** daniel____ has quit IRC
195 2015-10-29T03:18:30  *** daniel____ has joined #bitcoin-core-dev
196 2015-10-29T03:18:35  *** daniel____ has quit IRC
197 2015-10-29T03:18:44  <jgarzik> Useful link.  They should have benched the KC hash db and not btree.  ;p
198 2015-10-29T03:19:20  <sipa> not a fair comparison, as lmdb/leveldb only do ordered maps
199 2015-10-29T03:20:09  *** daniel____ has joined #bitcoin-core-dev
200 2015-10-29T03:20:20  <gmaxwell> has anyone managed to complete a sync with jeff's sqllite attempt?
201 2015-10-29T03:20:36  <gmaxwell> I think jcorgan said it was going on day 2 for him.
202 2015-10-29T03:20:38  <tripleslash> if you build a win64 binary for me, I'll give it a go.
203 2015-10-29T03:21:22  <jgarzik> bench'd BDB in b-tree mode too :(
204 2015-10-29T03:21:30  *** daniel____ has quit IRC
205 2015-10-29T03:21:45  <jgarzik> if we didn't need ordering, things could go really fast
206 2015-10-29T03:21:59  <sipa> we don't really need ordering
207 2015-10-29T03:22:19  <sipa> though it may end up being useful if we go from per-tx caching to per-txout caching
208 2015-10-29T03:22:50  <sipa> and for normative utxo hashes
209 2015-10-29T03:23:10  *** daniel____ has joined #bitcoin-core-dev
210 2015-10-29T03:24:55  <phantomcircuit> jgarzik, more importantly we can significantly over provision the initial db to avoid resizing constantly
211 2015-10-29T03:29:10  *** Arnavion has joined #bitcoin-core-dev
212 2015-10-29T03:34:29  <jgarzik> LMDB could use a windowed mmap approach and support 32-bit systems, >2GB databases
213 2015-10-29T03:34:49  <jgarzik> or we could just drop 32-bit support
214 2015-10-29T03:35:09  <jgarzik> "full node = big database = big iron = no rPi"
215 2015-10-29T03:41:13  <Luke-Jr> jgarzik: …
216 2015-10-29T03:41:19  <Luke-Jr> I use 32-bit.
217 2015-10-29T03:41:56  <tripleslash> Luke-Jr, you also use dialup.  At some point, people have to upgrade. ;-)
218 2015-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.
219 2015-10-29T03:42:05  <Luke-Jr> tripleslash: I do not use dialup.
220 2015-10-29T03:42:13  <tripleslash> my apologies.
221 2015-10-29T03:42:33  <jgarzik> for large databases the address space helps a -lot-.  x32 useful but not in this case.
222 2015-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.
223 2015-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
224 2015-10-29T03:43:59  <jgarzik> not true (but off-topic so I'll stop)
225 2015-10-29T04:01:56  *** zooko has quit IRC
226 2015-10-29T04:06:30  *** zxzzt has quit IRC
227 2015-10-29T04:07:08  *** sdaftuar has quit IRC
228 2015-10-29T04:07:10  *** zxzzt has joined #bitcoin-core-dev
229 2015-10-29T04:07:43  *** sdaftuar has joined #bitcoin-core-dev
230 2015-10-29T04:32:20  <sipa> note: LMDB's on-disk format is platform dependent
231 2015-10-29T04:32:31  <sipa> (byte order and word size)
232 2015-10-29T05:35:19  *** molly has quit IRC
233 2015-10-29T05:36:54  *** d_t has joined #bitcoin-core-dev
234 2015-10-29T05:38:08  <phantomcircuit> jgarzik, unfortunately lmdb really isn't an option because of the trade offs they made
235 2015-10-29T05:38:56  <sipa> phantomcircuit: any specifics, apart from intentionally no support for 32 bit systems?
236 2015-10-29T05:44:46  <dcousens> Luke-Jr: "CPUs were fast enough that 32-bit was the better option
237 2015-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.
238 2015-10-29T05:45:02  <dcousens> If its not relevant, could you PM what you mean by that, ooi
239 2015-10-29T05:45:13  <Luke-Jr> dcousens: #bitcoin maybe?
240 2015-10-29T05:45:26  <dcousens> Luke-Jr: sure
241 2015-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. :-/
242 2015-10-29T06:08:07  *** Guest72716 has quit IRC
243 2015-10-29T06:20:01  *** pigeons has joined #bitcoin-core-dev
244 2015-10-29T06:20:23  *** pigeons is now known as Guest75176
245 2015-10-29T06:27:23  *** deepcore has joined #bitcoin-core-dev
246 2015-10-29T06:45:10  *** d_t has quit IRC
247 2015-10-29T07:26:56  *** deepcore has quit IRC
248 2015-10-29T07:41:39  *** Ylbam has joined #bitcoin-core-dev
249 2015-10-29T07:51:35  <wumpus> -1 for dropping 32 bit support, I want to support 32-bit ARM
250 2015-10-29T07:52:05  <wumpus> leveldb works well enough I see no need for any kind of desperate measures
251 2015-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
252 2015-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
253 2015-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
254 2015-10-29T08:02:59  <gmaxwell> it's very easy to use another one, though most alternatives have performance so poor they're just unusable.
255 2015-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.
256 2015-10-29T08:03:36  <CodeShark> apparently corruption is not that infrequent on windows
257 2015-10-29T08:03:50  <wumpus> then fix it on windows! it's not magic or rocket science
258 2015-10-29T08:03:56  <wumpus> I'm tired of this complaining
259 2015-10-29T08:04:01  <CodeShark> ?
260 2015-10-29T08:04:04  <gmaxwell> CodeShark: sure, so go fix it!  it's likely the same issue that existed on OSX or similar.
261 2015-10-29T08:04:05  <wumpus> can we pool a bounty or something like that
262 2015-10-29T08:04:25  <CodeShark> you mean fix leveldb itself?
263 2015-10-29T08:04:27  <gmaxwell> (where fsync didn't work for writes via mmaps)
264 2015-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
265 2015-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.
266 2015-10-29T08:04:56  <wumpus> yes
267 2015-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.
268 2015-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
269 2015-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.
270 2015-10-29T08:08:06  <Luke-Jr> (tomorrow we find out CodeShark stopped running Windows :p)
271 2015-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.
272 2015-10-29T08:09:16  <CodeShark> my windows development at present consists almost 100% of crossbuilds from linux
273 2015-10-29T08:10:16  <CodeShark> windows is just the way I access VMs and servers ;)
274 2015-10-29T08:10:31  <CodeShark> from one machine
275 2015-10-29T08:10:42  <CodeShark> none of my other machines run windows
276 2015-10-29T08:11:58  <CodeShark> http://research.cs.wisc.edu/adsl/Publications/alc-hotdep13.pdf
277 2015-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
278 2015-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
279 2015-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)
280 2015-10-29T09:03:35  *** [1]evoskuil has joined #bitcoin-core-dev
281 2015-10-29T09:04:31  *** evoskuil has quit IRC
282 2015-10-29T09:04:31  *** [1]evoskuil is now known as evoskuil
283 2015-10-29T09:23:23  *** zander has joined #bitcoin-core-dev
284 2015-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?
285 2015-10-29T09:24:33  <zander> Is the txid used for that removal?
286 2015-10-29T09:24:43  <zander> Or is it smarter that that.
287 2015-10-29T09:24:48  <zander> ?
288 2015-10-29T09:25:06  <phantomcircuit> zander, any transactions which conflicts with the new block is removed
289 2015-10-29T09:25:29  <zander> ah, ok. Thanks!
290 2015-10-29T09:28:11  *** rubensayshi has joined #bitcoin-core-dev
291 2015-10-29T09:29:50  *** davec has quit IRC
292 2015-10-29T09:30:27  *** davec has joined #bitcoin-core-dev
293 2015-10-29T09:54:02  *** BashCo has joined #bitcoin-core-dev
294 2015-10-29T09:56:06  *** max777555 has joined #bitcoin-core-dev
295 2015-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 !!!
296 2015-10-29T09:58:18  *** max777555 has quit IRC
297 2015-10-29T10:02:00  <phantomcircuit> wumpus, sipa ^
298 2015-10-29T10:07:28  *** ChanServ sets mode: +o wumpus
299 2015-10-29T10:07:40  *** wumpus sets mode: +b *!*@gateway/web/freenode/ip.
300 2015-10-29T10:07:43  *** ChanServ sets mode: -o wumpus
301 2015-10-29T11:11:58  *** PRab_ has joined #bitcoin-core-dev
302 2015-10-29T11:13:39  *** PRab has quit IRC
303 2015-10-29T11:13:43  *** PRab_ is now known as PRab
304 2015-10-29T11:18:01  *** jgarzik has quit IRC
305 2015-10-29T11:41:43  *** danielsocials has joined #bitcoin-core-dev
306 2015-10-29T11:42:58  *** fanquake has joined #bitcoin-core-dev
307 2015-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
308 2015-10-29T11:51:33  *** CodeShark has quit IRC
309 2015-10-29T12:05:53  *** danielsocials has quit IRC
310 2015-10-29T12:07:44  *** danielsocials has joined #bitcoin-core-dev
311 2015-10-29T12:11:06  *** jgarzik has joined #bitcoin-core-dev
312 2015-10-29T12:11:06  *** jgarzik has quit IRC
313 2015-10-29T12:11:06  *** jgarzik has joined #bitcoin-core-dev
314 2015-10-29T12:13:16  <GitHub111> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8daffe227bc6...26752767df45
315 2015-10-29T12:13:17  <GitHub111> bitcoin/master 3e187f2 Suhas Daftuar: Fix BIP65 p2p test...
316 2015-10-29T12:13:17  <GitHub111> bitcoin/master 2675276 Wladimir J. van der Laan: Merge pull request #6894...
317 2015-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
318 2015-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?
319 2015-10-29T12:14:33  <bsm117532> Questions about performance are a lot easier to be quantitative about...
320 2015-10-29T12:15:07  <wumpus> reproduction should be simple: run it on a windows pc, crashhe computer or disconnect the power
321 2015-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
322 2015-10-29T12:15:55  <bsm117532> That's pretty tedious.  :-/
323 2015-10-29T12:16:01  <bsm117532> I don't have a windows pc either...
324 2015-10-29T12:16:15  <wumpus> well from what I understand it *always* happens, so it's not that bad
325 2015-10-29T12:16:27  <bsm117532> I was thinking like kill -9 on a remote windows vm, or something like that.
326 2015-10-29T12:16:33  *** molly has joined #bitcoin-core-dev
327 2015-10-29T12:16:50  *** danielsocials has quit IRC
328 2015-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
329 2015-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.
330 2015-10-29T12:22:26  <bsm117532> We should be able to get a windows VM through Azure
331 2015-10-29T12:23:13  *** danielsocials has joined #bitcoin-core-dev
332 2015-10-29T12:31:04  <GitHub178> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/26752767df45...b2ce2c1f0fb1
333 2015-10-29T12:31:05  <GitHub178> bitcoin/master 95f4291 MarcoFalke: [trivial] Rewrite help text for feature enabled by default...
334 2015-10-29T12:31:06  <GitHub178> bitcoin/master bf68191 MarcoFalke: [trivial] rpcnet: fix typo
335 2015-10-29T12:31:06  <GitHub178> bitcoin/master 6782f58 MarcoFalke: [trivial] Latest config.guess...
336 2015-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
337 2015-10-29T12:40:12  <GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2ce2c1f0fb1...b28c229324d0
338 2015-10-29T12:40:12  <GitHub57> bitcoin/master a83f3c2 Bob McElrath: Add explicit shared_ptr constructor due to C++11 error
339 2015-10-29T12:40:13  <GitHub57> bitcoin/master b28c229 Wladimir J. van der Laan: Merge pull request #6899...
340 2015-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
341 2015-10-29T12:40:48  <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b28c229324d0...725539ea0376
342 2015-10-29T12:40:48  <GitHub189> bitcoin/master 0be387a Daniel Kraft: unittest: fix test for null tx input...
343 2015-10-29T12:40:49  <GitHub189> bitcoin/master 725539e Wladimir J. van der Laan: Merge pull request #6863...
344 2015-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
345 2015-10-29T12:42:36  *** daniel____ has quit IRC
346 2015-10-29T12:43:10  *** daniel___ has joined #bitcoin-core-dev
347 2015-10-29T12:52:26  *** danielsocials has quit IRC
348 2015-10-29T12:53:12  <dcousens> wumpus: for the windows box, would I need a complete chain?
349 2015-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
350 2015-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.
351 2015-10-29T12:58:22  *** bsm117532 is now known as mcelrath
352 2015-10-29T12:58:30  <dcousens> mcelrath: would I need to build latest?
353 2015-10-29T12:59:17  <dcousens> I'd assume so if the aim was to actually fix it haha
354 2015-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.
355 2015-10-29T13:00:58  <mcelrath> It's kind of an involved test :-/
356 2015-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
357 2015-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.  ;-)
358 2015-10-29T13:02:07  <mcelrath> Cool, thanks!
359 2015-10-29T13:02:40  *** fanquake has quit IRC
360 2015-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.
361 2015-10-29T13:08:24  <wumpus> dcousens: I don't think so, I think you just have to kill it while it's syncing
362 2015-10-29T13:09:10  <dcousens> wumpus: likely that the shutdown time itself will be dependent on how many writeops are waiting
363 2015-10-29T13:09:17  <dcousens> Perhaps worth doing on a HDD, not a SSD?
364 2015-10-29T13:09:18  <dcousens>  :P
365 2015-10-29T13:14:24  *** treehug88 has joined #bitcoin-core-dev
366 2015-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?)
367 2015-10-29T13:29:36  <wumpus> everything that is called by the consensus code is, in principle, consensus critical
368 2015-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.
369 2015-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
370 2015-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?
371 2015-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
372 2015-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)
373 2015-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.
374 2015-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
375 2015-10-29T13:40:05  <mcelrath> Exactly.  But having a majority of miners screw up is a bigger problem than little 'ol me.  ;-)
376 2015-10-29T13:42:56  *** danielsocials has joined #bitcoin-core-dev
377 2015-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
378 2015-10-29T13:57:48  *** jgarzik has joined #bitcoin-core-dev
379 2015-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
380 2015-10-29T14:32:09  *** jgarzik has quit IRC
381 2015-10-29T14:46:28  *** zooko has joined #bitcoin-core-dev
382 2015-10-29T14:48:16  *** mcelrath has quit IRC
383 2015-10-29T14:48:22  *** bsm1175321 is now known as mcelrath
384 2015-10-29T14:48:23  <morcos> sipa: what does the 25-50% of the cache number that's used for nCoinDBCache represent?
385 2015-10-29T14:49:12  *** bsm117532 has joined #bitcoin-core-dev
386 2015-10-29T14:53:17  *** testing-tape has joined #bitcoin-core-dev
387 2015-10-29T15:01:09  <mcelrath> Hmm I can't assign this to myself: https://github.com/bitcoin/bitcoin/issues/6903
388 2015-10-29T15:02:47  *** zooko has quit IRC
389 2015-10-29T15:03:14  <sipa> morcos: leveldb cache
390 2015-10-29T15:03:46  <morcos> sipa: you mean its internal caching?
391 2015-10-29T15:03:59  <sipa> yes
392 2015-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
393 2015-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
394 2015-10-29T15:09:49  <mcelrath> Why is someone other than jgarzik making PR's from his repo?
395 2015-10-29T15:12:00  <sipa> heh, i didn't even realize that by seeing github's email
396 2015-10-29T15:22:19  *** ParadoxSpiral has joined #bitcoin-core-dev
397 2015-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.
398 2015-10-29T15:27:45  *** randy-waterhouse has joined #bitcoin-core-dev
399 2015-10-29T15:30:18  *** testing-tape has quit IRC
400 2015-10-29T15:30:36  *** testing-tape has joined #bitcoin-core-dev
401 2015-10-29T15:34:05  *** testing-tape has quit IRC
402 2015-10-29T15:40:58  *** mcelrath has quit IRC
403 2015-10-29T15:46:53  *** danielsocials has quit IRC
404 2015-10-29T15:48:09  *** bsm1175321 has joined #bitcoin-core-dev
405 2015-10-29T15:48:23  *** bsm1175321 is now known as mcelrath
406 2015-10-29T15:57:36  *** paveljanik has joined #bitcoin-core-dev
407 2015-10-29T15:57:36  *** paveljanik has joined #bitcoin-core-dev
408 2015-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
409 2015-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
410 2015-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
411 2015-10-29T16:20:18  *** testing-tape has joined #bitcoin-core-dev
412 2015-10-29T16:22:35  *** MarcoFalke has joined #bitcoin-core-dev
413 2015-10-29T16:25:32  *** MarcoFalke has quit IRC
414 2015-10-29T16:26:09  *** MarcoFalke has joined #bitcoin-core-dev
415 2015-10-29T16:40:08  *** ParadoxSpiral has quit IRC
416 2015-10-29T16:50:43  *** d_t has joined #bitcoin-core-dev
417 2015-10-29T16:54:19  *** testing-tape has quit IRC
418 2015-10-29T16:54:32  *** randy-waterhouse has quit IRC
419 2015-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
420 2015-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
421 2015-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.
422 2015-10-29T17:24:48  <sipa> so pcoinsTip > TBV-Cache > ConnectBlock-Cache
423 2015-10-29T17:25:01  <sipa> and it's in pcoinsTip that pre-existing flags would matter?
424 2015-10-29T17:28:22  *** BashCo has quit IRC
425 2015-10-29T18:02:19  *** testing-tape has joined #bitcoin-core-dev
426 2015-10-29T18:04:54  <MarcoFalke> cfields, would you mind if I rebase trivial-next?
427 2015-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.
428 2015-10-29T18:08:27  <MarcoFalke> Ok, then. I will leave it to you to take care of it.
429 2015-10-29T18:19:21  *** testing-tape has quit IRC
430 2015-10-29T18:19:34  *** testing-tape has joined #bitcoin-core-dev
431 2015-10-29T18:28:09  *** zander has left #bitcoin-core-dev
432 2015-10-29T18:28:35  *** rubensayshi has quit IRC
433 2015-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
434 2015-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
435 2015-10-29T18:31:39  *** BashCo has joined #bitcoin-core-dev
436 2015-10-29T18:33:59  *** BashCo_ has joined #bitcoin-core-dev
437 2015-10-29T18:35:57  *** BashCo has quit IRC
438 2015-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.
439 2015-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
440 2015-10-29T18:53:27  *** evoskuil has quit IRC
441 2015-10-29T18:58:33  *** jgarzik has joined #bitcoin-core-dev
442 2015-10-29T19:02:17  *** evoskuil has joined #bitcoin-core-dev
443 2015-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
444 2015-10-29T19:04:06  *** zooko has joined #bitcoin-core-dev
445 2015-10-29T19:04:35  *** paveljanik has quit IRC
446 2015-10-29T19:04:53  *** paveljanik has joined #bitcoin-core-dev
447 2015-10-29T19:44:36  *** belcher has joined #bitcoin-core-dev
448 2015-10-29T19:44:41  *** d_t has quit IRC
449 2015-10-29T19:53:44  *** testing-tape has quit IRC
450 2015-10-29T19:53:59  *** testing-tape has joined #bitcoin-core-dev
451 2015-10-29T19:56:30  *** zooko has quit IRC
452 2015-10-29T20:00:55  <MarcoFalke> Any thoughts on the clang-format thing?
453 2015-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."
454 2015-10-29T20:01:11  *** testing-tape has quit IRC
455 2015-10-29T20:01:12  <jgarzik> already covered in #bitcoin-dev meeting
456 2015-10-29T20:01:28  *** testing-tape has joined #bitcoin-core-dev
457 2015-10-29T20:02:51  <MarcoFalke> Do those channels have different scopes? I remember bitcoin-dev is deprecated?
458 2015-10-29T20:11:46  *** jgarzik has quit IRC
459 2015-10-29T20:19:27  <wumpus> this channel has a very narrow scope: code changes to the bitcoin core project
460 2015-10-29T20:20:08  <sipa> clang format discussion would be very ontopic here IMHO
461 2015-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
462 2015-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.
463 2015-10-29T20:29:53  <MarcoFalke> It's a minimum per node basis to get into that nodes mempool.
464 2015-10-29T20:30:23  <davec> Well, the code is doing https://github.com/bitcoin/bitcoin/blob/master/src/amount.cpp#L22-L27
465 2015-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
466 2015-10-29T20:31:40  <MarcoFalke> yes, it's per kB
467 2015-10-29T20:33:50  <wumpus> right it's the minimum *per KB*, all fees in bitcoin core are per kB
468 2015-10-29T20:34:26  <wumpus> all fee settings at least
469 2015-10-29T20:34:47  <MarcoFalke> wumpus, not paytxfee ;)
470 2015-10-29T20:34:53  <MarcoFalke> not yet at least
471 2015-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.
472 2015-10-29T20:36:45  <davec> because that's obviously not what the code is doing
473 2015-10-29T20:37:01  <wumpus> MarcoFalke: hmm
474 2015-10-29T20:47:54  *** zooko has joined #bitcoin-core-dev
475 2015-10-29T20:54:19  *** zooko has quit IRC
476 2015-10-29T20:58:20  *** treehug88 has quit IRC
477 2015-10-29T20:58:40  *** zooko has joined #bitcoin-core-dev
478 2015-10-29T20:59:30  <MarcoFalke> Does src/qt require a different .clang-format style file?
479 2015-10-29T21:09:20  *** CodeShark has joined #bitcoin-core-dev
480 2015-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
481 2015-10-29T21:23:22  *** zooko has quit IRC
482 2015-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
483 2015-10-29T21:30:50  <sipa> heh, a rebase with master jumps to 300-600% CPU usage immediately
484 2015-10-29T21:30:53  <sipa> *reindex
485 2015-10-29T21:31:07  <gmaxwell> thats because reindex checks all the signatures.
486 2015-10-29T21:31:16  <sipa> not historical ones?
487 2015-10-29T21:31:25  <gmaxwell> yes, historical ones.
488 2015-10-29T21:32:49  <sipa> oh, because we don't have the header yet for the chainpoint it is an ancestor of
489 2015-10-29T21:36:05  *** daniel___ has quit IRC
490 2015-10-29T21:36:27  *** daniel___ has joined #bitcoin-core-dev
491 2015-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
492 2015-10-29T23:27:32  <phantomcircuit> sipa, :)
493 2015-10-29T23:27:46  *** BashCo_ has quit IRC
494 2015-10-29T23:28:18  *** BashCo has joined #bitcoin-core-dev
495 2015-10-29T23:38:27  *** MarcoFalke has quit IRC
496 2015-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...)