< 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
<@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>
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>
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
< 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?
< 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)
< 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.
< 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.
<@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.
< 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
< 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.
< 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
< 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
< 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
< 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.