--- 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 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]