--- Day changed Fri Nov 11 2016
00:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:21 -!- testnet [~testnet@gateway/tor-sasl/testnet] has quit [Ping timeout: 245 seconds]     
00:21 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 256 seconds]     
00:21 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
00:22 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev     
00:25 -!- testnet [~testnet@gateway/tor-sasl/testnet] has joined #bitcoin-core-dev     
00:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fhezalfmfirjhoqa] has joined #bitcoin-core-dev     
00:41 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
00:57 < fanquake> Competing pull-requests seems to be a "thing" now..
01:04 <@wumpus> yeah...
01:05 <@wumpus> sure, it can happen that pulls overlap, but I guess one certain person seems to be trying hard to duplicate other people's work
01:07 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
01:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71bc39eb7483...21e6c6b569c5
01:07 < bitcoin-git> bitcoin/master 617c96d fanquake: [depends] Set OSX_MIN_VERSION to 10.8
01:07 < bitcoin-git> bitcoin/master 21e6c6b Wladimir J. van der Laan: Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8...
01:07 < bitcoin-git> [bitcoin] laanwj closed pull request #9114: [depends] Set OSX_MIN_VERSION to 10.8 (master...depends-min-osx-10-8) https://github.com/bitcoin/bitcoin/pull/9114
01:07 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
01:08 <@wumpus> we're better off implementing our own secure random functionality, given how critical it is for the wallet at least
01:09 <@wumpus> at least relying on the C++ library to do the right thing, especially with a new thing (I hadn't heard of std::Random_device before) seems a bad idea...
01:11 < Victorsueca> wumpus: you mean that bitcoin core should have it's own random service like, for example, OpenPGP that uses other computationally intensive processes running on your system?
01:11 <@wumpus> Victorsueca: maybe. At the least we should be reading /dev/urandom ourselves
01:12 <@wumpus> it's not rocket science and there is nothing to be gained by hiding it behind layers of abstraction
01:12 < Victorsueca> sounds good, definitely better than using the default source of randomness which could be backdoored by the hardware manufacturer
01:13 < sipa> if your hardware is backdoored, the technical term for the situation you're in is: utterly fucked
01:13 <@wumpus> that's not really the threat model we're fighting here...
01:13 <@wumpus> right
01:14 < luke-jr> wumpus: I just meant in addition to other entropy sources
01:15 <@wumpus> buggy hardware is more common though, so relying only on hw random instructions is a bad idea no matter how much you trust or don't trust your CPU vendor
01:16 < luke-jr> sure, only reason I even thought of it was seeing GCC's compile checking for /dev/u(?)random for std::random_device  :p
01:17 <@wumpus> there's always talk about backdoored this and that, but in practice there is no need for explicit backdoors in CPUs. They are way too risky from a commercial perspective. There are also so many bugs in hardware and software that no one needs them...
01:17 < luke-jr> just happened to glance at that shell at the right instant
01:17 < Victorsueca> would be nice if someone made a Plug&Play open-source device that you plug into a USB and uses some external sources like temperature with a accuracy of 0.0001, microphone ambient noise, amount of lumens etc... to fill your computer's randomness
01:17 < luke-jr> eh, Intel ME is a pretty low risk explicit backdoor
01:17 < Victorsueca> is the kind of thing I never seen but I think it should already exist
01:18 < luke-jr> Victorsueca: pretty sure something does using radio waves
01:18 <@wumpus> luke-jr: well in any case thanks for letting me know it exists at all, it may be useful for some other projects
01:19 <@wumpus> Victorsueca: those exist and are in active use, both for secure randomness and by gambling sites
01:20 < Victorsueca> wumpus: thought gambling sites used atomic event observation which is pretty expensive devices, I was thinking on something affordable for any home user
01:20 <@wumpus> luke-jr: I mean the "flip a few bits in a certain pattern and gain instand code execution" kinds of backdoors, who needs them if there's bugs like rowhammer :-)
01:20 < luke-jr> heh     
01:21 < Victorsueca> and what if rowhammer is a backdoor and was implemented on purpose?
01:21  * Victorsueca adjusts tinfoil hat
01:21 <@wumpus> Victorsueca: there's low end and high end devices in that range, just a google away :p
01:22 <@wumpus> you can even build a randomness device pretty easily yourself, building unstable hardware is not rocket science :-)
01:23 < Victorsueca> wumpus: maybe, but preventing it from putting your house on fire is ;)
01:23 < Victorsueca> then use the shape of the flames as random source
01:24 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
01:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
01:25 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection]     
01:26 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
01:27 <@wumpus> Victorsueca: meh. I read a report back in the 90's about an evolutionary algorithm being used to optimize code. After some time it found an optimal solution but no one understood how it worked. To the surprise of the researchers it only worked on that specific chip, not others of the same kind. Turns out it was expliting some timing/physical peculiarity of that specific chip. Rowhammer is 
01:27 <@wumpus> similar, though much more general.
01:27 <@wumpus> Victorsueca: physical processes have effects on electronics that are not always taken into account, especially when there's undefined behavior at the instruction level (given timing etc)
01:28 <@wumpus> Victorsueca: ascribing such natural engineering properties to state actors is paranoid to the level of schizofrenia :)
01:29 <@wumpus> *finding* these kinds of bugs on the other hand is something they're certainly working very hard at
01:30 < Victorsueca> they control temperature and humidity to manipulate your randomness
01:30  * Victorsueca puts tinfoil around his parts
01:33 < Victorsueca> jokes apart, Yesterday I had an idea
01:34 < Victorsueca> would be possible to make that after abandoning a transaction core spends the same inputs for the next transaction you make?
01:34 < Victorsueca> I think it's possible, the question would rather be if it makes sense
01:35 <@wumpus> what are you trying to accomplish? if you want to make the transaction impossible to be mined later on you should *immediately* create a new transaction spending them to yourself
01:36 <@wumpus> delaying it until you happen to need to send again creates a potentially huge time window in which you're exposed
01:36 < Victorsueca> I was thinking on somebody who has his transaction stuck because ha paid a low fee
01:37 < Victorsueca> so he abandons the transaction and double-spends it with a higher fee
01:37 <@wumpus> just use RBF?
01:37 < Victorsueca> then why is there a banadon transaction button at all?
01:37 < Victorsueca> abandon*
01:38 < Victorsueca> not to mention RBF is not yet implemented in the GUI
01:39 <@wumpus> bumpfee needs to be on RPC first e.g. see https://github.com/bitcoin/bitcoin/pull/8456
01:39 <@wumpus> all needs review
01:39 <@wumpus> sorry to say this but we need more review and testing on actual work people are doing, not out-there ideas
01:40 < Victorsueca> it's ok
01:41 < Victorsueca> I was thinking that making core automatic input picking to give priority to inputs that have been spent in a abandoned unconfirmed transaction would be easier to review and implement
01:41 <@wumpus> no, it's not
01:41 < Victorsueca> thought so
01:42 <@wumpus> changes to coin selection are one of the most difficult categories of changes
01:46 -!- chris2000 [~chris2000@p5082A627.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
01:46 < Victorsueca> well, I can help testing changes on windows, AFAIK few devs work on windows
01:50 <@wumpus> awesome!
01:50 < fanquake> Great!
01:51 < fanquake> There is always need for more reviewers, especially on Windows, because as you've mentioned, few devs are using it.
01:52 <@wumpus> yes especially for GUI changes there's pretty few testers at all
01:52 < fanquake> If your interested in testing more general issues/changes, there is a decent list of Windows specific issues, some which have been open for > 4 years here.
01:52 < fanquake> https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3AWindows
01:53 < jonasschnelli> For multiwallet, this PR is large but simple to review: https://github.com/bitcoin/bitcoin/pull/8764
01:54 < phantomcircuit> wumpus: the wallet recovery stuff will print a warning if it fails to parse the value in the key/value pair
01:54 < phantomcircuit> this is the last reference to CWallet from CWalletDB
01:54 < phantomcircuit> i have a patch that just removes this
01:54 < phantomcircuit> i'd like to know what you think about it
01:54 < phantomcircuit> (not the patch, removing the warning)
01:54 <@wumpus> please don't remove that warning. You can't move it anywhere else?
01:55 <@wumpus> we have open issues with salvagewallet that's why the debug level there was increased
01:55 <@wumpus> https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20salvagewallet
01:55 < phantomcircuit> ok i'll take another look at it to see if there's a better way of handling that
01:56 < phantomcircuit> (i mean really the better way would be a completely separate tool, but that is not in scope)
01:56 < fanquake> wumpus: I've ack'd #9112 if you just want to merge it.
01:56 < gribble> https://github.com/bitcoin/bitcoin/issues/9112 | Avoid ugly exception in log on unknown inv type by laanwj · Pull Request #9112 · bitcoin/bitcoin · GitHub
01:57 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
01:57 <@wumpus> phantomcircuit: jonasschnelli made such a tool https://github.com/bitcoin/bitcoin/pull/8745  - but yeah that's out of scope
01:57 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
01:57 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
01:57 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:57 < jonasschnelli> wumpus: we first need to solve the cirular dependencies.
01:57 <@wumpus> fanquake: thanks, yes just going to merge it, I think we should have some solution there but I don't want to spend more time discussing details
01:57 < jonasschnelli> *circular
01:59 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21e6c6b569c5...46027e8668ec
01:59 < bitcoin-git> bitcoin/master e9f25dd Wladimir J. van der Laan: Avoid ugly exception in log on unknown inv type...
01:59 < bitcoin-git> bitcoin/master 46027e8 Wladimir J. van der Laan: Merge #9112: Avoid ugly exception in log on unknown inv type...
01:59 < bitcoin-git> [bitcoin] laanwj closed pull request #9112: Avoid ugly exception in log on unknown inv type (master...2016_11_invtype_debugging) https://github.com/bitcoin/bitcoin/pull/9112
01:59 < bitcoin-git> [bitcoin] laanwj closed pull request #9113: Return the type when it's unknown instead of throwing an exception (master...ReturnNotThrow) https://github.com/bitcoin/bitcoin/pull/9113
02:02 < Victorsueca> how do you do to pull a unmerged pull request into your working directory?
02:03 < fanquake> Have a look at the github-merge script in this dir https://github.com/bitcoin/bitcoin/tree/master/contrib/devtools
02:03 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/46027e8668ec...7977a1157a3a
02:03 <@wumpus> contrib/devtools/github-merge.py 1234
02:03 < bitcoin-git> bitcoin/master 47e9659 Russell Yanofsky: [qa] Fix bug in compactblocks v2 merge...
02:03 < bitcoin-git> bitcoin/master 55bfddc Russell Yanofsky: [qa] Fix stale data bug in test_compactblocks_not_at_tip...
02:03 < bitcoin-git> bitcoin/master dac53b5 Russell Yanofsky: Modify getblocktxn handler not to drop requests for old blocks...
02:03 <@wumpus> yes, that :)
02:03 < bitcoin-git> [bitcoin] laanwj closed pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (master...fix-8842-sync-timeouts) https://github.com/bitcoin/bitcoin/pull/9058
02:03 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit []     
02:04 < jonasschnelli> heh     
02:04 -!- fengling [~fengling@123.117.40.78] has quit [Ping timeout: 268 seconds]     
02:04 <@wumpus> you can also do it manually e.g. git fetch upstream pull/1234/head && git checkout FETCH_HEAD  ... this will give you the literal commit instead of a version merged to master
02:05 <@wumpus> (where "upstream" is the name of your remote for bitcoin/bitcoin, big chance it is "origin" for you)
02:05 < jonasschnelli> For testing, it's probably better if you test them applied on the current master
02:05 < jonasschnelli> (unless they have merge conflicts)
02:05 <@wumpus> yes, true
02:14 < Victorsueca> ok, got it, thanks
02:15 < Victorsueca> building it at the moment
02:16 < bitcoin-git> [bitcoin] jonasschnelli pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/7977a1157a3a...ab914a65301b
02:17 < bitcoin-git> bitcoin/master 7c9a98a Jon Lund Steffensen: Allow network activity to be temporarily suspended....
02:17 < bitcoin-git> bitcoin/master e38993b Jon Lund Steffensen: RPC: Add "togglenetwork" method to toggle network activity temporarily...
02:17 < bitcoin-git> bitcoin/master 32efa79 Jon Lund Steffensen: Qt: Add GUI feedback and control of network activity state....
02:17 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
02:17 < Victorsueca> it's me or this new bot is more spammy than the previous one?
02:18 < luke-jr> just you
02:19 < jonasschnelli> Luke-Jr: how do we continue with https://github.com/bitcoin/bitcoin/pull/8889? Close?
02:19 < luke-jr> for now
02:20 < bitcoin-git> [bitcoin] luke-jr closed pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889
02:20 < jonasschnelli> Okay. Yes. We can always reopen this.
02:20 < luke-jr> I suspect the problems were due to tooltips not normally having focus
02:22 < luke-jr> ie, the theme doesn't bother defining the tooltip-with-focus colours sanely
02:25 <@wumpus> there is no 'new bot', I've just changed its configuration to use a consistent name
02:26 <@wumpus> if it seems more spammy it's just because there's a lot of merging going on
02:26 < Victorsueca> ahh ok
02:27 < Victorsueca> 0.14 seems like it's finally going to be a version dedicated to GUI and wallet
02:27 <@wumpus> there is increased activity lately, which is mostly a good thing, though it also means we need to be selective in how much attention we pay to what
02:29 < fanquake> wumpus: If you want to get the PR list down, there are a few trivial ones.
02:29 <@wumpus> fanquake: sure, let me know
02:29 < fanquake> #9115 has been updated so can get ACK'd/merged.
02:29 < gribble> https://github.com/bitcoin/bitcoin/issues/9115 | Mention reporting security issues responsibly by paveljanik · Pull Request #9115 · bitcoin/bitcoin · GitHub
02:30 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab914a65301b...bfc7aad00884
02:30 < bitcoin-git> bitcoin/master 7d1de30 Pavel Janík: Mention reporting security issues responsibly
02:30 < bitcoin-git> bitcoin/master bfc7aad Wladimir J. van der Laan: Merge #9115: Mention reporting security issues responsibly...
02:30 < bitcoin-git> [bitcoin] laanwj closed pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115
02:31 < fanquake> #9064 Should get a yes/no on wether it's going to be to much work for translators, otherwise, can probably be merged. It does include some whitespace changes to line-endings.
02:31 < gribble> https://github.com/bitcoin/bitcoin/issues/9064 | unify capitalization of "bitcoin address" by s-matthew-english · Pull Request #9064 · bitcoin/bitcoin · GitHub
02:32 <@wumpus> ooh capitalizing Bitcoin just now that internet is no longer going to be capitalized :)
02:32 < Victorsueca> heh     
02:33 <@wumpus> I don't really care, I guess it makes sense to be consistent though...
02:34 < fanquake> #8983 Has had some review, but now needs rebasing, and probably some concept ACKs as to if it's wanted. Given it seems to be a WIP it could be closed for now and re-opened when finished.
02:34 < gribble> https://github.com/bitcoin/bitcoin/issues/8983 | WIP: Log block height and size when received by rebroad · Pull Request #8983 · bitcoin/bitcoin · GitHub
02:34 < paveljanik> wumpus, internet and Internet are two different things... ;-)
02:35 < Victorsueca> shouldn't be really difficult to change capitals, except for some languages like German where concepts are one-worded
02:35 <@wumpus> paveljanik: "the internet of different things"
02:36 <@wumpus> it's not "difficult" in any sense of the work, the only thing I'm afraid of is giving people useless busywork in these hard times
02:37 < Victorsueca> not to mention that could cause people blames capitals being wrong, I still remember when someone put "advertize" in the log messages
02:37 < Victorsueca> almost starts WW3
02:38 <@wumpus> capital punishment
02:39 < fanquake> #9124 Is a trivial merge, variable renaming in the benchmarking code.
02:39 < gribble> https://github.com/bitcoin/bitcoin/issues/9124 | Use better name for local variable to prevent -Wshadow compiler warning by paveljanik · Pull Request #9124 · bitcoin/bitcoin · GitHub
02:39 <@wumpus> phantomcircuit: I don't understand why you can't keep a warning in #9101 when the try{...} fails
02:39 < gribble> https://github.com/bitcoin/bitcoin/issues/9101 | [Wallet] Do not parse ssValue in CWalletDB::Recover by pstratem · Pull Request #9101 · bitcoin/bitcoin · GitHub
02:40 <@wumpus> you do catch(...) { continue; } silently ignoring aspecific exceptions is usually a code smell and means there should be a warning at least
02:43 <@wumpus> silent errors mean that someone is going to have a very difficult time troubleshooting at some point
02:44 < Victorsueca> what about make it silent by default but not when -debug is enabled?
02:44 <@wumpus> WHY?
02:44 <@wumpus> salvagewallet is already a troubleshooting option
02:44 < Victorsueca> right
02:45 <@wumpus> why the hell would you want to have people enable debug to see when things go wrong? that's nonsense
02:46 < Victorsueca> maybe somebody who expects salvagewallet to go well doesn't want his logs nuked with lots of lines
02:46 < Victorsueca> if something goes wrong you can always try again with -debug
02:46 <@wumpus> if it goes well there will be no logging because it won't get there!
02:47 < Victorsueca> hmmm I don't know what would I do
02:47 <@wumpus> you're worrying about the bedsprings being noisy on the titanic while it is colliding against an iceberg
02:47 < rabidus_> :DD     
02:47 < Victorsueca> heh yeah
02:48 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfc7aad00884...87ab49e4fe38
02:48 < bitcoin-git> bitcoin/master bf49f10 Pavel Janík: Use better name for local variable to prevent -Wshadow compiler warning
02:48 < bitcoin-git> bitcoin/master 87ab49e Wladimir J. van der Laan: Merge #9124: Use better name for local variable to prevent -Wshadow compiler warning...
02:49 < bitcoin-git> [bitcoin] laanwj closed pull request #9124: Use better name for local variable to prevent -Wshadow compiler warning (master...20161110_Wshadow_benchcheckblock) https://github.com/bitcoin/bitcoin/pull/9124
02:49 < Victorsueca> - Mr president, the poles are melting, the global warming has reached too high extremes
02:49 < Victorsueca> - Thanks for informing, now go away
02:49 < Victorsueca> President* Looks at a Titanic picture
02:49 < Victorsueca> - The revenge is ours!
02:51 < fanquake> #9100 is another fairly trivial one, with your questions answered.
02:51 < gribble> https://github.com/bitcoin/bitcoin/issues/9100 | tx_valid: re-order inputs to how they are encoded by dcousens · Pull Request #9100 · bitcoin/bitcoin · GitHub
03:02 < bitcoin-git> [bitcoin] paveljanik opened pull request #9130: Mention the new network toggle functionality in the tooltip. (master...20161111_disable_network_tooltip) https://github.com/bitcoin/bitcoin/pull/9130
03:10 <@wumpus> I'd like an ack from someone else on #9100 before merging
03:10 < gribble> https://github.com/bitcoin/bitcoin/issues/9100 | tx_valid: re-order inputs to how they are encoded by dcousens · Pull Request #9100 · bitcoin/bitcoin · GitHub
03:10 <@wumpus> I'm not sure enough about it
03:11 <@wumpus> I think it's ok though
03:13 -!- whphhg is now known as mistermister     
03:23 < fanquake> wumpus: I'll look at that shortly.
03:24 < fanquake> One thing I wanted you to take a look at this this diff generated by your diff-tool -> https://github.com/bitcoin/bitcoin/pull/8808#issuecomment-259657066 , the bottom change seems to significant to be part of the PR.
03:25 < fanquake> I'm working on making the maintainer tools run on OS X so there are a few more people running them.
03:27 <@wumpus> for the Wshadow stuff I want to be entirely sure that it doesn't cause floods of warnings for anyone
03:27 <@wumpus> I don't want to enable it again and get complaints that some obscure compiler is generating a shitton of senseless warnings
03:28 < fanquake> Sure. Is them some threshold for compiler age/obscureness.
03:28 < fanquake> *there
03:29 <@wumpus> maybe  a solution that enables it conditionally for compilers where it is shown to be ok
03:29 <@wumpus> yeah if someone wants to chase obscure rabbits there's enough issues, for example the bench crash on freebsd
03:30 <@wumpus> I just don't have the conviction anymore, after reading around a bit and googling for WShadow, that it's not going to be an endless source of busywork
03:31 <@wumpus> even if you enable it by default you may not see any warnings, but someone wit hcompiler Y might
03:31 <@wumpus> resulting in tons of extra nits on every pull
03:32 <@wumpus> or 'fix Wshadow after blablba' commits forever
03:34 < fanquake> Indeed. I guess we either define some set/range of compilers, and guarantee them to be warning-less, and suggest their use? Or as you say, possibly enable it by default for only that set.
03:34 < fanquake> I think the improvements/potential bug catching effects of having it turned on should outweigh potential concerns?
03:37 < MarcoFalke> If you enable it only for a specific set of compilers, it is the same issue as enabling it for all compilers and having compilers handle it differently. 
03:37 < MarcoFalke> Sadly there is no -Wshadow-common-for-all-compilers
03:46 < phantomcircuit> wumpus: the parsing is done by the CWallet dummyWallet
03:46 < phantomcircuit> which i removed entirely
03:46 < phantomcircuit> so the exception handling is basically just for the type not parsing
03:47 < MarcoFalke> phantomcircuit: Maybe add a comment why that case is not needed to be handled
03:48 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
04:23 -!- cryptapus [~cryptapus@87.254.202.192] has joined #bitcoin-core-dev     
04:23 -!- cryptapus [~cryptapus@87.254.202.192] has quit [Changing host]     
04:23 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:26 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit]     
04:39 < Victorsueca> ok, so I got #8456 built
04:39 < gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
04:40 < Victorsueca> how do I create a BIP 125 transaction?
04:49 < jonasschnelli> Victorsueca: createrawtransaction
04:50 < jonasschnelli> Victorsueca: set nSequence to INT::MAX-2
04:50 < jonasschnelli> but wait..
04:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fhezalfmfirjhoqa] has quit [Quit: Connection closed for inactivity]     
04:50 < Victorsueca> yeah, I'm trying to use createrawtransaction but not sure how to signal that the transaction is replaceable
04:51 < jonasschnelli> I though we have a global OptInRBF flag...
04:51 < jonasschnelli> but looks like we never merged it..
04:51  * jonasschnelli checking...
04:51 < Victorsueca> i'm currently using head f3833f4
04:52 < jonasschnelli> Victorsueca: we have one!
04:52 < jonasschnelli> -walletrbf=1
04:52 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8601/files
04:52 < Victorsueca> nice, will try that
04:52 < jonasschnelli> This will autoset the inputs nSequence Number to INT::MAX-2
04:52 < jonasschnelli> phantomcircuit: ping
04:53 < jonasschnelli> In PR9101 you mentioned that "Removes the last dependency from walletdb.cpp on CWallet."
04:53 < jonasschnelli> I see other CWallet interaction in walletdb.cpp
04:53 < jonasschnelli> IMO CWalletDB should be hidden behind CWallet
04:53 < jonasschnelli> And CWalletDB should habe no knowhow of CWallet
04:54 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]     
04:55 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
04:56 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
04:58 < Victorsueca> nice, it worked
04:59 < Victorsueca> got to bump the fee for a transaction from 260sat to 520sat
05:00 -!- cdecker [~quassel@2a02:aa16:1105:4a80:bcd4:7d3b:d57e:787f] has joined #bitcoin-core-dev     
05:00 <@wumpus> phantomcircuit: why would 'type not handled' not need to be warned about?
05:02 < Victorsueca> here's the result https://softnet.homenet.org/zerobin/?915143c9d44e6ad6#gzz/IhVKwH2IRWeZoIuYermb53dUYWjEhY3sTtwc9Sk=
05:09 < jonasschnelli> Victorsueca: nice! Please report on the PR and ACK
05:11 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9131: fNetworkActive is not protected by a lock, use an atomic (master...2016/11/net_toggle) https://github.com/bitcoin/bitcoin/pull/9131
05:13 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
05:21 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]     
05:24 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
05:28 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:37 < Victorsueca> done, ping me whenever you need to test something on windows
05:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
05:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
05:41 < jonasschnelli> Victorsueca : thx
05:41 < Victorsueca> no problem
05:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
05:56 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
05:58 -!- mistermister [whphhg@gateway/vpn/mullvad/x-auuhcnhldzjvcrfx] has quit [Quit: Leaving]     
06:13 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
06:43 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
06:48 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
07:00 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:05 < bitcoin-git> [bitcoin] morcos opened pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
07:31 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:32 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 265 seconds]     
07:59 -!- abpa [~abpa@2602:306:b837:dbf0:b530:d6ac:5237:29f6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:00 -!- PatBoy [~crypto@192.99.249.194] has joined #bitcoin-core-dev     
08:06 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
08:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-smcigipgwyndgedz] has joined #bitcoin-core-dev     
08:22 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds]     
08:44 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:49 -!- GoogleHater [~Bitcoin@126-88-179-94.pool.ukrtel.net] has joined #bitcoin-core-dev     
08:49 < GoogleHater> Hello.
08:49 < GoogleHater> Why speed limit isn't implemented in Bitcoin Core?
09:00 < Lauda> What speed limit?
09:00 -!- tulip [uid192128@gateway/web/irccloud.com/x-huqalxbywqadyrll] has joined #bitcoin-core-dev     
09:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
09:10 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
09:10 < GoogleHater> It's too hard for me to download 100 GB without half-speed.
09:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:13 < tulip> > and what if rowhammer is a backdoor and was implemented on purpose?
09:13 < tulip> Victorsueca: it's a physical property. on a deep level a lot of what you do in software can have an impact on other things electrically. for example, without care one circuit turning on can be enough to "trigger" others near a threshold. normally random timings become synchronised as a result. 
09:23 < Victorsueca> GoogleHater: I think it's planned to add a feature to limit or halt bandwidth usage
09:23 < Victorsueca> tulip: ik, I was joking
09:23 < GoogleHater> Second problem.
09:24 < GoogleHater> I'm using Tor through iptables.
09:24 < GoogleHater> My Bitcoin Core does not finding *.onion peers.
09:26 < Victorsueca> try adding yu7sezmixhmyljn4.onion, it's mine
09:31 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
09:39 < GoogleHater> I'm using Testnet now.
09:39 < GoogleHater> But I want to use mainnet soon.
09:40 < Victorsueca> ahh wait a second, i'll boot my testnet node
09:44 < Victorsueca> there, my testnet node is at agw4m7vx4gceyttj.onion
10:12 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
10:16 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 240 seconds]     
10:28 -!- cryptapus [~cryptapus@87.254.202.160] has joined #bitcoin-core-dev     
10:28 -!- cryptapus [~cryptapus@87.254.202.160] has quit [Changing host]     
10:28 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
11:04 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
11:30 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]     
11:31 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
11:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
11:40 -!- tulip [uid192128@gateway/web/irccloud.com/x-huqalxbywqadyrll] has quit [Quit: Connection closed for inactivity]     
11:45 < phantomcircuit> wumpus: i dont think it can actually fail
11:52 < phantomcircuit> yeah im pretty sure that ssKey >> strType; cannot fail actually
11:58 -!- abc [5eda49a0@gateway/web/freenode/ip.94.218.73.160] has joined #bitcoin-core-dev     
11:58 -!- abc is now known as Guest24458     
12:00 -!- Guest24458 [5eda49a0@gateway/web/freenode/ip.94.218.73.160] has quit [Client Quit]     
12:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
12:06 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
12:10 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
12:10 -!- rabidus_ [~lauri.j@uhiainen.com] has quit [Ping timeout: 252 seconds]     
12:21 < sipa> phantomcircuit: what if ssKey is empty?
12:23 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
12:46 -!- dermoth [~thomas@dsl-216-221-56-109.mtl.aei.ca] has quit [Ping timeout: 260 seconds]     
13:02 -!- GoogleHater [~Bitcoin@126-88-179-94.pool.ukrtel.net] has quit [Read error: Connection reset by peer]     
13:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]     
13:09 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9136: sync_blocks cleanup (master...sync-clean) https://github.com/bitcoin/bitcoin/pull/9136
13:10 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9137: WIP: Allow wallet key import RPCs to track TxOut amounts on -prune nodes (master...import-pruned) https://github.com/bitcoin/bitcoin/pull/9137
13:14 -!- chris2000 [~chris2000@p5082A627.dip0.t-ipconnect.de] has quit []     
13:30 -!- whphhg [whphhg@gateway/vpn/mullvad/x-sqswbncosgcbcvue] has joined #bitcoin-core-dev     
13:30 < bitcoin-git> [bitcoin] morcos opened pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
13:32 < bitcoin-git> [bitcoin] morcos closed pull request #9123: Remove extraneous LogPrint from fee estimation (master...eliminateFeeWarning) https://github.com/bitcoin/bitcoin/pull/9123
13:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:39 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
13:52 < phantomcircuit> sipa: i guess it would fail then?
13:54 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
13:55 < sipa> phantomcircuit: yes, std::ios_base::failure("CDataStream::read(): end of data")
13:57 < phantomcircuit> the question is really how much checking of the result do we want to do?
13:57 < sipa> phantomcircuit: i miss context
14:04 -!- nibor [~nibor@185.9.34.66] has joined #bitcoin-core-dev     
14:07 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9139: Change sync_blocks to pick smarter maxheight (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
14:09 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-yffvmqugbxgpzcnf] has quit []     
14:09 -!- zmanian [sid113594@gateway/web/irccloud.com/x-vugldubckcmykpgf] has joined #bitcoin-core-dev     
14:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
14:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
14:30 -!- cryptapus_afk is now known as cryptapus     
14:31 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
14:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
14:42 -!- cryptapus is now known as cryptapus_afk     
14:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
14:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
15:07 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jivforlhhjsbmsbt] has quit [Quit: Connection closed for inactivity]     
15:18 -!- niska` [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
15:18 -!- niska [~niska@68.ip-149-56-14.net] has quit [Ping timeout: 256 seconds]     
15:31 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:03 < BlueMatt> cfields: hum, why do we even need fSuccessfullyConnected?
16:04 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
16:04 < BlueMatt> cfields: cant we just set nVersion at that location in ::VERSION processing and just keep using nVersion != 0
16:04 < BlueMatt> cfields: alternatively, shouldnt fSuccessfullyConnected be set in ::VERACK, not ::VERSION?
16:04 < cfields> BlueMatt: see the commit message. Sometimes we bail before fully finishing version
16:05 < BlueMatt> cfields: yes, I'm saying move that setting down
16:05 < cfields> BlueMatt: i think the confusion comes from trying to repurpose that var. What it really means is fCanSendToPeer
16:05 < cfields> how about renaming to that?
16:05 < BlueMatt> cfields: I'm asking if its redundant
16:06 < BlueMatt> the confusion is that it seems redundant
16:07 < cfields> BlueMatt: I suppose with the fDisconnect completely worked out, yes, it's redundant
16:08 < cfields> BlueMatt: the issue before was that sometimes we'd bail halfway through processing VERSION, leaving nVersion set, but we wouldn't want to send any new outgoing messages. But because some places didn't check for fDisconnected, outgoing messages got through anyway
16:08 < cfields> I believe that's fixed in that PR. So in that case, yes, they should be redundant. Will fix.
16:09 < BlueMatt> cfields: yes, i see that, but how hard is it to move the pfrom->nVersion = ... thing down 50 lines and do PushWithVersion for everything in between (is there anything)
16:09 < BlueMatt> ok     
16:09 < BlueMatt> thanks
16:10 -!- cdecker [~quassel@2a02:aa16:1105:4a80:bcd4:7d3b:d57e:787f] has quit [Ping timeout: 260 seconds]     
16:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
17:11 -!- testnet [~testnet@gateway/tor-sasl/testnet] has quit [Remote host closed the connection]     
17:11 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Read error: Connection reset by peer]     
17:11 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
17:11 -!- testnet [~testnet@gateway/tor-sasl/testnet] has joined #bitcoin-core-dev     
17:13 -!- testnet [~testnet@gateway/tor-sasl/testnet] has left #bitcoin-core-dev []     
17:25 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 245 seconds]     
17:26 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
17:44 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uaqfbtlvvblcjumo] has joined #bitcoin-core-dev     
18:00 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
18:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:10 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Ping timeout: 260 seconds]     
18:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:40 < BlueMatt> cfields: if you want to be extra super duper awesome for me you could even add a skip_bytes method in your CVectorWriter (see https://github.com/bitcoinfibre/bitcoinfibre/commit/70673283326f0ab7b542dfb16da32dd81f70176d) but thats not really a comment, just a note since I have a similar class in FIBRE and it would be useful
18:43 < sipa> BlueMatt: that just increments the write pointer?
18:43 < BlueMatt> essentially, yes
18:43 < sipa> the equivalent of writing zeroes, i guess?
18:43 < BlueMatt> sipa: yes
18:44 < BlueMatt> sipa: though for my use-case i couldnt care less if its 0s or garbage
18:44 < sipa> what is it used for?
18:44 < BlueMatt> though, i guess, sending un-init'd memory over the wire is generally frowned upon
18:46 < BlueMatt> cfields: didnt really read in too much detail, but the concept looks like what i was asking for
18:49 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
18:50 < sipa> BlueMatt: why do want to send (don't care) bytes over the wire?
18:50 < BlueMatt> sipa: pad transactions out so that they (often) start on packet/fec-chunk boundaries
18:50 < BlueMatt> you end up with null space
18:50 < BlueMatt> in an earlier implementation it even sent shorter packets to not send the null space, but you still use it for fec-coding
18:50 < BlueMatt> i think the current code sends the 0s just because it was annoying to try to code
19:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-smcigipgwyndgedz] has quit [Ping timeout: 245 seconds]     
19:02 -!- ybit_ is now known as ybit     
19:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vtrwftzzudtowfby] has joined #bitcoin-core-dev     
19:10 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vtrwftzzudtowfby] has quit [Quit: Connection closed for inactivity]     
19:52 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 248 seconds]     
20:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:03 < cfields> BlueMatt: hmm, it may make more sense to do that at the point where we're actually writing to the net?
20:04 < cfields> s/net/socket
20:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:04 < cfields> no problem adding it to CVectorWriter though, if that's the approach that makes sense
20:04 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
20:06 < cfields> BlueMatt: it surprises me that you'd see the benefits of padding like that though, considering how many layers of caching there are to get through on the OS side
20:08 < cfields> BlueMatt: and thanks for looking, btw
20:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:57 -!- Guest47022 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev     
20:58 < gmaxwell> matt's data neeeds to be padded in memory, not for the net.
20:59 < gmaxwell> he seralizes the block into memory and then runs forward error correction over it. The padding is added so that transactions begin on FEC packet bundaries.
21:01 < gmaxwell> The reason for this is that when using the mempool for reconstruction when a txn is missing the whole packet containing is missing. To prevent miss amplification there is some padding to get txn onto packet boundaries. 
21:01 < BlueMatt> cfields: note that if you've gotten to the point where you're sending tx data over the wire, you've failed horribly....at that point you've already sent a ton of fec data
21:01 < BlueMatt> also what gmaxwell said
21:01 < gmaxwell> if matt's FEC stuff was more optimized he'd probably never send the original packets at all ever. :P
21:01 < cfields> ah, i see
21:02 < BlueMatt> i mean i could just do that, but since i already have the data and all the plumbing for using it since the header stuff does...might as well send it :)
21:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
21:02 -!- abpa [~abpa@2602:306:b837:dbf0:4417:9fc5:8e0c:9082] has joined #bitcoin-core-dev     
21:02 < cfields> completely misunderstood what you were getting at, thanks for the explanation
21:10 -!- juscamarena [~jus@47.148.176.74] has joined #bitcoin-core-dev     
21:13 -!- juscamarena [~jus@47.148.176.74] has quit [Client Quit]     
21:24 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
21:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:09 -!- Naphex [~naphex@naphex.rocks] has joined #bitcoin-core-dev     
22:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:22 < luke-jr> I keep getting on master ./bench/data/block413567.raw.h:124989:40: error: redefinition of ‘const unsigned char block_bench::block413567 []’
22:22 < luke-jr> have to manually delete the file and try again
22:23 < luke-jr> the rules to generate it only append, shouldn't the first create anew?
22:23 < luke-jr> (and does make do the deletion of files when the rule fails, or must we?)
22:24 < luke-jr> looks like we need to do it..
22:56 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
22:58 -!- thokon00 [~thokon00@unaffiliated/thokon00] has quit [Ping timeout: 258 seconds]     
23:03 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
23:03 <@wumpus> luke-jr: strange, I just copied that rule from the tests, so I'd expect it would work as-is. But indeed it should create the file anew, not append to it, that's weird
23:03 < luke-jr> is there one of these in the tests I should fix too?
23:03 -!- thokon00 [~thokon00@unaffiliated/thokon00] has joined #bitcoin-core-dev     
23:03 -!- fengling [~fengling@43.255.178.115] has joined #bitcoin-core-dev     
23:04 <@wumpus> no, I think it's my fault, I removed the namespace{} around it, the first line in the test is probably ok
23:04 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
23:04 <@wumpus> should just change the first  >> $@ to > $@
23:04 <@wumpus> are you going to do it or should I?
23:04 < luke-jr> well, if any of these steps fails, we need to delete the file too :x
23:05 < luke-jr> (or else make will think it's up to date next run)
23:07 <@wumpus> the best option then would be to write to a temporary file
23:07 <@wumpus> then at the end mv it over atomically
23:07 <@wumpus> eg write to $@.tmp 
23:08 <@wumpus> in that case you need to do it in Makefile.test.include too
23:08 < luke-jr> hm, I was thinking http://codepad.org/SXhNyVzI
23:09 <@wumpus> meh, with my solution you never actually need to delete anything
23:09 <@wumpus> it's just not created if naything fails
23:09 < luke-jr> true
23:10 <@wumpus> or ... isn't that the case for yours too?
23:10 <@wumpus> you write the output to a pipe
23:10 <@wumpus> oh wait, yes
23:10 < luke-jr> http://codepad.org/Glnudlpw ?
23:10 <@wumpus> the pipe doesn't 'wait'. SO yes a temporary file then atomic move is probably better
23:11 <@wumpus> yes     
23:16 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:17 < bitcoin-git> [bitcoin] luke-jr opened pull request #9140: Bugfix: Correctly replace generated headers and fail cleanly (master...bugfix_genheaders) https://github.com/bitcoin/bitcoin/pull/9140
23:17 -!- fengling [~fengling@43.255.178.115] has quit [Ping timeout: 268 seconds]     
23:26 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
23:35 < bitcoin-git> [bitcoin] luke-jr closed pull request #7534: Minimal RPC & wallet support for CLTV-enabled multisig addresses (master...cltv_address) https://github.com/bitcoin/bitcoin/pull/7534
23:37 < bitcoin-git> [bitcoin] luke-jr closed pull request #8388: [0.13] mining: Optimise for typical mining use with blockmaxsize (0.13...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8388
23:40 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
23:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit]     
23:45 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
23:51 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]