12016-11-11T00:24:59 *** Guyver2 has quit IRC
22016-11-11T01:22:38 *** baldur has quit IRC
32016-11-11T01:22:56 *** baldur has joined #bitcoin-core-dev
42016-11-11T01:25:12 *** baldur has quit IRC
52016-11-11T01:25:27 *** baldur has joined #bitcoin-core-dev
62016-11-11T01:37:54 *** AaronvanW has quit IRC
72016-11-11T01:58:05 *** abpa has quit IRC
82016-11-11T01:58:55 <bitcoin-git> [bitcoin] sipa opened pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (master...sharedblock) https://github.com/bitcoin/bitcoin/pull/9125
92016-11-11T02:08:20 *** fengling has joined #bitcoin-core-dev
102016-11-11T02:08:33 *** DigiByteDev has joined #bitcoin-core-dev
112016-11-11T02:10:18 *** tulip has quit IRC
122016-11-11T02:19:23 *** jtimon has quit IRC
132016-11-11T02:20:08 <cfields> sipa: interesting
142016-11-11T02:20:39 <sipa> cfields: the PR above?
152016-11-11T02:20:42 *** sipa sets mode: -o sipa
162016-11-11T02:20:45 <cfields> sipa: yes
172016-11-11T02:21:08 <sipa> i was surprised that i didn't need to touch any of the block or transaction serialization logic
182016-11-11T02:21:31 <cfields> yes, it's simpler than I would've expected too
192016-11-11T02:21:46 <cfields> trying to decide how much foot-gun the serialize.h changes allow
202016-11-11T02:22:27 <sipa> the shared_ptr serializer only applies when the element type is const
212016-11-11T02:27:57 <cfields> sipa: yep, actually seems innocuous
222016-11-11T02:28:55 <cfields> sipa: and my knee-jerk when I see shared_ptr is to grumble about ownership models, but I can't imagine this being any worse than duplicating all over the place
232016-11-11T02:29:56 <sipa> cfields: right, but that doesn't apply when the element type is const
242016-11-11T02:30:11 <sipa> you can just see the different shared_ptr's as deduplicated copies of the same data
252016-11-11T02:30:53 <cfields> yes. I like it :)
262016-11-11T02:32:47 <gmaxwell> keep up the grumbling at shared_ptr, I agree.. but it sure seems to make sense for mempool transactions which otherwise we'd have copies of, since the different uses have different lifetimes.
272016-11-11T02:36:02 <cfields> yes, this seems like a really good use-case.
282016-11-11T02:40:10 *** Ylbam has quit IRC
292016-11-11T02:40:43 <cfields> probably requires new approaches in lots of places. For ex where copying a block becomes very cheap for the purposes of caching around locks.
302016-11-11T02:40:50 <cfields> s/requires/allows/
312016-11-11T02:42:33 <sipa> cfields: well that would better be served by using shared_ptr's to CBlock itself
322016-11-11T02:43:23 <cfields> sipa: i was wondering if that's the next logical step. I don't think they'd be mutually exclusive?
332016-11-11T02:45:07 <sipa> cfields: sure
342016-11-11T02:47:20 <sipa> there are probably a few more optimizations that i haven't addressed
352016-11-11T02:47:31 <sipa> i think ATMP should take a shared_ptr
362016-11-11T02:47:55 <sipa> so a reorg wouldn't require a copy back from the block to the mempool
372016-11-11T03:23:41 *** btcdrak has joined #bitcoin-core-dev
382016-11-11T03:44:36 *** fanquake has joined #bitcoin-core-dev
392016-11-11T03:48:45 *** DigiByteDev has quit IRC
402016-11-11T03:55:12 *** abpa has joined #bitcoin-core-dev
412016-11-11T04:56:14 *** kadoban has quit IRC
422016-11-11T05:26:16 *** Alopex has quit IRC
432016-11-11T05:27:22 *** Alopex has joined #bitcoin-core-dev
442016-11-11T05:31:21 *** jl2012 has quit IRC
452016-11-11T05:33:25 *** jl2012 has joined #bitcoin-core-dev
462016-11-11T05:40:45 *** DigiByteDev has joined #bitcoin-core-dev
472016-11-11T06:10:33 *** jl2012 has quit IRC
482016-11-11T06:10:54 *** jl2012 has joined #bitcoin-core-dev
492016-11-11T06:27:59 *** btcdrak has quit IRC
502016-11-11T06:28:29 <bitcoin-git> [bitcoin] theuni opened pull request #9128: net: Decouple CConnman and message serialization (master...connman-send) https://github.com/bitcoin/bitcoin/pull/9128
512016-11-11T06:33:03 *** DigiByteDev has quit IRC
522016-11-11T06:38:51 <bitcoin-git> [bitcoin] rebroad opened pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
532016-11-11T06:54:53 *** thokon00 has quit IRC
542016-11-11T06:58:52 *** windsok has joined #bitcoin-core-dev
552016-11-11T07:03:00 *** btcdrak has joined #bitcoin-core-dev
562016-11-11T07:03:19 *** windsok has quit IRC
572016-11-11T07:05:31 *** thokon00 has joined #bitcoin-core-dev
582016-11-11T07:06:04 *** windsok has joined #bitcoin-core-dev
592016-11-11T07:08:33 <luke-jr> should we be using std::random_device?
602016-11-11T07:10:25 <sipa> luke-jr: afaik it has 0 guarantees
612016-11-11T07:10:58 <luke-jr> can't hurt though, right?
622016-11-11T07:11:39 <luke-jr> (and what's the point of the exception if there's no guarantees at all? O.o)
632016-11-11T07:12:32 *** aalex has joined #bitcoin-core-dev
642016-11-11T07:13:49 <sipa> the exception is for when no random number can be generated at all
652016-11-11T07:14:10 <sipa> even if it generates one, it doesn't guarantee cryptographic quality (or any quality at all)
662016-11-11T07:14:53 *** DigiByteDev has joined #bitcoin-core-dev
672016-11-11T07:19:01 *** aalex has quit IRC
682016-11-11T07:25:17 *** cfields has quit IRC
692016-11-11T07:25:47 *** cfields has joined #bitcoin-core-dev
702016-11-11T07:39:43 *** DigiByteDev has quit IRC
712016-11-11T07:55:27 *** jl2012 has quit IRC
722016-11-11T07:57:02 *** jl2012 has joined #bitcoin-core-dev
732016-11-11T08:12:31 *** Guyver2 has joined #bitcoin-core-dev
742016-11-11T08:21:24 *** testnet has quit IRC
752016-11-11T08:21:25 *** wasi has quit IRC
762016-11-11T08:21:51 *** wasi has joined #bitcoin-core-dev
772016-11-11T08:22:55 *** rubensayshi has joined #bitcoin-core-dev
782016-11-11T08:25:46 *** testnet has joined #bitcoin-core-dev
792016-11-11T08:29:07 *** Ylbam has joined #bitcoin-core-dev
802016-11-11T08:41:54 *** DigiByteDev has joined #bitcoin-core-dev
812016-11-11T08:57:32 <fanquake> Competing pull-requests seems to be a "thing" now..
822016-11-11T09:04:46 <wumpus> yeah...
832016-11-11T09:05:45 <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
842016-11-11T09:07:33 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
852016-11-11T09:07:45 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71bc39eb7483...21e6c6b569c5
862016-11-11T09:07:45 <bitcoin-git> bitcoin/master 617c96d fanquake: [depends] Set OSX_MIN_VERSION to 10.8
872016-11-11T09:07:46 <bitcoin-git> bitcoin/master 21e6c6b Wladimir J. van der Laan: Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8...
882016-11-11T09:07:52 <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
892016-11-11T09:07:55 *** MarcoFalke has joined #bitcoin-core-dev
902016-11-11T09:08:17 <wumpus> we're better off implementing our own secure random functionality, given how critical it is for the wallet at least
912016-11-11T09:09:14 <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...
922016-11-11T09:11:02 <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?
932016-11-11T09:11:27 <wumpus> Victorsueca: maybe. At the least we should be reading /dev/urandom ourselves
942016-11-11T09:12:01 <wumpus> it's not rocket science and there is nothing to be gained by hiding it behind layers of abstraction
952016-11-11T09:12:45 <Victorsueca> sounds good, definitely better than using the default source of randomness which could be backdoored by the hardware manufacturer
962016-11-11T09:13:44 <sipa> if your hardware is backdoored, the technical term for the situation you're in is: utterly fucked
972016-11-11T09:13:47 <wumpus> that's not really the threat model we're fighting here...
982016-11-11T09:13:53 <wumpus> right
992016-11-11T09:14:17 <luke-jr> wumpus: I just meant in addition to other entropy sources
1002016-11-11T09:15:39 <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
1012016-11-11T09:16:55 <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
1022016-11-11T09:17:20 <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...
1032016-11-11T09:17:20 <luke-jr> just happened to glance at that shell at the right instant
1042016-11-11T09:17:45 <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
1052016-11-11T09:17:45 <luke-jr> eh, Intel ME is a pretty low risk explicit backdoor
1062016-11-11T09:17:58 <Victorsueca> is the kind of thing I never seen but I think it should already exist
1072016-11-11T09:18:14 <luke-jr> Victorsueca: pretty sure something does using radio waves
1082016-11-11T09:18:17 <wumpus> luke-jr: well in any case thanks for letting me know it exists at all, it may be useful for some other projects
1092016-11-11T09:19:12 <wumpus> Victorsueca: those exist and are in active use, both for secure randomness and by gambling sites
1102016-11-11T09:20:16 <Victorsueca> wumpus: thought gambling sites used atomic event observation which is pretty expensive devices, I was thinking on something affordable for any home user
1112016-11-11T09:20:37 <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 :-)
1122016-11-11T09:20:57 <luke-jr> heh
1132016-11-11T09:21:23 <Victorsueca> and what if rowhammer is a backdoor and was implemented on purpose?
1142016-11-11T09:21:29 * Victorsueca adjusts tinfoil hat
1152016-11-11T09:21:45 <wumpus> Victorsueca: there's low end and high end devices in that range, just a google away :p
1162016-11-11T09:22:35 <wumpus> you can even build a randomness device pretty easily yourself, building unstable hardware is not rocket science :-)
1172016-11-11T09:23:16 <Victorsueca> wumpus: maybe, but preventing it from putting your house on fire is ;)
1182016-11-11T09:23:40 <Victorsueca> then use the shape of the flames as random source
1192016-11-11T09:24:09 *** DigiByteDev has quit IRC
1202016-11-11T09:25:38 *** Guyver2 has quit IRC
1212016-11-11T09:25:50 *** rubensayshi has quit IRC
1222016-11-11T09:26:06 *** jannes has joined #bitcoin-core-dev
1232016-11-11T09:27:10 <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
1242016-11-11T09:27:16 <wumpus> similar, though much more general.
1252016-11-11T09:27:48 <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)
1262016-11-11T09:28:52 <wumpus> Victorsueca: ascribing such natural engineering properties to state actors is paranoid to the level of schizofrenia :)
1272016-11-11T09:29:52 <wumpus> *finding* these kinds of bugs on the other hand is something they're certainly working very hard at
1282016-11-11T09:30:10 <Victorsueca> they control temperature and humidity to manipulate your randomness
1292016-11-11T09:30:36 * Victorsueca puts tinfoil around his parts
1302016-11-11T09:33:38 <Victorsueca> jokes apart, Yesterday I had an idea
1312016-11-11T09:34:21 <Victorsueca> would be possible to make that after abandoning a transaction core spends the same inputs for the next transaction you make?
1322016-11-11T09:34:51 <Victorsueca> I think it's possible, the question would rather be if it makes sense
1332016-11-11T09:35:56 <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
1342016-11-11T09:36:44 <wumpus> delaying it until you happen to need to send again creates a potentially huge time window in which you're exposed
1352016-11-11T09:36:58 <Victorsueca> I was thinking on somebody who has his transaction stuck because ha paid a low fee
1362016-11-11T09:37:13 <Victorsueca> so he abandons the transaction and double-spends it with a higher fee
1372016-11-11T09:37:20 <wumpus> just use RBF?
1382016-11-11T09:37:50 <Victorsueca> then why is there a banadon transaction button at all?
1392016-11-11T09:37:58 <Victorsueca> abandon*
1402016-11-11T09:38:21 <Victorsueca> not to mention RBF is not yet implemented in the GUI
1412016-11-11T09:39:21 <wumpus> bumpfee needs to be on RPC first e.g. see https://github.com/bitcoin/bitcoin/pull/8456
1422016-11-11T09:39:27 <wumpus> all needs review
1432016-11-11T09:39:51 <wumpus> sorry to say this but we need more review and testing on actual work people are doing, not out-there ideas
1442016-11-11T09:40:22 <Victorsueca> it's ok
1452016-11-11T09:41:29 <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
1462016-11-11T09:41:40 <wumpus> no, it's not
1472016-11-11T09:41:50 <Victorsueca> thought so
1482016-11-11T09:42:04 <wumpus> changes to coin selection are one of the most difficult categories of changes
1492016-11-11T09:46:22 *** chris2000 has joined #bitcoin-core-dev
1502016-11-11T09:46:51 <Victorsueca> well, I can help testing changes on windows, AFAIK few devs work on windows
1512016-11-11T09:50:55 <wumpus> awesome!
1522016-11-11T09:50:59 <fanquake> Great!
1532016-11-11T09:51:37 <fanquake> There is always need for more reviewers, especially on Windows, because as you've mentioned, few devs are using it.
1542016-11-11T09:52:40 <wumpus> yes especially for GUI changes there's pretty few testers at all
1552016-11-11T09:52:53 <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.
1562016-11-11T09:52:54 <fanquake> https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3AWindows
1572016-11-11T09:53:39 <jonasschnelli> For multiwallet, this PR is large but simple to review: https://github.com/bitcoin/bitcoin/pull/8764
1582016-11-11T09:54:16 <phantomcircuit> wumpus: the wallet recovery stuff will print a warning if it fails to parse the value in the key/value pair
1592016-11-11T09:54:28 <phantomcircuit> this is the last reference to CWallet from CWalletDB
1602016-11-11T09:54:36 <phantomcircuit> i have a patch that just removes this
1612016-11-11T09:54:44 <phantomcircuit> i'd like to know what you think about it
1622016-11-11T09:54:53 <phantomcircuit> (not the patch, removing the warning)
1632016-11-11T09:54:57 <wumpus> please don't remove that warning. You can't move it anywhere else?
1642016-11-11T09:55:15 <wumpus> we have open issues with salvagewallet that's why the debug level there was increased
1652016-11-11T09:55:40 <wumpus> https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20salvagewallet
1662016-11-11T09:55:51 <phantomcircuit> ok i'll take another look at it to see if there's a better way of handling that
1672016-11-11T09:56:10 <phantomcircuit> (i mean really the better way would be a completely separate tool, but that is not in scope)
1682016-11-11T09:56:37 <fanquake> wumpus: I've ack'd #9112 if you just want to merge it.
1692016-11-11T09:56:38 <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
1702016-11-11T09:57:06 *** moli has quit IRC
1712016-11-11T09:57:07 <wumpus> phantomcircuit: jonasschnelli made such a tool https://github.com/bitcoin/bitcoin/pull/8745 - but yeah that's out of scope
1722016-11-11T09:57:14 *** AaronvanW has joined #bitcoin-core-dev
1732016-11-11T09:57:14 *** AaronvanW has quit IRC
1742016-11-11T09:57:14 *** AaronvanW has joined #bitcoin-core-dev
1752016-11-11T09:57:41 <jonasschnelli> wumpus: we first need to solve the cirular dependencies.
1762016-11-11T09:57:45 <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
1772016-11-11T09:57:45 <jonasschnelli> *circular
1782016-11-11T09:59:24 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21e6c6b569c5...46027e8668ec
1792016-11-11T09:59:24 <bitcoin-git> bitcoin/master e9f25dd Wladimir J. van der Laan: Avoid ugly exception in log on unknown inv type...
1802016-11-11T09:59:25 <bitcoin-git> bitcoin/master 46027e8 Wladimir J. van der Laan: Merge #9112: Avoid ugly exception in log on unknown inv type...
1812016-11-11T09:59:34 <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
1822016-11-11T09:59:44 <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
1832016-11-11T10:02:31 <Victorsueca> how do you do to pull a unmerged pull request into your working directory?
1842016-11-11T10:03:05 <fanquake> Have a look at the github-merge script in this dir https://github.com/bitcoin/bitcoin/tree/master/contrib/devtools
1852016-11-11T10:03:15 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/46027e8668ec...7977a1157a3a
1862016-11-11T10:03:15 <wumpus> contrib/devtools/github-merge.py 1234
1872016-11-11T10:03:15 <bitcoin-git> bitcoin/master 47e9659 Russell Yanofsky: [qa] Fix bug in compactblocks v2 merge...
1882016-11-11T10:03:16 <bitcoin-git> bitcoin/master 55bfddc Russell Yanofsky: [qa] Fix stale data bug in test_compactblocks_not_at_tip...
1892016-11-11T10:03:16 <bitcoin-git> bitcoin/master dac53b5 Russell Yanofsky: Modify getblocktxn handler not to drop requests for old blocks...
1902016-11-11T10:03:18 <wumpus> yes, that :)
1912016-11-11T10:03:25 <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
1922016-11-11T10:03:45 *** Evel-Knievel has quit IRC
1932016-11-11T10:04:07 <jonasschnelli> heh
1942016-11-11T10:04:33 *** fengling has quit IRC
1952016-11-11T10:04:46 <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
1962016-11-11T10:05:21 <wumpus> (where "upstream" is the name of your remote for bitcoin/bitcoin, big chance it is "origin" for you)
1972016-11-11T10:05:28 <jonasschnelli> For testing, it's probably better if you test them applied on the current master
1982016-11-11T10:05:35 <jonasschnelli> (unless they have merge conflicts)
1992016-11-11T10:05:40 <wumpus> yes, true
2002016-11-11T10:14:01 <Victorsueca> ok, got it, thanks
2012016-11-11T10:15:14 <Victorsueca> building it at the moment
2022016-11-11T10:16:59 <bitcoin-git> [bitcoin] jonasschnelli pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/7977a1157a3a...ab914a65301b
2032016-11-11T10:17:00 <bitcoin-git> bitcoin/master 7c9a98a Jon Lund Steffensen: Allow network activity to be temporarily suspended....
2042016-11-11T10:17:00 <bitcoin-git> bitcoin/master e38993b Jon Lund Steffensen: RPC: Add "togglenetwork" method to toggle network activity temporarily...
2052016-11-11T10:17:01 <bitcoin-git> bitcoin/master 32efa79 Jon Lund Steffensen: Qt: Add GUI feedback and control of network activity state....
2062016-11-11T10:17:09 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
2072016-11-11T10:17:32 <Victorsueca> it's me or this new bot is more spammy than the previous one?
2082016-11-11T10:18:11 <luke-jr> just you
2092016-11-11T10:19:09 <jonasschnelli> Luke-Jr: how do we continue with https://github.com/bitcoin/bitcoin/pull/8889? Close?
2102016-11-11T10:19:57 <luke-jr> for now
2112016-11-11T10:20:04 <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
2122016-11-11T10:20:20 <jonasschnelli> Okay. Yes. We can always reopen this.
2132016-11-11T10:20:59 <luke-jr> I suspect the problems were due to tooltips not normally having focus
2142016-11-11T10:22:29 <luke-jr> ie, the theme doesn't bother defining the tooltip-with-focus colours sanely
2152016-11-11T10:25:45 <wumpus> there is no 'new bot', I've just changed its configuration to use a consistent name
2162016-11-11T10:26:07 <wumpus> if it seems more spammy it's just because there's a lot of merging going on
2172016-11-11T10:26:42 <Victorsueca> ahh ok
2182016-11-11T10:27:11 <Victorsueca> 0.14 seems like it's finally going to be a version dedicated to GUI and wallet
2192016-11-11T10:27:12 <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
2202016-11-11T10:29:20 <fanquake> wumpus: If you want to get the PR list down, there are a few trivial ones.
2212016-11-11T10:29:39 <wumpus> fanquake: sure, let me know
2222016-11-11T10:29:42 <fanquake> #9115 has been updated so can get ACK'd/merged.
2232016-11-11T10:29:43 <gribble> https://github.com/bitcoin/bitcoin/issues/9115 | Mention reporting security issues responsibly by paveljanik · Pull Request #9115 · bitcoin/bitcoin · GitHub
2242016-11-11T10:30:47 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab914a65301b...bfc7aad00884
2252016-11-11T10:30:47 <bitcoin-git> bitcoin/master 7d1de30 Pavel JanÃk: Mention reporting security issues responsibly
2262016-11-11T10:30:48 <bitcoin-git> bitcoin/master bfc7aad Wladimir J. van der Laan: Merge #9115: Mention reporting security issues responsibly...
2272016-11-11T10:30:58 <bitcoin-git> [bitcoin] laanwj closed pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115
2282016-11-11T10:31:16 <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.
2292016-11-11T10:31:17 <gribble> https://github.com/bitcoin/bitcoin/issues/9064 | unify capitalization of "bitcoin address" by s-matthew-english · Pull Request #9064 · bitcoin/bitcoin · GitHub
2302016-11-11T10:32:40 <wumpus> ooh capitalizing Bitcoin just now that internet is no longer going to be capitalized :)
2312016-11-11T10:32:51 <Victorsueca> heh
2322016-11-11T10:33:51 <wumpus> I don't really care, I guess it makes sense to be consistent though...
2332016-11-11T10:34:11 <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.
2342016-11-11T10:34:14 <gribble> https://github.com/bitcoin/bitcoin/issues/8983 | WIP: Log block height and size when received by rebroad · Pull Request #8983 · bitcoin/bitcoin · GitHub
2352016-11-11T10:34:30 <paveljanik> wumpus, internet and Internet are two different things... ;-)
2362016-11-11T10:35:07 <Victorsueca> shouldn't be really difficult to change capitals, except for some languages like German where concepts are one-worded
2372016-11-11T10:35:44 <wumpus> paveljanik: "the internet of different things"
2382016-11-11T10:36: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
2392016-11-11T10:37:35 <Victorsueca> not to mention that could cause people blames capitals being wrong, I still remember when someone put "advertize" in the log messages
2402016-11-11T10:37:58 <Victorsueca> almost starts WW3
2412016-11-11T10:38:12 <wumpus> capital punishment
2422016-11-11T10:39:33 <fanquake> #9124 Is a trivial merge, variable renaming in the benchmarking code.
2432016-11-11T10:39:35 <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
2442016-11-11T10:39:54 <wumpus> phantomcircuit: I don't understand why you can't keep a warning in #9101 when the try{...} fails
2452016-11-11T10:39:55 <gribble> https://github.com/bitcoin/bitcoin/issues/9101 | [Wallet] Do not parse ssValue in CWalletDB::Recover by pstratem · Pull Request #9101 · bitcoin/bitcoin · GitHub
2462016-11-11T10:40:51 <wumpus> you do catch(...) { continue; } silently ignoring aspecific exceptions is usually a code smell and means there should be a warning at least
2472016-11-11T10:43:17 <wumpus> silent errors mean that someone is going to have a very difficult time troubleshooting at some point
2482016-11-11T10:44:18 <Victorsueca> what about make it silent by default but not when -debug is enabled?
2492016-11-11T10:44:37 <wumpus> WHY?
2502016-11-11T10:44:50 <wumpus> salvagewallet is already a troubleshooting option
2512016-11-11T10:44:56 <Victorsueca> right
2522016-11-11T10:45:06 <wumpus> why the hell would you want to have people enable debug to see when things go wrong? that's nonsense
2532016-11-11T10:46:11 <Victorsueca> maybe somebody who expects salvagewallet to go well doesn't want his logs nuked with lots of lines
2542016-11-11T10:46:25 <Victorsueca> if something goes wrong you can always try again with -debug
2552016-11-11T10:46:36 <wumpus> if it goes well there will be no logging because it won't get there!
2562016-11-11T10:47:20 <Victorsueca> hmmm I don't know what would I do
2572016-11-11T10:47:41 <wumpus> you're worrying about the bedsprings being noisy on the titanic while it is colliding against an iceberg
2582016-11-11T10:47:50 <rabidus_> :DD
2592016-11-11T10:47:53 <Victorsueca> heh yeah
2602016-11-11T10:48:57 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfc7aad00884...87ab49e4fe38
2612016-11-11T10:48:57 <bitcoin-git> bitcoin/master bf49f10 Pavel JanÃk: Use better name for local variable to prevent -Wshadow compiler warning
2622016-11-11T10:48:58 <bitcoin-git> bitcoin/master 87ab49e Wladimir J. van der Laan: Merge #9124: Use better name for local variable to prevent -Wshadow compiler warning...
2632016-11-11T10:49:09 <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
2642016-11-11T10:49:23 <Victorsueca> - Mr president, the poles are melting, the global warming has reached too high extremes
2652016-11-11T10:49:33 <Victorsueca> - Thanks for informing, now go away
2662016-11-11T10:49:46 <Victorsueca> President* Looks at a Titanic picture
2672016-11-11T10:49:55 <Victorsueca> - The revenge is ours!
2682016-11-11T10:51:39 <fanquake> #9100 is another fairly trivial one, with your questions answered.
2692016-11-11T10:51:40 <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
2702016-11-11T11:02: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
2712016-11-11T11:10:22 <wumpus> I'd like an ack from someone else on #9100 before merging
2722016-11-11T11:10:23 <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
2732016-11-11T11:10:26 <wumpus> I'm not sure enough about it
2742016-11-11T11:11:34 <wumpus> I think it's ok though
2752016-11-11T11:13:35 *** whphhg is now known as mistermister
2762016-11-11T11:23:08 <fanquake> wumpus: I'll look at that shortly.
2772016-11-11T11:24:21 <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.
2782016-11-11T11:25:28 <fanquake> I'm working on making the maintainer tools run on OS X so there are a few more people running them.
2792016-11-11T11:27:38 <wumpus> for the Wshadow stuff I want to be entirely sure that it doesn't cause floods of warnings for anyone
2802016-11-11T11:27:57 <wumpus> I don't want to enable it again and get complaints that some obscure compiler is generating a shitton of senseless warnings
2812016-11-11T11:28:31 <fanquake> Sure. Is them some threshold for compiler age/obscureness.
2822016-11-11T11:28:34 <fanquake> *there
2832016-11-11T11:29:00 <wumpus> maybe a solution that enables it conditionally for compilers where it is shown to be ok
2842016-11-11T11:29:33 <wumpus> yeah if someone wants to chase obscure rabbits there's enough issues, for example the bench crash on freebsd
2852016-11-11T11:30:40 <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
2862016-11-11T11:31:06 <wumpus> even if you enable it by default you may not see any warnings, but someone wit hcompiler Y might
2872016-11-11T11:31:12 <wumpus> resulting in tons of extra nits on every pull
2882016-11-11T11:32:28 <wumpus> or 'fix Wshadow after blablba' commits forever
2892016-11-11T11:34:19 <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.
2902016-11-11T11:34:58 <fanquake> I think the improvements/potential bug catching effects of having it turned on should outweigh potential concerns?
2912016-11-11T11:37:31 <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.
2922016-11-11T11:37:49 <MarcoFalke> Sadly there is no -Wshadow-common-for-all-compilers
2932016-11-11T11:46:09 <phantomcircuit> wumpus: the parsing is done by the CWallet dummyWallet
2942016-11-11T11:46:13 <phantomcircuit> which i removed entirely
2952016-11-11T11:46:31 <phantomcircuit> so the exception handling is basically just for the type not parsing
2962016-11-11T11:47:20 <MarcoFalke> phantomcircuit: Maybe add a comment why that case is not needed to be handled
2972016-11-11T11:48:12 *** DigiByteDev has joined #bitcoin-core-dev
2982016-11-11T12:23:32 *** cryptapus has joined #bitcoin-core-dev
2992016-11-11T12:23:32 *** cryptapus has joined #bitcoin-core-dev
3002016-11-11T12:26:13 *** cryptapus has quit IRC
3012016-11-11T12:39:42 <Victorsueca> ok, so I got #8456 built
3022016-11-11T12:39:43 <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
3032016-11-11T12:40:22 <Victorsueca> how do I create a BIP 125 transaction?
3042016-11-11T12:49:56 <jonasschnelli> Victorsueca: createrawtransaction
3052016-11-11T12:50:06 <jonasschnelli> Victorsueca: set nSequence to INT::MAX-2
3062016-11-11T12:50:09 <jonasschnelli> but wait..
3072016-11-11T12:50:10 *** Ylbam has quit IRC
3082016-11-11T12:50:58 <Victorsueca> yeah, I'm trying to use createrawtransaction but not sure how to signal that the transaction is replaceable
3092016-11-11T12:51:14 <jonasschnelli> I though we have a global OptInRBF flag...
3102016-11-11T12:51:23 <jonasschnelli> but looks like we never merged it..
3112016-11-11T12:51:26 * jonasschnelli checking...
3122016-11-11T12:51:45 <Victorsueca> i'm currently using head f3833f4
3132016-11-11T12:52:02 <jonasschnelli> Victorsueca: we have one!
3142016-11-11T12:52:04 <jonasschnelli> -walletrbf=1
3152016-11-11T12:52:09 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8601/files
3162016-11-11T12:52:17 <Victorsueca> nice, will try that
3172016-11-11T12:52:32 <jonasschnelli> This will autoset the inputs nSequence Number to INT::MAX-2
3182016-11-11T12:52:43 <jonasschnelli> phantomcircuit: ping
3192016-11-11T12:53:01 <jonasschnelli> In PR9101 you mentioned that "Removes the last dependency from walletdb.cpp on CWallet."
3202016-11-11T12:53:13 <jonasschnelli> I see other CWallet interaction in walletdb.cpp
3212016-11-11T12:53:30 <jonasschnelli> IMO CWalletDB should be hidden behind CWallet
3222016-11-11T12:53:45 <jonasschnelli> And CWalletDB should habe no knowhow of CWallet
3232016-11-11T12:54:17 *** JackH has quit IRC
3242016-11-11T12:55:12 *** moli has joined #bitcoin-core-dev
3252016-11-11T12:56:11 *** JackH has joined #bitcoin-core-dev
3262016-11-11T12:58:53 <Victorsueca> nice, it worked
3272016-11-11T12:59:34 <Victorsueca> got to bump the fee for a transaction from 260sat to 520sat
3282016-11-11T13:00:06 *** cdecker has joined #bitcoin-core-dev
3292016-11-11T13:00:44 <wumpus> phantomcircuit: why would 'type not handled' not need to be warned about?
3302016-11-11T13:02:29 <Victorsueca> here's the result https://softnet.homenet.org/zerobin/?915143c9d44e6ad6#gzz/IhVKwH2IRWeZoIuYermb53dUYWjEhY3sTtwc9Sk=
3312016-11-11T13:09:28 <jonasschnelli> Victorsueca: nice! Please report on the PR and ACK
3322016-11-11T13:11:31 <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
3332016-11-11T13:13:47 *** cryptapus has joined #bitcoin-core-dev
3342016-11-11T13:13:47 *** cryptapus has joined #bitcoin-core-dev
3352016-11-11T13:21:35 *** cryptapus has quit IRC
3362016-11-11T13:24:54 *** cryptapus has joined #bitcoin-core-dev
3372016-11-11T13:28:01 *** fanquake has quit IRC
3382016-11-11T13:37:49 <Victorsueca> done, ping me whenever you need to test something on windows
3392016-11-11T13:40:33 *** luke-jr has quit IRC
3402016-11-11T13:40:43 *** luke-jr has joined #bitcoin-core-dev
3412016-11-11T13:41:13 <jonasschnelli> Victorsueca : thx
3422016-11-11T13:41:25 <Victorsueca> no problem
3432016-11-11T13:54:50 *** laurentmt has joined #bitcoin-core-dev
3442016-11-11T13:56:59 *** laurentmt has quit IRC
3452016-11-11T13:58:34 *** mistermister has quit IRC
3462016-11-11T14:13:01 *** DigiByteDev has quit IRC
3472016-11-11T14:43:36 *** cryptapus has quit IRC
3482016-11-11T14:48:37 *** cryptapus has joined #bitcoin-core-dev
3492016-11-11T15:00:55 *** jtimon has joined #bitcoin-core-dev
3502016-11-11T15:05:36 <bitcoin-git> [bitcoin] morcos opened pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
3512016-11-11T15:31:23 *** aalex has joined #bitcoin-core-dev
3522016-11-11T15:32:03 *** PatBoy has quit IRC
3532016-11-11T15:59:25 *** abpa has quit IRC
3542016-11-11T16:00:27 *** PatBoy has joined #bitcoin-core-dev
3552016-11-11T16:06:39 *** aalex has quit IRC
3562016-11-11T16:18:31 *** Ylbam has joined #bitcoin-core-dev
3572016-11-11T16:22:48 *** cryptapus has quit IRC
3582016-11-11T16:44:37 *** abpa has joined #bitcoin-core-dev
3592016-11-11T16:49:23 *** GoogleHater has joined #bitcoin-core-dev
3602016-11-11T16:49:29 <GoogleHater> Hello.
3612016-11-11T16:49:48 <GoogleHater> Why speed limit isn't implemented in Bitcoin Core?
3622016-11-11T17:00:17 <Lauda> What speed limit?
3632016-11-11T17:00:22 *** tulip has joined #bitcoin-core-dev
3642016-11-11T17:09:32 *** Chris_Stewart_5 has quit IRC
3652016-11-11T17:10:39 *** Evel-Knievel has joined #bitcoin-core-dev
3662016-11-11T17:10:49 <GoogleHater> It's too hard for me to download 100 GB without half-speed.
3672016-11-11T17:11:20 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3682016-11-11T17:13:40 <tulip> > and what if rowhammer is a backdoor and was implemented on purpose?
3692016-11-11T17:13:40 <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.
3702016-11-11T17:23:24 <Victorsueca> GoogleHater: I think it's planned to add a feature to limit or halt bandwidth usage
3712016-11-11T17:23:38 <Victorsueca> tulip: ik, I was joking
3722016-11-11T17:23:58 <GoogleHater> Second problem.
3732016-11-11T17:24:24 <GoogleHater> I'm using Tor through iptables.
3742016-11-11T17:24:41 <GoogleHater> My Bitcoin Core does not finding *.onion peers.
3752016-11-11T17:26:28 <Victorsueca> try adding yu7sezmixhmyljn4.onion, it's mine
3762016-11-11T17:31:43 *** Giszmo has quit IRC
3772016-11-11T17:39:36 <GoogleHater> I'm using Testnet now.
3782016-11-11T17:39:54 <GoogleHater> But I want to use mainnet soon.
3792016-11-11T17:40:29 <Victorsueca> ahh wait a second, i'll boot my testnet node
3802016-11-11T17:44:19 <Victorsueca> there, my testnet node is at agw4m7vx4gceyttj.onion
3812016-11-11T18:12:10 *** DigiByteDev has joined #bitcoin-core-dev
3822016-11-11T18:16:17 *** DigiByteDev has quit IRC
3832016-11-11T18:28:28 *** cryptapus has joined #bitcoin-core-dev
3842016-11-11T18:28:29 *** cryptapus has joined #bitcoin-core-dev
3852016-11-11T19:04:37 *** jtimon has quit IRC
3862016-11-11T19:30:13 *** Arnavion has quit IRC
3872016-11-11T19:31:32 *** Arnavion has joined #bitcoin-core-dev
3882016-11-11T19:40:00 *** Chris_Stewart_5 has quit IRC
3892016-11-11T19:40:18 *** tulip has quit IRC
3902016-11-11T19:45:39 <phantomcircuit> wumpus: i dont think it can actually fail
3912016-11-11T19:52:07 <phantomcircuit> yeah im pretty sure that ssKey >> strType; cannot fail actually
3922016-11-11T19:58:07 *** abc has joined #bitcoin-core-dev
3932016-11-11T19:58:29 *** abc is now known as Guest24458
3942016-11-11T20:00:01 *** Guest24458 has quit IRC
3952016-11-11T20:00:31 *** Guyver2 has joined #bitcoin-core-dev
3962016-11-11T20:06:10 *** jannes has quit IRC
3972016-11-11T20:10:01 *** d9b4bef9 has quit IRC
3982016-11-11T20:10:58 *** rabidus_ has quit IRC
3992016-11-11T20:21:26 <sipa> phantomcircuit: what if ssKey is empty?
4002016-11-11T20:23:33 *** Giszmo has joined #bitcoin-core-dev
4012016-11-11T20:46:36 *** dermoth has quit IRC
4022016-11-11T21:02:12 *** GoogleHater has quit IRC
4032016-11-11T21:07:52 *** cryptapus has quit IRC
4042016-11-11T21:09:23 <bitcoin-git> [bitcoin] ryanofsky opened pull request #9136: sync_blocks cleanup (master...sync-clean) https://github.com/bitcoin/bitcoin/pull/9136
4052016-11-11T21:10:16 <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
4062016-11-11T21:14:09 *** chris2000 has quit IRC
4072016-11-11T21:30:04 *** whphhg has joined #bitcoin-core-dev
4082016-11-11T21:30:04 <bitcoin-git> [bitcoin] morcos opened pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
4092016-11-11T21:32:42 <bitcoin-git> [bitcoin] morcos closed pull request #9123: Remove extraneous LogPrint from fee estimation (master...eliminateFeeWarning) https://github.com/bitcoin/bitcoin/pull/9123
4102016-11-11T21:37:24 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4112016-11-11T21:39:32 *** achow101 has quit IRC
4122016-11-11T21:52:44 <phantomcircuit> sipa: i guess it would fail then?
4132016-11-11T21:54:25 *** achow101 has joined #bitcoin-core-dev
4142016-11-11T21:55:21 <sipa> phantomcircuit: yes, std::ios_base::failure("CDataStream::read(): end of data")
4152016-11-11T21:57:37 <phantomcircuit> the question is really how much checking of the result do we want to do?
4162016-11-11T21:57:46 <sipa> phantomcircuit: i miss context
4172016-11-11T22:04:36 *** nibor has joined #bitcoin-core-dev
4182016-11-11T22:07:53 <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
4192016-11-11T22:09:42 *** zmanian____ has quit IRC
4202016-11-11T22:09:55 *** zmanian has joined #bitcoin-core-dev
4212016-11-11T22:11:34 *** Chris_Stewart_5 has quit IRC
4222016-11-11T22:14:03 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4232016-11-11T22:17:50 *** Guyver2 has quit IRC
4242016-11-11T22:30:36 *** cryptapus_afk is now known as cryptapus
4252016-11-11T22:42:21 *** cryptapus has joined #bitcoin-core-dev
4262016-11-11T22:42:22 *** cryptapus has joined #bitcoin-core-dev
4272016-11-11T22:42:28 *** cryptapus is now known as cryptapus_afk
4282016-11-11T22:56:06 *** luke-jr has quit IRC
4292016-11-11T22:56:14 *** luke-jr has joined #bitcoin-core-dev
4302016-11-11T23:07:59 *** btcdrak has quit IRC
4312016-11-11T23:18:15 *** niska` has joined #bitcoin-core-dev
4322016-11-11T23:18:26 *** niska has quit IRC
4332016-11-11T23:31:38 *** abpa has quit IRC