< 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
< cfields> sipa: interesting
<@sipa> cfields: the PR above?
< cfields> sipa: yes
< sipa> i was surprised that i didn't need to touch any of the block or transaction serialization logic
< cfields> yes, it's simpler than I would've expected too
< cfields> trying to decide how much foot-gun the serialize.h changes allow
< sipa> the shared_ptr serializer only applies when the element type is const
< cfields> sipa: yep, actually seems innocuous
< 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
< sipa> cfields: right, but that doesn't apply when the element type is const
< sipa> you can just see the different shared_ptr's as deduplicated copies of the same data
< cfields> yes. I like it :)
< 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.
< cfields> yes, this seems like a really good use-case.
< 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.
< cfields> s/requires/allows/
< sipa> cfields: well that would better be served by using shared_ptr's to CBlock itself
< cfields> sipa: i was wondering if that's the next logical step. I don't think they'd be mutually exclusive?
< sipa> cfields: sure
< sipa> there are probably a few more optimizations that i haven't addressed
< sipa> i think ATMP should take a shared_ptr
< sipa> so a reorg wouldn't require a copy back from the block to the mempool
< bitcoin-git> [bitcoin] theuni opened pull request #9128: net: Decouple CConnman and message serialization (master...connman-send) https://github.com/bitcoin/bitcoin/pull/9128
< bitcoin-git> [bitcoin] rebroad opened pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
< luke-jr> should we be using std::random_device?
< sipa> luke-jr: afaik it has 0 guarantees
< luke-jr> can't hurt though, right?
< luke-jr> (and what's the point of the exception if there's no guarantees at all? O.o)
< sipa> the exception is for when no random number can be generated at all
< sipa> even if it generates one, it doesn't guarantee cryptographic quality (or any quality at all)
< fanquake> Competing pull-requests seems to be a "thing" now..
<@wumpus> yeah...
<@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
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71bc39eb7483...21e6c6b569c5
< bitcoin-git> bitcoin/master 617c96d fanquake: [depends] Set OSX_MIN_VERSION to 10.8
< bitcoin-git> bitcoin/master 21e6c6b Wladimir J. van der Laan: Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8...
< 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
<@wumpus> we're better off implementing our own secure random functionality, given how critical it is for the wallet at least
<@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...
< 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?
<@wumpus> Victorsueca: maybe. At the least we should be reading /dev/urandom ourselves
<@wumpus> it's not rocket science and there is nothing to be gained by hiding it behind layers of abstraction
< Victorsueca> sounds good, definitely better than using the default source of randomness which could be backdoored by the hardware manufacturer
< sipa> if your hardware is backdoored, the technical term for the situation you're in is: utterly fucked
<@wumpus> that's not really the threat model we're fighting here...
<@wumpus> right
< luke-jr> wumpus: I just meant in addition to other entropy sources
<@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
< 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
<@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...
< luke-jr> just happened to glance at that shell at the right instant
< 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
< luke-jr> eh, Intel ME is a pretty low risk explicit backdoor
< Victorsueca> is the kind of thing I never seen but I think it should already exist
< luke-jr> Victorsueca: pretty sure something does using radio waves
<@wumpus> luke-jr: well in any case thanks for letting me know it exists at all, it may be useful for some other projects
<@wumpus> Victorsueca: those exist and are in active use, both for secure randomness and by gambling sites
< Victorsueca> wumpus: thought gambling sites used atomic event observation which is pretty expensive devices, I was thinking on something affordable for any home user
<@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 :-)
< luke-jr> heh
< Victorsueca> and what if rowhammer is a backdoor and was implemented on purpose?
< * Victorsueca> adjusts tinfoil hat
<@wumpus> Victorsueca: there's low end and high end devices in that range, just a google away :p
<@wumpus> you can even build a randomness device pretty easily yourself, building unstable hardware is not rocket science :-)
< Victorsueca> wumpus: maybe, but preventing it from putting your house on fire is ;)
< Victorsueca> then use the shape of the flames as random source
<@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
<@wumpus> similar, though much more general.
<@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)
<@wumpus> Victorsueca: ascribing such natural engineering properties to state actors is paranoid to the level of schizofrenia :)
<@wumpus> *finding* these kinds of bugs on the other hand is something they're certainly working very hard at
< Victorsueca> they control temperature and humidity to manipulate your randomness
< * Victorsueca> puts tinfoil around his parts
< Victorsueca> jokes apart, Yesterday I had an idea
< Victorsueca> would be possible to make that after abandoning a transaction core spends the same inputs for the next transaction you make?
< Victorsueca> I think it's possible, the question would rather be if it makes sense
<@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
<@wumpus> delaying it until you happen to need to send again creates a potentially huge time window in which you're exposed
< Victorsueca> I was thinking on somebody who has his transaction stuck because ha paid a low fee
< Victorsueca> so he abandons the transaction and double-spends it with a higher fee
<@wumpus> just use RBF?
< Victorsueca> then why is there a banadon transaction button at all?
< Victorsueca> abandon*
< Victorsueca> not to mention RBF is not yet implemented in the GUI
<@wumpus> bumpfee needs to be on RPC first e.g. see https://github.com/bitcoin/bitcoin/pull/8456
<@wumpus> all needs review
<@wumpus> sorry to say this but we need more review and testing on actual work people are doing, not out-there ideas
< Victorsueca> it's ok
< 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
<@wumpus> no, it's not
< Victorsueca> thought so
<@wumpus> changes to coin selection are one of the most difficult categories of changes
< Victorsueca> well, I can help testing changes on windows, AFAIK few devs work on windows
<@wumpus> awesome!
< fanquake> Great!
< fanquake> There is always need for more reviewers, especially on Windows, because as you've mentioned, few devs are using it.
<@wumpus> yes especially for GUI changes there's pretty few testers at all
< 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.
< jonasschnelli> For multiwallet, this PR is large but simple to review: https://github.com/bitcoin/bitcoin/pull/8764
< phantomcircuit> wumpus: the wallet recovery stuff will print a warning if it fails to parse the value in the key/value pair
< phantomcircuit> this is the last reference to CWallet from CWalletDB
< phantomcircuit> i have a patch that just removes this
< phantomcircuit> i'd like to know what you think about it
< phantomcircuit> (not the patch, removing the warning)
<@wumpus> please don't remove that warning. You can't move it anywhere else?
<@wumpus> we have open issues with salvagewallet that's why the debug level there was increased
< phantomcircuit> ok i'll take another look at it to see if there's a better way of handling that
< phantomcircuit> (i mean really the better way would be a completely separate tool, but that is not in scope)
< fanquake> wumpus: I've ack'd #9112 if you just want to merge it.
< 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
<@wumpus> phantomcircuit: jonasschnelli made such a tool https://github.com/bitcoin/bitcoin/pull/8745 - but yeah that's out of scope
< jonasschnelli> wumpus: we first need to solve the cirular dependencies.
<@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
< jonasschnelli> *circular
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21e6c6b569c5...46027e8668ec
< bitcoin-git> bitcoin/master e9f25dd Wladimir J. van der Laan: Avoid ugly exception in log on unknown inv type...
< bitcoin-git> bitcoin/master 46027e8 Wladimir J. van der Laan: Merge #9112: Avoid ugly exception in log on unknown inv type...
< 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
< 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
< Victorsueca> how do you do to pull a unmerged pull request into your working directory?
< fanquake> Have a look at the github-merge script in this dir https://github.com/bitcoin/bitcoin/tree/master/contrib/devtools
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/46027e8668ec...7977a1157a3a
<@wumpus> contrib/devtools/github-merge.py 1234
< bitcoin-git> bitcoin/master 47e9659 Russell Yanofsky: [qa] Fix bug in compactblocks v2 merge...
< bitcoin-git> bitcoin/master 55bfddc Russell Yanofsky: [qa] Fix stale data bug in test_compactblocks_not_at_tip...
< bitcoin-git> bitcoin/master dac53b5 Russell Yanofsky: Modify getblocktxn handler not to drop requests for old blocks...
<@wumpus> yes, that :)
< 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
< jonasschnelli> heh
<@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
<@wumpus> (where "upstream" is the name of your remote for bitcoin/bitcoin, big chance it is "origin" for you)
< jonasschnelli> For testing, it's probably better if you test them applied on the current master
< jonasschnelli> (unless they have merge conflicts)
<@wumpus> yes, true
< Victorsueca> ok, got it, thanks
< Victorsueca> building it at the moment
< bitcoin-git> [bitcoin] jonasschnelli pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/7977a1157a3a...ab914a65301b
< bitcoin-git> bitcoin/master 7c9a98a Jon Lund Steffensen: Allow network activity to be temporarily suspended....
< bitcoin-git> bitcoin/master e38993b Jon Lund Steffensen: RPC: Add "togglenetwork" method to toggle network activity temporarily...
< bitcoin-git> bitcoin/master 32efa79 Jon Lund Steffensen: Qt: Add GUI feedback and control of network activity state....
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
< Victorsueca> it's me or this new bot is more spammy than the previous one?
< luke-jr> just you
< jonasschnelli> Luke-Jr: how do we continue with https://github.com/bitcoin/bitcoin/pull/8889? Close?
< luke-jr> for now
< 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
< jonasschnelli> Okay. Yes. We can always reopen this.
< luke-jr> I suspect the problems were due to tooltips not normally having focus
< luke-jr> ie, the theme doesn't bother defining the tooltip-with-focus colours sanely
<@wumpus> there is no 'new bot', I've just changed its configuration to use a consistent name
<@wumpus> if it seems more spammy it's just because there's a lot of merging going on
< Victorsueca> ahh ok
< Victorsueca> 0.14 seems like it's finally going to be a version dedicated to GUI and wallet
<@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
< fanquake> wumpus: If you want to get the PR list down, there are a few trivial ones.
<@wumpus> fanquake: sure, let me know
< fanquake> #9115 has been updated so can get ACK'd/merged.
< gribble> https://github.com/bitcoin/bitcoin/issues/9115 | Mention reporting security issues responsibly by paveljanik · Pull Request #9115 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab914a65301b...bfc7aad00884
< bitcoin-git> bitcoin/master 7d1de30 Pavel Janík: Mention reporting security issues responsibly
< bitcoin-git> bitcoin/master bfc7aad Wladimir J. van der Laan: Merge #9115: Mention reporting security issues responsibly...
< bitcoin-git> [bitcoin] laanwj closed pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/9064 | unify capitalization of "bitcoin address" by s-matthew-english · Pull Request #9064 · bitcoin/bitcoin · GitHub
<@wumpus> ooh capitalizing Bitcoin just now that internet is no longer going to be capitalized :)
< Victorsueca> heh
<@wumpus> I don't really care, I guess it makes sense to be consistent though...
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/8983 | WIP: Log block height and size when received by rebroad · Pull Request #8983 · bitcoin/bitcoin · GitHub
< paveljanik> wumpus, internet and Internet are two different things... ;-)
< Victorsueca> shouldn't be really difficult to change capitals, except for some languages like German where concepts are one-worded
<@wumpus> paveljanik: "the internet of different things"
<@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
< Victorsueca> not to mention that could cause people blames capitals being wrong, I still remember when someone put "advertize" in the log messages
< Victorsueca> almost starts WW3
<@wumpus> capital punishment
< fanquake> #9124 Is a trivial merge, variable renaming in the benchmarking code.
< 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
<@wumpus> phantomcircuit: I don't understand why you can't keep a warning in #9101 when the try{...} fails
< gribble> https://github.com/bitcoin/bitcoin/issues/9101 | [Wallet] Do not parse ssValue in CWalletDB::Recover by pstratem · Pull Request #9101 · bitcoin/bitcoin · GitHub
<@wumpus> you do catch(...) { continue; } silently ignoring aspecific exceptions is usually a code smell and means there should be a warning at least
<@wumpus> silent errors mean that someone is going to have a very difficult time troubleshooting at some point
< Victorsueca> what about make it silent by default but not when -debug is enabled?
<@wumpus> WHY?
<@wumpus> salvagewallet is already a troubleshooting option
< Victorsueca> right
<@wumpus> why the hell would you want to have people enable debug to see when things go wrong? that's nonsense
< Victorsueca> maybe somebody who expects salvagewallet to go well doesn't want his logs nuked with lots of lines
< Victorsueca> if something goes wrong you can always try again with -debug
<@wumpus> if it goes well there will be no logging because it won't get there!
< Victorsueca> hmmm I don't know what would I do
<@wumpus> you're worrying about the bedsprings being noisy on the titanic while it is colliding against an iceberg
< rabidus_> :DD
< Victorsueca> heh yeah
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfc7aad00884...87ab49e4fe38
< bitcoin-git> bitcoin/master bf49f10 Pavel Janík: Use better name for local variable to prevent -Wshadow compiler warning
< bitcoin-git> bitcoin/master 87ab49e Wladimir J. van der Laan: Merge #9124: Use better name for local variable to prevent -Wshadow compiler warning...
< 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
< Victorsueca> - Mr president, the poles are melting, the global warming has reached too high extremes
< Victorsueca> - Thanks for informing, now go away
< Victorsueca> President* Looks at a Titanic picture
< Victorsueca> - The revenge is ours!
< fanquake> #9100 is another fairly trivial one, with your questions answered.
< 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
< 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
<@wumpus> I'd like an ack from someone else on #9100 before merging
< 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
<@wumpus> I'm not sure enough about it
<@wumpus> I think it's ok though
< fanquake> wumpus: I'll look at that shortly.
< 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.
< fanquake> I'm working on making the maintainer tools run on OS X so there are a few more people running them.
<@wumpus> for the Wshadow stuff I want to be entirely sure that it doesn't cause floods of warnings for anyone
<@wumpus> I don't want to enable it again and get complaints that some obscure compiler is generating a shitton of senseless warnings
< fanquake> Sure. Is them some threshold for compiler age/obscureness.
< fanquake> *there
<@wumpus> maybe a solution that enables it conditionally for compilers where it is shown to be ok
<@wumpus> yeah if someone wants to chase obscure rabbits there's enough issues, for example the bench crash on freebsd
<@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
<@wumpus> even if you enable it by default you may not see any warnings, but someone wit hcompiler Y might
<@wumpus> resulting in tons of extra nits on every pull
<@wumpus> or 'fix Wshadow after blablba' commits forever
< 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.
< fanquake> I think the improvements/potential bug catching effects of having it turned on should outweigh potential concerns?
< 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.
< MarcoFalke> Sadly there is no -Wshadow-common-for-all-compilers
< phantomcircuit> wumpus: the parsing is done by the CWallet dummyWallet
< phantomcircuit> which i removed entirely
< phantomcircuit> so the exception handling is basically just for the type not parsing
< MarcoFalke> phantomcircuit: Maybe add a comment why that case is not needed to be handled
< Victorsueca> ok, so I got #8456 built
< gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
< Victorsueca> how do I create a BIP 125 transaction?
< jonasschnelli> Victorsueca: createrawtransaction
< jonasschnelli> Victorsueca: set nSequence to INT::MAX-2
< jonasschnelli> but wait..
< Victorsueca> yeah, I'm trying to use createrawtransaction but not sure how to signal that the transaction is replaceable
< jonasschnelli> I though we have a global OptInRBF flag...
< jonasschnelli> but looks like we never merged it..
< * jonasschnelli> checking...
< Victorsueca> i'm currently using head f3833f4
< jonasschnelli> Victorsueca: we have one!
< jonasschnelli> -walletrbf=1
< Victorsueca> nice, will try that
< jonasschnelli> This will autoset the inputs nSequence Number to INT::MAX-2
< jonasschnelli> phantomcircuit: ping
< jonasschnelli> In PR9101 you mentioned that "Removes the last dependency from walletdb.cpp on CWallet."
< jonasschnelli> I see other CWallet interaction in walletdb.cpp
< jonasschnelli> IMO CWalletDB should be hidden behind CWallet
< jonasschnelli> And CWalletDB should habe no knowhow of CWallet
< Victorsueca> nice, it worked
< Victorsueca> got to bump the fee for a transaction from 260sat to 520sat
<@wumpus> phantomcircuit: why would 'type not handled' not need to be warned about?
< jonasschnelli> Victorsueca: nice! Please report on the PR and ACK
< 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
< Victorsueca> done, ping me whenever you need to test something on windows
< jonasschnelli> Victorsueca : thx
< Victorsueca> no problem
< bitcoin-git> [bitcoin] morcos opened pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
< GoogleHater> Hello.
< GoogleHater> Why speed limit isn't implemented in Bitcoin Core?
< Lauda> What speed limit?
< GoogleHater> It's too hard for me to download 100 GB without half-speed.
< tulip> > and what if rowhammer is a backdoor and was implemented on purpose?
< 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.
< Victorsueca> GoogleHater: I think it's planned to add a feature to limit or halt bandwidth usage
< Victorsueca> tulip: ik, I was joking
< GoogleHater> Second problem.
< GoogleHater> I'm using Tor through iptables.
< GoogleHater> My Bitcoin Core does not finding *.onion peers.
< Victorsueca> try adding yu7sezmixhmyljn4.onion, it's mine
< GoogleHater> I'm using Testnet now.
< GoogleHater> But I want to use mainnet soon.
< Victorsueca> ahh wait a second, i'll boot my testnet node
< Victorsueca> there, my testnet node is at agw4m7vx4gceyttj.onion
< phantomcircuit> wumpus: i dont think it can actually fail
< phantomcircuit> yeah im pretty sure that ssKey >> strType; cannot fail actually
< sipa> phantomcircuit: what if ssKey is empty?
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9136: sync_blocks cleanup (master...sync-clean) https://github.com/bitcoin/bitcoin/pull/9136
< 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
< bitcoin-git> [bitcoin] morcos opened pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
< bitcoin-git> [bitcoin] morcos closed pull request #9123: Remove extraneous LogPrint from fee estimation (master...eliminateFeeWarning) https://github.com/bitcoin/bitcoin/pull/9123
< phantomcircuit> sipa: i guess it would fail then?
< sipa> phantomcircuit: yes, std::ios_base::failure("CDataStream::read(): end of data")
< phantomcircuit> the question is really how much checking of the result do we want to do?
< sipa> phantomcircuit: i miss context
< 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