< achow101> michagogo: interesting. My script (the on that is in contrib/) doesn't work. But yours does. Now I need to find what the difference is, because mine does a whole lot more stuff
< luke-jr> sigs pushed for rc2
< achow101> michagogo: I got it to work with my script (had to make a few tweaks). Thanks for making the vm image. Maybe part of the issue I have with setting up lxc on my computer is that I use Ubuntu 16.04 instead of 14.04
< luke-jr> https://lwn.net/Articles/704078/ local exploit in all released Linux kernels
< luke-jr> "An exploit using this technique has been found in the wild."
< jl2012> is there any way to generate the same block hash every time running regtest?
< luke-jr> jl2012: by giving it the same blocks?
< jl2012> so i can't generate blocks with the RPC generate command?
< luke-jr> nothing stopping you, but there's no reason to expect that to be deterministic
< luke-jr> might work if you set a mock time.. maybe
< jl2012> it'd be nice if it has a detministicgenerate command. Given the same condition, it always returns the same block hash
< luke-jr> but the conditions are never the same (timestamp)
< luke-jr> it's not like compiling where it's just a random timestamp being added, the timestamp actually has a role in the blockchain :p
< jl2012> that could be deterministic too, e.g. just make it always 600s apart
< luke-jr> seems like it'd defeat the purpose
< jl2012> sometimes, you want to faithfually repeat the process
< luke-jr> so try setting a mock time..
< jl2012> also setting the same pubkey for reward, I guess?
< luke-jr> or just load a set deterministic wallet ;)
< jl2012> thanks
< Victorsueca> morning
< wumpus> morning
< jonasschnelli> Would it be problematic to throw CoinControl into the wallet logic in cases where CoinControl is disabled? https://github.com/bitcoin/bitcoin/blob/master/src/qt/sendcoinsdialog.cpp#L233
< jonasschnelli> I guess CoinControls default should result in the exact same transaction like if it was not thrown into the CreateTransaction logic
< wumpus> youd' have to be really sure of that
< wumpus> also there's the possibility that the user disabled coincontrol and the settings are no longer at default
< wumpus> be careful
< jonasschnelli> hm...
< jonasschnelli> I'd like to use it for the confirmation target (instead of miss-using the default)
< Victorsueca> In theory the logic should be the same except maybe for some edge cases
< jonasschnelli> Instead of adding a parameter to CreateTransaction
< wumpus> I don't think passing in a defaults-only coincontrol structure if no coin control is desired is a bad idea per ce, it would simplify some checks
< wumpus> Victorsueca: "in theory" is not good enough for these kind of changes
< jonasschnelli> The problem is, CoinControl has bad test coverage. Mostly GUI only
< Victorsueca> wumpus: yeah, either is "maybe" for the edge cases
< wumpus> yes, that has to change
< Victorsueca> this would have to go through some extensive checks to be sure the logic is the same
< wumpus> requiring a coincontrol object would at least unify the coin control and non-coin control code paths for a bit
< wumpus> good idea to use it for the confirmation target. THat would change meaning of the the structure from "coin control" to "sending preferences" but that's OK
< wumpus> that's more general, I've always thought it was a bit strange to have an argument for what is basically a specific UI feature
< jonasschnelli> Yes. We could rename it soon.
< jonasschnelli> We aleady use it over RPC for fundraw
< wumpus> well no need to rename it immediately, just add a comment to the documentation or so
< wumpus> e.g. at the top of the class
< wumpus> right, it's alredy used for other things
< jonasschnelli> Currently, if you play with the smartfee-slider and use RPC or console (send*) it will affect your RPC/consoles send* confirmation target. :)
< wumpus> yes changing the default in the background is really ugly
< wumpus> that always bothered me, all the side effects and uncontained input in the wallet logic
< Victorsueca> it's also ugly how it uses different fee systems for the GUI and the RPC
< jonasschnelli> Yeah. We need to untangle the "CoinControls" layer violation. It should always respect the WalletModel
< Victorsueca> lots of people have made mistakes believing the GUI setting would affect the RPC backend (which is logic to think)
< jonasschnelli> Oh. So users may use the GUI to set the RPC parameters? So it's a features instead a bug?!
< tulip> Lightsword: testnet seems to be at least mostly working today. some of the testnet explorers are jammed, but blockr.io and blocktrail.com are keeping up.
< Victorsueca> jonasschnelli: AFAIK the GUI slider doesn't affect the RPC, and that's exactly the problem, some people tries it and ends sending a transaction with the RPC fee setting
< GitHub24> [bitcoin] jonasschnelli opened pull request #8989: [Qt] overhaul smart-fee slider, adjust default confirmation target (master...2016/10/qt_slider) https://github.com/bitcoin/bitcoin/pull/8989
< wumpus> nonono the GUI should *not* affect the RPC
< wumpus> that's completely clueless
< wumpus> e.g. third-party software using the RPC should not be affected by what the user happens to be currently doing in the GUI
< wumpus> of course this is different from clearly global scope changes like the 'settings' dialog
< wumpus> which should affect the whole process
< wumpus> but per-send options should definitely not affect RPC
< Victorsueca> wumpus: yeah, but maybe we should add a warning message to avoid confusion, some people actually tries to use the GUI to set the RPC fee
< luke-jr> wumpus: the slider isn't clearly per-send
< wumpus> it should be.
< luke-jr> wumpus: it's outside the entry-container, and remains set after you send
< luke-jr> this suggests to me that it's global
< luke-jr> even though I know it isn't
< jonasschnelli> It's per send.. but the value will be stored and persisted in QSettings
< luke-jr> jonasschnelli: how is that per send? :P
< wumpus> it can be a convenience to remember the setting
< jonasschnelli> With per-send I mean that its value should not be spread global and effect the CWallet structure and RPC
< wumpus> but if that puts people on wrong footing, it should probably just reset every time
< jonasschnelli> It's per-send in the software-design but persisted between multiple sends. :)
< luke-jr> Maybe a "set as default" button
< wumpus> but that default still shouldn't affect RPC
< jonasschnelli> I think it could be useful to keep the confirmation target between sends
< jonasschnelli> Yes. The default is GUI only
< luke-jr> wumpus: why?
< wumpus> there isn't even such a a setting in RPC, and QSettings should never affect core settings anyway
< jonasschnelli> Indeed
< wumpus> because RPC should be as stateless aspossible
< luke-jr> it's a command-line option from the user's perspective
< jonasschnelli> We could think of adding a conf-target feature to fundraw
< wumpus> and certainly not 'inhereit' from the GUI
< wumpus> this creates even more confusing differences between running bitcoind and running the GUI
< * jonasschnelli> needs to fo afk
< luke-jr> "Set as GUI default" :P
< wumpus> yes
< luke-jr> inb4 users ask what a GUI is <.<
< wumpus> the people that use RPC will know
< Victorsueca> think of it as a browser storing your login email for a web page, the web page only receives the email once per-login, even tho the browser can remember it and prefill the field the next time you visit the web page
< wumpus> people that only use the GUI don't need to know the distinction
< wumpus> but anyhow for the interface to be well-defined it needs to be entirely transparent which parameters affect RPC calls, there can't be any 'magic' side-input depending on whether a GUI is running
< wumpus> remember the goal is to decouple the GUI, not couple it further
< Victorsueca> what about putting a RPC-specific fee setting on the GUI? Maybe on Settings > Options...
< wumpus> no, let people set RPC settings through RPC
< wumpus> or preferably, pass necessary all input to the call itself so the message is self-contained
< wumpus> but yes, in the settings dialog there could be settings that affect both GUI and RPC, there are some like 'dbcache' which necessarily need to affect everything
< wumpus> there it is not confusing
< wumpus> those settings will have associated command line arguments, and should also be able to be changed through RPC if possible to change them during runtime
< wumpus> settings that affect RPC usage, but can't be set either through command line arguments or through RPC, but only through the GUI should be avoided at all costs
< wumpus> hey, coincontrol.h needs to be in src/wallet
< jl2012> is there any RPC command to clear the mempool or clear a txid from mempool?
< jl2012> for regtest
< wumpus> I don't think so
< jl2012> any reason not to have this? I think it's useful for testing
< wumpus> feel free to add it
< jl2012> ok, i'll try
< wumpus> though I'm not sure how useful it is for RPC testing, removing transactions manually seems a thing to exercise in mempool unit tests
< wumpus> but if you have a specific test inmind that would improve, sure
< jl2012> e.g. I submitted a tx, then I malleate the tx and resubmit, and want to see if the new version would be accepted
< shangzhou> i think one thing was BIP 16 has an accidental stack limit of 520 bytes for the script. you'd have to ask wumpus, gmaxwell, pwuille etc. https://bitcoincore.slack.com/archives/welcome/p1477041640021165
< jl2012> shangzhou: that's not accidental. The limit was there long before that
< michagogo> achow101: yeah, I'm pretty sure The Xenial Xerus was known to be problematic
< GitHub196> [bitcoin] laanwj opened pull request #8990: moveonly: move `coincontrol` to `src/wallet` (master...2016_10_coincontrol_wallet) https://github.com/bitcoin/bitcoin/pull/8990
< luke-jr> jl2012: it was accidental that it affected P2SH
< jl2012> no one realized that when P2SH was deployed?
< luke-jr> nope
< luke-jr> it wasn't until much later that we realised 20-of-20 multisig wouldn't work :p
< luke-jr> (or even 1-of-20 IIRC)
< jl2012> well......I can't believe everyone overlooked this
< Victorsueca> now that max script size is set on stone, fixing it would be a hard-fork
< jl2012> max script size is still 10000
< michagogo> jl2012: people overlook obvious things all the time
< wumpus> back then, getting a lot of good review for proposals was a problem, even more than it was now
< wumpus> segwit got *tons* of review compared to BIP16 I'm sure
< michagogo> It's just that overlooking things _here_ has a much bigger potential impact
< michagogo> Victorsueca: did you see my gitian appliance?
< luke-jr> BIP 16 was merged with exactly zero ACKs: https://github.com/bitcoin/bitcoin/pull/748
< wumpus> yes, way different times
< Victorsueca> michagogo: not yet
< michagogo> Victorsueca: you can download it at https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq
< michagogo> There's an .ova there, and a video showing the process of making it
< Victorsueca> wumpus: it's probably getting lots of reviews because everybody loves a well deployed hard-forks, so well deployed that it's even a soft-fork!
< michagogo> About one hour, from the first boot all the way through shutting it down to export
< Victorsueca> I guess nobody thought some years back that a block size increase could be implemented as a soft-fork
< michagogo> Including all the trial-and-error and pauses while I looked stuff up outside the VM
< michagogo> Victorsueca: "some years back" nobody was thinking about the block size and the need to increase it yet
< jl2012> i think the main argument for BIP16 was the output is not anyone-can-spend until it is actually spent. But the difference is very limited
< Victorsueca> michagogo: want me to torrent the .ova up? I could seed it for a while until it spreads
< michagogo> Ah, if you've got a seedbox I can make one
< michagogo> One sec
< Victorsueca> no need, i'll do everything
< Victorsueca> I will send you the magnet link when it's done
< luke-jr> jl2012: the main argument was the implementation didn't touch the script interpreter
< luke-jr> jl2012: which was at the time considered by some to be essentially beyond anyone's competency to modify
< luke-jr> in hindsight, that argument seems ridiculous to me. it may have seemed ridiculous to me at the time, I forget.
< wumpus> it wasn't ridiculous at the time
< wumpus> no one was competent to change that code at the time, least of all Gavin :)
< luke-jr> well, I was the one changing it with BIP 17 ;)
< * luke-jr> ponders if he went back and re-reviewed BIP 17's code, if he'd find any bugs
< michagogo> magnet:?xt=urn:btih:DA7ED2875C26C736B607719549894458E8283407&dn=Gitian%20builder.7z&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969&tr=udp%3a%2f%2ftracker.torrent.eu.org%3a451
< michagogo> Victorsueca: ^
< wumpus> and we still need to be extremely careful with changes to the script interpreter
< wumpus> but there are a few more people clueful in that regard now
< Victorsueca> michagogo: I prefer to create my own if you don't care
< Victorsueca> michagogo: I can use that one tho if you want
< michagogo> Victorsueca: how come?
< luke-jr> glancing at the 1 page of consensus-critical code for BIP 17, I think I'm pretty certain it wouldn't cause consensus failure at least :P
< Victorsueca> michagogo: currently downloading from 1drv
< Victorsueca> michagogo: i'll start seeding it as soon as it's done
< michagogo> molz: did you manage to get it from onedrive in the end?
< tulip> > now that max script size is set on stone, fixing it would be a hard-fork
< tulip> Victorsueca: not exactly. it can be done as a soft fork quite easily, same as segwit :)
< luke-jr> segwit2 can just change the magic bytes! :P
< luke-jr> actually, I guess that'd require retaining the old commitment too. hmm
< tulip> when you think about it, there's actually very little which can't be done with a soft fork. it just depends how far you're willing to go with it. the limit is changing the proof of work, and even that is mutable to a certain extent if you'd like to.
< luke-jr> tulip: go too far and it becomes a soft-hardfork
< tulip> luke-jr: you should implement mohs scale for soft forks, otherwise you're going to increasing make less and less sense.
< luke-jr> ?
< Victorsueca> and if you ever needed to make a hard-fork for whatever reason it could be well deployed if the hashrate majority merge-mines it while nuking the old chain
< aj> tulip: does that mean a bilateral hard-fork might be said to be diamond tipped?
< michagogo> Victorsueca: nuking the old chain how?
< michagogo> Merged mining implies continuing to mine this chain
< Victorsueca> michagogo: you merge-mine both the old and the new chain
< Victorsueca> and you nuke it by soft-forking it to 0 MB blocks
< luke-jr> Victorsueca: 100B
< Victorsueca> luke-jr: your BIP still has a high potential to hard-fork in a bad way if people chooses to build and distribute software that bypasses the Hardfork deployment bitfields, ignores the fact that there are unknown rules activated out there and keeps mining on that chain
< luke-jr> Victorsueca: nothing can prevent incompetent people from writing bad software, nor is it intended to
< Victorsueca> AFAIK the only ways to make a safe hard-fork are either tricking old nodes to think everything is ok and make it a soft-fork (segwit) or soft-fork the old chain in a way that makes it unusable AKA nuking it
< Victorsueca> 2 ways*
< Victorsueca> would be really appreciated by everybody if someone knew another way to make it reasonable safe to ensure the old chain will die
< aj> Victorsueca: you can let old nodes continue to see all the transactions but maybe not understand everything about them (soft-fork), you can let old nodes see none of the transactions (nuke the chain, evil/soft-hard-fork), or you can let old nodes see some but not all of the transactions (sidechains, layer two networks) ...
< Victorsueca> ahh right
< Victorsueca> 3 ways then, sidechains would be the third way
< wumpus> please move this to #bitcoin
< wumpus> it is not related to current bitcoin core development
< Victorsueca> wumpus: thanks, will keep that in mind for the next time, I think we're done now
< wumpus> this channel is for discussing code changes
< Victorsueca> so, what is libconsensus exactly for?
< Victorsueca> is it like a way to detach consensus rules from the main software?
< wumpus> a) so that third-party applications can make use of the consensus code b) to cordon off consensus code from the rest of the software
< jonasschnelli> I think the idea with a local instance would work as well...
< jonasschnelli> But the extra mapping from UI to the new coincontrol instance is a little bit nasty
< jonasschnelli> I would prefer per-send-wide coin-control... but I agree, there are some risks.
< jonasschnelli> In general, the CoinControl objects gets "nulled()" when the user disable the CC features in the settings: https://github.com/bitcoin/bitcoin/pull/8989/files#diff-76b18bd21ccf64e256f029a8198ecdd7L702
< wumpus> I understand, but I don't think we should be passing the CoinControlDialog's coincontrol instance in case coincontrol is disables. My code makes sure it gets a fresh instance with default values and just the confirmations overridden
< wumpus> which is exactly what we want if coin control is only to be used to pass that parameter
< jonasschnelli> Okay. Yes. Your right. Let me change it
< jonasschnelli> I also revert the slider direction inversion.
< jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/8989/files, in case you want to review it again
< wumpus> yes, that looks good to me now
< Victorsueca> michagogo: here's your torrent https://softnet.homenet.org/tokenid_3qsqxgu5wkhopt4k2daqbuxc/
< Victorsueca> username is bitcoin and password is mdtj4g5w5bppajnpmt2ow2dx
< Victorsueca> I password protected it so google doesn't bother me with malware removal warnings
< michagogo> Victorsueca: what's wrong with the other one?
< michagogo> Also, I'm not at my computer now
< michagogo> Don't know when I'll be able to get it
< michagogo> (And why not just a magnet link?)
< Victorsueca> michagogo: I make my torrents in a way they go sooper-fast :P
< Victorsueca> I tried it, but the way I do it magnet links are too long for any clipboard
< Victorsueca> also no need to hurry, take your time until you get to your computer
< Victorsueca> :)
< wumpus> github is so slow here...
< jonasschnelli> wumpus: yes. extra-slow at my end as well
< morcos> jonasschnelli: wumpus: i understand the logic of why the GUI fee estimation PR just changes 25 -> 2, but I don't want to risk that we end up with a GUI defaulting to 2. I worry that a separate PR to change the overall default from 2 -> 6 will get bikeshedded to death.
< morcos> And without that I think we're creating a worse user experience. Essentially even more people will be paying too much in fee. 25 is a better choice than 2 IMO.
< jonasschnelli> I think 6 would be resonable... but we would need to change RPC and GUI
< jonasschnelli> I don't expect to much bikeshedding
< GitHub78> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e228557f239...7b1bfa3a8786
< GitHub78> bitcoin/master 0a261b6 Jonas Schnelli: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()
< GitHub78> bitcoin/master 3154d6e Jonas Schnelli: [Qt] use NotifyHeaderTip's height and date for the progress update
< GitHub78> bitcoin/master 7b1bfa3 Jonas Schnelli: Merge #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip()...
< morcos> ok, well i'm just nervous becuase I tried to change it to 6 when it got changed to 2 and I met resistance
< GitHub79> [bitcoin] jonasschnelli closed pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (master...2016/10/fix_gui_overlay) https://github.com/bitcoin/bitcoin/pull/8985
< jonasschnelli> Okay. I see your point.
< wumpus> yes, I like 6 too
< GitHub53> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b1bfa3a8786...3fb3fade3c02
< GitHub53> bitcoin/master 1ae5839 Wladimir J. van der Laan: moveonly: move `coincontrol` to `src/wallet`
< GitHub53> bitcoin/master 3fb3fad Wladimir J. van der Laan: Merge #8990: moveonly: move `coincontrol` to `src/wallet`...
< GitHub155> [bitcoin] laanwj closed pull request #8990: moveonly: move `coincontrol` to `src/wallet` (master...2016_10_coincontrol_wallet) https://github.com/bitcoin/bitcoin/pull/8990
< * Victorsueca> starts building that
< jonasschnelli> Hmm... rc2 does not run on OSX 10.7
< michagogo> Victorsueca: hm, what is it that you do?
< michagogo> I would have thought a torrent is a torrent…
< Victorsueca> michagogo: not sure, I just touched a lot of settings to a option that sounded right to me and then it my torrent files started downloading things faster wherever I run them
< michagogo> Victorsueca: which settings?
< Victorsueca> michagogo: the ones when creating a new torrent file
< michagogo> I'm asking, what settings did you use!
< michagogo> use?*
< Victorsueca> not sure if any of them made actually some effect or it's just my connection
< Victorsueca> let me check...
< jonasschnelli> ping cfields_ : https://github.com/bitcoin/bitcoin/issues/8577
< Victorsueca> michagogo: set chunk size to 2 MiB and added a lot of trackers (200 or so)
< Victorsueca> those are the settings
< michagogo> Victorsueca: pretty sure the chunk size was 2 on mine too
< michagogo> Or maybe it was 4
< michagogo> And you can just add trackers...
< michagogo> Not that it really matters, since DHT+Peer Exchange mean that you don't really need trackers
< Victorsueca> I guess it's my connection then...
< michagogo> With pex, you really just need 1 other peer
< michagogo> Like Bitcoin, sort of
< Victorsueca> well, doesn't really matter, I already started seeding the one I made
< Victorsueca> I can seed yours tho if you really want
< instagibbs_> so why do we make outbound connections to nodes that can't serve us the data we want at all?
< sipa> instagibbs_: because they may give us addresses of peers that do
< instagibbs_> currently we don't do churn of those peers though right
< instagibbs_> like, every X minutes, cycle peers that don't offer services you require
< instagibbs_> (good point though)
< sipa> interesting
< sipa> we do have oneshot connections, which just request an addr and disconnect
< instagibbs_> yeah, feelers
< sipa> no, that's something else still :)
< instagibbs_> oh, doh
< sipa> those don't even get addresses, but just test whether the address is reachable
< instagibbs_> oh of course, i misread
< Victorsueca> we could make it connect, ask for addresses, check if any equiered service is available, if yes then keep alive, if no then drop
< sipa> oneshot connections are used when you're on tor and nedd to use a dns seed for example
< sipa> Victorsueca: we know whether the service is available before we connect
< instagibbs_> via service bits
< instagibbs_> ?
< sipa> yes
< Victorsueca> but you still need to connect to request addresses tho
< sipa> yes
< sipa> and to generally not worsen partitioning of the network
< sipa> even if no peers are available that we like, it's still better to keep the network whole
< instagibbs_> what is it called to talk to a peer for service bits but not connect?
< sipa> ?
< instagibbs_> "we know whether the service is available before we connect" yet we know service bits
< sipa> yes, because the service bits are in addrdb
< GitHub36> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fb3fade3c02...5af9a7117cff
< GitHub36> bitcoin/master 6f2f639 Jorge Timón: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/
< GitHub36> bitcoin/master 5af9a71 Wladimir J. van der Laan: Merge #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/...
< GitHub164> [bitcoin] laanwj closed pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (master...0.13-chainparams-init) https://github.com/bitcoin/bitcoin/pull/8975
< sipa> i'm just responding to Victorsueca that the idea of not disconnecting if they do offer the right setvices isn't meaningful... we know that beforehand
< GitHub86> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5af9a7117cff...3cf496d102d2
< GitHub86> bitcoin/master 72ca7d9 Matt Corallo: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock
< Victorsueca> yeah, I understand, if we know the IP to connect to it is because some node told us, and when it did it also told us the available services
< GitHub86> bitcoin/master 3cf496d Wladimir J. van der Laan: Merge #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock...
< Victorsueca> which are stored in the addrdb
< sipa> Victorsueca: exactly
< GitHub170> [bitcoin] laanwj closed pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
< wumpus> although the services in the addrdb could be wrong, e.g. the peer may have changed services in the mean time
< instagibbs_> err when do we store them in the addrdb
< * instagibbs_> looking at code
< sipa> right, but if the services in addrdb are wrong, we treat it as we accidentally connected to the wrong peer
< BlueMatt> wumpus: wait, when did we decide 8968 was for 0.13.1?
< BlueMatt> I thoguht we said no in milan?
< wumpus> oh it isn't?
< wumpus> removing tag
< Victorsueca> lel
< BlueMatt> yes, I think it is uneccessary for 0.13.1
< sipa> BlueMatt: i can't actually remember having a good reasoning why it isn't necessary... but ibagree with the assessment that without clear sign of problems it's just ugly
< BlueMatt> sipa: you're the one who pointed out that cs_main should always be the top lock
< BlueMatt> so adding a cs_main should be just fine
< wumpus> yes, at most you'll be holding it unnecessarily
< sipa> ah
< sipa> well, "should" :)
< * sipa> breakfast
< Victorsueca> don't know why but "cs_main" and "lock" in the same sentence sounds to me like you're going to fuck the databases and hard-fork something :P
< Victorsueca> and I don't know coding at all
< wumpus> please...
< sipa> Victorsueca: then perhaps you shouldn't comment in this channel
< Victorsueca> sorry, hope not to have jinxed you :S
< BlueMatt> so, thus far, rc2 is final - doc changes?
< sipa> want me to test whether "cs_main is always the topmost lock" is true?
< BlueMatt> sipa: please do
< BlueMatt> last block: propagated entire fibre network within 4ms of the speed of light between my servers
< BlueMatt> ok, thats a lie, 10
< BlueMatt> but whatever, thats pretty good
< sipa> your technology sucks. you could get the block a full 3000 km further in the same time!
< BlueMatt> not in glass!
< BlueMatt> (closer to 1750km)
< sipa> better get working on that vacuum-tube-fiber
< Victorsueca> someone said github was slow before?
< Victorsueca> I think I found why
< Victorsueca> someone has been DDoSing Dyn nameservers at US east coast
< Victorsueca> basically _half_ internet is down
< rabidus_> Victorsueca: github down for me, also netflix
< rabidus_> that's all i've found
< Victorsueca> yeah, it's mostly huge and important services
< Victorsueca> twitter, amazon, netflix, spotify...
< jtimon> github, soundcloud, twitter (not from the android app)...
< cfields_> wtf, i just came here to ask if half of the net was down for everyone else. I assumed it was a stupid question.
< BlueMatt> you want 192.30.253.113
< rabidus_> amazon.com works
< BlueMatt> cfields_: it works in most places
< BlueMatt> google dns appears to be working around it appropriately
< cfields_> BlueMatt: thanks. my dns setup is a bit weird, i'll wait a bit before changing stuff around
< BlueMatt> cfields_: hardcode to the above ip, then
< BlueMatt> (that is github)
< BlueMatt> /etc/hosts :)
< cfields_> BlueMatt: ah perfect, thanks
< rabidus_> because it doesn't work for me
< sipa> everything seems fine here
< BlueMatt> sipa: yea, west coast seems mostly fine, as in apac
< jtimon> alright, setting manual DNS to one in the spanish list here did the trick: http://public-dns.info/
< rabidus_> it think i'm going with big brother dns
< rabidus_> good old 8.8.8.8
< jtimon> oh, I tried 8.8.8.8, 8.8.4.4 first but it didn't worked because I forgot the coma, stupid me
< jtimon> this kind of thing wouldn't happen if all domains were in a blockchain
< * jtimon> hides
< * sipa> forks jtimon
< instagibbs_> stupid pill q: for inbound connections, how does the nServicesExpected vs offered check pass? It looks to me that expected services is only set for outgoing?
< instagibbs_> this line "if (pfrom->nServicesExpected & ~pfrom->nServices)"
< sipa> that check is always false if nServicesExpected is 0
< instagibbs_> I was thinking xor... lol. sorry.
< instagibbs_> Confused myself into thinking logic was "any difference in bits" vs "any expected but missing services"
< cbit> yeah, done for me too
< cbit> down*
< cbit> west coast here..
< rabidus_> just started working here in finland
< rabidus_> at least netflix :P
< GitHub174> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3cf496d102d2...f08222e882b1
< GitHub174> bitcoin/master 3a286ab S. Matthew English: Eliminating Inconsistencies in Textual Output...
< GitHub174> bitcoin/master f08222e MarcoFalke: Merge #8982: Eliminating Inconsistencies in Textual Output...
< GitHub104> [bitcoin] MarcoFalke closed pull request #8982: Eliminating Inconsistencies in Textual Output (master...patch-6) https://github.com/bitcoin/bitcoin/pull/8982
< BlueMatt> cat /etc/hosts
< BlueMatt> 192.30.253.113github.com
< BlueMatt> 151.101.100.133 assets-cdn.github.com
< BlueMatt> for those who are missing the cdn entry, though that one might very well be geoip, so have fun on the HKG one
< rabidus_> or 8.8.8.8,8.8.4.4
< BlueMatt> github isnt resolving on 8.8.8.8 for me atm
< rabidus_> wtf, it is for me
< BlueMatt> 8.8.8.8 isnt just one server :p
< rabidus_> or then my main dns started working
< rabidus_> oh, yeah :P
< BlueMatt> cfields_: ok, #8969 is ready for review since the cs_main fix was merged :)
< btcdrak> There are also level3 DNS servers at 4.2.2.1, 4.2.2.2
< BlueMatt> those dont work from all networks
< BlueMatt> (also, level3 hates it when you publish those - they're supposed to be for l3 customers)
< * btcdrak> shrugs
< jeremyrubin> Annoyingly, Dyn ddos also seems to break travis.
< jeremyrubin> Because travis doesn't have a pinned ip or something for github, so they can't find any of the repos
< midnightmagic> :-/ What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
< midnightmagic> "Sign this message acknowledging you authorize this github user to own your commits."
< GitHub149> [bitcoin] instagibbs opened pull request #8992: Enable pubkey lookup for p2sh-p2wpkh in validateaddress (master...validatep2pkh) https://github.com/bitcoin/bitcoin/pull/8992
< GitHub91> [bitcoin] paveljanik opened pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993