--- Day changed Sun Oct 23 2016
00:20 -!- whphhg [whphhg@gateway/vpn/mullvad/x-mlrqpwufzhrezwpt] has quit [Remote host closed the connection]     
00:23 -!- whphhg [whphhg@gateway/vpn/mullvad/x-esubhllmpubqjlkk] has joined #bitcoin-core-dev     
00:28 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b541:5335:1ffb:2cf0] has joined #bitcoin-core-dev     
00:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
00:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
00:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cgamizkzqzjurxpu] has joined #bitcoin-core-dev     
00:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
00:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
00:56 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Ping timeout: 265 seconds]     
01:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
01:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
02:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
02:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds]     
02:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
02:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
02:56 < gmaxwell> why is getblocktemplate returning txn results for me on a 0.13.1rc1 node?
02:56 < gmaxwell> I thought as soon as segwit was defined it needed the capability?
02:57 < gmaxwell> ... if thats only triggered on activation, then uh we would expect some portion of hashpower who hasn't correctly prepared to simply drop off at that point.
02:57 < gmaxwell> Where did I desync?
02:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
03:04 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
03:07 -!- murch [~murch@p4FE38A82.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:17 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
03:27 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-njkvpupsylyxruua] has joined #bitcoin-core-dev     
03:28 < sdaftuar_> gmaxwell: possible I'm misremembering but I think gbt just won't signal for segwit until the capability is specified, but it will still return successfully
03:28 < sdaftuar_> There should be tests for the intended behavior in segwit.py or p2p-segwit.py
03:30 < gmaxwell> oh thats okay too then!
03:33 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded]     
03:33 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
03:35 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
03:35 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
03:37 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection]     
03:37 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
03:40 -!- sdaftuar__ [uid164573@gateway/web/irccloud.com/x-bocfdrrtcglazjit] has joined #bitcoin-core-dev     
03:40 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-njkvpupsylyxruua] has quit [Ping timeout: 260 seconds]     
03:41 -!- sdaftuar__ is now known as sdaftuar_     
03:41 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
03:44 -!- ratoder [~ratoder@static.111.19.201.138.clients.your-server.de] has joined #bitcoin-core-dev     
03:49 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
03:51 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-bocfdrrtcglazjit] has quit [Ping timeout: 260 seconds]     
03:52 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-zqkujflaoprdrowe] has joined #bitcoin-core-dev     
04:01 < wumpus> luke-jr: because including the svg rendering engine would introduce an extra dependency, and also qt4/qt5 differences IIRC
04:01 < wumpus> also drawing SVG is generally slower than just drawing pixmaps, unless you have some smart caching layer, I have no clue where Qt is in that regard
04:02 < wumpus> tldr it's just a big risky change and things work pretty well as they do
04:03 < wumpus> maybe it makes sense when, if ever, moving from qt widgets to qml quick or such based gui. I have no relevant experience with any of the qt newness in the last few years though.
04:03 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
04:06 < wumpus> in any case I doubt we'll accept a patch that just changes image rendering to svg and has zero visual changes for the user, even though it would be 'neater' way of doing things in some sense, it's just not worth the review and testing overhead
04:07 < wumpus> on the other hand a snappy GUI-redo that blows everyone away and happens to need SVG rendering, well, sure
04:13 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
04:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:17 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
04:18 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
04:18 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
04:21 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
04:28 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
04:35 -!- testnet [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
04:35 -!- testnet [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has left #bitcoin-core-dev []     
04:38 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-zqkujflaoprdrowe] has quit [Ping timeout: 260 seconds]     
04:40 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-yyxyeqtqjubmguit] has joined #bitcoin-core-dev     
04:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
04:56 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
04:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:00 -!- sdaftuar_ [uid164573@gateway/web/irccloud.com/x-yyxyeqtqjubmguit] has quit [Ping timeout: 260 seconds]     
05:00 -!- sdaftuar__ [uid164573@gateway/web/irccloud.com/x-ovypfnjixgllmvwi] has joined #bitcoin-core-dev     
05:03 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
05:04 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
05:05 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
05:06 < nsh> there were a couple issues identified in NCC audit by NCC group which might be relevant to bitcoin-core. not sure if they made it upstream. 
05:06 < nsh>  NCC-2016-015 - Out-of-bounds Read in Boost date Class #1459 - https://github.com/zcash/zcash/issues/1459
05:06 < nsh>  NCC-2016-008 - Potential uninitialized reads #1464  - https://github.com/zcash/zcash/issues/1464
05:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:08 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:09 < wumpus> I've seen the report, but thanks for the update
05:09 < wumpus> the respective fixes haven't made it upstream yet
05:10  * nsh nods
05:19 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
05:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
05:21 < jtimon> gmaxwell: wumpus btcdrak sorry I missed the rest conversation in https://botbot.me/freenode/bitcoin-core-dev/2016-10-22/?msg=75272893&page=1
05:22 < jtimon> I know btcdrak hates "cascading PRs", but I think it makes sense here
05:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:23 < jtimon> I plan to finish https://github.com/jtimon/bitcoin/compare/0.13-new-testchain...jtimon:0.13-blocksign hopefully on monday 
05:23 < btcdrak> nice!
05:24 < jtimon> but I think they could really just use this temporarily and I'm afraid the block signing part will require a lot more review and testing and will take longer to merge
05:24 < jtimon> they can -chain=custom -chainpetname=lightning, new chain
05:25 < btcdrak> I'm ok with two PRs. blocksign will be rebased on the first PR anyway right? 
05:26 < jtimon> if an idiot spends a lot of energy mining that testchain, you can just -chain=custom -chainpetname=lightning2 and show him your middle finger, you can always -listen=0 -connect=... etc
05:27 < jtimon> btcdrak: yeah blocksigning will be on top of this one since to create a new blocksigning chain you need to first create a new chain
05:28 < jtimon> reading from a file was a later addition, but it was like 4 lines extra
05:29 -!- mol is now known as moli     
05:30 < jtimon> at least reusing ReadConfigFile, if we really prefer a json file over a conf file that may be more extra work, not sure how strongly wumpus wants json, I personally don't see the gain
05:31 < btcdrak> I think json makes sense, there are potentially a lot of chain params to configure.
05:33 < jtimon> regarding "what they asked for" rusty asked for providing the genesishash manually instead of it being calculated dynamically  from the genesis block (you can force a new genesis just changing -chainpetname) like this PR does, so I wanted his feedback on that (it's true I didn't need to open the PR already for that)
05:34 < jtimon> btcdrak: the same number as with a conf file, but you're just not able to reuse util to handle them
05:35 < jtimon> I don't think CChainParams::UpdateFromArgs() will get smaller by using json
05:36 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Remote host closed the connection]     
05:36 < btcdrak> It's also easier to share chain details with a json file.
05:37 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
05:37 < jtimon> regarding "a pointless feature that we've already lowered the quality of the codebase to enable" I strongly disagree but I'm not entirely sure what gmaxwell is refering to
05:38 < jtimon> he mentions Params().GetConsensus().getdarnaninterger() inside a loop
05:39 < wumpus> let's bury that part of the discussion please
05:39 < wumpus> both gmaxwell and me went out of line there
05:39 < wumpus> blame it on stress, or whatever
05:41 < jtimon> as opposed to chainparams.GetConsensus().getdarnaninterger() so I assume he is not complaining about changes related to #7829 . If he is complaining about the GetConsensus part, that was only for libconsensus to avoid the chainparams dependency which contains globals. Of course I agree that shouldn't be in a loop, it should be called once and made a local variable outside the loop, if it is the only chainparams that the function
05:42 < jtimon>  needs, it should take darninteger directly as parameter instead of the whole CChainParams
05:42 < jtimon> ok, not trying to revive any fire, just trying to make sure we're on the same page
05:42 < wumpus> I explained the reasoning behind it afterward, and what will be the future direction, no need to rake up anything
05:43 < wumpus> right
05:43 < jtimon> btcdrak: how is sharing mychain.json any easier than sharing mychain.conf ?
05:43 < wumpus> if there's a bla().bla().bla() in a loop we can just factor it out of the loop, this is not rocketscience :)
05:44 < gmaxwell> putting things in a file does not make them configurable.
05:44 < gmaxwell> please keep that in mind.
05:44 < wumpus> jtimon: json may be a more convenient format for automatic generation from the tests / handling nested structures, but I don't care deeply
05:44 < jtimon> wumpus: what are your thoughts on json vs conf since you brought that up?
05:44 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Ping timeout: 260 seconds]     
05:44 < gmaxwell> many of our constants tie deeply into algorithims and protocol assumptions.
05:44 < jtimon> I see
05:44 < btcdrak> what wumpus said
05:45 < wumpus> yes, there is compromise somewhere on what constants whould be configurable, I think the ones curently in ChainParams make sense though
05:45 < wumpus> this doesn't mean the entire algorithm should be micro-manageable though the configuration file
05:45 < wumpus> unless you want to replace it with JITed LUA or so, but that's clearly not a goal here
05:46 < gmaxwell> yep.
05:46 < gmaxwell> (as I said, just something to keep in mind.)
05:47 < wumpus> it may be possible to switch between discretely defined algorithms in the config file though, e.g. between a PoW or "centrally signed blocks"
05:47 < gmaxwell>         fRequireStandard = false;
05:47 < gmaxwell> sure
05:47 < jtimon> once they're in ChainParams they are not constants, but we may have abused ChainParams and maybe we want to try to turn some back into constants (if testnet and regtest have the same values at least)
05:48 < wumpus> well they are constants after reading them from the configuration file
05:48 < wumpus> they don't change at runtime, that would be madness
05:48 < jtimon> the way I was planning to expose the blocksigning was through a variable like -blocksignscript, maybe a boolean too
05:48 < wumpus> sure, at the language leven they're not constants, but they already are not because they're fetched from a structure...
05:49 < wumpus> leveL
05:49 < jtimon> wumpus: right, they init once and then ChainParams should be always passed as const
05:49 < gmaxwell> there are a at least some things that the values in chain params for testnet/regtest are at odds with the code. don't assume the paramters for testnet or regtest were especially well thought out. :) there may be places where we want to reduce their divergence with mainnet in the future... as their differences are a continued source of time-waste.
05:50 < wumpus> gmaxwell: that's our whole point, though, there may be use for testnets that are more close to mainnet, or further away from it, dependeing on the specific testing
05:50 < jtimon> I fear a cleanup may require testnet4 and regtest2
05:50 < gmaxwell> I am wtfing at regtest2.
05:51 < wumpus> regtest2 makes no sense
05:51 < gmaxwell> but duh sure, improving things may mean some incompatiblities. thats fine.
05:51 < wumpus> there is no shared 'regtest' network
05:52 < wumpus> although compatibility between versions may be useful for comparison testing
05:52 < wumpus> (!)     
05:52 < jtimon> well, maybe if you want to make some values more similar to the mainnet to make them constants again, but I really don't know, I've thought more about testnet4, particularly in the context of bip70 which maybe gets replaced or something
05:53 < gmaxwell> E.g. I don't think when we created testnet or regtest anyone tought of the idea of inserting an optional bit mask in the target comparison function, so that high value blocks could be seen as meeting much lower targets.  I think if we'd thought of that we could have avoided some of the special difficulty rules there.
05:53 < jtimon> I particularly hate the fact that in bip70 testnet3 is called "test" instead of "testnet3" but that's a tiny detail
05:54 < wumpus> well a new testnet would need a new bip70 identifier I guess so that can be fixed then... but it's a minor inconsequential thing
05:55 < jtimon> and I dislike testnet's special case for pow too, but matt said it was quite useful (I don't really know)
05:55 < wumpus> well it will always need a special case for PoW, the question is can we do better than testnet3
05:56 < jtimon> not sure I understand gmaxwell's point about the bit mask
05:57 < wumpus> without special case for PoW a miner entering it and exiting it will just kill it, this happened before and was the reason for adding it to testnet3 in the first place. That doesn't mean it's the perfect solution that shoudl be used forever, but just reverting to plain PoW would be stupid.
05:57 < gmaxwell> regtest's 'special casing' requires difficulty go below one, which causes a large amount of divergence in the code.
05:57 < jtimon> wumpus: maybe a different difficulty filter would help more, but that's strong special-casing too
05:58 < wumpus> I sometimes wonder why doesn't just ignore PoW completely
05:58 < wumpus> regtest*
05:58 < wumpus> that would mean the PoW checking is regression tested less, ofcourse
05:58 < wumpus> jtimon: my point is just that testnet requires special casing there, the type of special casing is open for proposals though
05:58 < jtimon> gmaxwell: I see, what about making regtest just always pass the pow check?
05:59 < gmaxwell> that could have been better accomplished with a if (params->weakpow) memset(blockhash,0,4);  in the pow comparison. 
05:59 < jtimon> I see
05:59 < gmaxwell> jtimon: there are tests that need pow to not be bypassed. Or at least there have been in the past, e.g. feeding lower difficulty blocks.
06:00 < wumpus> yes, that would make sense
06:00 < jtimon> gmaxwell: yeah just passing pow would need those tests to move to mainnet or testnet, but your solution seems less disruptive
06:00 < gmaxwell> the testnet getting stuckthing, even the current setup has problems with that, part of the call for the availability of signed block testnets.
06:00 < wumpus> regtest as it is now was a compromise back in the day and it works pretty well for regression testing, most trivial alternatives are probably worse
06:01 < gmaxwell> it also existed as a patch at first, it wasn't quite so designed out. Did it's roll fine, but with expirence better could be done now.
06:01 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
06:01 < jtimon> gmaxwell: right, so maybe after adding signed blocks it makes more sense to remove testnet3's mindif special case
06:02 < gmaxwell> It might also be possible to set the rest of the paramters like normal (2016 blocks, yadda yadda, just make it cheaper to mine if its not fast enough)
06:02 < gmaxwell> jtimon: potentially.
06:03 < gmaxwell> Basically we should either have divergences that _really_ aid testing (signed blocks) or otherwise minimize them, we really have lost of a lot of troubleshooting time due to testnet having issues that mainnet would never have, not all due to paramter differences, but many.
06:03 -!- n1ce2 [~n1ce@198.144.116.60] has joined #bitcoin-core-dev     
06:04 < jtimon> right
06:05 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
06:06 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Ping timeout: 260 seconds]     
06:06 < jtimon> regarding block signing, I was thinking making it optional at compile time and just have blocks having both nBits-nNonce and scriptChallenge-scriptSolution in blocks (that's a hit on memory requirements that shouldn't be imposed on production nodes)
06:06 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
06:07 < jtimon> previously thought of union, but even that would be a hit if you cannot disable it at compile time
06:07 < jtimon> how does that sound?
06:08 < jtimon> I mean, even an extra pointer and polymorphism would be 4 or 8 extra bytes per header (apart from polymorphism performance concerns)
06:08 < wumpus> where would be the hit in memory requirements? header stoage?
06:08 < jtimon> yep, header storage
06:09 < wumpus> ok yes bleh, that structure is already too fat
06:09 < jtimon> in elements we just remove nBits and nNonce, but obviously we cannot do that here
06:09 -!- n1ce2 [~n1ce@198.144.116.60] has quit [Ping timeout: 250 seconds]     
06:09 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
06:09 < jtimon> so ack on compile time option for signed blocks?
06:09 < wumpus> using an union sounds better then
06:10 < wumpus> well compile time option does mean it cannot be used for the normal tests
06:10 < wumpus> and probably won't be enabled by default in releases
06:10 < wumpus> I'd prefer not to do that, unless this is a rarely used, memory hogging option, but then who would enable it in practice?
06:10 < jtimon> mhmm, if you allow the option you compile the tests that need it too?
06:11 < sipa> i don't think you can use a union with non-trivial C++ types in it
06:11 < jtimon> only devs I was assuming
06:11 < wumpus> this is about trivial C++ types such as ints right? nBits, nNonce etc
06:11 < sipa> c+11 relaxed the requirements a bit, though
06:11 < wumpus> if not that's a dangerous minefile
06:11 < wumpus> minefield*
06:11 < sipa> for block signing the signature is a CScript
06:11 < gmaxwell> compile time is pretty sad, how about an auxiliray datastructure that only gets created if using signed blocks, e.g. a second index?
06:11 < sipa> in CBlockHeader
06:12 < wumpus> that needs to be stored for every block, permanently?
06:12 < sipa> yes, instead of a nonce you have a signature
06:12 < jtimon> I was thinking ethier a union of structs PowProof and ScriptProof or an IntOrScript union for both nBits and nNonce
06:12 < wumpus> gmaxwell: yes
06:12 < gmaxwell> well technically it's a block witness...
06:13 < gmaxwell> segregate all the witnesses. :P
06:13 < wumpus> that makes sense; with using an union you could even take the additional memory requirement to 0
06:13 < wumpus> union a pointer with nBits,nNonce
06:14 < jtimon> I mean, the challenge field could be just constant per chain instead of being included in every block, I was just thinking that maybe someone could get creative with CalculateNextScriptChallenge or something
06:14 < wumpus> (i mean the additonal memory requirement when not using the feature, which is what we care about here)
06:14 < jtimon> this is it's actually in both CBlockHeader and CBlockIndex
06:15 < jtimon> wumpus: yeah, at a minimum union a pointer would be an extra pointer per block, that's my worry
06:16 < sipa> ah, it seems you can have non-trivial classes in a union now
06:16 < sipa> but it requires placement new and explicit destructor invocations
06:16 < jtimon> yep IntOrScript seemed to compile
06:17 < wumpus> jtimon: I don't understand that. You'd only need the pointer when using block signing, youd' only need nBits+nNonce when using PoW, those could be in the same memory space right?
06:18 < jtimon> so it would be a pointer to a struct that is either nBits+nNonce or a script (or a couple of them)
06:18 < sipa> wumpus: nBits is the "challenge" which can in theory also be replaced with a "block scriptPubKey"
06:18 < wumpus> jtimon: in the first case it'd just be nBits+nNonce in-place, in the second case it'd be a pointer to a script
06:18 < sipa> wumpus: so you can allow rules about how the signer(s) can change over time
06:18 < wumpus> sipa: okay
06:18 < sipa> however, that seems overkill here
06:18 < gmaxwell> a bit out of scope here but not incompatable.
06:19 < jtimon> sipa: right, but we can also remove that if the challenge script is going to be always constant
06:19 < sipa> as the block challenge can just be a chain wide constant as jtimon says
06:19 < gmaxwell> the union is the 64 bits of nbits+nonce or a pointer to an extension datastructure.
06:20 < jtimon> wumpus: I see, yeah, that's better and removes the need for the compile time option, thanks!
06:20 < sipa> perhaps we want the union to be between {nBits,nNonce} on the onenhand, and CScript *scriptSig on the other
06:20 < wumpus> sipa: that's what both gmaxwell and me are saying , yes :)
06:21 < sipa> note the *
06:21 < wumpus> I had assumed the *
06:21 < jtimon> or we could put the script in the coinbase with the other witnesses, but I'm not really sure I like that
06:21 < wumpus> I have no clue what the size of CScript is, but I'd guess it's larger than 8
06:21 < wumpus> so yes that should be a pointer
06:21 < sipa> 24     
06:22 < sipa> on 64-bit
06:22 < sipa> actually, it's a prevector, so much larger
06:22 < jtimon> yep, now I'm embarrased I didn't thought of the union being like that myself, but thanks guys, good call
06:22 < sipa> for some reason i am very scared of using unions
06:23 < wumpus> in this case the way it is used depends on a global setting, so I'm okay with it
06:23 < wumpus> I'm scared of tagged/per-case unions though
06:23 < jtimon> sipa: yeah that motivated my run to the compile option too
06:23 < sipa> but the CBlockHeader destructor will need to know which of the two cases is being used
06:23 < sipa> that's very ugly
06:23 < sipa> how will it know? a global?
06:24 < wumpus> maybe have two different CBlockHeader types?
06:24 < jtimon> oh, right, that's ugly
06:24 < jtimon> a static field in CBlockHeader maybe
06:24 < sipa> jtimon: that's just a global
06:24 < wumpus> CPoWBlockHeader CSignedBlockHeader .. but yeah that moves the problem up :)
06:24 < jtimon> sipa: yep
06:24 < sipa> wumpus: then you need to templatize all the block logoc
06:25 < jtimon> wumpus: CPoWBlockHeader CSignedBlockHeader is way too disruptive
06:25 < wumpus> yes...
06:25 < wumpus> no, never mind, that would be stupid in c++ :)
06:26 < jtimon> I mean, it's CBlockHeader<proofType> or whatever, but still, not an option I think
06:26 < wumpus> this is pretty much the place where the inflexibilty of C languages starts to show
06:27 < gmaxwell> only if the header itself owns the data, and it isn't just an index into a seperate data structure.
06:27 < wumpus> either you have to template everything, or do some crazy union hack, both seem like bad choices...
06:27 < sipa> it is in fact much easier (in terms of code changes) to make it tagged
06:27 < jtimon> well, I guess the less disruptive option would be to make CBlockHeader the base and use polymorphism, but I think we want to avoid that too
06:27 < gmaxwell> e.g. you could have a header-extradata structure, and the header just gets indexes into it. iirc we don't ever delete headers one accepted.
06:28 < wumpus> sipa: yes, but the tag takes up extra space, which was what we wre trying to avoid in the first place :)
06:28 < sipa> wumpus: i know, but far less than just always having both cases
06:28 < gmaxwell> so the extradata structure would own its own memory and be responsable for freeing it on shutdown.
06:28 < sipa> gmaxwell: the extra data is not just in CBlockIndex
06:28 < wumpus> gmaxwell: yes, indeed
06:29 < sipa> it's part of every CBlockHeader we send and receive
06:29 < jtimon> I think the best candidates are union and a compile time option
06:29 < sipa> it sounds very hard to avoid a memory leak if you do not deal with deletion
06:29 < jtimon> right, plus CBlock extends from CBlockHeader
06:30 < wumpus> what I like least about this is that it changes consensus data structures
06:30 < wumpus> for something that is just for testing
06:31 < jtimon> yep, that may be another argument in favor of the compile time option (which I realise is independent from using the union or not)
06:32 < gmaxwell> Compile time option would greatly diminish the utility of this. (especially considering the size of our static binaries)
06:32 < wumpus> with compile time option you could *guarantee* that the normal case remains unchanged
06:33 < gmaxwell> Yes.
06:33 < gmaxwell> at that point, might as well just make it a seperate repo and resync to core periodically, I think.
06:33 < wumpus> which is, imo, the only acceptable way to do this
06:33 < wumpus> yes, probably. It's effectively an altcoin at that point :)
06:34 < gmaxwell> Right, so why take noise in the codebase for it if we can't even make it as integrated as testnet? it's at least a pretty clean patch.
06:35  * wumpus wants pluggable consensus libraries
06:35 < wumpus> yes, it seems it's not practically doable at this time
06:35 < wumpus> in our current codebase and structure
06:38 < jtimon> well, I will try with the union and without compile time option and see how it looks like
06:39 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Quit: Nettalk6 - www.ntalk.de]     
06:39 < jtimon> if we do it as a constanly rebased branch, at least merging the custom chain patch would make the blocksigning one more maintainable
06:40 < sipa> jtimon: agree
06:40 < sipa> i was surprised there was not a resurgence of coingen like sites after chainparams was merged :)
06:42 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
06:44 < jtimon> sipa: you where also surprised there wasn't an elements_alpha_with_pow_back altcoin I asume, I guess you forget that the most important part of an altcoin is the logo not the features :p
06:44 < wumpus> proabably coingen didn't work too well as a business model
06:45 < wumpus> making it even easier to make altcoins by just changing one source file undermines that further, who would pay for it anymore :)
06:45 < sipa> wumpus, jtimon: we can of course trying the separate-branch approach first, merging only the unlikely-to-affect-consensus patches in mainline, to see how much interest there is in it
06:45 < wumpus> yes     
06:45 < sipa> sure, not having it integrated inline may hurt adoption of such a chain
06:46 < sipa> but on the other hand, it would be a pity tongo throigh all the work of plugging this in if it doesn't get used
06:46 < sipa> *to go through
06:48 < jtimon> in any case, I think chainparams is older than coingen , isn't it? I don't remember not being a chainparams
06:51 < gmaxwell> not at all.
06:53 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
06:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
06:55 < sipa> chainparams was only in june 2013
06:56 < sipa> before that, we just had "if (fTestnet)" all over the place
06:57 < sipa> and testnet itself was october 2010, 2 months before i ever looked at the code
07:00 < wumpus> also altcoins, inherently driven by speculation, have always tended to fork from what is the speculation hotness of the day, at one point this was litecoin, after that the "PoS" coins, now it's probably ethereum-ism things. A profitable coingen would have to follow all that :p
07:00 -!- sdaftuar__ [uid164573@gateway/web/irccloud.com/x-ovypfnjixgllmvwi] has quit [Quit: Connection closed for inactivity]     
07:01 < tulip> for a long time most alt coins were, and still are 0.6 based branches. the original proof of stake patches were never rebased onto modern Bitcoin Core until quite late in the crazy. the original lfnet IRC channels still have hundreds of alt coin nodes (but only 2-3 wxBitcoin). 
07:02 < wumpus> yes :)
07:02 < sipa> many earlier ones forked off namecoin, was was based on 0.3.24 afaik
07:02 < tulip> up until recently there was a 0.3 and a 0.4 node still connected to #bitcoin00 on lfnet, one of the two still had 8333 routed. I'd love to know where that was running to be still up, but obviously well behind the chain this number of years on.
07:03 < wumpus> it's a lemons market, flooded with even more lemons every day, quite interesting from a psychology point of view not so much from a technological :)
07:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:08 < tulip> wumpus: given there's >200 name coin clients on lfnet I assume they never rebased past 0.5? surprised it even functions, they must be missing some serious patches by this point. 
07:12 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
07:13 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
07:14 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
07:15 < wumpus> namecoin did fairly recently rebase on top of newer bitcoin core (not sure what version). But yes most coins do not, it's not like they're a big target for attacks, nor actively maintained. The only way we notice is that sometimes people file bugs/build system issues against bitcoincore that have been fixed years ago, not realizing we've moved on since
07:17 < wumpus> I'm going to try to get this gcbpay person banned from our github, this can no longer be accidental: https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20author%3Agcbpay%20
07:17 < luke-jr> wumpus: go the organization settings
07:17 < luke-jr> there's a "tab" for banning users
07:25 < sipa> wumpus: he has a bunch of repositories, but none contain code, and all issues are self created and look like nonsense as well
07:25 < sipa> it may be just someone who has no clue
07:25 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
07:28 < sipa> but if they're a nuisance and not responsive to comments, yes ban
07:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
07:31 < wumpus> Blocking a user prevents the following on all your repositories: opening or commenting on issues or pull requests, starring, forking, or watching,  adding or editing wiki pages
07:32 < wumpus> they can still download the source, or check it out
07:32 < wumpus> which is great
07:32 < wumpus> I don't expect any useful contributions from them, but they won't lose access completely, so this is the right thing to do
07:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:40 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
07:40 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
07:41 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Remote host closed the connection]     
07:42 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
07:42 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
07:42 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
07:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
07:44 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
07:46 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
07:47 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
07:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
07:57 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
07:57 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
07:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
08:00 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Remote host closed the connection]     
08:09 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
08:09 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
08:14 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
08:15 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
08:15 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
08:15 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
08:15 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
08:16 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
08:26 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
08:40 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
08:40 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
08:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
09:21 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
09:33 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
09:38 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
09:39 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 244 seconds]     
09:45 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
09:47 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
09:47 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
10:00 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
10:06 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Quit: MarcoFalke]     
10:06 -!- MarcoFalke [~marco@host125-2.natpool.mwn.de] has joined #bitcoin-core-dev     
10:06 < arubi> something weird on regtest (did not try testnet), I have two nodes addnode'd to eachother (A and B).  A first mines 750 blocks, sends the sum in one output to B, and mines block 751.  then B creates a 1 input to 607 p2wsh(15-of-15 multisig) outputs (to itself) tx and relays it to A which then mines a block.  B now has 607 15-of-15 p2wsh utxos, it combines them all a 607 p2wsh(15-of-15) -> 1 p2wpkh output tx, and relays to A which now has it 
10:06 < arubi> in mempool too.  now, I can not get either A or B to mine this tx, no matter if hours pass or if I mine a thousand blocks at a time.  it just stays in both mempools.
10:06 < arubi> the same process with a 606 15-of-15 outputs works fine.  still trying other types of scripts.  I couldn't get this to happen with p2pkh or p2sh(15-of-15).  it either aborts because the tx is too large, or too many sigops.
10:07 < arubi> 606 and below*
10:08 < achow101> arubi: is it related to https://github.com/bitcoin/bitcoin/pull/8499#issuecomment-252420342
10:08 < achow101> the new policy limits for p2wsh?
10:09 < arubi> is 15 of 15 multisig affected?  looking
10:12 < sipa> how large is the 607 p2wsh output?
10:12 < arubi> well the script is 513 bytes
10:13 < arubi> signatures + pushes.. 1110 bytes?  I think
10:13 < arubi> can check, moment
10:14 < sipa> eh, i mean the size and weight of the transaction that does not get mined
10:14 < arubi> oh heh, sec.
10:15 < arubi> size": 999515, vsize": 268602,
10:16 < jl2012> vsize over 100000 is nonstandard?
10:16 < arubi> hm, so it's relayed around because regtest?  then not mined because it's too exotic?
10:17 < jl2012> not tested. but if it is accepted to mempool, it should also be mined?
10:17 < sipa> yes, being relayd/accepted but not mined sounds like a bug
10:18 < jl2012> arubi: are you sure your blocks are synced between the 2 nodes?
10:18 < arubi> yep     
10:18 < jl2012> have you tried to do everything with only 1 node?
10:19 < arubi> I can try, though neither will mine it
10:19 < arubi> (trying)
10:19 < jl2012> are you doing it by hand or automated?
10:20 < jl2012> if automated, would you please share the script?
10:20 < arubi> a lot is automated, the script is a monstrosity
10:20 < arubi> I'm rewriting it, making it useful for more complex stuff.  mast in mind
10:21 < arubi> maybe it's time..  I'll get a gitlab account tomorrow and put it there
10:22 < jl2012> size: 999515 is for 606 or 607 inputs?
10:23 < arubi> 607     
10:23 < jl2012> i think there is a setting about the block size/weight, forgot the name
10:23 < jl2012> maybe you hit the limit
10:23 < arubi> maxblocksize=1m , maxblockweight=4m with my nodes
10:23 < jl2012> try with only maxblockweight=4m ?
10:23 < arubi> unless weight can go higher, I didn't assume it could
10:24 < arubi> hm.  alright
10:24 < sipa> do you literally set '1m' as value?
10:24 < arubi> oh no no
10:24 < jl2012> i think the problem is maxblocksize=1m
10:24 < sipa> ok, just making sure
10:24 < sipa> yes, maxblocksize=1000000 may be too much
10:24 < arubi> yea no worries.  so just not set it?  
10:24 < sipa> i think we always stay 1000 bytes below the limit
10:24 < jl2012> too small, you mean?
10:25 < sipa> you can set both weight and size to 4000000
10:25 < arubi> re-running with 1 node now, waiting for it to finish.  sipa, oh really?  I really didn't think that's the case
10:26 < sipa> maxblocksize is about the total serialized size, including witness
10:27 < arubi> and weight?  seems like the default value for maxsize is 750000, so maybe that's why I assumed
10:28 < arubi> and default weight is 3m so really seemed like the x4 factor at the time, now I remember
10:28 < sipa> weight is (total_size + 3*size_without_witness)
10:30 < arubi> I see, thanks.  jl2012, single node same behavior.  trying w/ setting maxsize to 4m as well
10:31 < jl2012> quite sure it's because of the max size
10:31 < jl2012> i tried before
10:32 < arubi> you mean without setting it at all, or setting it to 4m?
10:32 < sipa> if you only specify maxblockweight, the maxblocksize is implicitly 4M
10:32 < jl2012> i think i just set max weight
10:32 < GitHub114> [bitcoin] theuni opened pull request #9000: miner debugging: faux-mining (master...faux-mining) https://github.com/bitcoin/bitcoin/pull/9000
10:33 < jl2012> #9000
10:33 < arubi> ah, so is it correct to say maxblockweight supersedes maxblocksize?  congrats! :)
10:34 < arubi> bitcoin is officially over 9000
10:34 < sipa> not _over_ 9000.
10:34 < jl2012> arubi: if you set both, i guess it always take the effective lower one
10:35 < sipa> jl2012: if you set both, it respects both
10:35 < jl2012> make sense
10:36 < arubi> sipa, programmers of all people don't start counting at 1 :P
10:37 < sipa> arubi: ok, so we're at 8999 even.
10:39 < arubi> sipa, thanks :(
10:54 < arubi> \o/ jl2012 , sipa , thank you!  setting only weight=4m cleared a 607 inputs tx.  I'll play around with both size and weight, got a better idea what they mean now
10:54 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds]     
10:55 -!- murch [~murch@p4FE38A82.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
11:00 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:03 < luke-jr> we are well over 9000 byte blocks, and even 9000 MB blockchain
11:03  * luke-jr ducks
11:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:14 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
11:18 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
11:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]     
11:20 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
11:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
11:36 -!- MarcoFalke [~marco@host125-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
11:38 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
11:48 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
11:50 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
11:53 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
11:59 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 256 seconds]     
12:04 -!- MarcoFalke [~marco@host125-2.natpool.mwn.de] has joined #bitcoin-core-dev     
12:04 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
12:11 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
12:13 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
12:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
12:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
12:40 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
12:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
12:46 -!- whphhg [whphhg@gateway/vpn/mullvad/x-esubhllmpubqjlkk] has quit [Quit: Leaving]     
12:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
12:48 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
12:56 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev     
12:56 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Changing host]     
12:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:05 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 250 seconds]     
13:09 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
13:09 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
13:16 -!- MarcoFalke [~marco@host125-2.natpool.mwn.de] has left #bitcoin-core-dev []     
13:16 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 256 seconds]     
13:17 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
13:18 -!- grindeltoshi is now known as andytoshi     
13:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
13:24 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
13:24 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
13:29 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
13:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
13:49 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Quit: AtashiCon]     
13:50 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
13:52 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
14:17 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
14:42 < GitHub52> [bitcoin] TheBlueMatt closed pull request #7903: Fix help text around importaddress and rename it to importscript (master...16-04-importaddress-helptext) https://github.com/bitcoin/bitcoin/pull/7903
15:24 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
15:29 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
15:38 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
15:50 -!- Cheeseo [~x@c-174-59-204-158.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
15:50 -!- Cheeseo [~x@c-174-59-204-158.hsd1.pa.comcast.net] has quit [Changing host]     
15:50 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
15:56 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b541:5335:1ffb:2cf0] has quit [Ping timeout: 260 seconds]     
15:58 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 256 seconds]     
16:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
16:17 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
16:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
16:35 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:40 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
16:43 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:46 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Remote host closed the connection]     
16:46 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
16:46 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
16:46 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:51 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]     
16:52 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 260 seconds]     
17:36 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
17:38 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Client Quit]     
17:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Write error: Broken pipe]     
17:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev     
17:42 -!- jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #bitcoin-core-dev     
17:42 -!- roasbeef_ [~root@104.131.26.124] has joined #bitcoin-core-dev     
17:42 -!- andytosh1 [~apoelstra@wpsoftware.net] has joined #bitcoin-core-dev     
17:43 -!- nickler_ [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
17:43 -!- roasbeef [~root@104.131.26.124] has quit [Write error: Broken pipe]     
17:43 -!- jouke_ [~jouke@a83-163-42-163.adsl.xs4all.nl] has quit [Remote host closed the connection]     
17:43 -!- nickler [~nickler@185.12.46.130] has quit [Remote host closed the connection]     
17:43 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Remote host closed the connection]     
17:43 -!- helo [~helo@unaffiliated/helo] has quit [Remote host closed the connection]     
17:44 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
17:44 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
17:47 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
17:49 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
17:49 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev     
17:50 -!- jl2012_ [uid133844@gateway/web/irccloud.com/x-ipmlfobbgnauutig] has joined #bitcoin-core-dev     
17:51 -!- Giszmo1 [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
17:53 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-xtxvnmzntbrnyazt] has quit [Ping timeout: 265 seconds]     
17:53 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 265 seconds]     
17:53 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 265 seconds]     
17:53 -!- e4xit_ is now known as e4xit     
17:53 -!- jl2012_ is now known as jl2012     
17:55 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]     
17:57 -!- ill [~ill@172.56.23.70] has joined #bitcoin-core-dev     
18:04 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Ping timeout: 260 seconds]     
18:07 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
18:11 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Killed (Sigyn (Spam is off topic on freenode.))]     
18:19 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev     
18:24 < GitHub14> [bitcoin] gmaxwell opened pull request #9002: Make connect=0 disable automatic outbound connections. (master...connect0) https://github.com/bitcoin/bitcoin/pull/9002
18:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cgamizkzqzjurxpu] has quit [Quit: Connection closed for inactivity]     
--- Log closed Sun Oct 23 18:33:00 2016
--- Log opened Sun Oct 23 18:33:38 2016
18:33 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
18:33 -!- Irssi: #bitcoin-core-dev: Total of 145 nicks [0 ops, 0 halfops, 0 voices, 145 normal]     
18:34 -!- thestringpuller [~stevie@ec2-52-3-128-9.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
18:34 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
18:34 -!- thestringpuller is now known as Guest16408     
18:34 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
18:34 -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has joined #bitcoin-core-dev     
18:36 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev     
18:39 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev     
18:40 -!- ill [~ill@172.56.23.70] has quit [Ping timeout: 276 seconds]     
18:43 -!- ill [~ill@172.56.23.70] has joined #bitcoin-core-dev     
18:44 -!- Irssi: Join to #bitcoin-core-dev was synced in 661 secs
18:45 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
18:47 -!- ill [~ill@172.56.23.70] has quit [Ping timeout: 244 seconds]     
18:54 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
18:54 -!- ill [~ill@184.209.159.65] has joined #bitcoin-core-dev     
18:55 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
19:01 -!- ill [~ill@184.209.159.65] has quit [Ping timeout: 260 seconds]     
19:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:08 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:23 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev     
19:29 < midnightmagic> :-/     
20:05 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds]     
20:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:19 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
20:23 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
20:50 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
20:51 -!- ill [~ill@172.56.22.144] has joined #bitcoin-core-dev     
20:58 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:59 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:11 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
21:11 < luke-jr> does it not do that again? :x
21:13 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit]     
21:15 < sipa> do what?
21:18 < luke-jr> sipa: disable outbound connections.
21:18 < luke-jr> it used to do so at least, and seemed to work when I recently did it for testing
21:27 -!- ill [~ill@172.56.22.144] has quit [Ping timeout: 250 seconds]     
21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:32 < gmaxwell> My belief is that it used to work, but what it does right now is just loop continually trying to connect to '0' and on my system this manages to connect to myself.
21:32 < gmaxwell> this, indeed, does prevent it from connecting to other parties...
21:33 < luke-jr> O.o     
21:33 < gmaxwell> but in a fairly log spammy way (esp with debugging turned up)
21:34 < sipa> any theory why '0' results in a connect to self? :s
21:34 < sipa> that shouldn't even resolve to a valid ip
21:34 < luke-jr> sipa: most integers are a valid IP
21:35 < gmaxwell> I didn't bother checking my belief that it used to behave better.
21:35 < aj> sipa: telnet 0 22 -> 0.0.0.0:22 -> ssh to localhost
21:35 < gmaxwell> $ telnet 0 8333
21:35 < gmaxwell> Trying 0.0.0.0...                                                                                                                           
21:35 < gmaxwell> Connected to 0.                                                                                                                             
21:35 < gmaxwell> Escape character is '^]'.                                                                                                                   
21:35 < gmaxwell> ^]                                                                                                                                          
21:35 < gmaxwell> telnet> close
21:35 < sipa> well i knew it'd resolve to 0.0.0.0
21:35 < sipa> i'm surprised 0.0.0.0 is a valid thing to connect to
21:35 < gmaxwell> This surprised me too. I figured it was some quirk of my system... but in any case, better to just not have the useless thread.
21:36 < luke-jr> ping 2130706433
21:36 < luke-jr> (this is 0x7f000001)
21:36 < aj> 0.0.0.0 means "all ipv4 addresses on the local machine", so seems kinda plausible
21:36 < sipa> luke-jr: some browsers even allow much larger integers (up to 2^1000-ish), resolving them modulo 2^32
21:37 < luke-jr> >_<     
21:38 < sipa> as to why anyone ever tbought to support that: i believe a naive decimal-to-uint32 converter will actually behave that way
21:38 < gmaxwell> we it would stop at 2^1000 isn't clear. :P
21:39 < luke-jr> I should access my KVMoIP by decimal. I don't have DNS on it anyway. :p
21:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
21:44 < sipa> gmaxwell: ish
21:45 < sipa> it's probably just an input buffer size limit
21:51 < midnightmagic> 0 is the inaddr_any wildcard/alias address, and in some systems (the ones I'm familiar with) it means "the first interface that was ifconfig'd at boot" -- in other words, it's *not* guaranteed to be 127.0.0.1.
21:52 < luke-jr> I would have expected 0.0.0.0 to be a blackhole :/
21:52 < luke-jr> midnightmagic: what if you ifconfig the first interface with 0.0.0.0? <.<
21:55 < midnightmagic> luke-jr: i dunno, can you ifconfig an interface to 0.0.0.0?
21:55 < luke-jr> probably not
21:55 < luke-jr> I think that means unconfigure
22:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
22:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:41 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
22:46 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Quit: Nettalk6 - www.ntalk.de]     
23:15 < midnightmagic> or on some machines you get:
23:15 < midnightmagic> :dom13:06:14:57 ~# telnet 0 22
23:15 < midnightmagic> 0: No address associated with hostname
23:25 < wumpus> IP parsing is not guaranteed to parse '0' as '0.0.0.0', in this csae it just thinks it's a hostname
23:27 < wumpus> any other 0.x.y.z IP seems to give "invalid argument" on linux
23:30 < wumpus> anyhow the problem here is that bitcoin core uses the OS's IP parsing, this has resulted in confusion before
23:30 < gmaxwell> I don't ~think~ special casing "0" is too ugly, but I am open to that idea. :)
23:31 < wumpus> but it's not just 0, some IP parsers will happily parse any int32 into a IPv4
23:32 < wumpus> +have other OS/libc specific quirks
23:33 < gmaxwell> right, this discussion is inspired by my patch that special cases "0" to disable connect. Which itself was inspired by me getting irritated with my logs being flooded with connects to self after setting connect=0 to disable automatic outbound connections.
23:34 < wumpus> yes, the reason to special-case 0 would be for -noconnect
23:34 < wumpus> which is fine with me
23:34 < gmaxwell> Yes, right now, my PR doesn't handle -noconnect (I believe), good point on that.
23:34 < wumpus> noconnect should automatically get converted to connect=0
23:35 < wumpus> you shoudln't have to do anything special for that
23:35 < wumpus> -noX bcomes X=1 in the low-level arg handling
23:35 < wumpus> ehhh X=0
23:36 < gmaxwell> Will test.
23:36 < wumpus> in any case special-casing 0 makes sense because the argument handling special-cases 0 for 'no'
23:38 < wumpus> we do that in plenty of places in init.cpp, and adding one more is not a problem at all. If someone really wants to connect to 0.0.0.0, let them specify 0.0.0.0
23:39 < wumpus> -noconnect should ideally mean "no outgoing connections"
23:40 < wumpus> ooh rowhammer on ARM, we're nowhere safe are we
23:40 < gmaxwell> positive news, now that ECC memory will be needed to prevent users from controlling their own devices, we might get ecc memory in more devices.
23:41 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
23:41 < gmaxwell> so I thought about "should it imply nodnsseed" and "what if you are goofy and combine connect=0 and addnode? should it still addnode?".
23:42 < gmaxwell> the former seems like a harmless and reasonable thing to do, the latter... I dunno if it should touch the addnode behavior, I think probably not.
23:42 < wumpus> I guess it should mean "no automatic connections"
23:42 < gmaxwell> Yes. No automatic connections makes sense.
23:42 < wumpus> if you really want to force a connection using addnode, I don't see why it should stop it
23:42 < gmaxwell> Okay, I'll add the imply on dnsseed.
23:43 < wumpus> yes stopping dnsseed is an optimiziation that makes sense
23:43 < wumpus> why dnsseed if you're going to ignore the result
23:43 < gmaxwell> hardly likely to cause a negative surprise... you won't know if you got seeded or not, with no automatic connections. :)
23:43 < gmaxwell> well it's not a total no-op as it does update your peers.dat. If a tree falls in the forrest...
23:44 < wumpus> well if you really insist on that you can still override it to true right? I suppose you're using 'soft' parameter interaction?
23:44 < gmaxwell> Yep.
23:46 < gmaxwell> oh actually any seting of connect already softsets dnsseed to off, even -noconnect.  (also listen too, which is potentially confusing, but historic, and conservative)
23:46 < wumpus> re: android I'm happy that these kind of exploits allow full control of the device by their owner, on the other hand, OSes such as android *invite* people to install all kinds of bullshit apps because of their claimed secure sandbox, and all of those can take full control of the device too, that worries me
23:47 < wumpus> ah yes that's true
23:50 < wumpus> although the DRM-on-IoT thing is perverse, if someone hacks your phone (or toaster) through a rogue app, they will have root, but you can't get control yourself to chase them off again
23:51 < wumpus> "how to hand the world to blackhats with one easy trick"
23:53 < midnightmagic> wumpus: you're talking about rowhammer?
23:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
23:54 < gmaxwell> part of the reson we have this problem is due to technical illiteracy-- to Joe Blow, he doesn't know how to control his device in a meaningful way no matter how much root you give him;  so to actually take control from him (even while still accidentally giving it to hackers) doesn't seem like that big of a loss.
23:54 < wumpus> yes rowhammer, though it similarly applies to dirty cow, or still-undisclosed-exploit-of-the-day
23:57 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:59 < wumpus> technical illiteracy is certainly part of the problem - another one would be lack of standards in regard to gaining control of a device by someone with technical literacy
23:59 < midnightmagic> "It's okay I'm just going to root your phone.." "Uh, okay Jim. Would you like another beer too?"
23:59 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]