--- Day changed Sun Dec 04 2016 00:08 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 00:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 00:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 00:25 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9273: Remove unused CDiskBlockPos* argument from ProcessNewBlock (master...2016-12-remove-unused-pnb-param) https://github.com/bitcoin/bitcoin/pull/9273 00:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 00:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 00:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ajtnjskbevfyaukl] has joined #bitcoin-core-dev 00:37 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev 00:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] 00:59 -!- gabridome [~gabridome@87.18.61.184] has quit [Quit: gabridome] 01:00 -!- gabridome [~gabridome@87.18.61.184] has joined #bitcoin-core-dev 01:00 -!- gabridome [~gabridome@87.18.61.184] has quit [Client Quit] 01:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 01:12 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [] 01:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 01:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 02:15 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Quit: ZNC] 02:16 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev 02:31 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 02:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 02:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 02:36 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 02:37 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 02:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 02:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 03:01 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] 04:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 04:41 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 04:41 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 04:41 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 05:12 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev 05:26 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 05:36 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 05:36 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:d90d:baaf:4009:8491] has joined #bitcoin-core-dev 05:41 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:d90d:baaf:4009:8491] has quit [Ping timeout: 258 seconds] 05:47 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 248 seconds] 05:48 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 05:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 05:55 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 06:14 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 06:17 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds] 06:25 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Remote host closed the connection] 06:26 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 06:26 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 06:26 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 06:30 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 06:31 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 06:31 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 06:41 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 06:42 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 06:45 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has quit [Ping timeout: 260 seconds] 06:46 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 06:48 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 06:54 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 265 seconds] 06:57 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 07:05 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 07:06 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 07:08 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 07:09 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:12 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:18 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 07:47 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 07:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:09 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 08:09 -!- Cheeseo [~x@2601:985:1:ca10:ec94:fa06:17b0:78cd] has joined #bitcoin-core-dev 08:09 -!- Cheeseo [~x@2601:985:1:ca10:ec94:fa06:17b0:78cd] has quit [Changing host] 08:09 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 08:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 08:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit] 08:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:39 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 08:48 -!- wvr [~wvr@189.red-83-33-12.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:49 -!- protomar [~protomar@91.214.169.69] has joined #bitcoin-core-dev 08:59 -!- wvr [~wvr@189.red-83-33-12.dynamicip.rima-tde.net] has quit [] 09:16 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 09:17 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 09:19 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds] 09:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 09:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:56 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:57 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 10:21 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds] 10:24 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 10:24 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9274: [qa] pruning: Use cached utxo set to run faster (master...Mf1612-qaPruningCacheUtxos) https://github.com/bitcoin/bitcoin/pull/9274 10:25 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 10:26 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds] 10:40 -!- RoyceX [~x@2601:985:1:ca10:48cb:9af7:b9bd:c2a1] has joined #bitcoin-core-dev 10:40 -!- RoyceX [~x@2601:985:1:ca10:48cb:9af7:b9bd:c2a1] has quit [Changing host] 10:40 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 10:52 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 10:54 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds] 10:54 -!- LeMiner2 is now known as LeMiner 11:02 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 11:05 -!- Guyver2__ is now known as Guyver2 11:07 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 11:11 -!- Guyver2__ is now known as Guyver2 11:11 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 250 seconds] 11:13 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 11:27 -!- JackH [~laptop@79-73-189-171.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 11:32 -!- wvr [~wvr@189.red-83-33-12.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 11:32 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 11:32 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 11:32 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 11:38 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 11:58 < bitcoin-git> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2efcfa5acfac...4d955fc5824b 11:58 < bitcoin-git> bitcoin/master 827d9a3 Wladimir J. van der Laan: qt: Replace NetworkToggleStatusBarControl with generic ClickableLabel... 11:58 < bitcoin-git> bitcoin/master 042f9fa Wladimir J. van der Laan: qt: Show progress overlay when clicking spinner icon... 11:58 < bitcoin-git> bitcoin/master 4d955fc Jonas Schnelli: Merge #9218: qt: Show progress overlay when clicking spinner icon... 11:58 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9218: qt: Show progress overlay when clicking spinner icon (master...2016_11_overlay_when_clicking_sync_icon) https://github.com/bitcoin/bitcoin/pull/9218 12:18 < BlueMatt> jtimon: re: libconsensus: have you thought more about it after the discussions in milan? I'm still not a huge fan of exposing a ton of functions and prefer a simple refactor that a) makes it so that everything ProcessNewBlock calls isnt aware of disk positioning/etc and b) move all that stuff into a class which owns mapBlockIndex, chainActive, etc 12:18 < BlueMatt> jtimon: see https://github.com/TheBlueMatt/bitcoin/commits/2016-12-cconsensus 12:20 < jtimon> I keep thinking the same thing more or less 12:21 < jtimon> if you don't want to expose verifyHeader or verifyTx...I know some people want verifyHeader for SPV wallets, but not so sure about verifyTx 12:21 -!- bobbytux__ [~bobbytux@ARouen-653-1-4-84.w82-126.abo.wanadoo.fr] has joined #bitcoin-core-dev 12:21 < jtimon> regarding process block, as discussed, I think we should expose verifyBlock instead 12:22 -!- bobbytux_ [~bobbytux@ARouen-653-1-105-100.w90-22.abo.wanadoo.fr] has quit [Ping timeout: 258 seconds] 12:22 < BlueMatt> jtimon: why, though? if you expose ProcessNewBlock{,Headers} someone can implement a full spv client and full client all in the same codepaths, without exposing low-level partial-verification functions 12:23 < BlueMatt> (or, excuse me, without requiring users do their own utxo-management shit, while still giving them access to query the utxo state) 12:23 < jtimon> how can an SPV node calle ProcessNewBlock? 12:23 < BlueMatt> ProcessNewBlockHeaders 12:23 < jtimon> why would they want to depend on levelDB ? 12:23 < BlueMatt> nono, that part should be abstracted out 12:24 < BlueMatt> as discussed 12:24 < BlueMatt> eg see the blockstores in bitcoinj: https://github.com/bitcoinj/bitcoinj/tree/master/core/src/main/java/org/bitcoinj/store 12:25 < jtimon> oh, right, you were ok with abstracting storage, just wanted libconsensus to manage reorgs and all the rest in an abstracted way 12:25 < BlueMatt> yea, best to handle /all/ the complexity imo 12:25 < jtimon> isn't ProcessNewBlockHeaders an intermediate function? 12:25 < BlueMatt> no? it takes headers and adds them and selects the best headers chain it has seen 12:27 < jtimon> then I'm not sure what you mean by "intermediate" in this context 12:27 < BlueMatt> ehh, I apologize, I forgot that your definition of verifyBlock also means checking all the txes connect, ie essentially TestBlockValidity 12:28 < BlueMatt> instead of existing CheckBlock-type functions 12:28 < jtimon> well, no really testblockvelidity since that call connectBlock too 12:28 < BlueMatt> hmm? 12:28 < jtimon> not really 12:28 < BlueMatt> huh 12:29 < jtimon> my proposed verifyBlock just tells you whether a block is valid or not, but it doesn't do anything with it 12:29 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev 12:29 < BlueMatt> indeed, like TestBlockValidity? 12:31 < jtimon> mhmm, connect block updates transactions, updates undo info and updates the view of the best block, no? 12:32 < BlueMatt> but TestBlockValidity throws away all that info afterwards 12:32 < jtimon> oh, I see 12:32 < BlueMatt> and you have to keep an updated-utxo-state as you connect the block to test validity 12:32 < jtimon> well, then yes, but without generating info than then throws away 12:33 < BlueMatt> you cand check a block without doing that 12:33 < jtimon> yeah, you need to update at least a view of the utxo 12:33 < jtimon> right, that was my idea for verifyBlock 12:39 < BlueMatt> jtimon: ok, so back to my original question...what do you think of not exposing that and actually having a utxo/disk-storage-abstraced full consensus layer 12:39 < BlueMatt> ? 12:40 < jtimon> well, where I have te strongest opinion is in abstracting from storage 12:41 < jtimon> and agree on that 12:41 < BlueMatt> ok...? 12:41 < BlueMatt> oh, well sure, I dont think anyone wants libconsensus to require a certain storage layer 12:41 < jtimon> what would be the API? precessnewblock and processnewheaders? 12:43 < BlueMatt> jtimon: essentially, yes, PNB, PNBH, some initialization api (see https://github.com/TheBlueMatt/bitcoin/blob/2016-12-cconsensus/src/validation.cpp#L80) and a utxo-state-accessor/loadblock-accessor api 12:43 < jtimon> well, I do think some people want to depend on a concrete storage , but since it's neither of us, let's leave that aside 12:44 < jtimon> what about caches? any API for those? 12:44 < BlueMatt> well once the bitcoin core codebase "eats its own dogfood", as it were, we can take the storage layer we have and expose that optionally 12:44 < jtimon> right 12:44 < BlueMatt> no, caches are up to the client application, ie the client application gives libbitcoinconsensus pcoinsTip 12:44 < BlueMatt> similarly, in the future, maybe we can expose CCoinsViewCache or whatever 12:44 < BlueMatt> but for v1, its uneccessary 12:45 < jtimon> mhmm, I mean for example the versionbits cache 12:45 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…] 12:45 < jtimon> is that hidden to the caller or exposed somehow? 12:46 < BlueMatt> since its currently not exposed, hidden and present 12:46 < BlueMatt> dont expose anything unless its required, and for v1, dont worry too much about performance or memory usage 12:47 < sipa> the reason for not exposing would exactly be performance and memory usage, i think 12:47 < sipa> it's pretty hard to design a stable api that can be used efficiently for those things 12:47 < sipa> so i'd say make all state (caches, indexes, ...) by default part of the abstracted state 12:48 < sipa> and perhaps later introduce a way for the caller to install callbacks to override it, and provide their own 12:48 < jtimon> well, the api may change if consensus rules change 12:52 < jtimon> BlueMatt: I highly doubt some implementors (say libbitcoin) will use processNewBlock, then again I also doubted they were going to use verifyBlock directly either, I was hoping maybe verifyHeader, verifyTx + GetConsensusFlags 12:53 < BlueMatt> sipa: yea, except for v1 it doesnt matter, really - just dont expose anything and later, if we remove caches to make the library lighter, expose hooks to replace the caches 12:53 < bitcoin-git> [bitcoin] morcos opened pull request #9276: Some minor testing cleanups (master...rpccleanup) https://github.com/bitcoin/bitcoin/pull/9276 12:53 < jtimon> leaving that aside, I would like libconsensus to be the specification of the consensus rules for a given block to be valid, it seems that with your approach it would be more than that 12:54 < jtimon> but bitcoin core is currently way more than that, so... 12:54 < BlueMatt> jtimon: I mean the way any sane full node is structured there is an abstracted utxo/blocks-on-disk storage and something which checks everything and itnerfaces with that state 12:55 < jtimon> I also hope you don't intend to put half of the server package in the consensus package 12:55 < BlueMatt> jtimon: I see no reason why libbitcoinconsensus shouldnt repalce everything in between because if the goal is to reduce the risk of consensus incompatibility, we should replace everything we can 12:55 < BlueMatt> jtimon: I dont care what it weighs, only what it does....cutting down the weight is for later versions 12:55 < BlueMatt> :p 12:56 * BlueMatt -> brunch 12:57 < jtimon> because some implementors (like libbitcoin) value more the ability to have their own concurrency model (ie without locks) than reducing risks of consensus incompatibility beyond verifyScript (which they also use only optionally) 12:58 * jtimon should have brinner soon too 13:00 < jtimon> I agree, that we can leave "cutting weight" for later (like we're leaving moving CFeeRate for later for very long), my point is that with your approach, even after you're done, it will be much bigger than "the specification for whether a block is valid or not" 13:01 < jtimon> it would be more like the specification of "how to follow and store the longest valid chain" 13:01 < jtimon> then someone will want prunning too... 13:02 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 13:04 < sipa> jtimon: yes, it's the specification for whether a blockchain is valid or not 13:04 < jtimon> sipa: processNewBlock does much more than that 13:04 < sipa> well, yes, due to necessity 13:04 < sipa> we can't track the validity of every single chain 13:04 < sipa> so we only have a utxo set at a tip 13:05 < jtimon> that's we, maybe other callers want to do things differently 13:07 < jtimon> then maybe someone else asks for "sharded prunning" or something else, and soon you end up again with a lot of things that don't have anything to do with consensus rules 13:07 < sipa> yes, so we can later provide ways to plug in your own state storage (utxo/caches/indexes/...) 13:08 < jtimon> sipa: oh, BlueMatt's approach already gives you an abstraction for the utxo and chain index storage 13:08 < sipa> oj 13:08 < sipa> ok 13:09 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 13:09 < jtimon> but my example is that if it supports prunning, that needs to be exposed somehow 13:10 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 13:10 < sipa> heh? 13:10 < sipa> how does block storage have anything to do with this 13:10 < jtimon> isn't prunning deleting blocks you are storing? 13:10 < sipa> yes, but blocks wouldn't be stored by libconsensus 13:11 < jtimon> they would with BlueMatt's approach 13:11 < sipa> hmm, that seems strange 13:11 < jtimon> if I undesrtood him correctly 13:11 < sipa> i would have an api where you plug in a way libconsensus to ask you for a block 13:12 < sipa> if yiu're abstracting utxo storage, i don't see why you wouldn't abstract nlock storage 13:12 < jtimon> that's why he needs something like https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/store/BlockStore.java#L39 13:12 < sipa> which is even less consensus critical 13:12 < sipa> but that's the user that provides the blockstore 13:12 < sipa> not the library 13:14 < jtimon> right, the library provides an API and callbacks the implementor for stored data in both cases, but in bluematt's case, it also updates the storage, it doesn't use it in a read only way 13:14 < jtimon> maybe prunning was a bad example, I agree you don't need to put it in libconsensus even in that case 13:15 < gmaxwell> I think abstracting things like all this storage maybe getting into the realm of imaginary users... is there really many users that want to make no change (not even instrumentation) to consensus but is very interested at implementing their own UTXO database? 13:16 < jtimon> in my case, it takes a block and says valid or validation error x and does nothing more than that 13:16 < sipa> jtimon: but you need to reimplement a lot of complicated logic in your application for it 13:16 < sipa> utxo caching is hard 13:16 < sipa> block index tracking with skiplists is not trivial 13:16 < jtimon> gmaxwell: I agree that part of the problem here is not having a clear idea of the users or their preferences 13:16 < gmaxwell> I thought the goal for libconsensus is that so that when someone wants to make their own custom wallet thing they wouldn't need to reimplment any of the consensus logic, just to create their own application logic. 13:17 < jtimon> gmaxwell: but it seems that your objection would apply to both my approach and matt's 13:17 < sipa> i really don't care about users at this point - we don't have any, and have no easy way to build somwthing others could use 13:17 < sipa> i care about separating consensus from nonconsensus logic 13:18 < gmaxwell> if so that would really mean all the chain management would really be inside the library. 13:18 < gmaxwell> sipa: okay so for the purpose of consensus safty of changes, the caches and utxo database are all consensus critical-- 13:18 < sipa> gmaxwell: fair enough, but so is the c++ standard library 13:18 < jtimon> gmaxwell: right, matt puts the chain management inside, but also provides an abstraction for storage 13:19 < sipa> i think having block storage outside the library is perfectly fine, as consensus logic really does not need blocks except for reorgs 13:19 < gmaxwell> jtimon: Providing an abstraction for IO though is different than something that expects the user to implement a complex database. 13:20 < sipa> even utxo storage i can be convinced of, i think 13:20 < sipa> but block chain tracking (cblockindex/mapblockindex/...) should really be inside 13:20 < sipa> it's highly dependent on how we manage chains 13:20 < jtimon> providing a wrapper that includes the same storage as bitcoin core, as an extended library should be easy 13:21 < gmaxwell> so long as the requirements are very clear and simple... where no bitcoin specific understanding is required... sure. though doing that without breaking efficiency might be hard. 13:21 < sipa> i don't want every cblockindex access to go through wrapper calls 13:22 < gmaxwell> e.g. there are ordering requirements for fixation of block data vs utxo data to disk. 13:22 < jtimon> yep, efficiency is the main concern with my approach I think 13:23 < jtimon> btw, as always comments on https://github.com/bitcoin/bitcoin/pull/8493 welcomed 13:25 < jtimon> this kind of thing (for the abstracted storage) is disruptive though https://github.com/bitcoin/bitcoin/pull/8493/commits/0a1ff996c5db5265742e3e90f3690a0b8d9cf045 13:26 < jtimon> and the way I implemented it there, is also inneficient for bitcoin core 13:36 < jtimon> anyway, there's 2 separated topics here 13:36 < jtimon> whether to abstract and expose storage 13:37 < jtimon> and whether or not to manage reorgs and other things beyond "check whether a given block is valid or not" 13:39 < jtimon> my answers are yes and no, matt's is yes and yes. If gmaxwell's is no and yes, and sipa's are yes and yes, we have all the options represented :p 13:43 < jtimon> s/sipa's are no and no/ 13:45 < sipa> the first thing we should probably do is separate CBlockIndex into block storage data (file, offset, undo, ...), and chain data (block index, work, validation) 13:46 < sipa> that would be required if we'd want to abstract block storage out from a library 13:46 < sipa> but i thibk it shoukd hapoen regardless 13:46 < jtimon> I don't need to do that in my approach 13:46 < sipa> the block storage data doesn't even need to be in memory permnantly 13:46 < sipa> i understand 13:47 < sipa> but my point is that we should do that, even if there never is a library at all 13:48 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 13:48 < jtimon> chain.o and coins.o are already separated, I'm not entirely sure I understand what you mean 13:50 < sipa> CBlockIndex stores things about where blocks are on disk 13:50 < jtimon> oh, I see 13:50 < sipa> (which has nothing to do with consensus) 13:50 < sipa> and things like validation flags and chainwork 13:51 < sipa> and the block header 13:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 13:51 < sipa> which do 13:51 -!- Guyver2__ is now known as Guyver2 13:53 < jtimon> regarding the validation flags, I replaced #7779 with https://github.com/bitcoin/bitcoin/pull/9271 (although got errors in unittests because we're already relying on the consensus flags being coupled for testing it seems) 13:53 < gribble> https://github.com/bitcoin/bitcoin/issues/7779 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 13:56 < jtimon> see https://github.com/bitcoin/bitcoin/pull/9271/commits/7a90173b839e682932426f7d6ac91d2df88e2cfb 14:02 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Ping timeout: 268 seconds] 14:04 < bitcoin-git> [bitcoin] s-matthew-english opened pull request #9277: clear typo "skipepd" changed to "skipped" (master...patch-12) https://github.com/bitcoin/bitcoin/pull/9277 14:11 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9277: clear typo "skipepd" changed to "skipped" (master...patch-12) https://github.com/bitcoin/bitcoin/pull/9277 14:19 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 14:20 -!- protomar [~protomar@91.214.169.69] has quit [Quit: Leaving] 14:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 14:38 -!- bitdev01 [~frojas@251.red-81-40-205.staticip.rima-tde.net] has joined #bitcoin-core-dev 14:45 -!- bitdev01 [~frojas@251.red-81-40-205.staticip.rima-tde.net] has quit [Quit: Konversation terminated!] 14:56 < sdaftuar> gmaxwell: regarding bumpfee... i'd been advising mrbandrews to try to simplify what the rpc command is doing as much as possible, with the hope of getting a helpful utility in place tht we could layer more advanced behavior on top of 14:57 < sdaftuar> gmaxwell: so in particular, i wasn't aware of a robust way to identify the change output, so i suggested for this rpc to have the user supply it 14:57 < sdaftuar> is there a robust way to identify the change output? 14:58 < sipa> yes, IsMine() and not in address book 15:03 < sdaftuar> sorry i'm so unfamiliar with this... i guess there's an IsChange() function, with a TODO saying that this might not work with multisig behavior in the future. is that not a concern now? 15:09 < gmaxwell> sdaftuar: We really should be storing the data in the wallet, but just using IsMine would be better than asking for it. 15:09 < gmaxwell> (I think specifying it is basically something that would only be useful to the same people who could use createrawtransaction) 15:10 < gmaxwell> Simplifying it is good, but we can't make it a hazard to users-- which is why I was saying it needed to somehow assure that the outputs will not get spent while unconfirmed. 15:11 < gmaxwell> Simiarly, just diminishing the change and never adding inputs will produce transactions which won't relay (dust). though I suppose instead of being able to add inputs it could just limit itself to places where that wouldn't be the case. 15:11 < sdaftuar> gmaxwell: i haven't looked at the PR lately but i thought it was going to do the right thing with dust. 15:11 < gmaxwell> Because of the need to restrict dependant transaction chains I thought a 'bump everything' might be simpler. 15:12 < gmaxwell> sdaftuar: it didn't look like it could add inputs to me but equally possible that I was confused. 15:13 < sdaftuar> gmaxwell: oh it won't currently add inputs, as i recall, but i think if it would reduce the change output to less than dust, then it would get dropped altogether 15:13 < sdaftuar> (that's what i recall some discussion of, anyway) 15:13 < sdaftuar> are you saying though that you don't think it should allow feebumping a tx that has descendants? 15:13 < sdaftuar> i thought that was part of the point of this RPC, to get that right. 15:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 15:18 < gmaxwell> imagine you have txn A, and B that spends A. Then you bump A creating a replaceme A' that replaces A/B. Now you make nother spend that spends the output of A' ... you really need to draft two versions of it one that spends B and one that spends A'... and switch to relaying the other depending on what confirms. 15:18 < gmaxwell> I thought that was too advanced, which is why I was suggesting prohibiting descendants. 15:18 < sdaftuar> ahh right 15:18 < sdaftuar> wow, i totally missed that 15:19 < gmaxwell> GAit has implemented bumping in the green address wallet and I think it deals with all this stuff. 15:20 < sdaftuar> PRs welcome? :) 15:20 < gmaxwell> even my suggestion of making unspendable for one confirm is a bit risky, since it couple be reorged out. :( 15:20 < sdaftuar> so i think bumpunconfirmed is a good idea, but i worry about old transactions that have long since been double spent 15:20 < gmaxwell> esp since there is non-trivial amounts of hashpower that won't take replacements. 15:20 < sdaftuar> or rather, distinguishing those from other unconfirmed transactions 15:21 < gmaxwell> well we track conflicted transactions. 15:21 < sdaftuar> but not perfectly 15:21 < sdaftuar> we can't track conflicted transactions where the conflict chain is broken with tx's not in our wallet 15:22 < gmaxwell> Point. Though it would be sufficient for this functionality to only work on transactions where the closure of unconfirmed parents are all in the wallet, I guess. 15:24 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…] 15:25 < gmaxwell> I wonder how often someone has multiple unconfirmeds pending and doesn't want to just bump them all. Usually it will save them total fees if they do so. 15:25 < gmaxwell> ignoring crazy corner cases like some being doublespent. 15:26 < sdaftuar> yeah i think it does seem like a useful feature 15:27 < gmaxwell> it just seemed simpler to me than getting all the corner cases right. 15:28 < sdaftuar> well i think that has a bunch of corner cases too. you probably want to make sure you conflict with anything that might possibly confirm, so you have to include even abandoned transactions right? 15:28 < sdaftuar> (maybe even 1-confirm tx's!) 15:28 < sdaftuar> er 1-conflicted 15:29 < gmaxwell> You need to conflict with anything whos outputs you include, so that you don't potentially double-pay. 15:30 < sdaftuar> i guess that raises a good UI point 15:30 < sdaftuar> probably the user would want to see all the outputs and transactions being bumped, and ack that? 15:30 < sdaftuar> in case of the really old wallet tx that the user forgot about problem 15:31 < sdaftuar> i dunno, i guess i just assume that heavy wallet users that have been running for a while must have lots of those, maybe that's not a good assumption 15:32 < sdaftuar> ? 15:32 < gmaxwell> I think it would work like this: take the set of unconfirmed transactions which are AllFromMe (whatever the test that excludes coinjoins is called). Then eliminate all transactions whos parents aren't either all AllFromMe or 6 confirmed. Then gather up all their outputs, eliminate all the IsMine outputs, and generate a new transaction which conflicts each transaction in the set, and pays suffi 15:33 < gmaxwell> ciently more fees. Then its change output (if any) should be marked so that it will not be treated as IsFromMe for spending purposes. (UI wise we should encourage somewhat overpaying due to this last point) 15:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:34 < gmaxwell> I don't think most users have a lot of long lost transactions. I hope not. :) since they'll pretty likely to lose coins if they ditch the wallet thinking the balance was zero. 15:34 < sdaftuar> that seems like it ought to work. 15:34 < sdaftuar> do we have a way right now to do the mark-change-as-unspendable thing? 15:34 < gmaxwell> We have something that doesn't do what we want here. 15:34 < gmaxwell> (lockunspent) 15:35 < gmaxwell> For this, I think we need to add a boolen to the wallet txn and have isfromme check that. 15:36 < gmaxwell> Later we could have more advanced bumping logic that does the make-multiple-transaction-versions. 15:37 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 15:37 < gmaxwell> sdaftuar: if you really think that there are many users with txn stuck never confirmed... then we really need to add a 'Pending Payments' -- sum of confirmed outputs which are spent by unconfirmed transactions -- in the UI/rpc. So that people don't discard wallets as empty when they're really not. 15:38 < sdaftuar> gmaxwell: actually, maybe i am missing something. with your proposed algorithm, what would happen if you bumpunconfirmed twice? 15:39 < gmaxwell> You would ignore the existing bump (it would fail the AllFrom me in step 1) and make a new bump of all the other unconfirmed transactions in your wallet. 15:40 < sdaftuar> i didn't follow why it would fail the AllFromMe step, but if you managed to construct a new tx that didn't conflict with the older bumped fee one, you're screwed right? 15:41 < gmaxwell> It would fail the all from me, because I propose the change output of the bumb be flagged specifically so that it does. ... so that under no condition wall the wallet spend it until it is 6 confirmed. Specfically to avoid having to deal with things spending it then having the originals confirm. 15:42 < sdaftuar> isn't IsAllFromMe purely a function of the tx inputs? 15:42 < gmaxwell> The new tx doesn't need to conflict with it, so long as it doesn't pay to any of its outputs, which it won't because it wasn't included in the set of available txn. 15:43 < sdaftuar> i think i am pretty confused right now, why don't i spend another day thinking about the wallet and then rejoin this conversation 15:43 < gmaxwell> It's a function of the input's outputs. Is every input an output of mine. 15:44 < gmaxwell> sdaftuar: this stuff makes my head hurt too. I really want to get some kind of bumping in ASAP, it's hard to come up with a minimal feature... 15:45 < sdaftuar> one last try before i call it a night -- let's say i have tx1, tx2, tx3 -- each one is IsAllFromMe. i bump and create tx4, which conflicts with each, and pays all their outputs, and the change output of tx4 is specially flagged or whatever to be unspendable until it confirms. 15:45 < sdaftuar> wont't tx4 still be IsAllFromMe? 15:46 < sdaftuar> (actually i have to run, back later) 15:47 < gmaxwell> Right, okay -- I should have said IsMine and IsAllFromMe -- the flagging should make it not IsMine. 15:47 < gmaxwell> sdaftuar: ttyl 15:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 15:50 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 15:58 < BlueMatt> gmaxwell: ok, I missed a bunch of scrollback, but hell yes...everyone wants the utxo db in their own format so that they can do other queries against it 15:58 < BlueMatt> jtimon: no, I absolutely think we should abstract out block storage 15:59 < BlueMatt> jtimon: hell, the branch I sent you did that for ConnectBlock/DisconnectBlock in the first commit 15:59 < jtimon> right, I said "yes and yes" for you 16:00 < jtimon> but let me check that commit 16:00 < BlueMatt> oh, what? you told sipa that the "it updates the storage" 16:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:02 < jtimon> I mean it updates what you store, through the api (ie the library handles reorgs and updates things) 16:02 < BlueMatt> well of course, you tell the library about a block and it connects what it can, possibly asking the library owner for blocks that it previously saw but (ofc) didnt store 16:03 < BlueMatt> I dont see how else you'd possibly do it 16:03 < BlueMatt> gmaxwell: see, eg, the bitcoinj stuff, where all the contributions to "full mode" since it was added have been to add it to database X, so that people can put it in their own db 16:03 < jtimon> see the backlog for when I say for people answer the 4 possible combinations to 2 yes/no questions 16:05 < jtimon> you and me agree on abstracting storage 16:05 < jtimon> I mean, if I understood everyone's position correctly 16:06 < gmaxwell> BlueMatt: without using a highly efficient format like ours, I'm dubious that the system can stay in sync without insane hardware. 16:06 < jtimon> the other question is only check that a block is valid or also handle reorgs, update tables etc 16:06 < BlueMatt> gmaxwell: thats not our problem, thats theirs 16:06 < BlueMatt> gmaxwell: hell, they can use leveldb if they want 16:07 < jtimon> ie verifyBlock vs processBlock 16:07 < BlueMatt> gmaxwell: and, if we prefer, its also easy to add eg a single flag like "use X MB of utxo cache, because I dont want to implement that myself" 16:07 < gmaxwell> BlueMatt: not just about leveldb or not, but the compressed ccoins representation is worthless for queries. 16:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 16:08 < BlueMatt> gmaxwell: the compressed ccoins thing doesnt matter all that much if you're talking about an actually-high-performance db on high-performance hardware....if folks need their shit in their own db and are willing to pay $$$$$ for it to run, more power to them 16:08 < gmaxwell> As far as 'their problem' goes, we shouldn't waste our resources (or code base clarity, or performance) supporting functionality that won't be useful to anyone (or to anyone beyond a couple centeralized API services). 16:08 < jtimon> we can add a wrapper with our own implementation of the interfaces, beyond that, right, it is their problem 16:08 < BlueMatt> gmaxwell: ok, then what is the point of libconsensus at all? 16:09 < sipa> BlueMatt: i don't care about libconsensus. i care about abstracting consensus logic out 16:09 < BlueMatt> and whats your answer to folks like btcd/the new javascript one, who do have dbs that are performant enough to stay in sync 16:09 < gmaxwell> The way it was pitched to me is so that people could make wallets and other similar applications without having to reimplement consensus logic. 16:09 < jtimon> right 16:09 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 16:09 < BlueMatt> gmaxwell: sure, but that doesnt mean we have to handle db logic ourselves 16:09 < sipa> well, the hardest part of that is already available: we expose script verification 16:10 < jtimon> how is that incompatible with allowing them to chose their database implementation? 16:10 < BlueMatt> sipa: I dont think thats the only hard part, really 16:10 < sipa> but i also don't think it's very hard to abstract utxo storage out... so if there is a use case, sure 16:10 < BlueMatt> sipa: indeed, abstracting out utxo/block storage is also abstracting consensus logic out of other crap 16:10 < sipa> maybe it is. 16:11 < sipa> something like changing to per-output rather than per-tx utxo model would be impossible with a stable utxo storage abstraction 16:11 < jtimon> I assume the use cases come from the fact that they want to reuse that database for some of their logic somehow 16:11 < sipa> s/impossible/inefficient or complicated/ 16:11 < gmaxwell> I'm not opposed to it being abstractable-- but I don't see how this is related to that goal-- it's the opposite of it, the blockchain storage and utxo set is consensus and may even be quite normative in its behavior (e.g. if we have a commited utxo set of some kind), and if it trashes performance or code clarity then it's not a good move. 16:12 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 16:12 < BlueMatt> sipa: oh? if you query per-utxo then per-tx can be hidden on the backend and could still be pretty performant....indeed, the other way around doesnt really work 16:12 < gmaxwell> and for an example of the kind of complexity it creates: if you think you can just query a utxo database it means we can't have writeback caching internally. 16:13 < BlueMatt> gmaxwell: sure, no one wants to do anything that ends up introducing performance regressions 16:13 < sipa> abstracting storage is more to avoid dependencies rather than it being reusable 16:13 < gmaxwell> I think callers that want a database probably don't want to replace the database used for consensus-- what they want is a node that maintains an external database for their application. 16:14 < gmaxwell> Which is probably not the same thing due to consistency requirements. 16:15 < jtimon> gmaxwell: it shouldn't trash performance or code clarity, I agree 16:15 < BlueMatt> gmaxwell: it might be worse performance, but syncing after every block after ibd (ie having a flag to sync) isnt all that hard, either.... 16:15 < BlueMatt> eg ProcessNewBlock(block); SyncToDB(); 16:16 < sipa> BlueMatt: but for a full node, you probably don't want to sync after every block 16:16 < BlueMatt> gmaxwell: and its easy to do that without introducing our own performance regressions....just dont call Sync after every block.... 16:16 < BlueMatt> sipa: depending on your application, maybe you do 16:16 < jtimon> sipa: once abstracted out, changing the interface in certain ways may be painful, correct 16:16 < BlueMatt> at least after IBD 16:16 < gmaxwell> Not writing out the utxo set constantly is critical for performance. Leveldb is slow. 16:16 < sipa> BlueMatt: but it'd be using our block validation code, which has known performance characteristics 16:17 < sipa> BlueMatt: and if you don't care about that, you wouldn't be using libconsensus at all 16:17 < BlueMatt> sipa: as long as we dont drop the cache when we flush (like we do now, which we already need to fix), I dont see a performance issue there? 16:17 < sipa> BlueMatt: fair enough 16:17 < sipa> BlueMatt: that's a good point - but the current code doesn't do that 16:17 < gmaxwell> I can't imagine an application which needs to muck around storing the utxo database in an application format which wouldn't be equally or better served by block processing callback that maintains an external database that isn't used for validation. 16:17 < BlueMatt> suresure, but these are all minor issues that are trivial to fix 16:17 < jtimon> avoiding dependencies is also a great gain, although I think we should have a version depending on levelDB and our own implementation too 16:18 < sipa> again, i'm not against abstracting things out 16:18 < gmaxwell> Widespread application visiblity into the actual utxo database would be pretty toxic for commited utxo or stxo improvements. 16:18 < BlueMatt> gmaxwell: duplicate databases? people who run shit on modern services where you literally have no local persistent storage? 16:18 < sipa> i very much feel that utxo storage is one of the things that is abstractable 16:18 < sipa> but that doesn't mean it's necessarily useful for sharing that information with other purposes 16:18 < sipa> it also doesn't mean it's not 16:19 < jtimon> yeah, I assume one use case could be having everything in memory 16:19 < gmaxwell> BlueMatt: basically any standard database approach would have horrible performance to the point that it would only be useable on very high end hardware. Having two copies of the utxo set would hardly be a consideration there, our copy is only about 2GB data. 16:20 < BlueMatt> gmaxwell: I seriously dont believe that...maybe it takes 10 seconds or 30 seconds to sync a block to the db, but so what? you just dont flush all the time during IBD and then wait it out 16:20 < BlueMatt> (and, yes, I get that in most dbs it actually will take 30 seconds, but it wont take much longer than that) 16:20 < BlueMatt> or a minute with segwit blocks 16:20 * BlueMatt -> out 16:20 < gmaxwell> BlueMatt: see also the electrum channel with people complaing about their servers falling multiple blocks behind. 16:20 < gmaxwell> and two minute updates. 16:21 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 16:22 < BlueMatt> gmaxwell: ok...? that doesnt mean its impossible to build a db that can store the utxo set with reasonable performance, even if not blazing fast performance? 16:22 < gmaxwell> I just feel that the purpose of these changes is no longer clear. Expecting the user to implement complex interfaces with bitcoin specific and consensus critical behavior is at odds with what I understood to be the stated goal. 16:22 * BlueMatt doesnt see the problem with it taking a minute for your db to sync the utxo set....if you're just a merchant and its slow, so what? 16:22 < jtimon> it is also possible to build something faster than our solution, isn't it? 16:23 < BlueMatt> gmaxwell: I highly disagree that selecting a sane DB (ie not using some external SQL thing) is "implementing complex interfaces" 16:23 < gmaxwell> And if maintaining a database for a block explorer is a goal-- then it can be done in a better way then also trying to use that database for consensus... just run it in parallel, the resource overhead will be moderate. 16:23 < BlueMatt> and I dont expect every exchange to do so, I'd expect folks like btcd/bitcoinj/javascript thinggy to do it 16:23 < BlueMatt> and people to use it 16:23 < BlueMatt> gmaxwell: go look at the bitcoinj users...people actually use its full validation shitshow so that they can do exactly this 16:23 < jtimon> gmaxwell: we don't need to expect the user to reimplement it, we should provide our own implementation to the interfaces 16:23 < BlueMatt> and its slow, but they dont care 16:23 < BlueMatt> (and the interface is trivial) 16:24 < gmaxwell> BlueMatt: Complex interfaces is that you need to actually pass the data as fields and not opaque blobs. And what happens when the set of data needed for consensus changes (as sequence locktiming did). 16:24 < BlueMatt> its like 4 functions and only a single non-trivial requirement for which there are unit tests (the utxo-replacement-thing) 16:24 < jtimon> again, you keep discussing the slow case, what if I'm faster than our implementation? 16:24 < gmaxwell> BlueMatt: that usage doesn't even need full node support at all, run your bitcoinj behind a full node, have it log blocks to a database. Hurray. 16:25 < BlueMatt> gmaxwell: yes, except people dont do that 16:25 < sipa> maybe we should write a simple daemon that maintains the utxo set in SQL 16:25 < BlueMatt> people prefer to run full validation shit in btcd or bitcoinj, despite knowingly putting themselves at risk 16:25 < sipa> (without validation) 16:25 < jtimon> or are we discarding that as a possibility? 16:25 < gmaxwell> sipa: that is what I was saying. 16:25 < gmaxwell> BlueMatt: they don't know they're putting themselves at risk. 16:26 < BlueMatt> gmaxwell: ok, well either way I dont see an alternative great solution here? most developers do want a library that handles all the background validation shit for them 16:26 < BlueMatt> and as long as such things exist, they will use them 16:26 < gmaxwell> jtimon: because there exists nothing faster currently, or else we'd be using it. 16:26 < BlueMatt> proxy-nodes be damned 16:26 < gmaxwell> BlueMatt: the alternative is to have support for maintaining a database synced with the blockchain-- that doesn't mean inserting things into the consensus logic. 16:27 < gmaxwell> It just means having a simple set of hooks that run post tip change and update the database. 16:27 < BlueMatt> gmaxwell: you missed my previous point about how lots of "modern" developers run shit on services with ~no persistent storage 16:27 < BlueMatt> anyway, I actually need to run, have an apt to keep 16:27 < sipa> run, BlueMatt, run 16:28 < jtimon> there's no storage solution optimized for having everything in memory that outperforms leveldb or offers some other advantage? 16:28 < sipa> apt-keep BlueMatt 16:28 < sipa> jtimon: -dbcache=8000 16:28 < gmaxwell> We already have that built in. 16:28 < sipa> jtimon: leveldb won't be used at all 16:29 < jtimon> sipa: right, I know, but I doubt there's nothing better than levle db with unbounded cache 16:29 < jtimon> sipa: levledb is what we're using, no? 16:29 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Ping timeout: 248 seconds] 16:29 < gmaxwell> jtimon: that doesn't use leveldb (except to persist across restarts) 16:29 < jtimon> oh 16:30 < jtimon> I see, I didn't know that, thanks 16:32 < jtimon> even if we only expose the version with our implementation, I think it would be good to abstract consensus storage even for bitcoin core rewardless of libconsensus users 16:32 < gmaxwell> our storage is already abstracted. 16:34 < jtimon> I really think not trashing preformance for our own implementation should be the priority at first, if the interface needs to go through a few iterations not to trash other implementations too, I think that's fine since we will be offering the "don't use storage abstractions" version too anyway 16:35 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 244 seconds] 16:35 < jtimon> yes, our storage is abstracted in more ways than we would want to expose in an storage-independent libconsensus C API 16:37 < jtimon> I mean, since I'm in favor of exposing both, one storage independent and one that is not, I'm fine with starting with the one that is not, I'm just more interested technically in the other one 16:39 < jtimon> can we talk a little bit about the other question? 16:42 < jtimon> ie whether libconsensus should fully validate a given block, or also accept it and update the state, manage reorgs, etc 16:44 < jtimon> again I'm ok with offering both but I'm more interested in the smaller one 16:44 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…] 16:47 < jtimon> or at least that's what I have been imagining all this time, I wasn't counting reorgs or updating the tip as part of the validation 16:50 -!- e4xit [~e4xit@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 17:01 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 17:01 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 17:01 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:05 < morcos> gmaxwell: sdaftuar: to return to the fee bumping, in suhas' example, where you first try to bump tx1,2,3 with tx4, and then you try again. 17:05 < morcos> i can see how you could invent a way to prevent tx4 from getting bumped, but how are you stopping 1,2,3 from being bumped again? 17:06 < morcos> or more generally, lets say you manually had tried to bump and tx1 and tx1a both are trying to pay the same guy (maybe you were smart enought to conflict, maybe not) 17:06 < gmaxwell> They should be marked abandoned when the bump is created. 17:06 < morcos> how do you stop a bumpunconfirmed from bumping both 17:06 < gmaxwell> (but even if they weren't they're conflicted at that point) 17:06 < morcos> they aren't conflicted 17:07 < gmaxwell> by tx4, which is in your mempool. 17:07 < morcos> conflicted means the conflicting tx is in the block 17:07 < morcos> a conflicting tx in the mempool is something you are not even aware of 17:08 < morcos> which brings me to the second point i wanted to make, aobut what you said about people abandoning wallets they think are empty 17:08 < morcos> thats a fantastic point, that i wish had been made a while ago 17:08 < gmaxwell> you're right, I'd been assuming it would be conflicted without thinking carefully what that test actually means right now. 17:08 < gmaxwell> I know for sure people do abandon wallets that they think are empty (or even 'almost empty') 17:09 < morcos> before we made the change to the confliction logic (for 0.12 ?) then if your spend was not in your mempool, it was considered conflicted (regardless of whether it was by an in-block, in-mempool tx, or nothing) 17:09 < morcos> so it would be kind of rare for you to think you were out of money but not 17:09 < morcos> but now, for sure that might happen 17:10 < morcos> now if you issue a tx that never makes it into a block or for some reason can't ever make it into your own mempool 17:10 < gmaxwell> I seem to vaguely recall that something else would still prevent us from doublespending the inputs on txn that weren't in the mempool, even then. 17:10 < morcos> regardless of any conflicting txs, its uses up your balance until you abandon it 17:10 < morcos> i don't think so 17:11 < morcos> it seems like we need another notion of balance (or maybe 2 more) 17:11 < morcos> potential balance (which is not reduced by non-in chain (6 deep?) spends) and maybe even a pending receive balance (although i guess that hasn't been a problem historically, that hasnt' changed) 17:15 < gmaxwell> Yes, agreed. I worry about the use 'balance' for a number which will go down without user interaction. :) 17:15 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 17:15 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:406d:4d62:14ab:17e4] has joined #bitcoin-core-dev 17:16 < gmaxwell> More like "pending outgoing payments: outbound payments which are not N confirms deep yet" and "pending incoming payments". 17:16 < Taek> Would it be enough to have a [confirmed balance] and an [unconfirmed diff]? 17:16 < morcos> if this is really the only use case, it would be easy enough to make a rpc call that just give you a report on how "empty" your wallet is 17:17 < morcos> Taek: we already have that.. , oh yeah, nm, thats the second thing i was talking abou tthen, the pending received balance 17:17 < morcos> getunconfirmedbalance 17:17 < Taek> if I'm following correctly, the worry is about coins that become unconfirmed due to e.g. change outputs? 17:18 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 17:18 < morcos> i think the primary worry is that if you spend some coins , but your spend never makes it into a block 17:18 < morcos> your wallet still deducts that spend from your balance 17:18 < morcos> forever 17:19 < morcos> until you manually mark it as abandoned (which is sort of an advanced feature, that we don't often recommend) 17:19 < Taek> technically some adversary could un-abandon any transaction that hasn't been double-spent 17:19 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:406d:4d62:14ab:17e4] has quit [Ping timeout: 240 seconds] 17:20 < morcos> exactly why its an advanced manual feature 17:20 < Taek> imo your confirmed balance should not change until the tx is in the blockchain 17:20 < Taek> and the confirmed balance should be what is presented to the user as the primary balance 17:21 < morcos> perhaps confirmed balance is the wrong word for what getbalance returns... it returns your spendable balance.. which certainly should be decremented for spends that haven't yet made it into the blockchain 17:21 < morcos> and i think thats what people expect to see when they ask their balance 17:22 < Taek> I don't think it's safe enough to show the user just one number. 17:23 < Taek> simply because the whole unconfirmed uncertainty is unseparatable from the blockchain way of doing thigns 17:23 < Taek> (well, lightning doesn't really have this issue) 17:25 < BlueMatt> gmaxwell: thinking about it more, the way we'd probably do it is, initially (ie v1) you make the libconsensus consumer provide a k-v store api, and we use that the same way we use leveldb, and then add functionality to parse the blobs we provide the k-v store into things like scriptPubKeys later 17:25 < jtimon> perhaphs both confirmed and spendable balances should be shown? 17:25 < BlueMatt> this provides functionality, without breaking our ability to change the format to add new things 17:26 < jtimon> I understand k-v is key-value kind of storage 17:27 < jtimon> BlueMatt: if so, what would the values be? C structs ? 17:27 < BlueMatt> the values are binary blobs that libconsensus provides which the user does not have any visibility into 17:28 < BlueMatt> (in our case its the serialization of CCoins or whatever with our compression stuff) 17:28 < sipa> BlueMatt: yup, that's what i imagined 17:28 < BlueMatt> if the user wants to know whats inside, there is some api which can parse it into a c struct or whatever 17:28 < sipa> a batch key-value write operation, and a key read operation 17:29 < jtimon> kind of like https://github.com/bitcoin/bitcoin/pull/8493/commits/ad3ac37387b231378573f4996c59467247fccd44 ? 17:30 < jtimon> ^ for the "binary blobs the caller doesn't know about" 17:30 < sipa> jtimon: i don't see such a thing at all 17:31 < sipa> that commit is about bitcoinconsensus_create_consensus_parameters 17:32 < jtimon> well, yeah, sorry, this are void pointers the other it's just data like in the tx for current verifyScript 17:33 < jtimon> in this case we would use the serialize lib to interpret and produce the "blobs", correct? 17:33 < sipa> if there needs to be a way to view the utxo set, i'd just provide a separate api for that 17:34 < sipa> not a parser for the database 17:34 < sipa> and not in the first stage 17:36 < jtimon> I am extremely interested in hearing in what other people's next steps, or more feedback on my own proposed next step 17:38 < jtimon> sipa: I'm still not sure if you prefer to expose verifyBlock or processBlock 17:39 < sipa> jtimon: i don't think we can do so right now anyway, without having a way to abstract state out 17:40 < sipa> imho the first step is just continuing refactoring so that consensus logic and other things become better separated internally 17:40 < sipa> and not focus on exposing things 17:40 < sipa> but others may disagree - i think wumpus prefers first having a clear idea of what will be exposed 17:41 < sipa> even a verifyBlock will need a way to pass in the utxo set and the block index 17:42 < sipa> the only difference is that a processBlock doesn't need a way to update set utxo set, and doesn't need to be able to request other blocks in case of a reorg 17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ajtnjskbevfyaukl] has quit [Quit: Connection closed for inactivity] 17:44 < jtimon> althought I tend to agree, I feel that's very vague and doesn't help on clarifying priorities, thinking of the next thing to expose, I think, helps clarify what the goal of the refactors should be and where are we supposed to be moving towards to 17:44 < sipa> you know my opinion - i don't care about exposing anything at all at this point, so i'm the wrong person to ask 17:44 < jtimon> yes verifyBlock would need an interface to access data from the utxo 17:44 < sipa> i think we have harder problems to solve before exposing even comes into question 17:45 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 17:45 < jtimon> dcousens: proposal was to pass all required data explicitly for the block you were validating 17:46 < sipa> essentially, i think we should first introduce clean abstractions between certain modules inside bitcoin core, in such a way that it's effectively bitcoind using a consensus library already, without it being exposed 17:46 < sipa> when it's good enough for us to use, we can think about exposing it to others 17:47 < sipa> (but again, others may see things differently) 17:48 < jtimon> right, and I think the module that should be a priority to cleanly separate is the part of the code that is required to fully validate whether a block is valid or not from everything else 17:48 < sipa> but that's very tightly coupled with validation of the whole chain, through CBlockIndex 17:49 < jtimon> right, it basically depends on chain.o and coins.o 17:50 < sipa> you can't validate a block without knowing its CBlockIndex 17:50 < jtimon> more specifically on two existing classes on them, an API for that is not hard 17:50 < sipa> so i'm not sure whether "single block validation" is a useful abstraction on its own 17:50 < sipa> transaction validation may be useful 17:51 < jtimon> CBlockIndex is the storage interface I abstract (or abstract from its own exsiting abstraction) in 8493 17:51 < sipa> i don't want an abstraction for CBlockIndex 17:52 < jtimon> my proposed next steps are single header validation or single tx validation 17:52 < jtimon> but without policy checks 17:53 < sipa> as i said, i don't think we should focus on exposing interfaces now, but on separating modules 17:53 < sipa> and i think separating block validation from chain validation is hard 17:54 < BlueMatt> jtimon: I'm with sipa here - The Main Split was the first of many steps that make sense on their own to abstract out consensus and non-consensus code 17:54 < BlueMatt> jtimon: the few commits I sent you earlier form the very tiny beginning of what I think are the next steps 17:54 < jtimon> separating network things was absolutely brilliant, thanks again 17:54 < BlueMatt> jtimon: ie having a state object internally which keeps chainstate in it and calls out to things for disk access and has ProcessNewBlock as a member function 17:55 < sipa> BlueMatt: chainstate include mapBlockIndex? 17:55 < BlueMatt> and its ~no code changes, just some function splitting and putting ClassName:: in front of them 17:55 < BlueMatt> sipa: yes, mapBlockIndex and chainActive and related variables 17:55 < BlueMatt> sipa: but calling out for ReadBlockFromDisk, and pcoinsTip is just a pointer that is passed to it 17:56 < sipa> BlueMatt: got it 17:56 < sipa> seems like an easy first step 17:56 < jtimon> sipa: if you don't care about exposing, that's fine, let's talk about dependencies, I want the consensus module to fully verify a single tx and a single header and a single block without depending on coins.o or chain.o 17:56 < BlueMatt> yea, should be pretty clean...I dont have time to do it for the next week or two...do you want to take it up jtimon? 17:56 < BlueMatt> I also want to work on splitting up net_processing more so that we can multithread ProcessMessages 17:57 < BlueMatt> jtimon: I dont see how thats possibel? 17:57 < sipa> yes, i think those are possible 17:57 < jtimon> I don't know what you want to do, how can I pick it up? 17:57 < sipa> (don't 17:57 < BlueMatt> jtimon: literally the point of "fully validating" a tx is to validate it against a CCoins-holding UTXO db 17:57 < BlueMatt> jtimon: did you look at the top commit on the branch I sent you? 17:57 < sipa> efficiency of validation is highly dependent on low-level access to coins and chain 17:57 < jtimon> sigh, I thought I had proved it was possible repeated times... 17:58 < BlueMatt> jtimon: https://github.com/TheBlueMatt/bitcoin/commit/54c967e73a1d1abba8f426fce0f14c5eeaf277e6 17:58 < sipa> it's possible if you introduce abstractions everywhere 17:58 < jtimon> is it possible to fully validate a header without depending on chain.o? 17:58 < sipa> no 17:58 < sipa> (unless you abstract it out, of course) 17:59 < jtimon> then what's happening in 8493 17:59 < jtimon> right 17:59 < sipa> but i think such abstraction are both a performance issue and an unnecessary code complication 18:00 < jtimon> well, more than half of 8493 is purely for demonstrating the exposed api and without benchmarking of any kind 18:03 < jtimon> my goal was to separate the code the verify a full block, depending on chain.o and coins.o (but only on those related to storage) [maybe put it all in the consensus folder? or wait for later?] but not putting it in the consensus module until you want to expose more and abstract it from chain and coins 18:05 < jtimon> anyway, I'm happy reviewing any related refactors, please ping me 18:07 < jtimon> sipa: does the GetConsensusFlag make any sense to you at a first glance? at least more than the previous version? 18:08 < jtimon> without exposing anything, just as a refactor (note that calling GetConsensusFlag inside ContextualCheckBlock is painful performance-wise) 18:27 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev 18:32 -!- netzin [~netsin@unaffiliated/jiggalator] has quit [Client Quit] 18:38 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 245 seconds] 18:43 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 18:46 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 19:24 -!- Netsplit *.net <-> *.split quits: Guest13131 19:30 -!- Guest13131 [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev 19:36 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 19:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:39 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 19:49 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 19:50 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 19:52 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 19:57 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 20:03 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds] 20:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:17 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 20:20 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 20:42 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4dbd:d6b8:36ed:7512] has quit [Quit: .] 20:45 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:ed5c:b7f7:7c11:5b25] has joined #bitcoin-core-dev 21:02 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has quit [Quit: -a- Android IRC 2.1.17] 21:04 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 21:07 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 21:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 245 seconds] 21:45 < bitcoin-git> [bitcoin] jtimon opened pull request #9279: Consensus: Move CFeeRate out of libconsensus (master...0.13-consensus-dust-out-minimal) https://github.com/bitcoin/bitcoin/pull/9279 21:46 < bitcoin-git> [bitcoin] jtimon closed pull request #7820: Consensus: Policy: Move CFeeRate out of consensus module and create CPolicy interface (master...0.12.99-consensus-dust-out) https://github.com/bitcoin/bitcoin/pull/7820 21:52 -!- Atomicat_ [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev 21:53 -!- _mn3monic [~guido@176.9.68.68] has quit [Ping timeout: 248 seconds] 21:53 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev 21:53 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Ping timeout: 248 seconds] 21:54 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 248 seconds] 21:54 -!- Atomicat_ is now known as Atomicat 22:10 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Ping timeout: 245 seconds] 22:15 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has joined #bitcoin-core-dev 22:15 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has quit [Changing host] 22:15 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 22:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jwrejxtznosozzqy] has joined #bitcoin-core-dev 22:47 < gmaxwell> FWIW, I'm noticing connection slots full on my nodes. 22:47 -!- BCBot_ [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 22:48 -!- bobbytux_ [~bobbytux@ARouen-653-1-4-84.w82-126.abo.wanadoo.fr] has joined #bitcoin-core-dev 22:48 < gmaxwell> including some clown at 138.68.10.138 who looks like he's connected three times to everyone; while pretending to be android wallet (he's not). 22:50 -!- Alina-malina_ [~Alina-mal@37.157.216.171] has joined #bitcoin-core-dev 22:50 -!- ville- [~ville@xollo.net] has joined #bitcoin-core-dev 22:51 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer] 22:52 -!- bobbytux__ [~bobbytux@ARouen-653-1-4-84.w82-126.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds] 22:52 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 22:53 -!- owowo [ovovo@gateway/vpn/mullvad/x-bskagjsotednaztd] has quit [Ping timeout: 244 seconds] 22:53 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 244 seconds] 22:53 -!- ville-- [~ville@xollo.net] has quit [Ping timeout: 244 seconds] 22:53 -!- BCBot [~BCBot@46.101.246.115] has quit [Ping timeout: 244 seconds] 22:54 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 22:55 -!- owowo [ovovo@gateway/vpn/mullvad/x-pjjzrsyosvqkerfe] has joined #bitcoin-core-dev 22:57 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 23:00 -!- dermoth [~thomas@dsl-66-36-132-180.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:01 -!- dermoth [~thomas@dsl-66-36-132-180.mtl.aei.ca] has joined #bitcoin-core-dev 23:06 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/4d955fc5824b...46904ee5d2ce 23:06 < bitcoin-git> bitcoin/master a188353 Pieter Wuille: Switch GetTransaction to returning a CTransactionRef 23:06 < bitcoin-git> bitcoin/master c3f5673 Pieter Wuille: Make CWalletTx store a CTransactionRef instead of inheriting 23:06 < bitcoin-git> bitcoin/master 42fd8de Pieter Wuille: Make DecodeHexTx return a CMutableTransaction 23:08 < bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/46904ee5d2ce...d04aebaec7bb 23:08 < bitcoin-git> bitcoin/master 6fdd43b Matt Corallo: Add struct to track block-connect-time-generated info for callbacks 23:08 < bitcoin-git> bitcoin/master fd9d890 Matt Corallo: Keep blocks as shared_ptrs, instead of copying txn in ConnectTip 23:08 < bitcoin-git> bitcoin/master ae4db44 Matt Corallo: Create a shared_ptr for the block we're connecting in ActivateBCS 23:08 < bitcoin-git> [bitcoin] laanwj closed pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014 23:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 23:27 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 23:36 -!- Alina-malina_ [~Alina-mal@37.157.216.171] has quit [Changing host] 23:36 -!- Alina-malina_ [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 23:36 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 23:36 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 23:42 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 23:44 < sipa> BlueMatt: i can't build flto with -O3, but i can with -O2