--- Day changed Wed Jul 13 2016
00:12 -!- chris2000 [~chris2000@p5DCB4315.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bjpknejpomvlcclh] has joined #bitcoin-core-dev
00:19 -!- chris2000 [~chris2000@p5DCB4315.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
00:19 < GitHub99> [bitcoin] maiiz opened pull request #8336: Issues #8334 (master...issues-8334) https://github.com/bitcoin/bitcoin/pull/8336
00:20 -!- bustd_soket [weechat@gateway/vpn/mullvad/x-ltlwxtmsbpcvfvsm] has joined #bitcoin-core-dev
00:25 -!- murch [~murch@p4FDB706B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:25 < murch> gmaxwell: https://github.com/bitcoin/bitcoin/issues/7664#issuecomment-232230899 <-- I think you meant "is a large multiple" instead of "isn't"
00:28 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
00:29 < jtimon> so NicolasDorier and I are discussing libconsensus
00:29 < gmaxwell> murch: ya, thanks.
00:30 < jtimon> do we want locks inside libconsensus? my understanding was no, due to complexity reasons. NicolasDorier thinks it's fine with std C++11 but it wasn't fine with boost
00:31 < jtimon> well, personally I think libconsensus should move towards plain C, but that's another discussion it seems I lost already
00:32 < sipa> jtimon: i was talking about this with NicolasDorier earlier
00:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:33 < sipa> jtimon: i expected that the point of contention would be the idea of it managing its own state
00:33 < sipa> (which would imply using locks for that state)
00:33 < NicolasDorier> ah yes you wanted to keep the libconsensus "stateless"
00:34 < sipa> i don't know whether it should be stateless - having state, especially for caches, would hugely simplify things
00:34 < sipa> but i think that should be the first thing to discuss
00:34 < sipa> as it using locks or not follows naturally
00:36 < phantomcircuit> sipa: that pr doesn't seem to have improved removeForBlock times by much
00:36 < gmaxwell> phantomcircuit: that means it improved them at all?
00:37 < phantomcircuit> im gonna need to do the mempool save/restor thing to know for sure unfortunately
00:37 < phantomcircuit> if it did it certainly wasn't spectacular
00:38 < NicolasDorier> I'm working right now on a verify_block for consensus lib. (like jtimon doing) I think the question of state won't come immediately to me as I first need to finish that. Once I done my verify_blocks, I'll just make several proposal for handling the hash cache of segwit
00:38 < NicolasDorier> I have several idea, will just try to code them see if they make sense at all :p
00:40 < sipa> NicolasDorier: how does your verifyblock get access to the chainstate and the block index?
00:40 -!- KwukDuck [~chatzilla@82-197-210-65.dsl.cambrium.nl] has joined #bitcoin-core-dev
00:40 < KwukDuck> My Bitcoin Core client keeps crashing since a few days... http://pastebin.com/fiPXrzZY
00:40 < KwukDuck> any ideas?
00:41 < jtimon> sipa: well, I think the interface for the caches can be really simple, and we can provide the implementations we have for those who don't want to implement their own, so I disagree on "hugely simplify things"
00:41 < NicolasDorier> sipa: By cheating, I delegate to the client the calculation of the flags and contextual informations (height, bestblock, mtp)
00:41 < NicolasDorier> such that all the consensus code does not depends on CBlockIndex at all
00:42 < NicolasDorier> but just to 2 types
00:42 < phantomcircuit> KwukDuck, hardware error
00:42 < NicolasDorier> CConsensusContextInfo and CConsensusFlags
00:42 < jtimon> but yeah, my plan has always been to have a C++ version of verifyBlock first, well, I mean, first VerifyHeader, verifyTx...but never got past the point of simply moving the consensus functions out of main...
00:42 < NicolasDorier> both can be calculated by "main" with pIndex trivially. Then passed to consensus methods
00:42 < sipa> jtimon: yes, but that means the api changes whenever a cache is added/changed
00:43 < jtimon> yes, if you add a cache the api changes, not sure what you mean by changing the cache
00:43 < sipa> if it ends up working differently somehow
00:43 < jtimon> just as if the storage changes, the api for the storage would change as well
00:44 < NicolasDorier> I started working on https://github.com/NicolasDorier/bitcoin/commits/blkconsensus but still not done
00:44 < jtimon> assuming people want libconsensus to be storageless
00:44 < sipa> jtimon: yeah, i understand the use case
00:45 < sipa> it's just a lot harder to introduce abstractions for block indexes and chainstate, especially without degrading performance
00:45 < jtimon> I was working on https://github.com/jtimon/bitcoin/commits/jt but I broke the branch when backported bip9 and never cared to fix it (but review is still very welcomed since I plan to rewrite/cherry pick most of the stuff from there)
00:46 < jtimon> my interfaces: https://github.com/jtimon/bitcoin/commit/c97fa96c2f9e8989b9f1a9dd41688e07bcc163b9#diff-c2a099d775bac1dccc5f146a3cda81b8R82 https://github.com/jtimon/bitcoin/commit/34780bd9af20ddf60dd309eff90b9caf01b63f64
00:47 < NicolasDorier> my main problem with interface is that the callback will probably cross language boundary (C++ calling C#) and it is a performance nightmare (but maybe it has gone better now). I'm not against callback but this has to be coarse grained.
00:48 < NicolasDorier> ho I finish my PR I'll see when I hit there
00:49 < KwukDuck> phantomcircuit: Hardware error? Like what..? I think my hardware is fine? Experiencing no other issues with the system, even tried running it on a different disk.
00:49 < jtimon> at least for bitcoin core as a caller (assuming one day bitcoin core directly calls libconsensus instead of its internals) I don't see how performance would be affected very negatively, I worry more about serializing and deserialzing the parameters (like the tx in verify) for example, since people have complained (that's the reason why libbitcoin copies the code instead of using libconsensus' API directly)
00:50 < gmaxwell> KwukDuck: that kind of issue is usually caused by hardware error, lose or bad disk cables, or bad memory (run memtest86?)-- sometimes antivirus software can screw with the files bitcoin is using.
00:50 < jtimon> NicolasDorier: as said privately, I think people should use the function pointer to call their DB directly, not calling their external language there, but you said that may be complicated too
00:51 < gmaxwell> or running out of disk space potentially.
00:51 < NicolasDorier> jtimon: yes, it really depends on the backend technology. Some might have poor support of C lib. :(
00:52 < KwukDuck> gmaxwell: I considered a bad disk that's why i ran it on another one. Not sure about the memory though, but i'm not experiencing any other issues so... I guess i'll be running memtest later. Thanks :)
00:52 < NicolasDorier> also I know I'm not pro in C so it would take me 10 times  more than you to make use of a C lib even if it existed
00:53 < jtimon> on another topic, should utilmoneystr be part of libconsensus only for this line or should we just write the message in satoshis? https://github.com/bitcoin/bitcoin/pull/8329/files#diff-ca81084f62961a188f5c1e86a5ff1d7cR238
00:53 < jtimon> maaku things yes it should be part of libconsensus, I'm not very convinced
00:53 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
00:55 < jtimon> if we're sure about it belonging in libconsensus, I should squash https://github.com/bitcoin/bitcoin/pull/8329/commits/8af7c64f6908ea4526efde9896d046c431016e00 in #8328
00:55 < jtimon> NicolasDorier: thoughts ?
00:57 < NicolasDorier> checking that a sec
00:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
00:58 < NicolasDorier> jtimon: well, I think the smaller the diff the better, so I am more inclined to keep it for now, but not really strongly neither
01:01 < jtimon> well, if I keep it and move it to the consensus dir, that actually makes the diff bigger
01:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
01:16 -!- DigiByteDev [~JT2@128.90.115.240] has joined #bitcoin-core-dev
01:20 -!- DigiByteDev [~JT2@128.90.115.240] has quit [Client Quit]
01:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
01:37 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has joined #bitcoin-core-dev
01:37 -!- AaronvanW [~ewout@220pc230.sshunet.nl] has quit [Changing host]
01:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:41 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:53 -!- chris200_ [~chris2000@p5DCB4315.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:43 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
02:55 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
03:04 -!- ArthurNumbanumba [~ArthurNum@h247079.upc-h.chello.nl] has joined #bitcoin-core-dev
03:22 -!- YOU-JI [~youyouyou@q046244.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-core-dev
03:33 < jonasschnelli> sipa, gmaxwell: mind doing a review of https://github.com/bitcoin/bitcoin/pull/8323? I'd like and I think its important to have this in 0.13
03:41 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
03:45 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
03:55 -!- xinxi_ [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
03:57 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 276 seconds]
04:17 < jonasschnelli> sipa, gmaxwell: maybe you find time to quickly review the BIP151 switch from HMAC_SHA512 "KDF"  to HKDF: https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/bip151_hkdf?expand=1
04:30 -!- assder [82eb8819@gateway/web/freenode/ip.130.235.136.25] has quit [Ping timeout: 250 seconds]
04:31 -!- harrymm [~wayne@37.58.59.81] has quit [Ping timeout: 250 seconds]
04:34 -!- davidlj95 [~davidlj95@deic-dyn-232.uab.es] has quit [Remote host closed the connection]
04:39 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
04:42 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
04:43 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds]
04:43 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 258 seconds]
04:46 -!- harrymm [~wayne@178.162.199.116] has joined #bitcoin-core-dev
04:47 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
04:57 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:57 -!- cryptapus_ is now known as cryptapus_afk
04:57 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]
05:06 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
05:10 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 258 seconds]
05:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:26 -!- Lysander1 [~Lysanders@unaffiliated/lysanders] has quit [Ping timeout: 240 seconds]
05:40 -!- YOU-JI [~youyouyou@q046244.dynamic.ppp.asahi-net.or.jp] has quit [Quit: Leaving...]
05:43 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
05:48 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
05:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
06:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
06:09 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
06:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
06:15 -!- go1111111 [~go1111111@104.200.154.97] has quit [Ping timeout: 240 seconds]
06:21 < GitHub12> [bitcoin] jtimon closed pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
06:21 -!- arubi__ is now known as arubi
06:26 < GitHub147> [bitcoin] jtimon reopened pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
06:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
06:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host]
06:27 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
06:28 -!- go1111111 [~go1111111@104.200.154.97] has joined #bitcoin-core-dev
06:28 < jtimon> kanzure: NicolasDorier: https://github.com/bitcoin/bitcoin/pull/8337
06:32 < jtimon> and I will continue in https://github.com/jtimon/bitcoin/tree/0.12.99-consensus but I won't open more PRs for now
06:39 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:41 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
06:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
06:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:45 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
06:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
06:50 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
06:54 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:20 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
07:23 -!- kinlo [peter@unaffiliated/kinlo] has quit [Ping timeout: 264 seconds]
07:24 -!- kinlo [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev
07:25 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds]
07:27 -!- bsm117532 is now known as bsm2319171311753
07:27 -!- bsm2319171311753 is now known as bsm117532
07:30 -!- bsm117532 is now known as bsm2357
07:47 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
07:50 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
07:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
07:51 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
08:09 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
08:13 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 276 seconds]
08:21 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:23 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
08:28 -!- arubi__ is now known as arubi
08:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
08:48 -!- fengling_ [~fengling@58.135.95.137] has joined #bitcoin-core-dev
08:53 -!- fengling_ [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
09:24 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev
09:25 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 252 seconds]
09:25 -!- LeMiner2 is now known as LeMiner
09:38 < jtimon> NicolasDorier: it just occurred to me that you can always implement my function pointers interface by pre-filling memory with whatever data you were counting on passing as a parameter. Therefore it will be trivial to offer the all-data-upfront interface you want while using my more generic API inside. The costs will be to reading the pointer to a function, the function and executed it, but the function should be merely a map from
09:38 < jtimon>  your parameters to a pre-filled position in memory. Does that sound accetable to you? no C# inside
09:38 < jtimon> we can offer both interfaces with trivial development costs I think, let's see
09:39 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]
09:42 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
09:55 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:08 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
10:08 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
10:12 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gaming, m8]
10:32 < jtimon> just force pushed 0.12.99-consensus
10:33 < jtimon> but I will force push again soon
10:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:44 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
10:51 -!- fifth_ [~fifth@80.215.138.48] has joined #bitcoin-core-dev
11:07 -!- fifth_ [~fifth@80.215.138.48] has quit [Ping timeout: 272 seconds]
11:08 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
11:15 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has left #bitcoin-core-dev ["Leaving"]
11:30 < bsm2357> I expect a common error for people using python-bitcoinlib will be to call SignatureHash with the scriptPubKey of the corresponding segwit input, rather than an actual script.  This is easy to detect, and insert the corresponding script for calculating the sighash, but causes the SignatureHash function to depart from the behavior of the one in core.
11:30 < bsm2357> What are your opinions?  Is detecting this and inserting the correct script desirable or not?
11:33 < bsm2357> Hmmm.  Taking this question to #bitcoin-dev.
11:34 < sipa> bsm2357: perhaps also good to discuss on the repository itself in an issue
11:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
11:35 < bsm2357> Of course.  I'll push my latest there soon with a working SignatureHash.  Just looking for some quick feedback from people who might use it, before I go write code.
11:41 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev
11:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:53 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
11:58 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:03 < Chris_Stewart_5> Is it unusual for nodes to give back one ip address back for a getaddr message?
12:05 < sipa> we only respond to one getaddr per connection
12:05 < sipa> after that, only normal addr relay
12:06 < Chris_Stewart_5> Ok, but it it unusual to respond with only one ip address? The behavior I am seeing is connecting to a node, I send a getaddr message, then I only get ONE ip address back in the addr message
12:07 < Chris_Stewart_5> and that ip address is the node's ip address. I guess I was under the impression that it would send back the nodes that it is connected to
12:07 < sipa> it's not responding at all
12:07 < sipa> the addr you see is likely just an independently relayed addr
12:08 < sipa> hell no, nodes try to hide who they are connected to
12:08 < xinxi_> jtimon: are you still there?
12:09 < Chris_Stewart_5> so how do you connect with more than one node on the network then? It seems that you could only connect to dns seeds then. 
12:10 < sipa> i don't understand the question
12:10 < sipa> normally, you get 1000 IP addresses back in response to getaddr
12:10 < sipa> unless the peer does not know about many, of course
12:10 < Chris_Stewart_5> I should preface this with it is testnet, perhaps the behavior is different? 
12:10 < sipa> it's very likely that on testnet the peer just does not know about many peers
12:11 < jtimon> xinxi_: yes
12:11 < sipa> also, if you send getaddr multiple times, the second and later times it is just ignored
12:11 < xinxi_> jtimon: great. I want to discuss with you about the libconsensus that you are working on.
12:11 < xinxi_> it's a great project. 
12:12 < jtimon> xinxi_: absolutely, always interested in discussing that
12:12 < Chris_Stewart_5> sipa: I found that out the hard way :-). But it seems unlikely that a response to a getaddr message would have just ONE ip address even on testnet, right? 
12:13 < xinxi_> my I know when this will be merged into the master branch?
12:14 < jtimon> xinxi_: right now the longest branch I have is https://github.com/jtimon/bitcoin/tree/0.12.99-consensus but I still have things to cherry pick from https://github.com/jtimon/bitcoin/commits/jt (plus some things that will just have to be new)
12:15 < jtimon> xinxi_: uff, no idea myself, I wish I knew, I believe the idea is focusing on refactors like this and the ones going on in net.o and wallet right after forking 0.13's branch, which should be soon
12:16 < jtimon> whether the PRs will be merged or not, I cannot know, depends on review
12:16 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 250 seconds]
12:16 < xinxi_> does libconsensus include the wallet and the network parts?
12:16 < jtimon> no
12:16 < jtimon> but there's other people doing refactors both in the net and wallet parts
12:17 < jtimon> ie cfields and jonasschnelli respectively
12:17 < morcos> sipa: i think on machines with a lot of cores, the sig cache actually slows down block validation.   my guess is its the contention on the lock since we erase every time
12:17 < morcos> sipa: i think it might be better to batch erase, or randomly erase or something else
12:18 < cfields> morcos: i've scratched my head at that one several times. seems we'd be better off nuking a bucket at a time or so
12:18 < xinxi_> jtimon: cool. so all the code in libconsensus is in this directory https://github.com/jtimon/bitcoin/tree/0.12.99-consensus/src/consensus, right?
12:18 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
12:19 < morcos> cfields: it defaults to nuking a bucket at a time if it gets full anyway (although i'm not sure thats super efficient either, but that tends to happen in ATMP, so who cares)
12:19 < jtimon> morcos: I once tried with a huge sigcache just to see if the swap partition was working. didn't benchmarked but it certainly didn't seem to accelerate things
12:19 < cfields> morcos: eh? i thought it just killed a single entry each time
12:20 < jtimon> xinxi_: no, there's still some in main.cpp, but the idea it's that it all should end up there (without counting the code in src/crypto and libsecp256k1)
12:20 < cfields> morcos: looks to me like it just picks a random bucket and removes the first entry in it. am i misreading?
12:20 < morcos> cfields: the problem i'm referring to is that on validating a block, you erase each stored signature as you read it
12:20 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
12:21 < morcos> but yes, if it's gotten to big anyway, then it'll pick a random bucket and remove entires until its below the limit, but isn't that what you said?
12:21 < jtimon> I will keep updating jtimon/0.12.99-consensus moving more things there though
12:21 < xinxi_> jtimon: I guess most of the work has already been done?
12:21 < Chris_Stewart_5> sipa: also you said it can relay 1000 addresses at a time, doesn't that effectively give a history of the nodes they are connected to?
12:22 < morcos> the second thing happens when trying to set a new entry, which is in ATMP, so not important to shave micros... as it is in block validation
12:22 < sipa> Chris_Stewart_5: nodes typically know way more 1000 addresses
12:22 < sipa> Chris_Stewart_5: and typically know of many addresses they are not currently, or even never have been, connected to
12:22 < Chris_Stewart_5> sipa: So basically caching addresses from addr messages?
12:22 < sipa> Chris_Stewart_5: yes, and from dns seed responses
12:22 < Chris_Stewart_5> unsolicited ones
12:23 < sipa> Chris_Stewart_5: that's addrman
12:23 < cfields> morcos: ah yes, i was talking about the full case
12:23 < xinxi_> jtimon: we plan to prove the correctness of the consensus part.
12:24 < sipa> xinxi_: again, correctness compared to which specification?
12:24 < morcos> cfields: yeah the problem is lock contention on validation since each of your script validating cores is contending on the sig cache lock since they each have to erase from it.  if you eliminate or batch those erases, it speeds up validation significantly
12:24 < jtimon> xinxi_: well, the part of making a complete verifyBlock, I would say it has been done several times. exposing it as a C API is another thing, specially since probably the APIs will be discussed extensively (plus I never decoupled Consensus::Params from uint256)
12:24 < sipa> morcos: interesting
12:24 < xinxi_> sipa: as discussed, we are going to derive a specification from the code.
12:25 < jtimon> xinxi_: interesting
12:25 < sipa> xinxi_: a specification derived from the code will by definition match the code, no? :)
12:25 < Chris_Stewart_5> sipa: Is there documentation for addrman any where? Doesn't seem to be in the p2p networking part: https://bitcoin.org/en/developer-reference#p2p-network
12:25 < sipa> Chris_Stewart_5: in addrman.h :)
12:25 < jtimon> sipa: I guess the goal is that from then on you can't change the code without appropriately changing the specifications or the tests will fail
12:25 < sipa> jtimon, xinxi_: yes, that would be awesome
12:25 < cfields> morcos: hmm. ignoring larger fixes, if the contention is that high, i wonder if the shared lock is doing more harm than good
12:26 < xinxi_> sipa: i would say it's going to match the code as much as possible unless we find bugs/inconsistencies in the specification. 
12:26 < sipa> xinxi_: then the specification is wrong
12:26 < jtimon> hehe
12:26 < sipa> (but it would still be very interesting to know)
12:26 < jtimon> the specification is clearly my branch
12:26 < xinxi_> sipa: yeah, as discussed, we don't want to have a specification with flaws or bugs. if we find that, we should upgrade.
12:27 < sipa> xinxi_: i think you're dreaming if you think that's going to happen
12:27 < morcos> sipa: on my 16 core machine, i think it speeds up the "Connect total" part by about 40% to just not erase..   But I didnt' run that over a long enough period to model the lower hit rate that'll eventually result from not having smart erasing.  If we can conveniently batch the erases from the block that'll be best
12:27 < xinxi_> sipa: why is that?
12:27 < xinxi_> a hard fork is not possible?
12:27 < sipa> xinxi_: because i expect a hard fork to switch to something with only theoretical advantages to be very controversial
12:28 < xinxi_> sipa: well, we will definitely test that first.
12:28 < cfields> morcos: whoa
12:28 < jtimon> xinxi_: yes, but a hardfork doesn't magically get deployed in all computers when you update the specification, whatever is deployed is the specification in practice
12:29 < sipa> xinxi_: not trying to discourage you... i would be very exciting if you can contribute to the correctness of the system using formal proofs, at whatever level
12:29 < sipa> xinxi_: but please... keep it about analysing the actual code
12:29 < sipa> *excited
12:29 < xinxi_> sipa: the actual code is in C++, which is almost impossible to prove.
12:30 < xinxi_> if you rewrite it in C, we may be able to help.
12:30 < sipa> even that has been controversial in the past
12:30 < jtimon> xinxi_: in the end the new tests are going to fail when you change either the specification or the implementation, right?
12:30 < xinxi_> jtimon: what do you mean by failure?
12:31 < sipa> xinxi_: you could of course do a rewrite in C, and analyse that... we could learn very interesting things from that
12:31 < sipa> xinxi_: but that still doesn't mean we need to actually switch to that C code
12:31 < jtimon> if you changed the specification, sipa was right, the bug was there, if you change the implementation but you were't expecting change in funtionality, then your changes are wrong
12:31 < xinxi_> jtimon: how did you guys fix bugs in the past I am wondering.
12:32 < sipa> xinxi_: soft forks
12:32 < xinxi_> so you just leave the bugs there?
12:32 < jtimon> let me search for a ccc talk about what I'm thinking you wanted to do
12:32 < sipa> xinxi_: if they're not dangerous and merely annoying.. yes, we have no other choice
12:32 < jtimon> xinxi_: no, sipa answered: softforks
12:32 < sipa> xinxi_: we don't decide the rules of the network
12:32 < xinxi_> OK. so can we just deploy the slightly different bug free version using a soft fork?
12:33 < sipa> maybe
12:33 < sipa> that depends on the kind of changes you want to make
12:33 < jtimon> for example, the code in bip99 fixes a known bug which is not a priority
12:33 < jtimon> but that fix is a hardfork
12:33 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
12:34 < xinxi_> so can you explain to me what kind of changes require a soft fork and what kind of changes require a hard fork?
12:34 < xinxi_> and what's the difference between the hard and soft forks?
12:34 < sipa> xinxi_: everything that leaves things that were previously invalid invalid is a softfork
12:35 < xinxi_> how do you define invalid?
12:35 < jtimon> meh, can't find the ccc video about proving correctness, I though you were coming from there
12:35 < sipa> xinxi_: abstractly speaking, the consensus rules are black box which you feed a sequence of blocks
12:35 < sipa> xinxi_: and it returns whether that sequence of blocks is valid or not
12:35 < jtimon> their "specification" was basically another program for an abstract machine
12:36 < sipa> it cannot depend on the order in which those blocks were received, or whatever earlier states the node went through
12:36 < sipa> xinxi_: a softfork leaves all previously invalid inputs invalid
12:37 < xinxi_> so a soft fork can only invalid a previously valid input.
12:37 < sipa> correct
12:37 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection]
12:37 < jtimon> or in other words, it only add restrictions, doesn't remove them: everything that was invalid remains invalid
12:37 < Chris_Stewart_5> xinxi_: You can think of the set of all consensus rules R with cardinality n, a soft fork increments the cardinality of R one. 
12:38 < xinxi_> and a hard fork has no such restriction.
12:38 < Chris_Stewart_5> xinxi_: Any removal from the set R is a hard fork though 
12:38 < gmaxwell> xinxi_: the whole purpose of the system it to come to a consistent worldwide agreement on the history of the ledger. This is the first and foremost definition of correctness in the system.
12:38 < sipa> xinxi_: and it's very surprising how many things are actually possible with softforks
12:38 < xinxi_> sipa: sure, i can imaging that.
12:38 < sipa> xinxi_: one analogy is seeing the consensus rules a block of marble from which pieces are cut away that give the complexity
12:39 < xinxi_> so how do hard forks and soft forks differ in terms of deployment?
12:39 < jtimon> some people theorize that everything that is possible via hardfork is also possible via softfork in some other way, but I'm not convinced that means we should always prefer softforks
12:39 < sipa> a hard fork: convince the whole world to switch to different code; period
12:39 < sipa> a soft fork: read BIP34 and BIP9
12:40 < sipa> (BIP9 is newer)
12:40 < xinxi_> has any hard fork happened?
12:40 < sipa> very early on in the history of the system, yes
12:40 < sipa> in the first 1.5 years
12:40 < jtimon> xinxi_: for softforks miners need to coordinate for deployment, then other nodes can upgrade when they want/can. for hardforks everybody needs to upgrade before deployment, which makes them slower to deploy
12:41 < sipa> xinxi_: there is also BIP50 which is a post-mortem of a consensus failure that occurred between old and new versions of the system
12:41 < xinxi_> jtimon: how can you upgrade without deployment? 
12:42 < xinxi_> basically, you can automatically activate when a certain height is reached?
12:42 < sipa> xinxi_: softforks only apply new rules to blocks after some changeover point
12:42 < sipa> they use old rules for everything before
12:42 < xinxi_> sipa: yeah, you've explained that well.
12:42 < sipa> BIP30 used a fixed timestamp for the changeover point
12:42 < jtimon> xinxi_: for softforks bip9 describes it, for hardforks there's different opinions on what would be the best way to signal activation
12:43 < xinxi_> jtimon: got it.
12:43 -!- d_t [~textual@185.69.203.10] has quit [Read error: No route to host]
12:43 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
12:43 < sipa> BIP34 used block versions above a certain number to let miners indicate they are enforcing the new rules
12:44 < xinxi_> so who makes the final decision on whether a fork should be deployed or not?
12:44 < sipa> xinxi_: for a soft fork: miners
12:44 < sipa> as it's really just miners deciding to start enforcing some additional rules in addition to what the network requires them to
12:44 < sipa> for a hard fork: politics
12:44 < sipa> (let's not go there)
12:45 < xinxi_> the politics between whom?
12:45 < jtimon> xinxi_: here's a few different ways to coordinate activation, the last 3 in there use bip 9 : https://github.com/jtimon/bitcoin/blob/0.12.99-consensus/src/consensus/versionbits.cpp#L172
12:45 < xinxi_> I think it's better to clarify things.
12:45 < petertodd> xinxi_: a hard fork is arguably the creation of a new currency for starters...
12:45 < sturles> xinxi_: All bitcoin users.
12:45 < sipa> xinxi_: some people believe developers or some committee should decide on hard forks, and then assume everyone will follow them
12:46 < sipa> xinxi_: others think hard forks should be reserved for clearly uncontroversial things
12:46 < xinxi_> is there any democratic decision making process?
12:46 < sipa> democracy is pretty hard in a system designed to avoid fixed identities
12:47 < petertodd> xinxi_: there's no agreement on what a "democratic decision making process" even looks like
12:47 < jtimon> bip2 tries to clarify things, but it can only decided on whether something was "accepted" or not observing adoption a posteriori. BIP99 also tries to clarify things, but it's based on a vaguely defined concept of "uncontroversial"
12:47 < xinxi_> sipa: sybil attack.
12:47 < petertodd> xinxi_: whose votes do you count? miner-triggered soft-forks at least have a natural metric: hashing power
12:47 < sdaftuar> 15:43 < sipa> xinxi_: for a soft fork: miners
12:47 < xinxi_> then, can we just let miners vote?
12:47 < sdaftuar> ^ this is not correct, users have to adopt the rules as well
12:48 < sdaftuar> but please, this discussion should be elsewhere
12:48 < jtimon> I wouldn't call that a vote, but just confirmation that they have upgraded
12:48 < jtimon> for coordination
12:48 < sipa> xinxi_: miners should absolutely not be allowed to decide on hardforks (they could for example decide to increase their own reward that way)
12:48 < jtimon> the softfork is supposed to be uncontroversial in the first place
12:48 < xinxi_> sipa: why not?
12:48 < petertodd> xinxi_: "why not?" is a political question...
12:48 < sipa> xinxi_: "who watches the watchmen?"
12:49 < jeremyrubin> xinxi_: probably discuss this on #bitcoin
12:49 < jtimon> sipa: not only they shouldn't not be allowed but they have no power over hardforks in practice, "should" or "shouldn't" is irrelevant here
12:49 < sipa> xinxi_: they're called consensus rules because every user in the system choose to accept them
12:49 < xinxi_> sipa: sure. that's a good reason.
12:49 < sipa> agree, this is getting off topic
12:49 < sipa> sorry
12:50 < jtimon> yep, sorry, #bitcoin I guess
12:50 < xinxi_> well, it's not off topic actually.
12:50 < jtimon> well, it's not really development
12:50 < sipa> it is off topic for the developer of bitcoin core, which is what this channel is about
12:50 < xinxi_> i need to make sure that tremendous amount of effort that could make Bitcoin even greater will be deployed.
12:50 < petertodd> xinxi_: I'd suggest you take that kind of discussion to #bitcoin-wizards at least
12:51 < sipa> xinxi_: if your tremendous amount of effort requires a hard fork, the answer is that nobody can promise you it will happen
12:51 < xinxi_> if there is no certainty but extremely high risk, we will just have to give up.
12:52 < sipa> xinxi_: i think there are very interesting things you can do if you aim at something a bit less ambitious than proofs about the entire consensus system
12:52 < petertodd> xinxi_: if you want certainty, then yes, I'd suggest you give up. but I'd prefer you took sipa's advice
12:52 < xinxi_> petertodd: so you mean i should at least try no matter what the result is?
12:53 < sipa> xinxi_: you can focus on for example just a scripting language... rewriting that part in C would not be very hard, and the result could be very interesting
12:54 < petertodd> xinxi_: I'm just saying, that anything that for any work you do that may require a hard-fork to deploy, you should accept that you may need to create a new currency, economically distint from bitcoin, to deploy your work in production
12:54 < sipa> proofs about its complexity, memory usage, equivalence after certain changes
12:54 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
12:54 < petertodd> xinxi_: whereas if you want high certainty of being able to deploy your work in production on bitcoin, you'll need to set your sights lower to thinks that can be done in a soft-fork
12:55 < xinxi_> sipa: complexity, memory usage, etc are certainly important but not the most critical thing.
12:55 < sipa> xinxi_: also, we can always propose a softfork that effectively delegates validation under certain conditions to a completely new scripting language
12:55 < petertodd> xinxi_: for example basically all my scalability research is stuff that I do knowing full well that it may never be able to be deployed on bitcoin
12:55 < Chris_Stewart_5> sipa: Does it make any sense at all that a dns seed on testnet would only relay one addr from a getaddr message? Sorry if answered already but I'm still unclear on this
12:55 < sipa> xinxi_: which can be implemented in a different language
12:55 < sipa> xinxi_: BIP143 (which we're in the process of finished up) makes that very easy
12:56 < sipa> xinxi_: it's effectively designed to allow new scripting language to be plugged in in a softfork compatible way
12:56 < xinxi_> petertodd: do you have a fulltime job?
12:56 < sipa> xinxi_: there are people working on thinking about improvements that could be made in a new scripting language
12:57 < sipa> xinxi_: and for that, all options are open
12:57 < xinxi_> sipa: why does a scripting language make a difference? 
12:57 < petertodd> xinxi_: I'm a consultant, who works pretty much full time on contracts in this space (including Bitcoin Core development contracts)
12:57 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
12:57 < sipa> xinxi_: by 'scripting' we mean bitcoin Script here, which is the language used inside transaction outputs to describe the condition under which they can be spent
12:57 < sipa> xinxi_: it's not scripting as in bash or python
12:57 < xinxi_> petertodd: So Bitcoin Core developers get paid?
12:58 < sipa> it's a bytecode language inspired by Forth
12:58 < sipa> xinxi_: and arguable, the implementation of that language interpreter is the most complicated piece of the consensus rules
12:58 < petertodd> xinxi_: many do - there's no "bitcoin foundation" that pays core developers, but there's lots of ways to get paid
12:58 < xinxi_> sipa: yeah, i know what you are talking about. but doesn't that require a hard fork?
12:58 < sipa> xinxi_: nope!
12:59 < petertodd> xinxi_: (there is a "bitcoin foundation", but they don't pay anyone, and are essentially bankrupt last I checked)
12:59 < sipa> xinxi_: the basic idea is that we can redefine some of the remaining NOP opcodes in the language
12:59 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:59 < sipa> xinxi_: it goes further than that, but it would lead me to far to explain it all here
12:59 < xinxi_> sipa: i know what you mean.
13:00 < sipa> and redefining NOPs can be done as a softfork
13:00 < sipa> (as can the new script versions introduced by BIP143)
13:00 < xinxi_> sipa: you invalid more blocks syntatically, but you add more semantics.
13:01 < sipa> xinxi_: we basically take a particular script whose meaning was "anyone can spend this", and replace it with a new meaning
13:01 < sipa> aka moving to a new piece of marable
13:01 < sipa> marble
13:02 < xinxi_> now I also have a feeling that softforks can solve all problems.
13:02 < sipa> to give an extreme example... we can switch to a different proof of work function using softforks
13:03 < petertodd> sipa: explain :)
13:03 < sipa> (in a hacky way that likely wouldn't actually work, as it would go against the interest of miners who decide on softforks...)
13:04 < sipa> petertodd: define a height-dependent function that maps difficulty of the old PoW to difficulty of the new one
13:04 < sipa> petertodd: now demand that every block satisfies both PoWs
13:04 < sipa> and choose the function so that the difficulty of the old one becomes almost irrelevant over time
13:04 < petertodd> sipa: eh... that's not "switching" to a different PoW, that's additing an additional PoW
13:04 < Chris_Stewart_5> interesting
13:04 < sipa> of course... in a softfork we can by definition only 'add' rules
13:05 < sipa> but in practice it would mean switching
13:05 < sipa> (this is a contrived example, and not something i'd ever actually propose)
13:05 < petertodd> sipa: also, I'm not sure I'd want to call that a soft-fork, given that the cost for an attacker to attack old clients goes down to zero - I'd limit the use of the term "soft-fork" to things that retain lite-client level security for non-adopting clients indefinitely
13:05 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
13:06 < petertodd> sipa: example: the switch to most-work-chain from bitcoin 0.1's longest-chain rule is something I'd definitely call a hard-fork
13:06 < sipa> petertodd: fair point
13:06 < sipa> interesting... i'm not sure i would see the chain selection rule as a part of consensus
13:06 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
13:06 < petertodd> I certainly would!
13:06 < sipa> it's necessary for convergence... but many things are necessary for convergence, like a working p2p system
13:07 < xinxi_> about soft fork, can you explain to me how it gets deployed and why we can only be more restrictive? 
13:07 < sipa> xinxi_: read BIP9 about how to deploy it
13:08 < petertodd> I could make the chain selection rule be "only headers whose merkle-root end with the byte string 'peter todd'", and we'd quickly e in a situation where far less than 50% of hashing power is sufficient to attack non-adopting clients
13:08 < sipa> xinxi_: why we can only be more restrictive... so that all rules demanded by old nodes remain satisfied by the majority of the hash rate
13:08 < petertodd> sipa: _exactly_: your example fails the "majority of the hash rate" condition
13:08 < sipa> petertodd: interesting
13:08 < sipa> i agree
13:09 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
13:09 < sipa> it is a validation-rule-more-restrictive change then, but not a soft forking change
13:09 < petertodd> sipa: having said that, I think we need a new term for the case where a hard-fork is introduced gradually; maybe staged hard-fork? 
13:10 < sipa> we should name the different types of consensus rule changes after pokemon
13:10  * sipa hides
13:10 < xinxi_> Ha, I see the key is backward compatibility.
13:10  * petertodd glares at sipa
13:10 < petertodd> xinxi_: yup
13:10 < xinxi_> nodes accepted by new nodes should be accepted by old nodes too.
13:10 < sipa> xinxi_: otherwise, any old node will end up not accepting the majority chain
13:11 < xinxi_> that's the easiest explanation to me. 
13:11 < petertodd> xinxi_: you mean, blocks accepted by...
13:11 < xinxi_> petertodd: yep
13:11 < xinxi_> that's a typo.
13:11 < sipa> xinxi_: and the ledger will split in half, where each pre-existing coin becomes spendable on both sides of the fork
13:11 < xinxi_> that's interesting. 
13:11 < petertodd> xinxi_: spendable on both sides of the fork, because the hard-fork _is_ the creation of a new currency
13:12 < xinxi_> do you know COM+ invented by Microsoft? It's also backward compatible.
13:12 < xinxi_> But they can keep releasing new versions of DirectX, which is based on COM+.
13:12 < sipa> yup, just a currency that implicitly assigns the new coins exactly according to how they were distributed at the forking point in the old currency
13:12 < petertodd> xinxi_: heck, I've been asked two or three times now by exchanges and the like to vet their plans for separating UTXO's cleanly onto both sides post-hard-fork, so they can trade/withdraw them separately (likely to be a legal requirement)
13:13 < xinxi_> petertodd: that's funny.
13:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
13:18 < xinxi_> so how to nodes check whether a block is valid or not?
13:19 < xinxi_> do they just check the syntactics? 
13:19 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
13:19 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
13:19 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
13:19 < petertodd> xinxi_: what do you mean by "the syntactics"?
13:20 < xinxi_> i mean the format of the block data.
13:20 < petertodd> xinxi_: you mean, without the context of previous blocks?
13:20 < xinxi_> petertodd: that's unlikely to be true. they need to verify transactions, which are dependent on history.
13:21 < petertodd> xinxi_: indeed
13:21 < xinxi_> petertodd: yeah, so how do they check?
13:21 < sipa> xinxi_: 1) we receive headers and verify them syntactically, and check whether their PoW matches, then check whether they connect to previous headers, and their expected difficulty is correct, then store them
13:22 < xinxi_> how about the block size? the op codes used?
13:22 < petertodd> xinxi_: I'm not clear what you mean by "how" - are you thinking that full nodes check blocks differently than miners?
13:22 < sipa> xinxi_: 2) we download blocks along the best headers from our peers, and when a block arrives, check it syntactically and that its transactions' hash matches what is in the claimed header we already know; and if so, then store them
13:23 < xinxi_> petertodd: should miners and full nodes use the same set of rules to check blocks?
13:23 < sipa> yes
13:23 < petertodd> xinxi_: if they didn't, how would we ever get miners to enforce rules that we wanted enforced?
13:23 < xinxi_> yeah, that's what I expected.
13:23 < xinxi_> what if a node see a newer version of blocks?
13:24 < sipa> xinxi_: 3) once we have all blocks along a chain whose total work exceeds that of our previous best chain, we look up its input in a database of unspent transaction outputs, validate the scripts, check resource limits, and various other things, ... and if succesful, remove the outputs it spent from the database, and add the outputs it created
13:24 < sipa> xinxi_: what does that mean?
13:24 < petertodd> xinxi_: then a soft-fork may have happened, adding rules to the existing set of rules, so the node should warn the user that the consensus rules enforced by it are no longer complete
13:25 < petertodd> xinxi_: of course, changing the version number for soft-forks is just a nicity - we can't force miners to do that
13:25 < petertodd> xinxi_: (modulo radical redesigns of how bitcoin works, like my client-side validation concepts)
13:25 < xinxi_> i mean, if a Bitcoin client of a very low version sees a block generated by the newest version of Bitcoin client, what will happen? 
13:25 < sipa> xinxi_: it will just accept it
13:25 < sipa> xinxi_: all software down to 0.2.10 should still work
13:25 < sipa> (and that was because of a change in the p2p protocol)
13:26 < xinxi_> so 0.2.10 is a hard fork.
13:26 < petertodd> xinxi_: all that can happen is the node can warn the user that a soft-fork may have happened
13:26 < sipa> xinxi_: nope, it was a p2p change
13:26 < petertodd> xinxi_: not quite, that was a p2p change that can be easily worked around w/o changing the core consensus rules
13:26 < sipa> xinxi_: you could create a bridge between 0.2.9 and the current network
13:26 < xinxi_> based on your definition, soft forks should be backward compatible.
13:26 < sipa> xinxi_: validation of the blocks should be backward compatible
13:26 < sipa> and it is
13:27 < sipa> the 0.2.9 software just doesn't know how to talk to newer clients anymore
13:27 < xinxi_> OK. although the consensus protocol did not change, it's not backward compatible. 
13:28 < xinxi_> how did you guys manage to upgrade from 0.2.9 to 0.2.10?
13:28 < petertodd> sipa: note that the change from longest-chain to most-work was in 0.3.3 https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420
13:28 < sipa> xinxi_: long before my time
13:28 -!- chris200_ [~chris2000@p5DCB4315.dip0.t-ipconnect.de] has quit []
13:29 < morcos> is there really no better channel for this discussion?
13:29 < petertodd> xinxi_: it'd be very easy for people to continue to run nodes that had backwards compatbility with 0.2.9
13:29 < petertodd> morcos makes a good point...
13:29 < sipa> ack, let's move to #bitcoin
13:29 < xinxi_> so this is not even dev related?
13:29 < petertodd> xinxi_: it's covering really basic material
13:30 < xinxi_> but that's still dev. anyway, let's move.
13:30 -!- shatoshi [~legitimo@66-191-253-147.dhcp.kgpt.tn.charter.com] has joined #bitcoin-core-dev
13:30 < shatoshi> INCREDIBLE! Send me some bitcoin and I can turn it into MUCH more, using special blockchain accelerating technology. Your bitcoin wallet will explode! Guaranteed to work & vouched by the OPS. PM me to begin!
13:30 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
13:30 -!- mode/#bitcoin-core-dev [+b *!*legitimo@*.dhcp.kgpt.tn.charter.com] by sipa
13:30 -!- shatoshi was kicked from #bitcoin-core-dev by sipa [shatoshi]
13:30 < morcos> ha ha, you've been replaced by somethign even worse
13:30 < sdaftuar> thank you x 2
13:30 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
13:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:38 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev
13:44 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Ping timeout: 258 seconds]
13:48 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
13:51 -!- harrymm [~wayne@178.162.199.116] has quit [Remote host closed the connection]
13:54 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:56 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
13:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
14:00 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
14:00 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
14:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:16 -!- MiraclePerson [~parson@host86-171-249-63.range86-171.btcentralplus.com] has joined #bitcoin-core-dev
14:16 < MiraclePerson> SUPER!!!! Want more bitcoin? Send me some Bitcoin and I'll instantly send you MORE back. I use special block-chain exploding skills. Totally safe & secure. Vouched by all the OPS! Pm me to begin!
14:16 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
14:16 -!- mode/#bitcoin-core-dev [+b *!*parson@*.range86-171.btcentralplus.com] by sipa
14:16 -!- MiraclePerson was kicked from #bitcoin-core-dev by sipa [MiraclePerson]
14:37 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds]
14:39 -!- xinxi_ [~xinxi@116.86.156.222] has quit [Remote host closed the connection]
14:40 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
14:41 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection]
14:46 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev
14:53 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
14:57 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
15:01 < morcos> sipa: how do you feel about boost::lockfree::queue?
15:02 < morcos> as a proof of concept that solved the lock contention problem really well
15:02 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
15:02 < morcos> jeremyrubin pointed me in this direction, but we weren't sure if this is somethign we wanted in the code
15:02 < morcos> https://github.com/morcos/bitcoin/commit/3e8a10aa78a8a84a44eca9350178ecf7c308c21c
15:07 <@sipa> morcos: interesting
15:07 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
15:07 <@sipa> morcos: alternatively, there could be thread-local lists of entries to erase, that get applied once there are enough
15:08 <@sipa> morcos: though i believe performance of thread locals may be platform dependent
15:08 < jeremyrubin> sipa: lockfree is also platform dependent unfortunately 
15:08 < morcos> sipa: yeah i thought about that, but found the boost thing the easiest to code
15:09 <@sipa> morcos: did you benchmark?
15:09 -!- belcher is now known as beIcher
15:09 < morcos> yes, for validation its equally as fast as not erasing at all
15:09 <@sipa> cool!
15:09 < morcos> so maybe on the order of a 40% speedup
15:10 < morcos> there is the added erase time
15:10 <@sipa> that's much more than i would have expected
15:10 < morcos> but the way i coded it it happens the next time ATMP gets called
15:10 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
15:10 < morcos> well 16 cores, so thats a lot of lock contention
15:10 -!- beIcher is now known as belcher
15:10 < sipa> ah, yes
15:10 < sipa> we should probably also look for ways to avoid sha256 there
15:11 < morcos> the added erase time is small though, maybe 1ms per block, but again happening at a much better time, and a small fraction of the savings
15:12 < jeremyrubin> sipa: we compared to using the iterator, but I think it was negligible
15:12 < jeremyrubin> but with the benefit of not having to check for iterator validity before erase
15:13 < jeremyrubin> (otherwise you would need to construct a set of iterators from the GC-list because concurrent Gets could add the same iter)
15:14 < jeremyrubin> sipa: wait could you clarify which you are referring to re: sha256? the uint256_t on the eviction list?
15:18 < sipa> jeremyrubin: the sigcache stores sha256's of the cached data
15:19 < sipa> sha256 is relatively slow
15:19 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds]
15:20 < sipa> jeremyrubin: no, not talking about erasing... just the cache in general
15:20 < jeremyrubin> sipa: gotcha, should be fine to use siphash right?
15:21 < sipa> jeremyrubin: i'm not sure
15:25 < sipa> jeremyrubin: it's not unreasonable to have a cache size of a billion with certain hardware today
15:25 < jeremyrubin> sipa: if it is salted then it wouldn't be possible to predictably create a block with bad cache lookup performance?
15:26 < sipa> if siphash's security claims are correct, salting should make it unpredictablr
15:26 < sipa> but the 64-bit hash may not be enough
15:26 < sipa> perhaps a 128-bit hash works
15:31 < jeremyrubin> sipa: ttyl
15:43 -!- murch [~murch@p4FDB706B.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
15:47 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
15:48 < gmaxwell> it's quite easy to just create a lockfree queue using atomics. I think bluematt has one in his fibre codebase.
15:48 < gmaxwell> so we don't need to take the additional boost dep if its irritating, or if we do it shouldn't be too hard to get rid of.
15:49 < BlueMatt> https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/udpnet.cpp#L1175
15:49 < BlueMatt> actually lockless ring buffer, but close enough
15:50 < gmaxwell> sipa: we could have a faster wide cryptographic hash, but last I looked low hitrate seemed to be the bigger performance ipediment than the time spent hashing.
15:53 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 252 seconds]
15:54 < sipa> gmaxwell: a sparse hash set would also be much more space efficient
15:55 < sipa> (no malloc for each entry)
15:56 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
15:58 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
16:02 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-wbpeujeikvdvgeah] has joined #bitcoin-core-dev
16:02 < sipa> BlueMatt: interesting!
16:03 < sipa> a ring buffer would suffice here, i guess... if it overflows you can always grab the lock and apply the erases regardless
16:03 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
16:05 < shangzhou> sipa: the bitcoin.sipa.be data looks like not up to date
16:05 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 246 seconds]
16:07 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
16:07 < sipa> shangzhou: oh?
16:08 < sipa> oh, yds
16:08 < sipa> yes
16:08 -!- Guest64966 [~user@94.14.208.33] has joined #bitcoin-core-dev
16:09 -!- Guest64966 [~user@94.14.208.33] has quit [Read error: Connection reset by peer]
16:12 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
16:17 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
16:17 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
16:17 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
16:20 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
16:23 < BlueMatt> thoughts on decreasing transaction-serialization time?
16:23 < BlueMatt> its currently slow as fuck, even when serializing into a static buffer
16:23 < BlueMatt> caching it helps a lot, but eats a decent chunk of memory
16:24 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection]
16:25 < BlueMatt> (and, mostly, caching tx serialization diverges fibre a decent chunk from core, which is annoying)
16:27 < cfields> BlueMatt: working on a few optims to tx right now. not sure how applicable though...
16:27 < cfields> BlueMatt: easy quick gain is lazy hashing
16:28 < BlueMatt> cfields: I said serialization, not deserialization :p
16:29 < sipa> BlueMatt: i think transaction data shoild be stored in a songle malloced buffer, with internal pointers
16:29 < cfields> BlueMatt: oh right, heh. i just assumed you were working on the other direction. nevermind then :)
16:29 < cfields> lazy hashing would be a quick way to slow you down, then :p
16:29 < BlueMatt> what we really should do is calculate the hash at the same time as we serialize/deserialize, since thats easy
16:29 < sipa> BlueMatt: that does require encapsulating all fields though
16:29 < BlueMatt> sipa: yes, that is a bit longer-term, though
16:29 < sipa> agree
16:29 < BlueMatt> but, yea, that would help a ton of things
16:30 < cfields> sipa: speaking of which, after profiling noticing how much time was spent in prevector, i've fixed up copying/moving to be much quicker. you opposed to dinking around in there?
16:34 < sipa> cfields: please do!
16:35 < sipa> cfields: actually, we should make it class safe...
16:35 < cfields> sipa: better, i added static_asserts :p
16:35 < sipa> and use std::move etc instead of realloc etx
16:35 < BlueMatt> cfields: ironically, no, FIBRE is mostly tx copy/serialize - it copies most tx from mempool into a CBlock, and serializes those txn to build the data-FEC chunks from which to calculate the missing chunks
16:36 < BlueMatt> it only ever has to deserialize txn that it missed from mempool (which is relatively few)
16:36 < sipa> BlueMatt: we could also add a means to serialize a block from a list of tx shared_pointers
16:36 < cfields> sipa: i started by special-casing it with enable_if<> and SFINAE, but I think we're better off just specializing for ~std::is_trivial<>
16:37 < gmaxwell> What fiber FECs is not the block directly, but the block with padding to make transactions line up on packet boundaries.
16:37 < sipa> BlueMatt: instead first needing a full deep copy of the tx into the block
16:37 < gmaxwell> er fibre
16:37 < BlueMatt> sipa: who said anything about serializing?
16:37 < BlueMatt> oh, what gmaxwell said
16:37 < BlueMatt> sipa: no, it just deep-copies into the CBlock that it hands to ProcessNewBlock
16:38 < sipa> "FIBRE is mostly tx copy/serializr" -- BlueMatt
16:38 < sipa> BlueMatt: ok, maybe we should just make CBlock have shared_ptr to transactions...
16:38 < BlueMatt> that would help a lot, but it doesnt solve my serialize-time problem
16:38 < BlueMatt> (which is like...all my time)
16:38 < sipa> ok
16:47 -!- adamg [~akg@50.242.93.33] has quit [Ping timeout: 240 seconds]
16:50 -!- adamg [~akg@50.242.93.33] has joined #bitcoin-core-dev
16:51 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
16:54 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds]
16:56 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 240 seconds]
17:00 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:05 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
17:25 < cfields> sipa: https://github.com/theuni/bitcoin/commits/copy-move
17:26 < cfields> sipa: benchmark shows copying is ~100x faster. moving is ~1000x (as there were no moves before, and moves are little more than pointer swapping)
17:28 < cfields> ofc those are suspiciously high. curious to see if others get anywhere near the same numbers
17:28 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
17:29 < phantomcircuit> cfields: how did you benchmark that?
17:29 < cfields> phantomcircuit: benchmark is included
17:30 < phantomcircuit> oh that reminds me
17:30 < phantomcircuit> cfields, can you look at doing a fuzzing framework?
17:31 < phantomcircuit> literally just needs to be an executable that takes input on stdin
17:31 < cfields> phantomcircuit: i thought you were working on one?
17:31 < phantomcircuit> my modifications to the build process to do this didn't seem to work right consistently
17:31 < phantomcircuit> yeah i was and it worked for me but it broke the build process in weird ways i dont understand because autotools
17:31 < cfields> phantomcircuit: oh, you just need the build changes skeleton?
17:31 < phantomcircuit> yeah
17:32 < phantomcircuit> the fuzzing executable itself is pretty trivial
17:32 < phantomcircuit> and i suspect the build changes are trivial too but not for me :)
17:32 < cfields> phantomcircuit: sure, though, you should basically be able to copy Makefile.bench.include
17:32 < phantomcircuit> i tried that first and somehow screwed it up so i ended up copying bitcoin-tx stuff but that's not great cause i actually do want multiple executables
17:34 < cfields> phantomcircuit: you're going to have to lay out exactly what you want. multiple executables gets more complicated
17:34 < phantomcircuit> i could also do it the way i was doing it before which is to make the first few bytes of the fuzzing input select which test to run
17:35 < phantomcircuit> i guess it could also be an executable with cli flags to select which test to run
17:36 < phantomcircuit> having them all be in a single executable isn't ideal for the fuzzer
17:36 < phantomcircuit> gmaxwell, ^ opinions?
17:36 < sipa> cfields: concept ack, i'll review in detail later
17:37 < sipa> on the copy/move
17:37 < cfields> sipa: thanks. if you'd prefer to make it class-safe, i can work on that instead
17:39 < cfields> sipa: but if so, i think it's worth having 2 versions. the POD implementation is much quicker and would suffer if lumped into per-element copies/moves
17:46 < sipa> cfields: i'm impressed by how much faster it id
17:46 < sipa> *it os
17:46 < sipa> ah, but that's move compared to the old placement new based approach?
17:46 < cfields> sipa: you reproduced? or going by my numbers?
17:47 < sipa> going by your numbers
17:48 < cfields> sipa: for move, if malloc'd, all you need to do is copy the pointer. so it's extremely light compared to the previous deep copy
17:49 < sipa> cfields: also, is the script/transaction move constructor/assignment actually invoked anywhere?
17:50 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:50 < cfields> sipa: unsure, but I suspect that there are plenty of places that pass in rvalues ala: myfunction(CScript())
17:52 < sipa> cfields: well, easy enough to create an explocit move constructor and putting a printf or gdb breakpoint in it
17:52 < gmaxwell> phantomcircuit: A single executable can be done, with top level branches. Because of aliasing it may be somewhat less effective than seperate, but I don't think it makes a big deal. Biggest downside is that you can't easily focus further testing.
17:53 < cfields> sipa: oh, if you're asking if the moves are actually resolved, yes, i tested that. in the prevector bench, I added a quick version with the exact same operations. CScript was sped up exactly the same amount.
17:55 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:57 < cfields> sipa: more precisely, I just stuck an assert(0) into the CTransaction move assignment oper, and test_bitcoin aborts right away
18:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
18:13 -!- adamg [~akg@50.242.93.33] has quit [Ping timeout: 264 seconds]
18:14 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 246 seconds]
18:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bjpknejpomvlcclh] has quit [Quit: Connection closed for inactivity]
18:19 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-wbpeujeikvdvgeah] has quit [Quit: Connection closed for inactivity]
18:19 -!- Kexkey [~kexkey@94.242.255.159] has joined #bitcoin-core-dev
18:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:27 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:32 -!- Kexkey [~kexkey@94.242.255.159] has quit [Remote host closed the connection]
18:45 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds]
18:47 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
18:55 -!- Justinus [~Justinus@192.122.131.41] has joined #bitcoin-core-dev
19:06 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
19:26 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev
19:30 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
19:45 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
19:50 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 276 seconds]
20:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
20:48 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 250 seconds]
20:54 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
20:54 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
20:54 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
21:44 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
21:46 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
22:43 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:54 -!- RoyceX [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
22:54 -!- RoyceX [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host]
22:54 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
22:57 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 264 seconds]
23:05 < GitHub118> [bitcoin] NicolasDorier opened pull request #8339: Consensuslib: Block Verify / Transaction Verify [Work in progress]  (master...blkconsensus) https://github.com/bitcoin/bitcoin/pull/8339
23:17 < GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4831a16223db...1bc9c8085f71
23:17 < GitHub69> bitcoin/master 252675e Pieter Wuille: Do not send witnesses in cmpctblock
23:17 < GitHub69> bitcoin/master 1bc9c80 Wladimir J. van der Laan: Merge #8271: [bugfix] Do not send witnesses in cmpctblock...
23:17 < GitHub138> [bitcoin] laanwj closed pull request #8271: [bugfix] Do not send witnesses in cmpctblock (master...nowitnesscb) https://github.com/bitcoin/bitcoin/pull/8271
23:18 < GitHub15> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1bc9c8085f71...4324bd237c31
23:18 < GitHub15> bitcoin/master 36ae37a Bob McElrath: Rename CTxinWitness -> CTxInWitness
23:18 < GitHub15> bitcoin/master 4324bd2 Wladimir J. van der Laan: Merge #8311: Rename CTxinWitness -> CTxInWitness...
23:19 < GitHub181> [bitcoin] laanwj closed pull request #8311: Rename CTxinWitness -> CTxInWitness (master...CTxInWitness) https://github.com/bitcoin/bitcoin/pull/8311
23:21 < GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4324bd237c31...ca40ef6029c1
23:21 < GitHub56> bitcoin/master bb66a11 Suhas Daftuar: Fix DoS vulnerability in mempool acceptance...
23:21 < GitHub56> bitcoin/master 46c9620 Suhas Daftuar: Test that unnecessary witnesses can't be used for mempool DoS...
23:21 < GitHub56> bitcoin/master ca40ef6 Wladimir J. van der Laan: Merge #8312: Fix mempool DoS vulnerability from malleated transactions...
23:21 < GitHub79> [bitcoin] laanwj closed pull request #8312: Fix mempool DoS vulnerability from malleated transactions (master...mempool-malleability) https://github.com/bitcoin/bitcoin/pull/8312
23:33 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev
23:47 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev