< phantomcircuit>
luke-jr, im looking at the wallet accounting tests (which afaict you wrote)
< phantomcircuit>
im confused by things like vpwtx[0]->nTimeReceived = (unsigned int)1333333335;
< phantomcircuit>
it seems like the unit test is mucking around with the internals of the wallet?
< GitHub143>
[bitcoin] rebroad opened pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8595
< luke-jr>
phantomcircuit: could be
< kanzure>
16:54 < saurik> so, I just spent a bunch of time making certain I didn't miss anything via IRC, and I've also checked e-mail. were they intending to tell me anything? I am kind of in shock that of all projects, bitcoin, another open source project, is now continuing the pattern of "we found something mysterious that we fixed that we don't bother mentioning directly to upstream"
< kanzure>
18:53 < kanzure> saurik: bitcoin core just a bunch of people hanging out on irc doing stuff. so i pinged you about it.
< kanzure>
i mean.. i don't expect how else to inform upstream other than sending messages :P.
< gmaxwell>
mindrays.
< kanzure>
shh don't tell them about my mind rays
< midnightmagic>
i thought they were my mindrays
< midnightmagic>
D-:
< Squidicuz>
woah.. full frontal lobotomy button, and now mindrays?!
< midnightmagic>
we are.. groot?
< phantomcircuit>
kanzure, what's he even talking about?
< kanzure>
don't speak so ill of the lobotomy</nobel prize committee>
< kanzure>
(actually i'm joking. no idea why that got the nobel prize.)
< kanzure>
phantomcircuit: osx code signing O_o
< phantomcircuit>
kanzure, you see you should have connected to his personal irc server
< kanzure>
actually you're right, there really is an irc.saurik.com
< midnightmagic>
:-o
< luke-jr>
kanzure: a pull request? :P
< cfields_>
kanzure: i fully intended to upstream it
< cfields_>
kanzure: what channel? I'll ping him to discuss
< midnightmagic>
I dunno if he really knows what it means to invite rando bitcoiners in to his IRC. :(
< dcousens>
is there any way to turn off pretty-printing in the bitcoind RPC JSON?
< kanzure>
cfields_: pm
< cfields_>
thanks
< kanzure>
cfields_: btw i don't think it's urgent; i just found his response funny :).
< cfields_>
kanzure: sure, i'd just like him to understand that I planned to PR it, but it's just a bunch of hard-coded hacks still
< dcousens>
phantomcircuit: nevermind, its just bitcoin-cli being smart :)
< phantomcircuit>
dcousens, yeah i think univalue always produces a single line
< dcousens>
phantomcircuit: yup, my bad, went into tcpdump and yeah its not pretty printed over the wire which is all I cared about
< phantomcircuit>
dcousens, as someone who is very guilty of this
< phantomcircuit>
i usually fine that if something looks dumb it is not
< phantomcircuit>
except when it is
< dcousens>
phantomcircuit: haha, yup. I need to put the rubber duck back on my desk, it usually gets most of my stupid questions before I branch out haha
< phantomcircuit>
luke-jr, indeed i think the unit tests are broken
< phantomcircuit>
or rather are testing the behaviour too specifically
< luke-jr>
"too specifically" is often subjective. ☺
< gmaxwell>
not really, ideally a test fails when the software is broken and only fails in those cases, passes when the software is not broken and only passes in those cases.
< gmaxwell>
this is an objective standard you can judge a test against, even if its not usually achievable for most functions.
< gmaxwell>
it can be useful, at times, to have test functions which define 'broken' as 'changes in any way at all'; but thats special and not usually a good requirement for tests; especially for functions which you intend to actually change.
< phantomcircuit>
luke-jr, can you explain why it's testing wtx nTimeReceived ?
< luke-jr>
gmaxwell: IMO there's a grey area smart times fall into. you don't care about the exact behaviour or even exact results per se, but you probably do need to test for exact results to know the results are sane.
< luke-jr>
phantomcircuit: what file/module is this?
< gmaxwell>
luke-jr: if you can't define "sane" better than "same as before" -- can anyone really know if the code is right or not? :P
< gmaxwell>
I don't think it's necessarily bad to have tests that do nothing but tell you if something changed, but if thats all we have, then we don't really have tests that are useful for anything except maybe refactoring.
< luke-jr>
gmaxwell: for example, some payment protocol could possibly provide better time estimate to a user that was offline at the time
< gmaxwell>
Consider, you intentionally change a function. Exact behavior tests fail, well "no shit"-- but was your change correct or not? the 'test' gives you no insight-- it just told you something you already knew.
< luke-jr>
phantomcircuit: it's testing that nTimeReceived either does or doesn't influence the sorting order as it should[n't]
< luke-jr>
gmaxwell: in this case, it's creating CWalletTxs, adding them to the wallet, and checking the sort comes out correct
< luke-jr>
(I was wrong thinking it was doing smart fee stuff; it's sort order)
< phantomcircuit>
luke-jr, is there something that describes how the smart time stuff works?
< luke-jr>
phantomcircuit: not besides the code, AFAIK. essentially when a new transaction is seen, it uses the earlier of the block time or received/current time, unless that's before the time of the most recent known transaction (within reason)
< luke-jr>
if the most recent known transaction is newer, it won't go backward
< luke-jr>
unless it's significantly earlier, IIRC 15 minutes or so
< phantomcircuit>
luke-jr, so you're simulating the blocktime?
< jonasschnelli>
gmaxwell: Though about the idea of the BLOB (encrypted key) stored in the wallet and passed to the signer. Do you propose that signing operations will be done in a separate process (or application) by handing over the required tx data and the encrypted private key?
< gmaxwell>
Yes. And the signer program has you confirm the transaction, enter the passphrase, returns the result.
< gmaxwell>
and it can have 100% mlocked memory, be highly sandboxed, etc.
< jonasschnelli>
How do the encrypted private keys get there in the first place?
< gmaxwell>
It generates them and gives the blob to the wallet, like you were thinking with 'getnewaddress'... but there would be an 'init' or 'initwallet' call.
< jonasschnelli>
So the signing device creates the encrypted keys,... what the reason of passing them to the wallet instead of keeping track (storing) them in the signers space?
< jonasschnelli>
*whats
< jonasschnelli>
Ah. mlocked mem
< gmaxwell>
because then you have two files to backup for you wallet, and now the signer needs filesystem access.
< jonasschnelli>
gmaxwell: Yes. I think this would be a nice add-on. Would be nice if the transport layer would be flexible enough to also support hardware wallets.
< jonasschnelli>
Hardware wallet will probably not export encrypted private keys.
< jonasschnelli>
So the "blob" could be optional.
< gmaxwell>
Yes. Also third party co-signers... or at least extended to that eventually.
< gmaxwell>
yes, it would be optional, but-- I dunno, perhaps a reasonable way to construct a low cost hardware wallet-- why give it any flash? all rom. :)
< jonasschnelli>
IMO the main problem with co-signing is the missing infrastructure for the communication layer, how to pass partial-signed transaction to the co-signer, etc.
< jonasschnelli>
The problem with the blob storing encrypted keys is the backward and forward-security IMO
< jonasschnelli>
A leaked encryption password will result in compromising everything
< GitHub61>
[bitcoin] rebroad opened pull request #8597: [WIP] Move code from VERACK to VERSION (since VERACK is not requied) (master...NotDependentOnVerack) https://github.com/bitcoin/bitcoin/pull/8597
< jonasschnelli>
I'd personally prefer only keeping pub-keys in my wallet and sign on a different system where the priv-keys are not exposed to many I/Os
< luke-jr>
phantomcircuit: I'm not sure - do smart fees even have tests?
< luke-jr>
smart times*
< phantomcircuit>
luke-jr, the accounting stuff appears to be th eonly thing testing them
< phantomcircuit>
and really it shouldn't be
< phantomcircuit>
it should at most be testing that they have the expected order
< luke-jr>
oh, the commit itself describes it: c3f95ef13f48d21db53992984976eac93e7a08fc
< GitHub134>
[bitcoin] jonasschnelli closed pull request #8135: [OSX] fix make deploy when compiling on OSX (master...2016/06/makedeploy) https://github.com/bitcoin/bitcoin/pull/8135
< GitHub48>
[bitcoin] fivepiece opened pull request #8598: Fix displaying of invalid and non-minimal small pushes as numbers (master...fixasm) https://github.com/bitcoin/bitcoin/pull/8598
< arubi>
<- ^, if anyone has questions
< jonasschnelli>
arubi: just commented that some tests would be nice
< arubi>
yep. I'll have a look!
< jonasschnelli>
thanks
< GitHub164>
[bitcoin] laanwj closed pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8595
< jonasschnelli>
sipa: Changing nCoinCacheUsage outside of the init process should be possible (assume covered under a LOCK)? What do you think in having two values, one for in-sync, one for catching up... maybe an additional -dbcacheinsync?
< jonasschnelli>
I guess sudden reduction of nCoinCacheUsage will just result in writing the state during the next FlushStateToDisk() while "overshooting" the new set target during the time until we do the next FlushStateToDisk()?
< sipa>
use an atomic instead of a lock
< jonasschnelli>
sipa: Indeed. What do you think about -dbcacheinsync?
< gmaxwell>
I don't think I've ever seen a user report that would really be helped by that.
< jonasschnelli>
Not sure if we should change nCoinDBCache and nBlockTreeDBCache during "runtime"
< gmaxwell>
I think we'd be using a much larger dbcache except we want to work correctly on the common 2gb hosts and vpses.
< gmaxwell>
and those hosts would crash during sync if it was bigger during sync.
< sipa>
i actually would want a separate dbcache value in IBD on my phone :)
< gmaxwell>
now-- allowing the dbcache to use memory the mempool isn't using-- that would be a useful stunt.
< GitHub129>
bitcoin/master 259ee09 R E Broadley: Show "end" instead of many zeros when getheaders request received with a hashStop of Null.
< GitHub129>
bitcoin/master 6c9f1b8 Wladimir J. van der Laan: Merge #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null...
< gmaxwell>
but wouldn't need an option (hurray)
< GitHub110>
[bitcoin] laanwj closed pull request #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null (master...LessGetheadersZeros) https://github.com/bitcoin/bitcoin/pull/8561
< jonasschnelli>
I started adding a DBCache option during the intro screen on the GUI... And I think users don't want to "waste" 2GB (example) during in-sync state... but they may want 2GB during IBD.
< sipa>
i think 2GB is not much anymore for most desktop systems
< sipa>
but there are others
< gmaxwell>
on systems where you're okay using that at ~any~ point, it's probably not a bad idea at all times. :(
< gmaxwell>
keep in mind too small a dbcache is responsible for some of the io thrashing users frequently complain about.
< phantomcircuit>
sipa, it would actually be nice to have a "stall" function for things which regularly overheat
< sipa>
phantomcircuit: you shouldn't run a full node on hardware that overheats
< phantomcircuit>
sipa, that covers virtually all phones and most laptops
< gmaxwell>
sipa: that excludes about 75% of laptops available commercially now.
< jonasschnelli>
;-)
< phantomcircuit>
the thermal protection stuff isn't designed for continuous load
< sipa>
heh
< gmaxwell>
only a few makers actually build hardware that can stat sustained load. (your lenovo being such an example)
< gmaxwell>
s/stat/stand/
< gmaxwell>
though it doesn't crash when overheating.
< gmaxwell>
mostly.
< phantomcircuit>
gmaxwell, 10:1 his lenovo is not designed for continuous max load either
< gmaxwell>
phantomcircuit: the t-series are.
< gmaxwell>
the x1 isn't, as I'm sure you've noticed.
< sipa>
i have a w540
< gmaxwell>
sipa: those too.
< phantomcircuit>
i have indeed
< phantomcircuit>
the t series is not generally designed for max tdp actually
< phantomcircuit>
they're more like 80%
< phantomcircuit>
the x1 is maybe 50%
< phantomcircuit>
a w450 probably is
< phantomcircuit>
540
< phantomcircuit>
whatever
< gmaxwell>
in any case, what about the suggestion I made about dbcache using unused mempool space?
< gmaxwell>
that basically matches the sync and cachup use case... and doesn't add parameters.
< sipa>
ugh.
< phantomcircuit>
gmaxwell, eh we should just fix this and have a unified "memory usage" thing
< gmaxwell>
It's only stupidly hard, have courage.
< phantomcircuit>
implement out own oom killer
< phantomcircuit>
:P
< phantomcircuit>
our
< sipa>
now normal transaction relay can trigger utxo flushing
< sipa>
actually, it already does
< gmaxwell>
yea, well if the flushing were ... less dumb, that wouldn't be a big deal.
< gmaxwell>
what I'm suggesting could be something kinda dumb, like, when the mempool goes over 10MB. take the 290 MB away from the dbcache, flushing once. and then go on with life.
< phantomcircuit>
gmaxwell, i tried making it less dumb and broke one of the unit tests
< phantomcircuit>
i dont think what i did was broken actually
< gmaxwell>
one can analyize the blockchain history to evaluate candidate eviction policies.
< phantomcircuit>
gmaxwell, yeah my eviction policy was random eviction
< phantomcircuit>
but even that broke the tests
< phantomcircuit>
so idk
< gmaxwell>
you need to carefully handle dirty entries.
< gmaxwell>
phantomcircuit: random eviction is probably pretty bad. I was thinking of taking age, total value, remaining txouts, then fitting a piecewise linear model to create an eviction score that gives the best hitrate when tested against the historical chain with some simulated cache size.
< jonasschnelli>
sipa: regarding your profiles idea: https://github.com/bitcoin/bitcoin/issues/8437, how could setting profile values make sense? I guess in bitcoin.conf would be ideal (not another file), this would mean, it must be something like -profile0-par or -profile1-maxconnections, etc.
< phantomcircuit>
gmaxwell, i just ignored dirty entries
< phantomcircuit>
still broke the unit tests
< sipa>
jonasschnelli: the profiles would just be hardcoded
< gmaxwell>
considering the tests work fine if you twiddle the dbcache size, you screwed something up. Perhaps you were dropping things while views existed.
< sipa>
the only option you have is selecting which profile to ude
< jonasschnelli>
sipa: this seems not to scale,..
< sipa>
how so?
< jonasschnelli>
If it covers DBCache, we would need to adjust the static value over time
< sipa>
why?
< sipa>
it corresponds to the amount of resources it can use
< jonasschnelli>
Lets say, we have a hardcoded profile "large", it could cover 2GB dbcache,.. in 3 years, the UTXO set is larger, computers have more RAM...
< sipa>
ok, then we occasionally update the profole
< sipa>
or add a "verylarge"
< jonasschnelli>
heh
< sipa>
allowing people to modify the profile seems to defeat the prupose
< jonasschnelli>
Not sure if I like hardcoded values...
< sipa>
why don't they just modify the settings directly?
< jonasschnelli>
Whats the advantage over -profile0-dbcache (could still have hardcoded defaults)
< sipa>
why would you have -profile0-dbcache, and not just... -dbcache ?
< sipa>
if you're going to override it, override it
< jonasschnelli>
Okay.. I see .. let me explain.
< jonasschnelli>
I'd like to have switchable profile...
< jonasschnelli>
Some users might want to run in blocksonly (or par=1) during a time when they want to use the system for different purposes
< jonasschnelli>
Then, switch back to a different profile when their system is idling
< sipa>
mobile phones used to have configurable profiles... for different times of the day, for special contants, ...
< sipa>
nobody used those as they take way too much time to maintain
< gmaxwell>
I feel like it's a mistake to optimize for users going in and twiddling detailed settings at runtime. Thats adding a feature less than 1% of users would use at all, and half of those who would use it would probably use it in confused ways.
< jonasschnelli>
Yes. You could set your "low bandwith" profile to take affect during 23:00 - 06:00 or so
< sipa>
and phones switched back to very simple things, like 3 preconfigured ones
< jonasschnelli>
Remember when we had the PR for "pause network activity"
< jonasschnelli>
I guess there are some users out there who like to change the resource consumption during runtime.
< sipa>
the point of profiles is to allow people to have more control with fewer tweakable
< sipa>
not mkre knobs
< sipa>
ok, so make the profile switchable at runtime
< gmaxwell>
jonasschnelli: yes, though often even that is someone trying to rationalize their suffering from something else we've screwed up.
< jonasschnelli>
Yes. Switchable during runtime makes sense... but I don't understand why there should be no optional -profile0-par, default overwrite option
< gmaxwell>
So for example, bandwidth bursts are distrubing their VoIP, so they ask for a pause. We can provide, but 1% of the users having the problem will find it and use it, the rest will suffer or just remove bitcoin.
< sipa>
jonasschnelli: pfft we could add that, but i think it's a waste of time
< jonasschnelli>
My goal is that people will not shut down bitcoin-qt in order to do a VoIP call (because restarting in pain in the ass).
< gmaxwell>
time spent setting up and maintaining knobs for a tiny pool of highly advanced users would usually be better spent figuring out the root issues that drive them to have any reason to customize at all.
< jonasschnelli>
Not sure if this feature would be for highly advanced users...
< jonasschnelli>
It could be a "turtle icon" somewhere with a tooltip "use less resources"...
< gmaxwell>
then we should fix it so that it doesn't screw up voip, _generally_, even when they don't know bitcoin is the cause, not by finding some obscure option.
< sipa>
jonasschnelli: that's why we have compact blocks and not pause network :)
< gmaxwell>
if you've figured out that bitcoin is the cause you are already more advanced than we should hope for, usually once they've figured that out bitcoin is doomed. :P
< jonasschnelli>
Yes. But IMO is a fact that people have stopped running bitcoin-qt because of its extensive resource consumption. But maybe I'm wrong here.
< gmaxwell>
I feel like you're not listening to me. :(
< jonasschnelli>
I agree with fixing it in the first place... but some stuff is on a layer not controllable by our stack.. like QoS.
< gmaxwell>
I agree that they have, but they will continue to stop running it unless the resource consumption is improved-- adding some advanced profile things will save a few users, but not that many.
< jonasschnelli>
Partially agree on that.
< gmaxwell>
and exposing many settings to users actually complicates improving resource management, since we have to figure out how to handle changing the sensible parameters.
< jonasschnelli>
A non-dump dbcache option would be significant more worth then a dbcache profile option
< sipa>
i don't think there is any problem with providing options to modify what the profiles correspond wth, and perhaps there is a good use for it... but having profiles in the first place is so much more valuable
< sipa>
right now, almost no user modify dbcache, and even less know that there are half a dozen other settings that affect memory usage
< sipa>
don't get carried away with configurability
< sipa>
the problem we're facing is that most users don't even touch the few settings we do have, adding more won't improve that
< phantomcircuit>
gmaxwell, hmm maybe i was dropping things while a view existed?
< MarcoFalke>
What about -maxtotalmem, and bitcoind will figure out how to use that memory on it's own?
< phantomcircuit>
im not sure actually
< sipa>
MarcoFalke: except we don't have good accounting for all of the memory yet
< jonasschnelli>
Yes. Maybe in the GUI intro we can offer a switch between "low" (default), "moderate" (1GB cache,...) and "height" (3GB cache).
< sipa>
MarcoFalke: and it is pretty hard to do due to memory fragmentation etc
< gmaxwell>
consider, if _we_ knew how to set all these things, we'd set them and not bother writing and translating UI for them.. but if we don't know how to set them, the user almost certantly doesn't.
< sipa>
jonasschnelli: yes, that's what i propose
< sipa>
jonasschnelli: but it could affect a few more options than dbcache
< gmaxwell>
MarcoFalke: ultimately thats what we should have, but it's hard. (and probably can't be done without changing to jemalloc, ... memory accounting was a big reason firefox changed to jemalloc, in fact)
< jonasschnelli>
Okay. What happens if a user sets profile "hight" (3GiB) and has only 2GB wired ram?
< jonasschnelli>
sipa: yes. more options..
< sipa>
jonasschnelli: no, less options
< sipa>
jonasschnelli: there is low, medium, and high
< jonasschnelli>
yes. I meant more values that are affected by the profiles.
< jonasschnelli>
-par, -maxuploadtarget, etc.
< sipa>
and each corresponds to a preset oglf settings for mempool, dbcache, maxconnections, ...
< sipa>
exactly
< sipa>
we could do a quick test
< sipa>
but i don't know if physical memory is portably detectable
< sipa>
allocate a gilb and see how fast a random walk through it is? :)
< * jonasschnelli>
:|
< sipa>
*gb
< gmaxwell>
too bad container objects basically force runtime allocation. :(
< phantomcircuit>
sipa, what are the assumptions CCoinsViewCache makes about it's contents?
< phantomcircuit>
if something isn't marked dirty i assumed it could just be removed
< phantomcircuit>
is this wrong?
< sipa>
yes, unless there is another view on top
< sipa>
in that case you are not allowed to modify it in any way
< GitHub65>
[bitcoin] MarcoFalke opened pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (0.13...Mf1608-walletRpcDropBackport) https://github.com/bitcoin/bitcoin/pull/8600
< GitHub161>
[bitcoin] laanwj opened pull request #8601: Add option to opt into full-RBF when sending funds (rebase) (master...2016_08_full_rbf_option) https://github.com/bitcoin/bitcoin/pull/8601
< GitHub138>
[bitcoin] laanwj closed pull request #7132: Add option to opt into full-RBF when sending funds (master...2015-11-opt-into-full-rbf-option) https://github.com/bitcoin/bitcoin/pull/7132
< * MarcoFalke>
likes sipa's new GitHub icon
< phantomcircuit>
sipa, how can you tell if there's another view on top?
< phantomcircuit>
also, why?
< sipa>
phantomcircuit: uh.. i can't say for sure. i've swapped out the understanding that resulting in that code :)
< sipa>
phantomcircuit: but there is an extensive random simulation test; if you can integrate your pruning into that, you're likely to find any errors
< sipa>
as to knowing when there is another view on top... don't call it from connectblock or anything below
< phantomcircuit>
sipa, hasModifier?
< sipa>
no
< sipa>
hasModifier is when there is a modifier :)
< sipa>
which is a RAII object to have an automatic cleanup after modifying an entry
< sipa>
still, these caches don't do any locking, so they're not safe to modify from multiple threads
< sipa>
and if you're doing cleanup from the same thread as the modifications are happening, you'll know when there is another cache on top just by the place of the code
< GitHub44>
[bitcoin] laanwj closed pull request #8227: tests: Re-enable RPC tests for Windows (master...2016_05_win_reenable_rpc_tests) https://github.com/bitcoin/bitcoin/pull/8227
< GitHub56>
[bitcoin] fanquake opened pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (master...trvial-dev-notes) https://github.com/bitcoin/bitcoin/pull/8602
< sipa>
can i haz ack on #8524 ?
< GitHub9>
[bitcoin] fanquake opened pull request #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md (master...release-process-refresh-keys) https://github.com/bitcoin/bitcoin/pull/8603
< phantomcircuit>
sipa, ACK the number 8524 is excellent
< phantomcircuit>
sipa, is that a picture of you in a ball pit?
< * sipa>
googles ball pit
< sipa>
phantomcircuit: yes
< wumpus>
heh, bitcoin can no longer be compiled with gcc 4.9.3 with OpenBSD's default max data segment limit of 1536MB
< wumpus>
(main.cpp)
< sipa>
FINALLY
< wumpus>
yes, a milestone
< btcdrak>
inb4 someone complains :)
< wumpus>
pushing the lmits of modern compiler technology
< GitHub182>
bitcoin/master ab53207 fanquake: [trivial][doc] Mention ++i as preferred to i++ in dev notes
< GitHub182>
bitcoin/master bb56676 Wladimir J. van der Laan: Merge #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes...
< GitHub114>
[bitcoin] laanwj closed pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (master...trvial-dev-notes) https://github.com/bitcoin/bitcoin/pull/8602
< sipa>
SyntaxError: Non-ASCII character '\xf0' in file /home/pw/git/bitcoin/qa/rpc-tests/test_framework/util.py on line 180, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
< sipa>
ah, i'm running with a python2 interpreter
< sipa>
those are still pretty weird characters to appear in source code...
< cfields_>
sipa: surely those chars are the least of your concerns, then? :)
< wumpus>
only python3 is supported for the RPC tests
< sipa>
yes, it works with python3
< wumpus>
for python2 it was necessary to define the character set at the top, python3 defaults to UTF-8
< wumpus>
(but yes, that's far from the only thing that prevents it from working in 2.x)
< sipa>
still, i'm baffled why we have unicode character u+1f4bb in our source code...
< wumpus>
probably to test RPC unicode support
< cfields_>
\xf0 does look suspiciously like typo'd hex
< wumpus>
if those funny characters work, then Chinese Russian etc certainly will (as they are in lower unicode planes)
< cfields_>
great. Soon every 13yr old's passwords will be filled with poop emojis, and we'll all have to account for that possibility.
< wumpus>
yes :-)
< Chris_Stewart_5>
lol
< sipa>
true ☺
< kanzure>
sipa: use "#encoding: utf8" at top of .py files for python2
< wumpus>
better to just not use python2 anymore :)
< wumpus>
but yes that works
< kanzure>
if you want to enforce definitely not using python2, then using a more explicit method might be good
< kanzure>
(import sys; sys.version_info.major)
< GitHub154>
[bitcoin] laanwj opened pull request #8604: build,doc: Update for 0.13.0+ and OpenBSD 5.9 (master...2016_08_openbsd_update) https://github.com/bitcoin/bitcoin/pull/8604
< wumpus>
I think there is a python version check in some scripts; though OTOH, most of them will probably error out on missing imports and other problems before they reach that
< phantomcircuit>
sipa, i dont see why you cant remove things from a CCoinsCacheView (or whichever arrangement of words it is) which aren't dirty
< phantomcircuit>
like
< phantomcircuit>
logically that makes no sense
< sipa>
ok, maybe i'm wrong
< phantomcircuit>
you see now i am questioning my own sanity
< phantomcircuit>
god damned caching problems!
< sipa>
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
< instagibbs>
are there any good summaries/discussions for tx relay DoS prevention in Core?
< instagibbs>
esp wrt when certain things are checked in sequence
< rinzes_>
I am trying to find out how to remove bitcoin core completely
< rinzes_>
windows 10
< helo>
rinzes_: #bitcoin
< btcdrak>
Control panel -> programs -> uninstall
< rinzes_>
will that remove the database and everything
< MarcoFalke>
seeing segfaults while testing the stalling issue
< sipa>
can you run from gdb and inspect?
< MarcoFalke>
Would that work with trickle?
< sipa>
what is trickle?
< sipa>
ah, bandwidth manager
< MarcoFalke>
Jup, I need to simulate my "rural bandwith"
< sipa>
yes, you can run bitcoind normally, and then gdb bitcoind -p <pid>
< MarcoFalke>
ok
< sipa>
to attach to the existing process
< sipa>
when it segfaults, type 'bt' to see a backtrace
< * sipa>
afk for 5 minutes
< gmaxwell>
::sigh:: "BU" ripped out the outbound connection limiting logic, so we can probably expect more ignorant users connecting to the whole darn network.
< luke-jr>
:|
< gmaxwell>
I'd try to encourage them to not do this, but they're so antagonistic towards me that I'm sure trying would just make them double down.
< Lauda>
Seems an Upstart error is present in Ubuntu 14.0.4 and 15.10 in a VM.
< * luke-jr>
wonders if there's a way to tell his node to only fetch blocks from CB peers
< murch>
sipa: thanks
< gmaxwell>
on PR #8606 did jonasschnelli find this before 0.13 was released and then we forgot it, or is this a new instance of a lock order inversion around cs_filter?