--- Day changed Fri Aug 26 2016
00:05 < phantomcircuit> luke-jr, the accounting stuff appears to be th eonly thing testing them
00:05 < phantomcircuit> and really it shouldn't be
00:05 < phantomcircuit> it should at most be testing that they have the expected order
00:06 < luke-jr> oh, the commit itself describes it: c3f95ef13f48d21db53992984976eac93e7a08fc
00:12 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
00:17 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
00:27 -!- laurentmt [~Thunderbi@80.215.210.120] has joined #bitcoin-core-dev
00:27 < 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
00:29 -!- laurentmt [~Thunderbi@80.215.210.120] has quit [Client Quit]
00:31 -!- JackH [~Jack@79-73-189-132.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
00:34 < 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
00:35 < arubi> <- ^, if anyone has questions
00:37 < jonasschnelli> arubi: just commented that some tests would be nice
00:38 < arubi> yep.  I'll have a look!
00:38 < jonasschnelli> thanks
00:42 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ljieqobucqgseqeg] has joined #bitcoin-core-dev
00:44 < 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
00:45 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
00:50 < jonasschnelli> I'd like to merge https://github.com/bitcoin/bitcoin/pull/8371 soon... thanks for reviews
00:52 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 240 seconds]
00:55 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev
00:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:59 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
01:00 < 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?
01:00 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
01:01 < 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()?
01:01 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
01:02 < sipa> use an atomic instead of a lock
01:02 < jonasschnelli> sipa: Indeed. What do you think about -dbcacheinsync?
01:03 < gmaxwell> I don't think I've ever seen a user report that would really be helped by that.
01:03 < jonasschnelli> Not sure if we should change nCoinDBCache and nBlockTreeDBCache during "runtime"
01:03 < gmaxwell> I think we'd be using a much larger dbcache except we want to work correctly on the common 2gb hosts and vpses.
01:04 < gmaxwell> and those hosts would crash during sync if it was bigger during sync.
01:04 < sipa> i actually would want a separate dbcache value in IBD on my phone :)
01:04 < gmaxwell> now-- allowing the dbcache to use memory the mempool isn't using-- that would be a useful stunt.
01:04 < GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/53f8f226bd1d...6c9f1b8c2405
01:04 < GitHub129> bitcoin/master 259ee09 R E Broadley: Show "end" instead of many zeros when getheaders request received with a hashStop of Null.
01:04 < 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...
01:04 < gmaxwell> but wouldn't need an option (hurray)
01:05 < 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
01:05 < 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.
01:05 < sipa> i think 2GB is not much anymore for most desktop systems
01:06 < sipa> but there are others
01:06 < gmaxwell> on systems where you're okay using that at ~any~ point, it's probably not a bad idea at all times. :(
01:06 < gmaxwell> keep in mind too small a dbcache is responsible for some of the io thrashing users frequently complain about.
01:06 < phantomcircuit> sipa, it would actually be nice to have a "stall" function for things which regularly overheat
01:07 < sipa> phantomcircuit: you shouldn't run a full node on hardware that overheats
01:07 < phantomcircuit> sipa, that covers virtually all phones and most laptops
01:07 < gmaxwell> sipa: that excludes about 75% of laptops available commercially now.
01:07 < jonasschnelli> ;-)
01:07 < phantomcircuit> the thermal protection stuff isn't designed for continuous load
01:07 < sipa> heh
01:08 < gmaxwell> only a few makers actually build hardware that can stat sustained load. (your lenovo being such an example)
01:08 < gmaxwell> s/stat/stand/
01:08 < gmaxwell> though it doesn't crash when overheating.
01:08 < gmaxwell> mostly.
01:08 < phantomcircuit> gmaxwell, 10:1 his lenovo is not designed for continuous max load either
01:08 < gmaxwell> phantomcircuit: the t-series are.
01:09 < gmaxwell> the x1 isn't, as I'm sure you've noticed.
01:09 < sipa> i have a w540
01:09 < gmaxwell> sipa: those too.
01:09 < phantomcircuit> i have indeed
01:09 < phantomcircuit> the t series is not generally designed for max tdp actually
01:09 < phantomcircuit> they're more like 80%
01:09 < phantomcircuit> the x1 is maybe 50%
01:09 < phantomcircuit> a w450 probably is
01:09 < phantomcircuit> 540
01:09 < phantomcircuit> whatever
01:10 < gmaxwell> in any case, what about the suggestion I made about dbcache using unused mempool space?
01:10 < gmaxwell> that basically matches the sync and cachup use case... and doesn't add parameters.
01:10 < sipa> ugh.
01:10 < phantomcircuit> gmaxwell, eh we should just fix this and have a unified "memory usage" thing
01:10 < gmaxwell> It's only stupidly hard, have courage.
01:10 < phantomcircuit> implement out own oom killer
01:10 < phantomcircuit> :P
01:10 < phantomcircuit> our
01:10 < sipa> now normal transaction relay can trigger utxo flushing
01:11 < sipa> actually, it already does
01:11 < gmaxwell> yea, well if the flushing were ... less dumb, that wouldn't be a big deal.
01:12 < 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.
01:14 < phantomcircuit> gmaxwell, i tried making it less dumb and broke one of the unit tests
01:14 < phantomcircuit> i dont think what i did was broken actually
01:15 < gmaxwell> one can analyize the blockchain history to evaluate candidate eviction policies.
01:16 < phantomcircuit> gmaxwell, yeah my eviction policy was random eviction
01:16 < phantomcircuit> but even that broke the tests
01:16 < phantomcircuit> so idk
01:16 < gmaxwell> you need to carefully handle dirty entries.
01:16 -!- laurentmt [~Thunderbi@80.215.210.118] has joined #bitcoin-core-dev
01:20 < 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.
01:20 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
01:20 -!- laurentmt [~Thunderbi@80.215.210.118] has quit [Ping timeout: 244 seconds]
01:22 -!- laurentmt [~Thunderbi@80.215.234.122] has joined #bitcoin-core-dev
01:22 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 240 seconds]
01:24 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
01:24 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev
01:29 < 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.
01:29 < phantomcircuit> gmaxwell, i just ignored dirty entries
01:29 < phantomcircuit> still broke the unit tests
01:30 -!- murch [~murch@p4FE386C8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:34 < sipa> jonasschnelli: the profiles would just be hardcoded
01:34 < gmaxwell> considering the tests work fine if you twiddle the dbcache size, you screwed something up. Perhaps you were dropping things while views existed.
01:34 < sipa> the only option you have is selecting which profile to ude
01:34 < jonasschnelli> sipa: this seems not to scale,.. 
01:34 < sipa> how so?
01:35 < jonasschnelli> If it covers DBCache, we would need to adjust the static value over time
01:35 < sipa> why?
01:36 < sipa> it corresponds to the amount of resources it can use
01:36 < 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...
01:36 < sipa> ok, then we occasionally update the profole
01:36 < sipa> or add a "verylarge"
01:36 < jonasschnelli> heh
01:37 < sipa> allowing people to modify the profile seems to defeat the prupose
01:37 < jonasschnelli> Not sure if I like hardcoded values...
01:37 < sipa> why don't they just modify the settings directly?
01:37 < jonasschnelli> Whats the advantage over -profile0-dbcache (could still have hardcoded defaults)
01:37 < sipa> why would you have -profile0-dbcache, and not just... -dbcache ?
01:38 < sipa> if you're going to override it, override it
01:38 < jonasschnelli> Okay.. I see .. let me explain.
01:38 < jonasschnelli> I'd like to have switchable profile... 
01:38 < 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
01:39 < jonasschnelli> Then, switch back to a different profile when their system is idling
01:39 < sipa> mobile phones used to have configurable profiles... for different times of the day, for special contants, ...
01:39 < sipa> nobody used those as they take way too much time to maintain
01:39 < 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.
01:39 < jonasschnelli> Yes. You could set your "low bandwith" profile to take affect during 23:00 - 06:00 or so
01:39 < sipa> and phones switched back to very simple things, like 3 preconfigured ones
01:39 < jonasschnelli> Remember when we had the PR for "pause network activity"
01:40 < jonasschnelli> I guess there are some users out there who like to change the resource consumption during runtime.
01:40 < sipa> the point of profiles is to allow people to have more control with fewer tweakable
01:40 < sipa> not mkre knobs
01:40 < sipa> ok, so make the profile switchable at runtime
01:41 < gmaxwell> jonasschnelli: yes, though often even that is someone trying to rationalize their suffering from something else we've screwed up.
01:41 < jonasschnelli> Yes. Switchable during runtime makes sense... but I don't understand why there should be no optional -profile0-par, default overwrite option
01:42 < 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.
01:42 < sipa> jonasschnelli: pfft we could add that, but i think it's a waste of time
01:42 < 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).
01:43 < 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.
01:43 < jonasschnelli> Not sure if this feature would be for highly advanced users...
01:43 < jonasschnelli> It could be a "turtle icon" somewhere with a tooltip "use less resources"...
01:43 < 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.
01:43 < sipa> jonasschnelli: that's why we have compact blocks and not pause network :)
01:44 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
01:44 < 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
01:44 < 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.
01:44 < gmaxwell> I feel like you're not listening to me. :(
01:45 < jonasschnelli> I agree with fixing it in the first place... but some stuff is on a layer not controllable by our stack.. like QoS.
01:45 < 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.
01:46 < jonasschnelli> Partially agree on that.
01:46 < 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.
01:46 < jonasschnelli> A non-dump dbcache option would be significant more worth then a dbcache profile option
01:56 -!- laurentmt [~Thunderbi@80.215.234.122] has quit [Quit: laurentmt]
01:56 < 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
01:57 < sipa> right now, almost no user modify dbcache, and even less know that there are half a dozen other settings that affect memory usage
01:57 < sipa> don't get carried away with configurability
01:57 < 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
01:57 < phantomcircuit> gmaxwell, hmm maybe i was dropping things while a view existed?
01:57 < MarcoFalke> What about -maxtotalmem, and bitcoind will figure out how to use that  memory on it's own?
01:57 < phantomcircuit> im not sure actually
01:58 < sipa> MarcoFalke: except we don't have good accounting for all of the memory yet
01:58 < jonasschnelli> Yes. Maybe in the GUI intro we can offer a switch between "low" (default), "moderate" (1GB cache,...) and "height" (3GB cache).
01:58 < sipa> MarcoFalke: and it is pretty hard to do due to memory fragmentation etc
01:58 < 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.
01:59 < sipa> jonasschnelli: yes, that's what i propose
01:59 < sipa> jonasschnelli: but it could affect a few more options than dbcache
01:59 < 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)
01:59 < jonasschnelli> Okay. What happens if a user sets profile "hight" (3GiB) and has only 2GB wired ram?
02:00 < jonasschnelli> sipa: yes. more options..
02:00 < sipa> jonasschnelli: no, less options
02:00 < sipa> jonasschnelli: there is low, medium, and high
02:00 < jonasschnelli> yes. I meant more values that are affected by the profiles.
02:00 < jonasschnelli> -par, -maxuploadtarget, etc.
02:00 < sipa> and each corresponds to a preset oglf settings for mempool, dbcache, maxconnections, ...
02:00 < sipa> exactly
02:00 < sipa> we could do a quick test
02:01 < sipa> but i don't know if physical memory is portably detectable
02:02 < sipa> allocate a gilb and see how fast a random walk through it is? :)
02:02  * jonasschnelli :|
02:02 -!- Megaf is now known as }[-_-]{
02:03 < sipa> *gb
02:03 < gmaxwell> too bad container objects basically force runtime allocation. :(
02:04 < phantomcircuit> sipa, what are the assumptions CCoinsViewCache makes about it's contents?
02:04 < phantomcircuit> if something isn't marked dirty i assumed it could just be removed
02:04 < phantomcircuit> is this wrong?
02:06 < sipa> yes, unless there is another view on top
02:06 < sipa> in that case you are not allowed to modify it in any way
02:15 < jonasschnelli> grml... bitcoind: sync.cpp:125: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `onlyMaybeDeadlock' failed.
02:15 < jonasschnelli> Aborted
02:15 < jonasschnelli> current master
02:16 < jonasschnelli> http://pastebin.com/YCVFK5KY
02:17 < jonasschnelli> Before I updated to current master, it was running for a couple of weeks,.. just updated an ran into the deadlock assertion
02:17 < sipa> jonasschnelli: open an issue so we don't forgrt
02:17 < jonasschnelli> ok
02:18 -!- }[-_-]{ [~quassel@unaffiliated/megaf] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
02:21 < GitHub123> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6c9f1b8c2405...c19f8a4a7795
02:21 < GitHub123> bitcoin/master 4c3e2cb R E Broadley: Show XTHIN in GUI
02:21 < GitHub123> bitcoin/master c19f8a4 Wladimir J. van der Laan: Merge #8583: Show XTHIN in GUI...
02:21 < GitHub63> [bitcoin] laanwj closed pull request #8583: Show XTHIN in GUI (master...ShowXTHINinGUI) https://github.com/bitcoin/bitcoin/pull/8583
02:21 < jonasschnelli> sipa: maybe my fault.. I'm running https://github.com/bitcoin/bitcoin/pull/7685/files on top
02:22 < GitHub197> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c19f8a4a7795...65837375d98b
02:22 < GitHub197> bitcoin/master fab5ecb MarcoFalke: [wallet] rpc: Drop misleading option
02:22 < GitHub197> bitcoin/master 6583737 Wladimir J. van der Laan: Merge #8581: [wallet] rpc: Drop misleading option...
02:22 < GitHub156> [bitcoin] laanwj closed pull request #8581: [wallet] rpc: Drop misleading option (master...Mf1608-walletDropRpc) https://github.com/bitcoin/bitcoin/pull/8581
02:33 < 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
02:47 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
03:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
03:13 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 240 seconds]
03:17 -!- spudowiar is now known as cc
03:17 -!- cc is now known as spudowiar
03:17 < 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
03:17 < 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
03:35 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
03:43 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]
03:47  * MarcoFalke likes sipa's new GitHub icon
03:51 < phantomcircuit> sipa, how can you tell if there's another view on top?
03:51 < phantomcircuit> also, why?
03:54 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
03:57 < sipa> phantomcircuit: uh.. i can't say for sure. i've swapped out the understanding that resulting in that code :)
03:58 < 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
03:58 < sipa> as to knowing when there is another view on top... don't call it from connectblock or anything below
04:01 < phantomcircuit> sipa, hasModifier?
04:02 < sipa> no
04:02 < sipa> hasModifier is when there is a modifier :)
04:03 < sipa> which is a RAII object to have an automatic cleanup after modifying an entry
04:03 < sipa> still, these caches don't do any locking, so they're not safe to modify from multiple threads
04:04 < 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
04:08 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
04:24 < GitHub41> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/65837375d98b...12892dbb9fb6
04:24 < GitHub41> bitcoin/master fa6dc9f MarcoFalke: Remove unused variables
04:24 < GitHub41> bitcoin/master 12892db Wladimir J. van der Laan: Merge #8590: Remove unused variables...
04:24 < GitHub7> [bitcoin] laanwj closed pull request #8590: Remove unused variables (master...Mf1608-unusedCode) https://github.com/bitcoin/bitcoin/pull/8590
04:27 < GitHub87> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/f2306fbe0142...122fdfdae915
04:27 < GitHub87> bitcoin/0.13 526d2b0 MarcoFalke: [wallet] rpc: Drop misleading option...
04:27 < GitHub7> [bitcoin] laanwj closed pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (0.13...Mf1608-walletRpcDropBackport) https://github.com/bitcoin/bitcoin/pull/8600
04:27 < GitHub87> bitcoin/0.13 122fdfd Wladimir J. van der Laan: Merge #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option...
04:36 < phantomcircuit> sipa, i was trying to make the change in ccoinsviewcache so it's triggered whenever usage goes above the limit
04:37 < phantomcircuit> so it wouldn't know where it is
04:38 < phantomcircuit> i guess i could add something to the constructor to call down to the base view and increment a counter in each
04:38 < wumpus> btcdrak: do you have a plan for https://github.com/bitcoin/bitcoin/pull/7562?
04:38 < wumpus> I think it's still relevant?
04:40 < 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
04:42 < 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
04:43 -!- cryptapus_afk is now known as cryptapus
04:47 < sipa> can i haz ack on #8524 ?
04:48 -!- Megaf [~quassel@unaffiliated/megaf] has quit [Remote host closed the connection]
04:49 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
04:56 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
05:01 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
05:04 -!- someone1337 [d51096c5@gateway/web/freenode/ip.213.16.150.197] has joined #bitcoin-core-dev
05:10 -!- someone1337 [d51096c5@gateway/web/freenode/ip.213.16.150.197] has quit [Quit: Page closed]
05:12 < 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
05:17 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:24 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
05:27 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
05:32 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
05:44 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
05:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:59 -!- jouke [~jouke@unaffiliated/komkommer] has quit [Ping timeout: 258 seconds]
06:00 < phantomcircuit> sipa, ACK the number 8524 is excellent
06:00 -!- Samdney [~Samdney@maus.hawo.stw.uni-erlangen.de] has joined #bitcoin-core-dev
06:00 < phantomcircuit> sipa, is that a picture of you in a ball pit?
06:01 -!- jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #bitcoin-core-dev
06:03  * sipa googles ball pit
06:03 < sipa> phantomcircuit: yes
06:29 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
06:34 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
06:38 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:46 < wumpus> heh, bitcoin can no longer be compiled with gcc 4.9.3 with OpenBSD's default max data segment limit of 1536MB
06:46 < wumpus> (main.cpp)
06:46 < sipa> FINALLY
06:47 < wumpus> yes, a milestone
06:47 < btcdrak> inb4 someone complains :)
06:47 < wumpus> pushing the lmits of modern compiler technology
06:54 < GitHub56> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/12892dbb9fb6...fd37acaedab1
06:54 < GitHub56> bitcoin/master c25083b fanquake: [trivial][doc] Mention gpg --refresh-keys in release-process.md
06:54 < GitHub56> bitcoin/master fd37aca Wladimir J. van der Laan: Merge #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md...
06:54 < GitHub169> [bitcoin] laanwj closed 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
06:54 < GitHub182> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd37acaedab1...bb566761fbe1
06:54 < GitHub182> bitcoin/master ab53207 fanquake: [trivial][doc] Mention ++i as preferred to i++ in dev notes
06:54 < GitHub182> bitcoin/master bb56676 Wladimir J. van der Laan: Merge #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes...
06:55 < 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
06:55 < GitHub183> [bitcoin] laanwj closed pull request #8547: Update btcdrak key with new expiry dates (master...btcdrak-key) https://github.com/bitcoin/bitcoin/pull/8547
06:59 < sipa> wth?
06:59 < 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
07:04 < sipa> ah, i'm running with a python2 interpreter
07:04 < sipa> those are still pretty weird characters to appear in source code...
07:04 < cfields_> sipa: surely those chars are the least of your concerns, then? :)
07:05 < wumpus> only python3 is supported for the RPC tests
07:05 < sipa> yes, it works with python3
07:05 < wumpus> for python2 it was necessary to define the character set at the top, python3 defaults to UTF-8
07:05 < wumpus> (but yes, that's far from the only thing that prevents it from working in  2.x)
07:06 < sipa> still, i'm baffled why we have unicode character u+1f4bb in our source code...
07:06 < wumpus> probably to test RPC unicode support
07:06 < cfields_> \xf0 does look suspiciously like typo'd hex
07:07 < sipa> i doubt it: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/util.py#L170
07:07 < cfields_> oh, huh
07:07 < wumpus> that's to test that unicode characters work in username/password
07:08 < cfields_> https://github.com/bitcoin/bitcoin/commit/fad184550e1c507a897be59169f9c5dabce8d652
07:08 < sipa> ah
07:10 < wumpus> if those funny characters work, then Chinese Russian etc certainly will (as they are in lower unicode planes)
07:12 < cfields_> great. Soon every 13yr old's passwords will be filled with poop emojis, and we'll all have to account for that possibility.
07:12 < wumpus> yes :-)
07:13 < Chris_Stewart_5> lol
07:14 < sipa> true ☺
07:16 -!- Samdney [~Samdney@maus.hawo.stw.uni-erlangen.de] has quit [Ping timeout: 264 seconds]
07:20 < kanzure> sipa: use "#encoding: utf8" at top of .py files for python2
07:21 < wumpus> better to just not use python2 anymore :)
07:22 < wumpus> but yes that works
07:27 < kanzure> if you want to enforce definitely not using python2, then using a more explicit method might be good
07:27 < kanzure> (import sys; sys.version_info.major)
07:28 < 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
07:28 -!- mkarrer [~mkarrer@159.red-83-47-122.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
07:29 < 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
07:30 -!- Irssi: #bitcoin-core-dev: Total of 152 nicks [0 ops, 0 halfops, 0 voices, 152 normal]
07:31 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
07:36 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
07:49 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
07:55 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has quit [Ping timeout: 244 seconds]
08:01 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev
08:06 < phantomcircuit> sipa, i dont see why you cant remove things from a CCoinsCacheView (or whichever arrangement of words it is) which aren't dirty
08:06 < phantomcircuit> like
08:06 < phantomcircuit> logically that makes no sense
08:08 < sipa> ok, maybe i'm wrong
08:09 < phantomcircuit> you see now i am questioning my own sanity
08:09 < phantomcircuit> god damned caching problems!
08:15 < sipa> There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
08:30 -!- laurentmt [~Thunderbi@80.215.234.122] has joined #bitcoin-core-dev
08:31 -!- epopt [~epopt@96.229.170.220] has joined #bitcoin-core-dev
08:32 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
08:35 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
08:37 < instagibbs> are there any good summaries/discussions for tx relay DoS prevention in Core?
08:37 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:38 < instagibbs> esp wrt when certain things are checked in sequence
08:38 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: leaving]
08:55 -!- whphhg [whphhg@gateway/vpn/mullvad/x-sdunvtgykxwvumsz] has quit [Quit: Leaving]
08:58 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev
09:06 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
09:06 -!- slackircbridge2 [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
09:06 -!- rinzes_ [45915974@gateway/web/freenode/ip.69.145.89.116] has joined #bitcoin-core-dev
09:07 < rinzes_> I am trying to find out how to remove bitcoin core completely 
09:08 < rinzes_> windows 10
09:09 < helo> rinzes_: #bitcoin
09:09 < btcdrak> Control panel -> programs -> uninstall
09:09 < rinzes_> will that remove the database and everything
09:10 -!- laurentmt [~Thunderbi@80.215.234.122] has quit [Quit: laurentmt]
09:13 < GitHub107> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bb566761fbe1...9a0ed08b40b1
09:13 < GitHub107> bitcoin/master ff8d279 Pavel Janík: Do not shadow member variables
09:13 < GitHub107> bitcoin/master 9a0ed08 Pieter Wuille: Merge #8109: Do not shadow member variables...
09:13 < GitHub43> [bitcoin] sipa closed pull request #8109: Do not shadow member variables (master...20160527_shadow_httpserver) https://github.com/bitcoin/bitcoin/pull/8109
09:16 -!- rinzes_ [45915974@gateway/web/freenode/ip.69.145.89.116] has quit [Quit: Page closed]
09:17 -!- laurentmt [~Thunderbi@80.215.234.122] has joined #bitcoin-core-dev
09:17 -!- laurentmt [~Thunderbi@80.215.234.122] has quit [Client Quit]
09:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
09:29 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:34 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
09:39 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
10:03 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:11 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 265 seconds]
10:18 < GitHub8> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9a0ed08b40b1...c072b8fd95cd
10:18 < GitHub8> bitcoin/master fa3d974 MarcoFalke: [doc] Update git-subtree-check.sh README
10:18 < GitHub8> bitcoin/master c072b8f Pieter Wuille: Merge #8545: [doc] Update git-subtree-check.sh README...
10:18 < GitHub93> [bitcoin] sipa closed pull request #8545: [doc] Update git-subtree-check.sh README (master...Mf1608-doc) https://github.com/bitcoin/bitcoin/pull/8545
10:35 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
10:40 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
10:41 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
10:45 -!- Megaf [~quassel@unaffiliated/megaf] has quit [Remote host closed the connection]
11:09 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:10 < Lauda> Does the gitian build script from achow101 include everything now? 
11:13 < sipa> i believe it does
11:14 < Lauda> I'll test now and post results then.
11:14 < Lauda> Thanks
11:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
11:34 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
11:37 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
11:38 -!- Guyver2_ is now known as Guyver2
11:42 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
11:44 -!- JZA [JZA@gateway/shell/elitebnc/x-kfgaixjybbaadriq] has joined #bitcoin-core-dev
11:45 < arubi> I pushed a few unit tests ( https://github.com/bitcoin/bitcoin/pull/8598/commits ) that triggered an error in a specific travis build ( https://travis-ci.org/bitcoin/bitcoin/builds/155297369 ), I'm trying to build that environment to try and debug it, and I'd appreciate input as to what should I be looking for.  I was pretty surprised that adding tests caused something like that
11:46 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
11:47 < arubi> specifically, it failed at: "Assertion failed: 449.99100000 != 999.980" when running 'qa/rpc-tests/segwit.py'
11:48 < sipa> we've been seeing that test fail for a while
11:48 < arubi> oh, so it might be that re-running it will pass then?
11:51 < arubi> sipa, er, maybe I misunderstood.  it fails consistently?  I see other builds pass, and my previous pr passed
11:53 < sipa> no, just occasionally
11:54 < arubi> mhm.  well, the PR is ready then, if anyone finds it useful :)
11:57 < sipa> great; will review in mmore detail
11:57 < arubi> thanks!
12:05 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
12:09 < GitHub103> [bitcoin] sipa opened pull request #8606: Fix some locks (master...lockfix) https://github.com/bitcoin/bitcoin/pull/8606
12:10 < GitHub127> [bitcoin] MarcoFalke opened pull request #8607: [doc] Fix doxygen off-by-one comments, fix typos (master...Mf1608-trivial17) https://github.com/bitcoin/bitcoin/pull/8607
12:15 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
12:15 < sipa> arubi: https://github.com/bitcoin/bitcoin/issues/8532
12:16 -!- achow101 [~achow101@206.196.187.145] has joined #bitcoin-core-dev
12:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg]
12:21 < arubi> sipa, I see, so this is some timing issue then?
12:23 < arubi> I see tests passed now, phew :)
12:30 -!- Megaf [~quassel@unaffiliated/megaf] has quit [Remote host closed the connection]
12:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
12:48 -!- achow101 [~achow101@206.196.187.145] has quit [Ping timeout: 258 seconds]
12:55 < btcdrak> sipa: do you have any idea why changing the default transaction version to 2 would break these tests? https://gist.github.com/btcdrak/7aeeccf8b487d6058ab87e1d3fcf6c62
13:01 -!- mappum [sid43795@gateway/web/irccloud.com/x-cpheoswxhcnmevug] has quit [Ping timeout: 264 seconds]
13:02 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ljieqobucqgseqeg] has quit [Ping timeout: 264 seconds]
13:03 -!- eragmus [sid136308@gateway/web/irccloud.com/x-jxvggbirwugslozf] has quit [Ping timeout: 258 seconds]
13:13 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving]
13:16 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
13:23 < MarcoFalke> ugh
13:23 < MarcoFalke> seeing segfaults while testing the stalling issue
13:24 < sipa> can you run from gdb and inspect?
13:24 < MarcoFalke> Would that work with trickle?
13:25 < sipa> what is trickle?
13:25 < sipa> ah, bandwidth manager
13:25 < MarcoFalke> Jup, I need to simulate my "rural bandwith"
13:25 < sipa> yes, you can run bitcoind normally, and then gdb bitcoind -p <pid>
13:25 < MarcoFalke> ok
13:25 < sipa> to attach to the existing process
13:26 < sipa> when it segfaults, type 'bt' to see a backtrace
13:26  * sipa afk for 5 minutes
13:28 -!- voids [~voids___@102.209.19.93.rev.sfr.net] has joined #bitcoin-core-dev
13:38 < gmaxwell> ::sigh:: "BU" ripped out the outbound connection limiting logic, so we can probably expect more ignorant users connecting to the whole darn network.
13:40 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
13:44 < luke-jr> :|
13:45 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
13:45 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
13:45 < 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.
13:45 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
13:47 -!- mappum [sid43795@gateway/web/irccloud.com/x-ocojqauoagxleklr] has joined #bitcoin-core-dev
13:54 -!- zooko [~user@73.95.137.123] has joined #bitcoin-core-dev
14:03 -!- eragmus [sid136308@gateway/web/irccloud.com/x-idytpswcdivcgsml] has joined #bitcoin-core-dev
14:10 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbeuiuwhsgqumwfu] has joined #bitcoin-core-dev
14:13 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
14:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Client Quit]
14:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:25 < MarcoFalke> sipa: Well, the trace does not look helpful? http://pastebin.ubuntu.com/23095029/
14:26 < sipa> MarcoFalke: try 'thread apply all bt'
14:28 < MarcoFalke> http://pastebin.ubuntu.com/23095049/
14:28 < MarcoFalke> sipa: ^
14:28 -!- kyletorpey [~kyle@pool-173-53-94-96.rcmdva.fios.verizon.net] has joined #bitcoin-core-dev
14:29 < sipa> MarcoFalke: that looks like a segfault inside trickle...
14:30 < MarcoFalke> Ok, will try without trickle during the weekend
14:36 < murch> sipa: I assume the P2WPKH is then 4 bytes/4 larger as well?
14:37 < sipa> murch: presumably
14:38 < murch> The sequence number is part of the discounted section, right?
14:39 < sipa> no
14:40 < sipa> since it is in non-witness inputs as well, it can't be discounted
14:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:41 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
14:45 < luke-jr> hm, looks like AMD may beat Intel to SHA instructions
14:46 < sipa> intel already has sha instructions?
14:46 < luke-jr> sipa: not in any desktop CPU, AFAIK
14:46 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
14:47 < Lauda> http://i.imgur.com/jEid47S.png Does anyone have any ideas how to mitigate this?
14:47 < Lauda> Seems an Upstart error is present in Ubuntu 14.0.4 and 15.10 in a VM.
14:49 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
14:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
14:54 -!- cryptapus is now known as cryptapus_afk
14:56 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
15:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:09 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Remote host closed the connection]
15:09 -!- spudowiar1 [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:10 -!- spudowiar1 is now known as spudowiar
15:17  * luke-jr wonders if there's a way to tell his node to only fetch blocks from CB peers
15:22 -!- achow101 [~achow101@206.196.187.145] has joined #bitcoin-core-dev
15:26 -!- zooko` [~user@73.95.138.230] has joined #bitcoin-core-dev
15:43 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
15:48 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
15:50 -!- zooko` [~user@73.95.138.230] has quit [Ping timeout: 250 seconds]
15:51 -!- zooko [~user@73.95.137.123] has quit [Ping timeout: 258 seconds]
15:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
15:55 -!- Alopex [~bitcoin@176.9.70.183] has joined #bitcoin-core-dev
16:02 -!- eragmus [sid136308@gateway/web/irccloud.com/x-idytpswcdivcgsml] has quit [Ping timeout: 250 seconds]
16:02 -!- mappum [sid43795@gateway/web/irccloud.com/x-ocojqauoagxleklr] has quit [Read error: Connection reset by peer]
16:03 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dbeuiuwhsgqumwfu] has quit [Read error: Connection reset by peer]
16:07 < murch> sipa: thanks
16:15 -!- eragmus [sid136308@gateway/web/irccloud.com/x-lktqyuajzgksgfhw] has joined #bitcoin-core-dev
16:19 -!- mappum [sid43795@gateway/web/irccloud.com/x-lvifmrruhqopzzna] has joined #bitcoin-core-dev
16:24 -!- voids [~voids___@102.209.19.93.rev.sfr.net] has quit [Quit: Leaving]
16:25 -!- voids [~voids___@102.209.19.93.rev.sfr.net] has joined #bitcoin-core-dev
16:34 -!- murch [~murch@p4FE386C8.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
16:36 < 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?
16:36 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-yatckbpedplarjop] has quit [Ping timeout: 265 seconds]
16:37 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-rfdoazewrevtwumc] has joined #bitcoin-core-dev
16:44 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
16:46 -!- eragmus [sid136308@gateway/web/irccloud.com/x-lktqyuajzgksgfhw] has quit [Remote host closed the connection]
16:46 -!- mappum [sid43795@gateway/web/irccloud.com/x-lvifmrruhqopzzna] has quit [Remote host closed the connection]
16:49 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
16:59 -!- JZA [JZA@gateway/shell/elitebnc/x-kfgaixjybbaadriq] has quit [Excess Flood]
17:00 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
17:05 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
17:13 -!- achow101 [~achow101@206.196.187.145] has quit [Ping timeout: 264 seconds]
17:14 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
17:22 -!- Alopex [~bitcoin@176.9.70.183] has quit [Remote host closed the connection]
17:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
17:42 -!- Kexkey [~kexkey@68.168.114.170] has joined #bitcoin-core-dev
17:44 < GitHub4> [bitcoin] nomnombtc opened pull request #8608: Install manpages via make install, also add some autogenerated manpages (master...man_automake2) https://github.com/bitcoin/bitcoin/pull/8608
17:46 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:51 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
17:52 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
18:05 -!- achow101 [~achow101@206.196.187.145] has joined #bitcoin-core-dev
18:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pxidrdkgwlygfpum] has quit [Quit: Connection closed for inactivity]
18:27 -!- mappum [sid43795@gateway/web/irccloud.com/x-ugsuoghozgnyjryr] has joined #bitcoin-core-dev
18:35 -!- eragmus [sid136308@gateway/web/irccloud.com/x-hyamejorjfrsbfnm] has joined #bitcoin-core-dev
18:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:39 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vbtmrzrnqdodjurk] has joined #bitcoin-core-dev
18:47 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
18:49 < btcdrak> is there a way to sign each commit during an interactive rebase?
18:51 -!- achow101 [~achow101@206.196.187.145] has quit [Ping timeout: 250 seconds]
18:52 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
18:59 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 264 seconds]
19:00 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
19:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:18 -!- achow101 [~achow101@206.196.187.145] has joined #bitcoin-core-dev
19:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:35 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
19:35  * luke-jr peers at rebroad.
19:47 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 252 seconds]
19:48 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
19:53 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
19:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:57 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:07 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
20:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:17 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
20:19 -!- Kexkey [~kexkey@68.168.114.170] has quit [Remote host closed the connection]
20:26 -!- achow101 [~achow101@206.196.187.145] has quit [Remote host closed the connection]
20:28 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
20:42 < roasbeef> btcdrak: signoff-rebase = "!GIT_SEQUENCE_EDITOR='sed -i -re s/^pick/e/' sh -c 'git rebase -i $1 && while git rebase --continue; do git commit --amend -S --no-edit; done' -"
20:43 < roasbeef> btcdrak: stuff that into an alias in your .gitconfig
20:48 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 264 seconds]
20:49 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
20:50 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
20:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:54 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
21:02 -!- cryptapus_afk is now known as cryptapus
21:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:32 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
21:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:46 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
21:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vbtmrzrnqdodjurk] has quit [Quit: Connection closed for inactivity]
21:59 -!- cryptapus is now known as cryptapus_afk
22:15 < luke-jr> hm, I would have thought verifying blocks was a read-only operation, but it seems to be writing about as much as it's reading?
22:15 < luke-jr> more actually
22:21 < gmaxwell> should be much more,
22:21 < gmaxwell> if it's reading your dbcache is too small.
22:43 < luke-jr> what's it writing?
22:44 < gmaxwell> the chainstate.
22:51 < wumpus> right, it's not the verification that causes writing, but *accepting* the blocks and updating the state
22:51 < wumpus> rejecting blocks should be a read-only operations
22:51 < wumpus> as well as verifying transactions outside blocks
22:55 < wumpus> gmaxwell: re: BU removing outward connection limit, sigh, it was to be expected somehow, you can't stop anti-social people by just telling them not to do a certain behavior, we'll need explicit anti-DoS measures for that
22:56 < wumpus> such a system could block spy-nodes connecting to everyone in one go
22:57 < wumpus> that there is no damn reason to connect to connect to more nodes also won't stop anyone
22:57 < wumpus> 'look mom we're real anarchists, we can misbehave on an open P2P network!'
23:02 < midnightmagic> any such mechanism if successful would at least in the short term eradicate blockchain.info's spying, as well as the various chainalysis mechs.
23:02 < wumpus> their name, their whole raison d'etre, is 'remove limits', so they removed another limit. It doesn't matter whether it had a purpose, they've remved a few lines of very limiting-feeling codes, and now they feel happy
23:04 < wumpus> pre-emtively filling all connection slots would also prevent blockchain.info's spying :-)
23:05 < midnightmagic> :-)
23:05 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
23:07 < wumpus> if this escalates and there is no solution, in the longer run, it will turn the P2P network to a ghetto, and I'd expect it to transition it to more of a F2F network w/ authenticated connections
23:08 < wumpus> but also a few more mass-connectors likely won't break the netwerk, it just depends on the scale
23:12 < midnightmagic> Bitcoin Classic -- DDoS'ing the Bitcoin network since 2016.
23:12 < midnightmagic> I wonder if someone could get gavin to scold them for that
23:12 < midnightmagic> or. Unlimited. Same diff.
23:14 < wumpus> it reminds me a bit of seeders versus leechers discussion for bittorrent, with the difference is that 'defecting' there is advantageous to the leecher, here it's just about being a jerk just because
23:15 < wumpus> though connecting to lots of nodes can get you blocks fractially faster, which is useful for miners, you can accomplish the same thing by listening and advertising
23:26 < wumpus> you can set a virtually unlimited number of incoming connection slots, then by having a node with a high uptime, it will drift up in the DNS seeder rankings, which means its address will be dealt out more often, resulting in more connections to other nodes. It's a slower process but the social thing to do.
23:34 < luke-jr> shouldn't those blocks (and the chainstate) already be correct? O.o
23:35 < wumpus> but blocks are a delta to the chainstate
23:36 < wumpus> if you accept a block, by definition, you have to update the chainstate. And undo files are produced, too, a reverse-delta just in case.
23:36 < luke-jr> so it's actually rewinding and re-accepting them? somehow I thought it just verified the current state was sane
23:37 < gmaxwell> wumpus: what you say is true, but its much harder to deal with abusive behavior when you also have many more 'honest' people also being abusive out of ignorance. (in part, because the motivational structure is different; e.g. we can discourage spy nodes by reducing information leaks, moving more users into tor, etc.)
23:37 < wumpus> luke-jr: no, just applying the block results in writes to the utxo state, to mark outputs as spent, add new outputs. it rewinds only on reorg
23:37 < gmaxwell> (But ignorance, "I'm gonna help the network out by connecting to EVERYTHING!" ... is harder to resolve by rational measures)
23:38 < luke-jr> wumpus: I'm talking about the verifying blocks at startup.. checkblocks/checklevel
23:38 < wumpus> luke-jr: ohhh! that wasn't clear to me.
23:38 < wumpus> luke-jr: no, that should be read-only
23:38 < luke-jr> sorry
23:38 < luke-jr> hmm
23:39 < wumpus> gmaxwell: sure, at least ignorance can be improved by trying harder to inform people about things
23:42 < wumpus> people may assume 'moaaarrrr outgoing connections is better' unless it's explained , .e.g in user interfaces, blog posts, that it's bad for yourself as well as others, with alternatives how to get more connections. Sure, some people will ignore it, or be jerks, but hopefully a miniority and most will heed.
23:43 < wumpus> luke-jr: the rewinding with checklevel 3 completely happens in memory, if it is writing anything to disk that'd be very wrong
23:44 < wumpus> (there could be a bug of course....)
23:56 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ijxscdtkbvjqwjuw] has joined #bitcoin-core-dev
23:57 < luke-jr> having trouble reproducing now. flushed Linux's disk caches though, and even with just reading, it's going super-slow :|
23:59 < luke-jr> (as in 1% every 2 minutes or so, ETA 3 hours at this rate)