--- Day changed Wed Jan 11 2017
00:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
00:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:16 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
00:16 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
00:16 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev     
00:17 -!- BitBully [~Mutter@197.210.25.225] has quit [Ping timeout: 252 seconds]     
00:18 -!- BitBully [~Mutter@197.210.25.174] has joined #bitcoin-core-dev     
00:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:40 -!- BitBully [~Mutter@197.210.25.174] has quit [Quit: Mutter: www.mutterirc.com]     
00:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:06 < bitcoin-git> [bitcoin] kallewoof opened pull request #9516: Bug-fix: listsinceblock: use max depth value for blocks in reorg'd chains (master...listsinceblock-reorg-fix) https://github.com/bitcoin/bitcoin/pull/9516
01:41 -!- waxwing [~waxwing@84.237.213.217] has quit [Quit: Leaving]     
01:41 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
02:23 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ieozikfyatksqjvo] has joined #bitcoin-core-dev     
03:08 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
03:08 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
03:08 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:09 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
03:10 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Remote host closed the connection]     
03:15 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
03:15 -!- pavel_ [~paveljani@79.98.72.176] has quit [Remote host closed the connection]     
03:18 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 248 seconds]     
03:24 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has quit [Ping timeout: 240 seconds]     
03:26 -!- BitBully [~Mutter@197.210.28.124] has joined #bitcoin-core-dev     
03:32 -!- BitBully [~Mutter@197.210.28.124] has quit [Quit: Mutter: www.mutterirc.com]     
03:38 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has joined #bitcoin-core-dev     
03:40 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
03:40 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
03:54 -!- jtimon [~quassel@37.134.30.245] has joined #bitcoin-core-dev     
03:56 < jtimon> rewarding 8994 (custom chainparams), how important it is that it loads the chainparams from a different conf file instead of regular args and the existing config file? the arguments will be ignored for main, testnet and regtest anyway
03:57 < jtimon> NicolasDorier: regarding your vision for libconsensus, do you mind if I make some more questions here?
03:57 < NicolasDorier> sure
03:57 < NicolasDorier> I think trying the following
03:57 < NicolasDorier> brand new project
03:57 < NicolasDorier> copy/pasta of bitcoin core
03:57 < NicolasDorier> then stripping everything not related to consensus
03:58 < NicolasDorier> removing all dependencies to third party libs
03:58 < jtimon> well, copy paste from core or doing it in core ignoring the rest is not that different is it?
03:59 < NicolasDorier> I think it is harder
03:59 < NicolasDorier> like there is so much reference to the utxo storage in the consensus code.
04:00 < NicolasDorier> I would prefer being able to strip that
04:00 < NicolasDorier> rather than trying to make interfaces
04:00 < jtimon> anyway, one frequent discussion is abstract storage yes no, you told me you say yes (like BlueMatt and me), but it seems your way of doing it it's a bit different. ie instead of function pointers, your API assumes that all the needed data will be provided directly in the parameters
04:01 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
04:01 < NicolasDorier> I changed my mind. I think the consensus lib does not have to know anything about storage, I think we can ask the client to pass the UTXO necessary for validating the block
04:01 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
04:01 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
04:01 < jtimon> but then the client needs to know which ones will be relevant before calling
04:01 < NicolasDorier> yes, and but the client know that
04:01 < jtimon> and will need to fetch them even if the tx/block was already invalid because of something trivial
04:01 < NicolasDorier> since he has the block
04:02 < NicolasDorier> correct. But the client can verify PoW before fetching
04:02 < jtimon> sure, just comparing with the function pointer version of it, in both cases it will need to have the data
04:02 < jtimon> another discussion was how the client gets that data
04:03 < NicolasDorier> this would be the client's business
04:03 < NicolasDorier> this is simple enough stuff to do
04:03 < NicolasDorier> iffunction pointer
04:03 < NicolasDorier> it is complicated to use, and 
04:04 < jtimon> matt advocated for, using a function pointer like interface, he would expose something like processBlock rather than only verifyBlock, that way if the block is valid it will also call the necessary function pointer api for the abstracted storage to store the new block, update the utxo, etc
04:04 < NicolasDorier> if the implementation cross boundary between languages, there is huge perf hit
04:05 < NicolasDorier> I don't think this is the right approach. I think it is just easier to ask the client to fetch everything preventively
04:05 < jtimon> right, that's the advantage of your approach, less performance hit by avoiding the function pointers (although more in some cases by prefetching everything)
04:05 < jtimon> right, just comparing the different approaches
04:06 < NicolasDorier> this also make it harder for us to break users of consensus
04:06 < NicolasDorier> because we would make no assumption on how they deal with their storage
04:06 < jtimon> in my model, there was no processBlock, just verifyBlock that tells you whether a block is valid or not and nothing else: the caller needs to update the storage and manage reorg and the like on his own
04:07 < NicolasDorier> one method is not enough, you need also to verify PoW for example. The client wants to verify PoW before pulling out the UTXOs from storage
04:07 < jtimon> right, that's an advantage for both the abstracted storage API or the abstracted storage by prefetching
04:08 < jtimon> the people that don't like to abstract the storage (at least greg and pieter), are happy with libconsensus depending on levelDB
04:09 < NicolasDorier> I don't think libconsensus should have any dependencies
04:09 < NicolasDorier> it should be plain dumb lib like libsecpk)#*R#)*$
04:09 < jtimon> so you would expose a function to verify pow before fetching the data? why just pow? there's many things that can be validated without storage
04:09 < NicolasDorier> yes other things as well
04:09 < NicolasDorier> like CheckContextual *
04:10 < jtimon> well, I think at the very least it should have libsecp256k1 as a dependency, but I agree it shouldn
04:10 < NicolasDorier> yes     
04:10 < jtimon> 't depend on levelDB
04:10 < jtimon> just pointing out that other people disagree
04:11 < NicolasDorier> yes     
04:11 < jtimon> so maybe you would expose checkblock and verifyBlock separately
04:11 < NicolasDorier> but what I plan to do is making it the way I see, using it with my C# full node, and if people are happy with it proposing to Core
04:11 < jtimon> makes sense, I thought about it
04:12 < jtimon> do you plan to expose lower level functions like say verifyHeader or verifyTx ?
04:13 < NicolasDorier> mh depends if my full node need it. VerifyHeader yes, VerifyTx might be good for mempool, but the problem is that it should not check policy rules
04:13 < NicolasDorier> it would
04:13 < jtimon> yeah, I think I will finish my vision on top of 0.14 and then see what happens
04:13 < NicolasDorier> it would not check policy rules
04:13 < jtimon> I was kind of doing that for 0.12 but I decided I would wait for bip9 and segwit instead
04:13 < NicolasDorier> I am tempted to still use my C# script validator for mempool stuff
04:14 < NicolasDorier> not including verifyTx
04:14 < jtimon> right, verifyTx would not check policy rules, perhaps we can have a verifyAndAcceptTx function too, but that's more bitcoin core specific I think
04:15 < jtimon> C# script validator? you don't use the verifyScript in current libconsensus ?
04:15 < NicolasDorier> NBitcoin has its own script validator yes
04:16 < jtimon> libbitcoin has his own validator as well, but optionally they allow you to use libconsensus instead
04:16 < NicolasDorier> right now the full node I did does not depends on libconsensus, but I want people to be able to activate it if they want
04:17 < NicolasDorier> the user can turn it for the script validation as well if he wants, but I want to verify the full block with libconsensus
04:17 < jtimon> is there any reason why you don't use libconsensus::verifyScript in nbitcoin ? do you plan to do it later?
04:17 < NicolasDorier> you can use it
04:17 < NicolasDorier> I do not by default because there is deployment headache
04:18 < NicolasDorier> pure C# code just run everywhere
04:18 < jtimon> oh, so then NBitcoin optionally depends on libconsensus, got it
04:18 < NicolasDorier> yes     
04:19 < NicolasDorier> I will also add a mode where you setup a trusted node, and just do not verify the blocks.
04:19 < jtimon> what about caches? what do you plan for caches? bip9 cache, sigcache?
04:20 < jtimon> I mean, how do you plan to handle that with your libconsensus ?
04:20 < NicolasDorier> not yes thought about it. BIP9 I think the easiest at beginning is that the user does it. I plan in v1 that the user will pass the consensus flags to activate
04:20 < NicolasDorier> so libconsensus will not depends on CBlockIndex
04:21 < NicolasDorier> hopefully, I would like to make that into libconsensus eventually though
04:21 < jtimon> he has to count the 95% in the last diff adjustment period manually?
04:21 < NicolasDorier> for the other cache, I have not decided yet I dont know
04:22 < NicolasDorier> yes     
04:22 < NicolasDorier> not perfect for sure
04:22 < jtimon> I guess no approach is perfect, all have drawbacks and advantages
04:23 < jtimon> I don't think I have any more questions, thank you!
04:23 < NicolasDorier> I think it is possible to make it part of libconsensus, but not yet thought about it, I would like a v1 without CBlockIndex
04:23 < jtimon> and btw, congrats on completing a full node alt implementation, not an easy task
04:24 < NicolasDorier> thanks, still stuff to do though. But happy with the results so far :D
04:24 < NicolasDorier> it is compatible with config file of Core, and has also rpc server
04:24 < NicolasDorier> my goal is to reuse the test suite of bitcoin core
04:24 < NicolasDorier> as is
04:25 < NicolasDorier> to test my implementation
04:25 < jtimon> in my approach I planned to expose a getConsensusFlags, but it would depend on a function_pointer-based API for CBlockIndex (the same I was using for verifyHeader in #8493 )
04:25 < gribble> https://github.com/bitcoin/bitcoin/issues/8493 | Untested: libconsensus: Expose VerifyHeader by jtimon · Pull Request #8493 · bitcoin/bitcoin · GitHub
04:25 < NicolasDorier> yes I remember
04:26 < jtimon> reusing bitcoin core's test suite is very interesting
04:45 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5754e0341b7c...bbf193fef049
04:45 < bitcoin-git> bitcoin/master 67ca130 Cory Fields: build: fix for out-of-tree/distdir qt builds
04:45 < bitcoin-git> bitcoin/master bbf193f Wladimir J. van der Laan: Merge #9513: build: fix qt distdir builds (retry)...
04:46 < bitcoin-git> [bitcoin] laanwj closed pull request #9513: build: fix qt distdir builds (retry) (master...out-of-tree-build) https://github.com/bitcoin/bitcoin/pull/9513
04:52 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbf193fef049...593a00ce1935
04:52 < bitcoin-git> bitcoin/master 74994c6 Pieter Wuille: Improve style w.r.t. if
04:52 < bitcoin-git> bitcoin/master 593a00c Wladimir J. van der Laan: Merge #9506: RFC: Improve style for if indentation...
04:52 < bitcoin-git> [bitcoin] laanwj closed pull request #9506: RFC: Improve style for if indentation (master...newstyle) https://github.com/bitcoin/bitcoin/pull/9506
04:56 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/593a00ce1935...ca615e6c05ef
04:56 < bitcoin-git> bitcoin/master 8217bd1 fanquake: [depends] libevent 2.1.7rc
04:56 < bitcoin-git> bitcoin/master ca615e6 Wladimir J. van der Laan: Merge #9471: [depends] libevent 2.1.7rc...
04:56 < bitcoin-git> [bitcoin] laanwj closed pull request #9471: [depends] libevent 2.1.7rc (master...depends-0-14-0-libevent) https://github.com/bitcoin/bitcoin/pull/9471
05:01 < wumpus> are there any remaining issues with #9375?
05:01 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
05:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:08 < instagibbs> same q for #9400
05:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9400 | Set peers as HB peers upon full block validation by instagibbs · Pull Request #9400 · bitcoin/bitcoin · GitHub
05:12 < sipa> wumpus: i was planning to review 9375 today
05:13 < wumpus> sipa: okay, great
05:26 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca615e6c05ef...e2e624d9ce54
05:26 < bitcoin-git> bitcoin/master 1fc4ec7 mrbandrews: Add pruneblockchain RPC to enable manual block file pruning.
05:26 < bitcoin-git> bitcoin/master afffeea Russell Yanofsky: fixup! Add pruneblockchain RPC to enable manual block file pruning....
05:26 < bitcoin-git> bitcoin/master e2e624d Wladimir J. van der Laan: Merge #7871: Manual block file pruning....
05:42 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Ex-Chat]     
05:46 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
05:51 -!- thokon00 [~thokon00@gw.linuxit.at] has left #bitcoin-core-dev []     
05:52 < bitcoin-git> [bitcoin] kallewoof opened pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (master...raii-httpserver) https://github.com/bitcoin/bitcoin/pull/9517
06:23 < sipa> i wonder why unique_ptr does not have an emplace method like the stl containers have
06:23 < sipa> would be a neat and cheap way to avoid explicit new calls
06:25 -!- Guest3710 [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
06:26 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has quit [Quit: Ex-Chat]     
06:27 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
06:27 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
06:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:39 < jtimon> oh, I didn't know about contrib/devtools/check-doc.py
07:01 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
07:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
07:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
07:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Ex-Chat]     
07:28 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
07:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:40 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has quit [Quit: Ex-Chat]     
07:43 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
08:00 -!- AaronvanW [~aaronvw@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
08:55 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:03 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
09:03 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit]     
09:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:08 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
09:20 < cfields> sipa: see std::make_unique in c++14. I assume that's what you mean?
09:23 < gmaxwell> Lets upgreade to C++14! :P
09:23 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
09:28 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
09:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:36 -!- Guest719 [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
09:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:37 -!- Guest719 is now known as roidster     
09:44 < sipa> cfields: but x.emplace(a,b) still looks nicer than x = std::make_unique<x_t>(a,b);
09:50  * luke-jr always found emplace to look ugly, but doesn't care enough to argue it
09:51 < cfields> sipa: ah, i see what you mean. seems a bit clumsy to me though, as emplace implies that you're constructing a new value in place, rather than replacing a (the) current one
10:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:06 < profall> Anyone have a link to the latest blockchain torrent?
10:06 < sipa> profall: the blockchain torrent has been discontinued (at least by the bitcoin core maintainers) since 0.10
10:06 < profall> ah ok
10:06 < sipa> as the bitcoin block download code is usually faster
10:07 < sipa> (it validates while downloading)
10:07 < profall> yea     
10:07 < profall> I am still experiencing issues with my node randomly dropping out of sync every few hours
10:07 < profall> I thought maybe a fresh resync might fix something, not sure.
10:08 < sipa> define 'dropping out of sync'
10:08 < profall> It'll be on the correct block if compared to blockchain.info or any other explorer. Then I will come back a few hours later and it'll be stuck on some block from 2 hours ago and not in sync anymore.
10:09 < profall> This is an E3 processor, 100mbps connection in a datacenter, 16GB ram server. Not resource starved. 
10:10 < sipa> anything in debug.log?
10:11 < profall> ping timeout 1200s
10:11 < profall> socket recv error Connection reset by peer (104)
10:12 < sipa> that's normal
10:12 < sipa> what version?
10:12 < sipa> of bitcoin core
10:12 < gmaxwell> well it's not normal if it happens to all peers?
10:12 < profall> 0.13.2 on Linux
10:13 < profall> I downloaded it straight from the website rather then use the repo, just in case as well.
10:13 < gmaxwell> profall: can you send one of us a copy of your debug log including one of these incidents?  the debug log will identify your IP and potentially some of your transactions if you're using it as a wallet.
10:13 < sipa> could you share a few hours worth of debug.log somewhere?
10:14 < profall> Sure, ill PM you just give me a few moments to prepare it.
10:23 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
10:24 < profall> PM'd both of you with debug.log
10:24 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
10:24 < profall> Oops, realized it's empty...
10:25 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
10:25 < luke-jr> morcos: c0507f800475edf003adb744061d864741d3ee12796834d4d7f9a72b0bbd4fe6 is the only one on your list that shows up in my debug.log
10:25 < luke-jr> 2017-01-10 21:23:32 not keeping orphan with rejected parents c0507f800475edf003adb744061d864741d3ee1279
10:25 < luke-jr> And its parent was rejected because… 2017-01-10 21:23:32 d97b0571f984420ffebb8f4e69e3d1ed1467797105ad602747ff1ddff322ff40 from peer=14 was not accepted: bad-txns-inputs-spent (code 18)
10:25 < luke-jr> looks like a double-spend? … so the competing parent probably had enough fee for the mempool, but not enough to be mined, and d97b0571f9 didn't have enough more to replace it
10:25  * luke-jr wonders if this might be exploitable
10:26 < profall> Resent 
10:33 < gmaxwell> BlueMatt: can you confirm that the new addnode behavior in master is sufficient to get rid of your fibre proxy thing?
10:33 < BlueMatt> gmaxwell: based on what you wrote in your pull, yes
10:34 < gmaxwell> okay, so if it does what it says on the tin you think its good to go.  fine with me.
10:34 < BlueMatt> I'd need to go re-test to confirm, but I did test pre-merge
10:34 < BlueMatt> yea     
10:34 < gmaxwell> (I just wanted to make sure if you needed any other features that I wrote them ASAP.)
10:34 < BlueMatt> heh, yea, all good thanks
10:35 < BlueMatt> in other news, I'm avoiding review because sick, and super pissed off about this :(
10:39 < sipa> pissed about being sick?
10:39 < BlueMatt> both - i have so much review to do :(
10:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
10:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:47 < sipa> should -maxmempool=0 imply -blocksonly ?
10:48 < gmaxwell> Probably, though blocksonly is still a hidden option.
10:48 < sipa> ah, really
10:48 < gmaxwell> It's hidden because it would probably be better if we had a service bit related to it before having lots of nodes running it.
10:48 < gmaxwell> probably thats too conservative, it's unlikely lots of nodes would run it.
10:49 -!- jtimon [~quassel@37.134.30.245] has quit [Read error: Connection reset by peer]     
10:54 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
10:56 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:02 < cfields> BlueMatt: heh, i'm very behind on review as well. slowly making my way through yours.
11:02 -!- owowo [ovovo@gateway/vpn/mullvad/x-sutgtiqxmxirkvkc] has quit [Ping timeout: 272 seconds]     
11:03 < sipa> likewise
11:04 < instagibbs> Someone have the list of high-priority review on hand
11:05 < sipa> i think we really want #9375 #9441 in
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
11:06 < cfields> BlueMatt: I've been stuck on the ActivateBestChain() kludge for quite a while now. I don't like it, but with no better argument than "it's ugly". Would it be reasonable instead to maintain a list of announced-but-not-stored hashes, combined with maybe just a quick hack like WaitForValidation(hash) ?
11:06 < cfields> (i assume that question has been posed already)
11:06 -!- owowo [ovovo@gateway/vpn/mullvad/x-hrrhsuxnrkjiafda] has joined #bitcoin-core-dev     
11:06 -!- owowo [ovovo@gateway/vpn/mullvad/x-hrrhsuxnrkjiafda] has quit [Changing host]     
11:06 -!- owowo [ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
11:06 -!- owowo [ovovo@unaffiliated/ovovo] has quit [Changing host]     
11:06 -!- owowo [ovovo@gateway/vpn/mullvad/x-hrrhsuxnrkjiafda] has joined #bitcoin-core-dev     
11:07 < BlueMatt> cfields: if you announce a block which turns out to be invalid, WaitForValidation wont help :/
11:07 < instagibbs> Ok, I really cant comment on the net locks overhaul but I'll re-review the former
11:07 < cfields> BlueMatt: well presumably it'd drop out of the list, valid or no
11:09 < cfields> BlueMatt: i suppose at an even higher level it could just be WaitForBestChainActivated()
11:11 < BlueMatt> cfields: i mean the ActivateBestChain kludge is only there for the case where you caught the cs_main lock right in the middle of ProcessNewBlock where it unlocks cs_main for a sec
11:11 < BlueMatt> ActivateBestChain literally is WaitForActivateBestChainActivated().....
11:12 < BlueMatt> its just the version for when you're already holding cs_main
11:14 < cfields> BlueMatt: understood. Just seems scary to allow that to be manipulated so easily. Like I said though, I can't come up with any realistic issue with it.
11:14 < BlueMatt> "manipulated"?
11:14 < BlueMatt> I mean I hope that its pretty much free if you're already on the best chain
11:30 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
11:32 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9518: Return height of last block pruned by pruneblockchain RPC (master...pr/prune-height) https://github.com/bitcoin/bitcoin/pull/9518
11:48 < sipa> ryanofsky: feel like having a look at https://github.com/sipa/bitcoin/commits/pertxoutcache ?
11:48 < gmaxwell> I will be travling during the meeting tomorrow.
11:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]     
11:59 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
12:02 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:03 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
12:04 -!- roidster [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 258 seconds]     
12:05 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye]     
12:05 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
12:11 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye]     
12:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:12 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
12:14 < cfields> BlueMatt: as an example of an unintended side-effect: miner mines a block, hands it to ProcessNewBlock, ProcessMessages (incoming GETBLOCKS) swoops in _just_ after AcceptBlock and runs ActivateBestChain, before the mining thread gets a chance to. As a result, miner has to read the block from disk
12:15 < cfields> BlueMatt: trivial and unlikely, but still a side-effect :\
12:16 < cfields> rather, the processor reads from disk.
12:20 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
12:25 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:26 < morcos> luke-jr: that was a replay, that tx was mined on 01-03
12:27 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
12:28 < bitcoin-git> [bitcoin] morcos opened pull request #9519: Exclude RBF replacement txs from fee estimation (master...excludeRBF) https://github.com/bitcoin/bitcoin/pull/9519
12:30 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
12:40 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
12:41 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
12:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
12:48 -!- xinxi_ [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
12:51 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 248 seconds]     
12:52 -!- adiabat [~adiabat@67.205.158.84] has joined #bitcoin-core-dev     
12:53 -!- ClockCat [~CattieCat@75-109-228-219.stjocmtk01.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
12:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
13:10 -!- xinxi_ [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
13:12 -!- roidster [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
13:23 -!- roidster [~chatzilla@47-41-33-247.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]     
13:59 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2e624d9ce54...05950427d310
13:59 < bitcoin-git> bitcoin/master fe7e593 Suhas Daftuar: Fix use-after-free in CTxMemPool::removeConflicts()
13:59 < bitcoin-git> bitcoin/master 0595042 Pieter Wuille: Merge #9507: Fix use-after-free in CTxMemPool::removeConflicts()...
13:59 < bitcoin-git> [bitcoin] sipa closed pull request #9507: Fix use-after-free in CTxMemPool::removeConflicts() (master...fix-mempool-useafterfree) https://github.com/bitcoin/bitcoin/pull/9507
14:08 < BlueMatt> cfields: I suppose I'm not too concerned by that kind of super-crazy race....in the future we probably do want to cache stuff like that more
14:09 < cfields> BlueMatt: i'm not at all concerned by it. My only concern is that it's entirely non-obvious what the side-effects are. And that they're bound to change in the future.
14:12 < cfields> BlueMatt: The first path I was chasing down was whether or not, in the same scenario, the miner's validationinterface would only receive a null pointer (in the case of the dummy ActivateBestChain) rather than the real block. That's obviously not the case. My fear, though, is that if that _were_ the case, we might not have noticed.
14:12 < BlueMatt> yes, I did check for that when writing the code :p
14:13 < BlueMatt> cfields: I think the (real) solution is to make callbacks out of ValidationInterface go in a background thread, and make ProcessNewBlock hold the cs_main lock the whole time
14:13 < BlueMatt> but that is definitely not a 0.14 refactor
14:13 < gmaxwell> great, but would I know to enforce that invariant if I were changing the code later?
14:14 < cfields> ^^ what he said :)
14:15 < BlueMatt> wait, which callback are you referring to?
14:15 < BlueMatt> it was already the case that ActivateBestChain could be called "loose" and connect a block, so I dont think I changed the requirements on ABS?
14:16 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]     
14:17 < cfields> ABS ?
14:17 < BlueMatt> activatebestchain
14:17 < BlueMatt> but the version that comes out when I've got a head-cold :p
14:17 < cfields> ah, ActivateBeStchain :p
14:17 < BlueMatt> yea, that
14:18 < sipa> Next PR: "Correct ActivateBestChain to ActivateBestShain"
14:18 < cfields> no, that didn't change, but there's now a publicly triggerable way to (try to) force an ABS between ProcessBlock and the ABS below it
14:18 < BlueMatt> mmm, fair enough
14:19 < cfields> sipa: heh. Blockshain all the things!
14:21 < sipa> since 9 days ago, the memory usage of mapBlockIndex exceeded 100M
14:22 < sipa> it's using 224 bytes per entry
14:22 < sipa> some of which could be avoided
14:22 < BlueMatt> yes, lets fix that
14:22 < gmaxwell> not that much could be avoided though.
14:22 < sipa> it's using 2 allocations per entry
14:23 < sipa> (which are included in the 224 number)
14:23 < BlueMatt> wait, it is?
14:23 < sipa> it should be 0
14:23 < BlueMatt> gmaxwell: like 20 bytes per entry last I checked
14:23 < sipa> but at least 1 should be trivial to avoid
14:24 < sipa> using a map<uint256, CBlockIndex> instead of map<uint256, CBlockIndex*>
14:24 < gmaxwell> sipa: how can it be zero? the data structure grows and things keep around pointers to it? no. 
14:24 < sipa> gmaxwell: direct hashtable
14:25 < sipa> and using map::iterators instead of CBlockIndex* all over the place
14:25 < gmaxwell> okay, perhaps we don't actually keep any of the pointers.
14:25 < sipa> but if we're going to do that, i'd want a proper encapsulation too, that has its own lock, and has accessor methods for the fields that can be accessed without lock
14:25 < sipa> ... post 0.14
14:26 < gmaxwell> sipa: well if the work is done to change how its accessed it should be encapsulated enough so that it could be diskbacked without changing any of the code.
14:26 < gmaxwell> even with all the overheads gone, it's a significant chunk of memory.
14:27 < sipa> right
14:27 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Read error: Connection reset by peer]     
14:28 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
14:28 < sipa> ideally we'd also split up the disk-storage part and the validity-related part
14:28 < sipa> into two structures
14:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:11 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
15:15 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 240 seconds]     
15:16 < bitcoin-git> [bitcoin] sipa closed pull request #8170: Remove lookup-tx-by-utxo functionality (master...betternotxindex) https://github.com/bitcoin/bitcoin/pull/8170
15:32 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
15:37 -!- Guest3710 [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving]     
15:37 < bitcoin-git> [bitcoin] sipa opened pull request #9520: Deprecate non-txindex getrawtransaction and better warning (master...warntxindex) https://github.com/bitcoin/bitcoin/pull/9520
15:41 -!- Magma [~magma@magma.tokyo] has quit [Ping timeout: 268 seconds]     
15:41 -!- Magma [~magma@magma.tokyo] has joined #bitcoin-core-dev     
15:48 -!- Magma [~magma@magma.tokyo] has quit [Ping timeout: 268 seconds]     
15:48 -!- Magma [~magma@magma.tokyo] has joined #bitcoin-core-dev     
15:56 < sipa> some review on #9261 plz?
15:56 < gribble> https://github.com/bitcoin/bitcoin/issues/9261 | Add unstored orphans with rejected parents to recentRejects by morcos · Pull Request #9261 · bitcoin/bitcoin · GitHub
16:16 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Ping timeout: 252 seconds]     
16:29 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has quit [Ping timeout: 272 seconds]     
16:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
16:44 < gmaxwell> oh good, you can thumbs up your own comments on github.
16:44 < gmaxwell> My life is now complete.
16:47 < luke-jr> lol     
16:54 -!- OfficialLeibniz is now known as officia||eibniz     
16:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ieozikfyatksqjvo] has quit [Quit: Connection closed for inactivity]     
16:58 < midnightmagic> I love thumbs-upping my own posts. It aggravates some of the kinds of people I like aggravating. :-)
16:58 < gmaxwell> sipa: thanks for the ack on #9484.
16:58 < gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
17:00 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:02 < gmaxwell> jonasschnelli: did you ever get to producing the change that removes keys from the keypool when they're seen used on the network?
17:12 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05950427d310...0b738075bd43
17:12 < bitcoin-git> bitcoin/master 54ee3fc Michael Rotarius: RPC help updated
17:12 < bitcoin-git> bitcoin/master 0b73807 MarcoFalke: Merge #9297: Various RPC help outputs updated...
17:13 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9297: Various RPC help outputs updated (master...rpchelp12/16) https://github.com/bitcoin/bitcoin/pull/9297
17:16 -!- cbits [~cbits@2607:f380:a61:650:b850:7958:8812:7d7d] has joined #bitcoin-core-dev     
17:16 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b738075bd43...9ec1330b455c
17:16 < bitcoin-git> bitcoin/master faaf3ca MarcoFalke: travis: make distdir before make
17:16 < bitcoin-git> bitcoin/master 9ec1330 MarcoFalke: Merge #9416: travis: make distdir before make...
17:16 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9416: travis: make distdir before make (master...Mf1612-travisDistDirCheck) https://github.com/bitcoin/bitcoin/pull/9416
17:19 < gmaxwell> I finally figured out why I wasn't getting any github emails.
17:21 < midnightmagic> Whyzzat
17:26 < gmaxwell> I configured an email rule to put them in another folder...
17:27 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
17:28 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
17:31 < morcos> gmaxwell: that sucks..  i only get like half of github notifications as emails..  and i was less bothered by the fact that not only i was affected
17:31 < gmaxwell> well I still may be only getting half.
17:32 < gmaxwell> But I'm not getting none.
17:39 < MarcoFalke> except: pass
17:39 < MarcoFalke> why is this still a thing?
17:41 < midnightmagic> haha
17:44 -!- AaronvanW [~aaronvw@unaffiliated/aaronvanw] has quit []     
17:45 < luke-jr> gmaxwell: why does #8775 need rebase? O.o
17:45 < gribble> https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
17:47 < gmaxwell> why is that linking issues?
17:48 -!- cbits [~cbits@2607:f380:a61:650:b850:7958:8812:7d7d] has quit [Ping timeout: 255 seconds]     
17:48 < gmaxwell> luke-jr: ask git, not me, it doesn't apply cleanly to master.
17:48 < gmaxwell> (git am -3 <patch> fails)
17:49 < luke-jr> gmaxwell: I ask only because both git and github merge it cleanly :x
17:50 < gmaxwell> gah whitespace errors
17:51 < gmaxwell> MarcoFalke: does your git diff not show crazy whitespace as wads of red? 
17:52 < MarcoFalke> It does
17:52 < gmaxwell> K. #9297 added big wads of end of line whitespace.
17:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9297 | Various RPC help outputs updated by Mirobit · Pull Request #9297 · bitcoin/bitcoin · GitHub
17:52 < gmaxwell> no biggie.
17:52 < gmaxwell> Just wanted to make sure you could see it-- used to be that you had to configure it that way, but I think its a default now.
17:53 < gmaxwell> luke-jr: just catches fire here. 
17:53 < gmaxwell> fatal: sha1 information is lacking or useless (src/wallet/rpcdump.cpp).
17:53 < gmaxwell> error: could not build fake ancestor
17:53 < gmaxwell> Patch failed at 0007 More tightly couple EnsureWalletIsAvailable with GetWalletForJSONRPCRequest where appropriate
17:54 < MarcoFalke> At some point I feel we need to merge a pull. It can't be always free of µnits...
17:54 < MarcoFalke> We have more pressing issues right now.
17:54 < luke-jr> gmaxwell: what if you use git-merge? could you have an old branch?
17:55 < MarcoFalke> But otoh I understand. Someone will fix it some day...
17:55 < gmaxwell> luke-jr: that is in a current checkout vs the patch from github.
17:55 < gmaxwell> MarcoFalke: I wasn't critizing, just making sure you could see it, so at least you were making the decision rather than just unaware. :)
17:55 < MarcoFalke> ok     
17:56 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
17:57 < luke-jr> gmaxwell: looks specific to git-am. merging it normally works
17:59 < gmaxwell> okay, well I'm not testing it unless it merges with git-am.
18:01 < luke-jr> ok, rebased and seems to work now
18:02 < gmaxwell> YUP!
18:02 < gmaxwell> thanks.
18:08 -!- cbits [~cbits@139.182.205.179] has joined #bitcoin-core-dev     
18:11 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
18:16 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 258 seconds]     
18:21 < fanquake> If anyone has some more info they could contribute to #8639, it would be appreciated. There's probably enough there now to turn it into some docs, but filling in a few more gaps would be handy. i.e minimum required openssl.
18:21 < gribble> https://github.com/bitcoin/bitcoin/issues/8639 | [Docs] Minimum required dependencies and current CVEs · Issue #8639 · bitcoin/bitcoin · GitHub
18:22 < sipa> for non-qt we only need openssl for the PRNG
18:23 < sipa> which i think means very old versions will work
18:23 < sipa> not sure if we should suggest that, though
18:25 < gmaxwell> and our use of it in the rng could darn near be replaced with rand()
18:25 < fanquake> Should we be suggesting use of the 1.0.1 series at all if it's out of support? Or is that irrelevant here.
18:26 < fanquake> We are currently using 1.0.1k in depends.
18:27 < gmaxwell> fanquake: virtually every linux distribution is 1.0.x something, 1.1 changed the API in incompatible ways. We're compatible now, but it would be weird to suggest software that no one has.
18:28 < MarcoFalke> How come that doxygen still has main.cpp?
18:28 < MarcoFalke> https://dev.visucore.com/bitcoin/doxygen/main_8cpp_source.html
18:28 < MarcoFalke> Generated on Wed Jan 11 2017
18:28 < MarcoFalke> We killed that last year
18:29 < fanquake> gmaxwell ok, thanks.
18:29 < gmaxwell> MarcoFalke: whatever is generating it is on a forked repository? 
18:30 < achow101> apparently decoderawtransaction is not decoding segwit txs properly: https://bitcointalk.org/index.php?topic=1748353.msg17477509#msg17477509
18:30 < MarcoFalke> ^ wumpus can you take a look at doxygen, please?
18:34 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]     
18:38 < gmaxwell> achow101: The issue is that segwit txn deseralizes as a 'crazy' non-segwit txn-- one with zero input transactions.
18:38 < gmaxwell> achow101: the decodehex tries to decode as non-segwit first and then segwit, but that txn successfully decodes.
18:39 < achow101> is that just bad luck then that it is able to successfully decode as non-segwit first?
18:39 < gmaxwell> well could be bad luck or you could construct ones that way,  in the actual protocol sw and non-sw txn are handled distinctly not by trying to decode both ways.
18:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
18:39 < gmaxwell> achow101: I believe that an acceptable solution is to just make that first try fail if the number of inputs is zero.  But this actually would reduce the functionality of raw transactions slightly, because passing around an inputless raw transaction isn't totally absurd.
18:40 < gmaxwell> But I think that is likely the correct fix.
18:40 < gmaxwell> or most correct.
18:40 < sipa> didn't we fix that already?
18:40 < gmaxwell> sipa: for decoderawtransactions?  my description is from reading the current code.
18:41 < achow101> what use case is there for 0 input txns?
18:41 < gmaxwell> an alternative would be to reverse the trial order, so it won't even try nonwit unless witness fails. 
18:42 < gmaxwell> achow101: I can use them as a payment request, for example... give you a txn with the outputs I want, leave it up to you to add inputs (and change, if required.)
18:42 < sipa> raw transactions are more often used for unsigned transactions
18:42 < sipa> which by definition aren't segwit
18:42 < achow101> oh     
18:43 < sipa> once they're signed, they're usually complete
18:43 < sipa> but it's unfortunate that there is ambiguity
18:43 < sipa> we should propose some 'partially signed' transaction format 
18:43 < sipa> that's unambiguous
18:43 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
18:44 < sipa> but has place for metadata etc
18:44 < gmaxwell> well in particular, amounts and scriptpubkeys.
18:44 < achow101> gmaxwell: what about having decoderawtx take a parameter to tell it to decode as segwit or non
18:44 < gmaxwell> achow101: thats a bit ugly.
18:44 < achow101> and have that somehow be related to soft fork activation
18:44 < gmaxwell> achow101: thats more than a bit ugly. :P
18:47 < sdaftuar> sipa: gmaxwell: does decoderawtransactions need to handle the 0 input case?  i remember discussing this for fundrawtransaction, where 0 inputs does make sense, but not obvious to me that decode should accept a 0-input tx?
18:47 < gmaxwell> sdaftuar: sure, except for this bug.
18:47 < gmaxwell> just shows now inputs.
18:48 -!- face [~face@94.26.41.139] has quit [Ping timeout: 240 seconds]     
18:48 < gmaxwell> I suppose it being unwilling wouldn't be the end of the world.
18:48 < sipa> decoderawtransaction and fundraetransaction both attempt old and new deserialization
18:48 < gmaxwell> it's not like I could sign a zero input transaction.
18:49 < sipa> but they only accept the old serialization if it exactly matches the string
18:49 < sipa> (no undecoded garbage at the end)
18:49 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev     
18:49 < gmaxwell> So I think it would be okay if decoderaw would not decode zero input.   But fundraw needs to read zero input, and this transaction example decodes both ways.
18:53 < achow101> changing decodehextx in core_read.cpp will also affect sendrawtx. but that shouldn't be an issue since a 0 input tx isn't valid
18:54 < sipa> decodehextx gets a bool arg
18:54 < sipa> to indicate if non-extended format decoding should be attempted
18:55 < sipa> only decoderawtx and fundrawtx set that bool to true
18:55 < gmaxwell> that should be false for sendraw.
18:55 < sipa> it iz
18:55 < sipa> it is
18:55 < gmaxwell> iz was okay too.
18:56 < sipa> i zhall rezord do uzing voized vowelz vrom now on
18:56 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
18:56 < gmaxwell> oh dear.
18:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
18:57 -!- arowser [~quassel@106.120.101.38] has quit [Client Quit]     
18:59 -!- Kexkey [~kexkey@184.75.212.157] has joined #bitcoin-core-dev     
19:00 < sdaftuar> gmaxwell: in #8456, we can replace a bumped transaction, so i don't think we should always mark the replacement as non-replaceable.  i agree with your second reason for wanting the ability though.
19:00 < gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
19:00 < sdaftuar> bumper* transaction
19:02 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
19:03 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has quit [Ping timeout: 248 seconds]     
19:03 < morcos> i think it would make the most sense to have the replacement tx inherit -walletrbf setting , but also add an option to explicitly set it...
19:04 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
19:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
19:04 < morcos> we never settled on a way to do that, but now with usings the options argument or named arguments to rpc, its easy enough to just add an rbfflag option to sendtoaddress, sendtomany, and bumpfee
19:05 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
19:06 < morcos> i suppose for starters having it inherit the -walletrbf setting is a very minor change and allows you to do anything you want if you're willing to restart your node
19:06 < sdaftuar> seems reasonable to me
19:08 < bitcoin-git> [bitcoin] achow101 opened pull request #9522: [RPC] Fix decoderawtransaction decoding of segwit txs (master...fix-decoderawtx) https://github.com/bitcoin/bitcoin/pull/9522
19:08 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]     
19:11 < sipa> achow101: the bool arg to decodehextx should probably be changed to being an enum, with extended_only, prefer_extended, prefer_normal
19:11 < sipa> instead of basing it on hex bytes
19:12 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
19:13 < achow101> it would still have to be based on the hex bytes to know when each one should be done though
19:13 < sipa> no     
19:14 < sipa> you've just implemented a "prefer extended" stratwgy
19:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
19:15 < achow101> but then how do you know which strategy to choose?
19:16 < sipa> decoderawtransaction would use prefer extended
19:16 < sipa> fundrawtransaction would use prefer olf
19:16 < sipa> all the rest would be extended only
19:16 -!- baldur [~baldur@209.95.50.137] has joined #bitcoin-core-dev     
19:16 < achow101> oh.     
19:16 < sipa> that's what you have implemented now
19:16 < achow101> I see
19:18 -!- Kexkey [~kexkey@184.75.212.157] has quit [Remote host closed the connection]     
19:20 < achow101> I can make that change
19:27 < sipa> actually
19:28 < sipa> what if you just pass false to decodehextx in decoderawtransaction?
19:28 < sipa> i believe the behavior will be the same as what you have now
19:29 < achow101> then it will be decoding all transactions as extended
19:30 < sipa> yes     
19:30 < sipa> that's what you want, no?
19:31 < sipa> the extended format for transactions without witness is identical to the old format
19:31 < achow101> right
19:31 < achow101> yes, that should work.
19:32 < achow101> why was it passing in true originally then?
19:33 < sipa> to pick old decoding in case it was ambiguous
19:34 < sipa> which is what you want for fundrawtransaction
19:34 < sipa> but perhaps not for decoderawtransaction
19:34 < sipa> i'm not sure, it's choosing between two suboptimal options
19:44 -!- cbits [~cbits@139.182.205.179] has quit [Ping timeout: 252 seconds]     
19:45 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]]     
19:46 < ZhibiaoPan> https://www.blocktrail.com/tBTC/tx/042e9225966258ec7d133d90a978d21ef1d7e4edc4800331a80f73f2d71316d8
19:46 < ZhibiaoPan> Mining Fee is -1.40625000 tBTC
19:46 < adiabat> ZhibiaoPan ... it's a coinbase tx
19:47 < ZhibiaoPan> CheckBlock() didn't check the block reward and mining fee?
19:47 -!- robmcl4 [ad315d5e@gateway/web/freenode/ip.173.49.93.94] has joined #bitcoin-core-dev     
19:47 < achow101> the output of a coinbase can be less than the reward that the miner is entitled to
19:47 < achow101> those coins are then just permanently missing
19:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:09 < wumpus> marcofalke: good catch, the script that is supposed to update it was not able to fetch the repo
20:14 -!- cbits [~cbits@139.182.205.179] has joined #bitcoin-core-dev     
20:17 -!- chris2000 [~chris2000@p5082AE70.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:20 -!- chris200_ [~chris2000@p5DCB51AC.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]     
20:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
20:23 -!- officia||eibniz [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
21:03 < btcdrak> ZhibiaoPan: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1876-L1881
21:06 -!- robmcl4 [ad315d5e@gateway/web/freenode/ip.173.49.93.94] has quit [Ping timeout: 260 seconds]     
21:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:20 < BlueMatt> cfields: hum, I owe you an apology - I dont think that issue is gonna go away by changing the threading stuff - I think the "unlock cs_main prior to ActivateBestChain" stuff is going to have to stay because it is the only way to let things which will be quick but need to check something against cs_main and want to run on NewPoW... run
21:20 < BlueMatt> I fixed your specific complaint (the read-block-from-disk one) by simply using the most_recent_block shared_ptr that was already lying around, but I get that thats not really a fix for your general comment of adding complexity
21:22 < cfields> BlueMatt: yea, i almost suggested that, but it would just kinda mask the issue (usually)
21:22 < cfields> BlueMatt: to be clear, i'm not worried about the disk access _at all_
21:22 < BlueMatt> I know
21:22 < BlueMatt> I am, though, so thanks for reporting :p
21:23 < cfields> was just using it as an example
21:23 < cfields> heh     
21:23 < BlueMatt> i mean it fixes your specific issue, but I'm really not a fan of the BlockUntilBlockIsWhereIWant in the net code
21:23 < BlueMatt> I know, I know
21:23 < cfields> BlueMatt: well if you're not a fan of that, certainly you're not a fan of ActivateBestChain there either :)
21:24 < BlueMatt> no, I'm specifically not a fan of BlockOnThing() over DoTheThingIWantToBlockOn()
21:24 < cfields> i see
21:24 < BlueMatt> wellllll, hum
21:24 < BlueMatt> now that i say that
21:24 -!- xinxi [~xinxi@116.87.187.139] has quit [Remote host closed the connection]     
21:25 < cfields> no, you're not doing anything in either action. Either way it's being treated as a fence.
21:25 < BlueMatt> well we need a fence primitive for wallet to fix #9148
21:25 < gribble> https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
21:25 < cfields> er, "not doing anything" is a very poor choice of words, that's obviously not what i meant
21:26 < BlueMatt> I mean I feel kinda yucky doing this because what if some braindead caller calls AcceptBlock without ActivateBestChain?
21:26 < BlueMatt> we then call the fence and freeze forever
21:26 < BlueMatt> is my concern
21:27 < BlueMatt> same applies for wallet, though....
21:27 < BlueMatt> hence my comment on prefering FenceButFeelFreeToDoWorkToGetThere
21:27 < BlueMatt> which is what ABC is to me, here, i guess
21:27 < cfields> BlueMatt: i was just picturing: at the top of ABC, working=true. at the bottom, working=false
21:28 < cfields> nasty hack, but that's what you really want to know, right?
21:28 < BlueMatt> no, you'd need to do that in ProcessNewBlock
21:29 < cfields> not for your purposes, i think? It's ABC that would trigger the callback to push out the message, no?
21:29 < cfields> er, nm
21:42 -!- cbits [~cbits@139.182.205.179] has quit [Ping timeout: 252 seconds]     
21:52 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: ZNC - 1.6.0 - http://znc.in]     
22:01 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
22:25 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
22:31 -!- xinxi [~xinxi@116.87.187.139] has quit [Ping timeout: 245 seconds]     
23:00 -!- dermoth [~thomas@dsl-66-36-128-167.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
23:01 -!- dermoth [~thomas@dsl-66-36-128-167.mtl.aei.ca] has joined #bitcoin-core-dev     
23:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
23:05 -!- xinxi [~xinxi@116.87.187.139] has joined #bitcoin-core-dev     
23:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uubzupkvraxrslps] has joined #bitcoin-core-dev     
23:28 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
23:45 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]     
23:45 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev