--- Day changed Fri Nov 18 2016
00:00 < btcdrak> Launda: thanks, will update
00:14 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds]     
00:19 < Lauda> Good btcdrauk
00:20 < cfields> BlueMatt: maybe we should discuss approaches? Seems we might have something different in mind for encryption
00:20 < cfields> and sipa ^^
00:24 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
00:24 < BlueMatt> cfields: probably, but bedtime for me rn
00:26 < cfields> BlueMatt: ok, np. I just re-read my comments and realized they could've sounded a bit hostile. Not meant to be, for sure. I went back and forth on different approaches, very open to something other than what I settled on.
00:28 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev     
00:43 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
01:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:27 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
01:41 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:95da:760d:df4e:e108] has joined #bitcoin-core-dev     
01:43 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 245 seconds]     
01:47 -!- ubuntu330 [2872dc88@gateway/web/freenode/ip.40.114.220.136] has joined #bitcoin-core-dev     
01:50 -!- ubuntu330 [2872dc88@gateway/web/freenode/ip.40.114.220.136] has quit [Client Quit]     
01:55 -!- gns3 [~Kitteh@159.203.134.113] has joined #bitcoin-core-dev     
01:55 -!- gns3 [~Kitteh@159.203.134.113] has quit [Remote host closed the connection]     
01:57 -!- gielbier [~michiel@unaffiliated/gielbier] has joined #bitcoin-core-dev     
02:13 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9185: [Qt] fix coincontrol sort issue (master...2016/11/fix_cc_sort) https://github.com/bitcoin/bitcoin/pull/9185
02:15 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
02:20 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
02:21 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
02:23 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]     
02:25 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]     
02:59 -!- laurentmt [~Thunderbi@80.215.234.133] has joined #bitcoin-core-dev     
02:59 -!- laurentmt [~Thunderbi@80.215.234.133] has quit [Client Quit]     
03:16 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 246 seconds]     
03:17 -!- DigiByteDev [~JT2@209.160.122.172] has joined #bitcoin-core-dev     
03:18 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:95da:760d:df4e:e108] has quit []     
04:07 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
04:13 < bitcoin-git> [bitcoin] laanwj opened pull request #9186: test: Fix use-after-free in scheduler tests (master...2016_11_scheduler_fix) https://github.com/bitcoin/bitcoin/pull/9186
04:46 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
05:04 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
05:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
05:21 -!- chris2000 [~chris2000@93.203.83.24] has joined #bitcoin-core-dev     
05:31 -!- DigiByteDev [~JT2@209.160.122.172] has quit [Quit: DigiByteDev]     
05:35 -!- laurentmt [~Thunderbi@80.215.234.133] has joined #bitcoin-core-dev     
05:35 -!- laurentmt [~Thunderbi@80.215.234.133] has quit [Client Quit]     
06:00 -!- laurentmt [~Thunderbi@80.215.234.133] has joined #bitcoin-core-dev     
06:02 -!- chris2000 [~chris2000@93.203.83.24] has quit []     
06:04 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
06:13 -!- laurentmt1 [~Thunderbi@80.215.234.133] has joined #bitcoin-core-dev     
06:14 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
06:15 -!- laurentmt [~Thunderbi@80.215.234.133] has quit [Ping timeout: 260 seconds]     
06:15 -!- laurentmt1 is now known as laurentmt     
06:25 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]     
06:27 -!- laurentmt [~Thunderbi@80.215.234.133] has quit [Quit: laurentmt]     
06:28 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev     
06:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:49 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
07:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
07:07 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
07:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
07:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
07:13 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
07:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 250 seconds]     
07:20 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:26 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
07:38 < btcdrak> ping wumpus
08:06 < jl2012> blocks mined by a real 0.13.1 comes with a witness commitment: https://www.blocktrail.com/BTC/tx/86eb9975fae041df063f7ac0a94847883243704a7d20fb7726ba14239895a129
08:07 -!- abpa [~abpa@mobile-166-137-179-159.mycingular.net] has joined #bitcoin-core-dev     
08:07 < jl2012> which is not found in slush's segwit blocks: https://www.blocktrail.com/BTC/tx/24dfb97c80d41e9dd153581b907c9270f8acd8509480e3bcde22684104d771c6
08:07 -!- JWU42 [~JW@unaffiliated/subpar] has joined #bitcoin-core-dev     
08:08 < sipa> jl2012: 0.13.1 only creates a commitment is there is a witness txn in the block, i believe
08:08 < jl2012> but there are already 2 blocks, from different miners, come with witness commitment
08:09 < sipa> it depends on their own stack, and arguably before activation there should certaibly not be a commitment
08:09 < jl2012> this one from an unknown miner: https://www.blocktrail.com/BTC/tx/c02b8e9c0321656a6ca429c3f38bed729b17347304aae9ce2b6454396621b1c1
08:10 < jl2012> not from BTCC: https://www.blocktrail.com/BTC/tx/5030f76f6411733458fa60fb706a9b2e0e7a3affd535004339482c42ec0a83d6
08:14 -!- abpa [~abpa@mobile-166-137-179-159.mycingular.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:18 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-dev     
08:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
08:23 -!- abpa [~abpa@mobile-166-137-179-159.mycingular.net] has joined #bitcoin-core-dev     
08:26 -!- JWU42 [~JW@unaffiliated/subpar] has left #bitcoin-core-dev []     
08:27 -!- abpa [~abpa@mobile-166-137-179-159.mycingular.net] has quit [Client Quit]     
08:44 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:45 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Client Quit]     
08:46 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:10 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection]     
09:13 < cfields> sipa: did i misunderstand your intention here? https://botbot.me/freenode/bitcoin-core-dev/2016-08-11/?msg=71172676&page=4
09:15 < cfields> jl2012: those are likely ckpool, which will insert whenever it sees the rule
09:17 < sipa> cfields: you did not misunderstand it.
09:17 < sipa> but it's not what bitcoin core does
09:18 < sipa> (which is irrelevant, as bitcoin core is not used for mining)
09:18 < cfields> sipa: it inserts whenever it sees the rule. If it sees the rule and default_witness_commitment, it compares them to make sure that the computed value is sane
09:19 < sipa> what is 'it'?
09:19 < sipa> ah, ckpool
09:20 < cfields> and cgminer, and the others I've done
09:21 < cfields> For the simple stratum server, it only inserts default_witness_commitment if present
09:25 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: brb]     
09:27 < BlueMatt> cfields: huh? I didnt read any comments you made as hostile? I think you needed sleep :p
09:27 < cfields> BlueMatt: ok good
09:31 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
09:33 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev     
09:53 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: brb]     
09:55 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
10:01 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
10:02 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
10:06 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
10:12 < sipa> cfields: i wonder if we could have a model where CNetMessage or whatever it is, is a virtual class that has an interface to produce a message on the fly
10:13 < sipa> cfields: which could be used to delay loading a block from disk until it's actually going to be sent out through the network, for example
10:13 < sipa> which could move the serialization of the checksum to the network thread as well
10:14 < sipa> ah, but the checksum is in front, so it can only be donr after fully serializing
10:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:17 < cfields> sipa: the current approach just leaves padding upfront, so i don't think that breaks anything?
10:20 < cfields> i'm not sure what you mean by "on-the-fly", though. You mean install a callback that triggers when a condition is met, then requests data to send out?
10:22 < cfields> sipa: ah, i see. it just inserts a place-holder, and when that comes up for sending, it requests the actual data.
10:26 < gmaxwell> cfields: I wish we always inserted the commitment when segwit rule is enabled. Without it, we may find the commitments fail after activation... not the end of the world, but more potential for delays.
10:27 < cfields> gmaxwell: agreed
10:29 -!- jannes [~jannes@178.132.211.90] has quit [Remote host closed the connection]     
10:30 < cfields> it'd be helpful to setup a patched bitcoind that validates the commitments as though they were required, in the off-chance that we might notice a busted one before activation
10:30 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:30 < cfields> i suppose it wouldn't actually be checking that much, but better than nothing
10:42 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
10:45 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
10:52 < gmaxwell> Well we're due for a 0.13.2, we could put the commitment in by default when the rule is enabled.
10:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
10:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
11:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
11:17 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9188: Make orphan parent fetching ask for witnesses. (master...witness_the_orphans) https://github.com/bitcoin/bitcoin/pull/9188
11:18 < sipa> cfields: maybe in bip151 the checksum should be at the end
11:18 < sipa> so it can be computee on the fly during sending
11:19 < cfields> sipa: ack
11:24 < luke-jr> gmaxwell: the commitment is inserted by the GBT client, not bitcoind
11:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:31 < gmaxwell> luke-jr: we make a proposed commitment that the client can use in lieu of implementing consensus rules when they don't need to (and thus won't put in the attention to do it right)
11:33 < luke-jr> oh, I guess I didn't realise that wasn't unconditional
11:33 < gmaxwell> for some reason it seems to be undocumented by any BIP. :( :(
11:34 < gmaxwell> But nom, it only shows up when there are segwit txn right now. AFAIK.
11:34 < sipa> right, default_witness_commitment is only added when there is an witness tx in the block
11:34 < sipa> we can change that
11:34 < luke-jr> yes, it's not in any BIP because it contradicts decentralised mining; it's a bitcoind-specific extension, not a GBT standard
11:36 < sipa> it'll be a bitcoind-specific extension that the whole ecosystem depends on, because doing it in the client is pointless
11:36 < gmaxwell> luke-jr: GBT as actually used contradicts decenteralized mining. We should fix decenteralized mining, not make a superficial stand that has a side effect of making the software more error prone.
11:37 < gmaxwell> Because if you ask someone who _really_ doesn't care about the extra flexiblity there to handle computing the commitments themselves, they'll _hate it_ and be more likely to not implement it at all or to do so and get it wrong.
11:37 < gmaxwell> Since they're getting the cost, but no one benefits because the end result doesn't improve mining decenteralization at all.
11:38 < luke-jr> sipa: nobody uses it AFAIK
11:39 < sipa> luke-jr: everyone uses it
11:39 < sipa> cfields: right?
11:39 < luke-jr> gmaxwell: it's not much more work than doing the txid merkle tree?
11:39 < cfields> sipa: yea, it's upstreamed in several pools/miners now
11:40 < luke-jr> cfields: ⁈
11:40 < sipa> luke-jr: why redo the work when bitcoind already does it for you
11:41 < cfields> luke-jr: the pools have enough things they could be breaking as-is. I don't see why we should pile more on
11:41 < gmaxwell> luke-jr: It's similar to the merkle tree, but it is completely pointless when the software doesn't support changing the transaction set... and also not fast.
11:42 < luke-jr> so why not just pass merkle branches in GBT too, if we're just going to throw the towel?
11:43 < luke-jr> then we could have a BIP standard for centralised GBT that's complete
11:43 < sipa> luke-jr: i think that is what we should do
11:44 < sipa> not because i'm in favor of more centralization of mining, but because none of this matters at all
11:44 < gmaxwell> It isn't necessarily centeralized though. e.g. phantomcircuit's unreleased protocol work does that and yet it's plausably much better for decenteralization than the deployment of GBT ever was in practice.
11:44 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev     
11:44 < morcos> sipa: agreed..  there should at the very least be an option of doing it the easy simple way where bitcoind does all the hard work for you.
11:45 < sipa> nothing is in a better position to do block composition than bitcoind... it has all the fee information, consensus rules, mempool data, ...
11:45 < luke-jr> well, fee info is passed over GBT; but sure
11:45 < sipa> if we want people to do their own composition, we should enable them to run bitcoind
11:45 < sipa> not hope they'll do the same thing in a layer on top
11:46 < gmaxwell> (phantomcircuits' work let you combine consensus from one source (e.g. your own bitcoind) with coinbase requests from another...)
11:46 < morcos> well to be honest, in an ideal world there would be nothing to differentiate transactions other than their fee/weight , so no reason at all to need your own tx selection
11:46 < luke-jr> so should I spend some time writing up a BIP for this? or is it just a low priority "maybe someday" thing?
11:47 < sipa> luke-jr: i think we should first have a functional implementiation
11:47 < luke-jr> morcos: disagree; but that may be all we end up having in practice perhaps
11:47 < gmaxwell> We've had too much BIP writing without any code at all lately. IMO. Actually implementing something grants a lot of insight into the construction.
11:48 < luke-jr> ok, but is there a desire to prioritise this?
11:49 < sipa> luke-jr: in an ideal world, there exists no means for miners to even distinguish any properties of a transaction other than its size and fee... anything else is an avenue for censorship
11:49 < sipa> luke-jr: i think the current situation with mining is pretty bad
11:50 < gmaxwell> There are other serious problems with mining, the total lack of authentication is a looming serious risk to the network.
11:50 < luke-jr> indeed
11:50 < gmaxwell> Which, if exploited, we'd be saying in hindsight we were foolish to not resolve more agressively.
11:50 < sipa> "hope is not a strategy"
11:50 < cfields> luke-jr: i think this arose from the idea of having 0.13.2 always injecting segwit commitments if the rule is active. Hence, default_witness_commitment would always be available and we'd want it documented
11:51 < sipa> i guess we can output default_witness_commitment always whenever the client is segwit-ready?
11:52 < gmaxwell> I think we should.
11:52 < luke-jr> sipa: IMO that's a "just do it" thing; should be simple and uncontroversial
11:52 < luke-jr> looks like maybe 2 lines of changed code
11:53 < gmaxwell> Yes, would need to be release noted as there is some fringe risk of negative interaction with mining pool software.
11:53 < gmaxwell> But otherwise, I think it's a no-brainer.
11:56 < luke-jr> actually, this might not be as simple as I assumed
11:56 < luke-jr> nm     
11:56 < gmaxwell> hah     
11:56 < sipa> luke-jr: i'm on it, it's easy
11:57 < luke-jr> what's the purpose of GetWitnessCommitmentIndex in GenerateCoinbaseCommitment?
11:57 < luke-jr> sipa: ok
11:57 < luke-jr> (that GetWitnessCommitmentIndex still looks pointless though?)
11:58 < cfields> luke-jr: making sure there's not one there already, i think?
11:58 < sipa> yup     
11:58 < luke-jr> cfields: but there never would be, in the one place it's called, no?
11:59 < cfields> luke-jr: miner could've added it in
11:59 < sipa> indeed
12:00 < luke-jr> cfields: it's only called from CreateNewBlock
12:00 < luke-jr> which is before the miner gets it
12:01 < luke-jr> (I had assumed it was being used for the miner's submitted block as well, which would pose a risk to invalidating submissions without a commitment, but that doesn't appear to be the case)
12:03 < cfields> luke-jr: dunno, maybe it was added before the mining side was fleshed out
12:04 < luke-jr> probably
12:05 < sipa> i believe so, yes
12:06 < luke-jr> maybe it should be removed if it's dead code (in master, not 0.13.2)
12:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
12:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:23 < bitcoin-git> [bitcoin] sipa opened pull request #9189: Always add default_witness_commitment with GBT client support (master...alwayscommit) https://github.com/bitcoin/bitcoin/pull/9189
12:24 < sipa> ^ i ran the rpc tests and unit tests, but i haven't tested the behaviour
12:28 < luke-jr> sipa: I don't think you need the additional check in GBT itself
12:28 < luke-jr> if segwit is active, we fail earlier on if the client doesn't support it
12:28 < sipa> luke-jr: yes, but there's no point producing a default_witness_commitment when the client doesn't understand it
12:29 < sipa> i guess it doesn't really matter
12:29 < luke-jr> there shouldn't be a commitment if the network doesn't have segwit active either, right?
12:29 < sipa> the intent here is that there would be, whenever the client and the server support it
12:30 < sipa> as it's a very nice end-to-end consistency check
12:30 < sipa> to see that their entire stack works correctly
12:31 < luke-jr> IMO it would be broken to insert a commitment (regardless of whether it's calculated) in a block without segwit being active on the network
12:31 < sipa> arguably, it's just a weird OP_RETURN output in that case, and not actually a commitment
12:31 < cfields> luke-jr: it's scary to count on all miners working 100% after activation
12:32 < cfields> at least this way we get to see if someone thinks they should be ready but is horribly broken
12:32 < luke-jr> if they add a commitment without "segwit" in "rules", there are already not working.
12:32 < cfields> (since the only way they'd insert is if they're signaling that they're ready)
12:32 < luke-jr> s/there/they/
12:33 < gmaxwell> luke-jr: I disagree strongly. There is nothing wrong with a commitment that has no effect, and this means that the risk of a "hard cut" activation is reduced.
12:33 < gmaxwell> Since if someone is producing broken commitments there is an oppturnity to go nag them to fix them, before the rule is enforced.
12:33 < gmaxwell> I do think that there shouldn't be a commitment unless they have segwit in the rules, however.
12:34 < sipa> gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
12:34 < luke-jr> sipa: even if they DO support BIP 145, they will ignore it..
12:34 < gmaxwell> yes, but you might do something with the commitment but fail to realize that you need to send the rules. I guess it wouldn't be that bad an outcome: you'd just fail to mine segwit txn.
12:34 < luke-jr> because "segwit" won't be in "rules" until it activates
12:34 < sipa> luke-jr: i'd say they are allowed to ignore it
12:35 < gmaxwell> yea, they're allowed to ignore it.
12:35 < sipa> but they don't have to... there is nothing wrong with adding a commitment ahead of time
12:35 < gmaxwell> Though I think it would be a good risk reduction if they didn't.
12:36 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
12:36 < luke-jr> I can't think of any downsides.
12:36 < luke-jr> (to including it prematurely)
12:37 < cfields> i suppose we have enough padding to ensure it doesn't push us over max size?
12:37 < luke-jr> cfields: ?
12:37 < sipa> cfields: if we have enough padding post activation, we certainly have enough before
12:38 < luke-jr> block size padding is 1000 bytes. whether that's enough depends on the client
12:38 < luke-jr> which is why Eloipool will modify the template in some circumstances I guess
12:38 < cfields> sipa: i suppose that was a vague question aimed at both sides of activation
12:38 < cfields> ok     
12:39 -!- meownow_ [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
12:39 < meownow_> anyone seen julian assange?
12:39 < gmaxwell> luke-jr: refresh my memory, can the GBT client request a smaller template (e.g. because it knows its coinbase will be bigger)? 
12:39 < sipa> gmaxwell: not afaik
12:40 < sipa> meownow_: off topic
12:40 < gmaxwell> that should really be added.
12:40 < luke-jr> gmaxwell: no, I don't think so. (either way, bitcoind doesn't support it)
12:40 < luke-jr> probably
12:40 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]     
12:41 < luke-jr> maybe "sizelimit" as a request param, to override -blockmaxsize?
12:41 < luke-jr> (and "weightlimit" the same)
12:41 < sipa> or a parameter to communicate the coinbase size?
12:41 < sipa> so the limit can still be set in bitcoind
12:42 < luke-jr> hmm     
12:42 < gmaxwell> yea, coinbase size seems better.
12:42 < gmaxwell> harder to screw up at least.
12:42 < luke-jr> yes, the client in theory might not know the network max
12:43 < sipa> the client in theory _shouldn't_ need to know the network max 
12:43 < luke-jr> "gentxsize" in the request then?
12:43 < sipa> (though gbt pretty much forces the client to know consensus rule)
12:43 < luke-jr> sipa: GBT provides the client with it, but only after the request
12:43 < sdaftuar> weight, not size
12:43 < luke-jr> sdaftuar: same thing basically in this case
12:43 < sdaftuar> yes, but confusing
12:44 < luke-jr> I'd find it less confusing to provide as size *shrug*
12:45 < gmaxwell> cbmaxweight  "construct a template assuming that the coinbase transaction will have a weight no greater than x"
13:03 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
13:06 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]     
13:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
13:35 -!- shesek [~shesek@bzq-84-110-54-135.cablep.bezeqint.net] has quit [Ping timeout: 260 seconds]     
13:35 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: Lost terminal]     
13:42 < jtimon> BlueMatt: so what's the next PR for the moveonly ?
13:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:49 -!- shesek [~shesek@bzq-84-110-57-133.cablep.bezeqint.net] has joined #bitcoin-core-dev     
13:51 -!- meownow_ [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]     
13:54 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]     
13:54 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
13:54 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
13:54 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
13:55 -!- cryptapus is now known as cryptapus_afk     
14:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
14:17 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 244 seconds]     
14:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
14:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
15:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
15:30 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]     
15:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
15:58 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xsecnlwrykzdqdwh] has quit [Quit: Connection closed for inactivity]     
15:59 < Lightsword> what’s the best way to compile 0.13.1 on debian 7? apparently doesn’t have full c++11 support
16:04 < cfields> clang?
16:08 -!- dermoth_ [~thomas@dsl-66-36-147-38.mtl.aei.ca] has joined #bitcoin-core-dev     
16:09 -!- dermoth [~thomas@43-78.162.dsl.aei.ca] has quit [Disconnected by services]     
16:09 -!- dermoth_ is now known as dermoth     
16:11 < BlueMatt> jtimon: hmm? I havent made it....since its likely to conflict like hell with everything I figure I should probably prep it when everything else is reviewed and in
16:11 < BlueMatt> instead of rebasing constantly
16:12 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Ping timeout: 260 seconds]     
16:12 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
16:13 < Lightsword> cfields, does the default clang on debian 7 support c++11?
16:15 < Lightsword> hmm, would appear debian 7 is default version 3.0 and min is 3.3 for c++11
16:16 -!- abpa [~abpa@mobile-166-137-178-241.mycingular.net] has joined #bitcoin-core-dev     
16:22 -!- abpa [~abpa@mobile-166-137-178-241.mycingular.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:26 < jtimon> BlueMatt: ok
16:27 < BlueMatt> jtimon: it should be +/- the same as the branch I gave you about a month ago
16:27 < BlueMatt> I think the current prs are all still that branch rebased without any major changes
16:28 < jtimon> BlueMatt: yeah was just curious on your plans about it
16:33 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
16:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
16:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
16:53 < sipa> Lightsword: that's annoying... 
16:53 < sipa> Lightsword: you could compile a static binary on a later system
16:54 < Lightsword> sipa, yeah that’s what I recommended
16:58 < cfields> the release binaries should be fine for that unless it needs patching
17:02 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
17:13 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:16 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
17:30 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mjfvdulwkiavzwmt] has quit [Quit: Connection closed for inactivity]     
18:06 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer]     
18:24 -!- nick118 [~nick118@5.134.149.124] has joined #bitcoin-core-dev     
18:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:34 -!- nick118 [~nick118@5.134.149.124] has left #bitcoin-core-dev ["Leaving"]     
18:42 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
18:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:29 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
19:30 < BlueMatt> cfields: hey
19:31 < BlueMatt> cfields/sipa: sorry, been missing all day, happy to chat about CConnman design if y'all're free, or can wait till tomorrow
19:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
20:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
20:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
20:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:29 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
21:06 < phantomcircuit> anybody have an opinion on where fuzzing examples should go? (ie which directory)
21:06 < phantomcircuit> i was thinking contrib
21:07 < luke-jr> phantomcircuit: under qa/?
21:08 < BlueMatt> luke-jr: only if there is infrastructure to automatically run them (travis, or if its too slow, at least some scripts)
21:08 < BlueMatt> but, yes
21:08 < phantomcircuit> luke-jr, yeah that sounds better
21:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:34 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ntifjroyqnztnevx] has joined #bitcoin-core-dev     
21:46 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
21:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:52 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
21:56 < meownow> can anyone summarize when i download the bitcoin source code on the github, what is the client i am downloading able to actually do?
21:58 < achow101> meownow: it fully verifies all blocks and transactions, relays said blocks and transactions, can manage a wallet, does signing operations with ecdsa keys, produces block template for miners
22:02 < meownow> ok thanks. so with it i can donate my cpu to acting as a node to store and verify blocks and transactions, which other nodes will very their own blocks against? as well as the other things you mentioned i can do. 
22:07 < achow101> no, nothing is verified against someone else. your node has a set of hard coded rules and it will verify blocks and transactions according to those rules. every other node will do the same, verify the block against the built-in rules
22:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:41 -!- abpa [~abpa@2602:306:b837:dbf0:b1f2:332c:c011:3645] has joined #bitcoin-core-dev     
22:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uhilryotocxftigv] has joined #bitcoin-core-dev     
22:44 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]     
22:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:00 -!- dermoth [~thomas@dsl-66-36-147-38.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
23:00 -!- dermoth [~thomas@dsl-66-36-147-38.mtl.aei.ca] has joined #bitcoin-core-dev     
23:17 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]