--- Day changed Fri Aug 05 2016
00:05 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 276 seconds]
00:06 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
00:13 -!- Pasha is now known as Cory
00:14 -!- laurentmt [~Thunderbi@80.215.138.94] has joined #bitcoin-core-dev
00:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:18 -!- LaudaM [~Lauda@2a06:8ec0:3::1:b224] has quit [Quit: I'm out!]
00:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:38 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer]
00:43 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:50 -!- Giszmo [~leo@ppp-188-174-92-26.dynamic.mnet-online.de] has joined #bitcoin-core-dev
00:53 -!- Giszmo [~leo@ppp-188-174-92-26.dynamic.mnet-online.de] has quit [Client Quit]
00:59 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 260 seconds]
01:01 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
01:23 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
01:39 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
01:40 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
01:40 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
01:41 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
02:02 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
02:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-soktggvfspsfnfal] has joined #bitcoin-core-dev
02:30 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
02:37 -!- shesek [~shesek@bzq-84-110-208-155.cablep.bezeqint.net] has joined #bitcoin-core-dev
03:40 < jonasschnelli> I think "memusage.h" should include "prevector.h"
03:46 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
03:50 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds]
03:55 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
03:56 < GitHub83> [bitcoin] jonasschnelli closed pull request #7865: [RPC] Add bumpfee command. (master...2016/04/rbf_combined) https://github.com/bitcoin/bitcoin/pull/7865
04:03 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
04:07 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
04:23 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has joined #bitcoin-core-dev
04:23 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has quit [Changing host]
04:23 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-soktggvfspsfnfal] has quit [Quit: Connection closed for inactivity]
04:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
04:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
04:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
05:03 -!- Lauda [~quassel@2a06:8ec0:3::1:b224] has quit [Changing host]
05:03 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev
05:11 -!- cryptapus_afk is now known as cryptapus
05:22 < wumpus> jonasschnelli: you'd say so, as the type is used; but does any compiler complain about this in practice? it's in a template, so it could be that you only need it at instantiation time
05:22 < wumpus> I'm a little rusty on the exact rules there though
05:23 < jonasschnelli> wumpus: I just added some stats stuff and included memusage.h, compiler was then complaining about the missing type prevector...
05:24 < jonasschnelli> memusage.h is directly using (in a template but directly) prevector
05:24 < jonasschnelli> But anyways... far away from important. :)
05:24 < wumpus> does the data structure that you're trying to measure include a prevector
05:24 < wumpus> ?
05:25 < jonasschnelli> no. I just want to measure a vector of structs... but mempool.h refers to prevector
05:25 < jonasschnelli> I guess all other places where mempool.h is included, prevector was previously already included
05:26 < wumpus> there is no mempool.h? I guess you mean memusage.h?
05:26 < jonasschnelli> argm. memusage.h
05:26 < wumpus> indeed, if including memusage.h forces you to include prevector.h then it should be included there
05:26 < jonasschnelli> static inline size_t DynamicUsage(const prevector<N, X, S, D>& v
05:27 < jonasschnelli> It's a nitpick and I'll try to cover that fix in one of my stats releated commits.
05:28 < wumpus> sometimes the c/c++ dependency management is a bit unfortunate, very easy to accidentally have something creep into your scope so you forget that direct dependencies exist but have no include, then it turns up later when the header happens to be used independently
05:28 < wumpus> right
05:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:29 < wumpus> unlike missing prototypes in C, at least this cannot lead to ugly type-unsafety bugs, you either have to include it somewhere or it just won't compile :)
06:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
06:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:33 -!- laurentmt1 [~Thunderbi@80.215.178.35] has joined #bitcoin-core-dev
06:35 -!- laurentmt [~Thunderbi@80.215.138.94] has quit [Ping timeout: 240 seconds]
06:35 -!- laurentmt1 is now known as laurentmt
06:47 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:48 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
06:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
06:51 -!- arubi__ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
06:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:19 -!- arubi__ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
07:22 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
07:23 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
07:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
07:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:00 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev
08:03 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kokrjmtruxobhryl] has joined #bitcoin-core-dev
08:06 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
08:21 -!- zooko [~user@73.95.139.67] has joined #bitcoin-core-dev
08:29 -!- mmortal03 [~mmortal03@96.32.230.231] has joined #bitcoin-core-dev
08:39 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
08:52 -!- laurentmt [~Thunderbi@80.215.178.35] has quit [Quit: laurentmt]
09:04 < GitHub89> [bitcoin] Mirobit closed pull request #8283: Move AdvertiseLocal debug output to net category (master...master) https://github.com/bitcoin/bitcoin/pull/8283
09:09 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]
09:12 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
09:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:15 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]
09:36 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
09:37 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
09:38 < GitHub188> [bitcoin] Mirobit opened pull request #8462: Move AdvertiseLocal debug output to net category (master...advertiselocal) https://github.com/bitcoin/bitcoin/pull/8462
09:51 -!- kvnn [~kvnn@cpe-108-185-240-254.socal.res.rr.com] has joined #bitcoin-core-dev
09:51 < kvnn> Can anyone tell me how much disk space testnet currenty takes?
10:04 < GitHub149> [bitcoin] MarcoFalke opened pull request #8463: [qt] Remove Priority from coincontrol dialog (master...Mf1608-qtPrio) https://github.com/bitcoin/bitcoin/pull/8463
10:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
10:16 < GitHub47> [bitcoin] JeremyRubin opened pull request #8464: "Lockfree" Checkqueue Implementation (master...lockfree-checkqueue-squashed) https://github.com/bitcoin/bitcoin/pull/8464
10:19 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has joined #bitcoin-core-dev
10:19 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has quit [Changing host]
10:19 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:19 < jeremyrubin> (forgot to mark as WIP fyi)
10:21 < btcdrak> you can edit the title
10:21 < btcdrak> jeremyrubin
10:22 < btcdrak> jeremyrubin: it's quite useful to use markdown task lists in the PR body, as those show up in lists and references on other tickets/PRs https://github.com/blog/1825-task-lists-in-all-markdown-documents and it also has the side benefit of making the WIP status clear
10:27 < jeremyrubin> btcdrak: what are the tasks?
10:27 < btcdrak> your todo list.
10:28 < jeremyrubin> btcdrak: the only stuff really remaining is more testing.
10:28 < jeremyrubin> btcdrak: actually I can think of two things
10:28 < sipa> jeremyrubin: if all that remains is testing, i wouldn't call it WIP :)
10:30 < btcdrak> sipa: exactly! if it's marked WIP no-one will test it.
10:31 < jeremyrubin> sipa: oh ok... I'll un WIP it then, it's ready for testing
10:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:33 < jeremyrubin> sorry was unclear at what point I should WIP/vs non WIP, thanks for the guidance
10:35 < jeremyrubin> I'm going to be awk for a little bit, but will respond to more things later.
10:35 < jeremyrubin> sipa: you may just want to view the whole diff rather than commit by commit
10:41 -!- zooko` [~user@73.95.139.67] has joined #bitcoin-core-dev
10:42 -!- zooko [~user@73.95.139.67] has quit [Ping timeout: 258 seconds]
10:42 < sipa> jeremyrubin: i tend to review per commit, as i think every commit should logically make sense... the combination into a pull request is there to see the bigger picture
10:48 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:52 < jeremyrubin> yep I agree, each commit should compile and run on this PR but is maybe not fully documented ;) 
10:53 -!- Greybits [~Greybits@unaffiliated/greybits] has joined #bitcoin-core-dev
10:54 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds]
11:07 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
11:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
11:09 -!- mmortal03 [~mmortal03@96.32.230.231] has quit [Ping timeout: 240 seconds]
11:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:16 -!- arubi__ is now known as arubi
11:24 -!- kvnn [~kvnn@cpe-108-185-240-254.socal.res.rr.com] has quit [Remote host closed the connection]
11:38 < bsm117532> wizkid057, the exploding bitcoin spammer, somehow got op permissions on #bitcoin-wizards and is banning people.  Can someone here take care of him?
11:41 < jonasschnelli> jeremyrubin: impressive PR... my review will take a while. :)
11:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:44 < pigeons> he's not banning people, just kicked you only and its not the spammer it really is wizkid. probably just a mistake
11:45 < bsm117532> sorry, don't know who wizkid is.
12:03 < GitHub178> [bitcoin] sipa opened pull request #8465: [0.13] Document reindexing changes (0.13...docreindex) https://github.com/bitcoin/bitcoin/pull/8465
12:07 < GitHub185> [bitcoin] paveljanik opened pull request #8466: [Trivial] Do not shadow variables in networking code (master...20160805_Wshadow_net) https://github.com/bitcoin/bitcoin/pull/8466
12:17 < sipa> i feel that 'New mempool information RPC calls' could move to 'Low-level RPC changes' in the release notes
12:17 < jtimon> thoughts on https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1 NicolasDorier btcdrak sipa should I open a PR?
12:18 < jtimon> this doesn't touch the script flags and doesn't move anything out of contextualCheckBlock like the previous one
12:18 < jtimon> it could be 1 or a few commits, but I kept it extremely separated just in case
12:22 < GitHub153> [bitcoin] paveljanik opened pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
12:22 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:32 < sdaftuar> sipa: ack
12:33 < sdaftuar> sipa: more generally i think if you're going to clean up further, perhaps reordering the Notable Changes section might be called for.  eg hd wallet support, segwit, cpfp mining, and compact blocks strike me as more important to highlight than c++11 code modernizations
12:36 < sipa> maybe a section that aggregates all non-user-visible code changes
12:36 < sipa> that would even include segwit, i guess
12:42 < sdaftuar> sure.  fyi the mining stuff references segwit, so if you move those around relative to each other, the text might need some edits
12:55 < GitHub14> [bitcoin] paveljanik opened pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
13:04 -!- zooko`` [~user@2601:281:8000:8387:e144:a18c:9f1:1fb] has joined #bitcoin-core-dev
13:06 -!- zooko` [~user@73.95.139.67] has quit [Ping timeout: 258 seconds]
13:13 < Chris_Stewart_5> Is this entire block of code inside of bloom.cpp basically so that we can match redeemScript/pubkey hashes in scriptPubKeys?
13:13 < Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/bloom.cpp#L163-LL177
13:16 < jonasschnelli> sipa: how do I get the DynamicUsage from a struct?
13:16 < jonasschnelli> MallocUsage(size_t alloc) is inline...
13:17 < sipa> jonasschnelli: sum the dynamic usages of its member fields
13:18 < jonasschnelli> sipa: what about MallocUsage(sizeof(mystruct))?
13:18 < jonasschnelli> +allow external calls to MallocUsage
13:19 < sipa> jonasschnelli: are you mallocing your stuct?
13:19 < jonasschnelli> sipa: ... ah... no.
13:19 < sipa> then you shouldn't be using either of them
13:20 < jonasschnelli> I guess std::vector<mystruct> is on the stack
13:20 < sipa> DynamicUsage is not how much memory a struct uses. It's how much _dynamic_ memory it uses. The static memory you find just using sizeof.
13:20 < sipa> jonasschnelli: use DynamicUsage on the vector.
13:20 < sipa> The vector is allocated on the stack. Its entries are allocated on the heap.
13:21 < sipa> DynamicUsage(vector) will tell you how much memory that vector malloced.
13:21 < jonasschnelli> sipa: yes. I'll do that. But i'd like to know how many elements i have to remove from the vector to match a usage target... therefore I need to calculate the size of a single element.
13:21 < sipa> jonasschnelli: use sizeof.
13:21 < sipa> also, removing elements from a vector does not reduce its memory usage.
13:21 < sipa> you need to call shrink_to_fit
13:21 < jonasschnelli> okay... but aren't the element malloced?
13:22 < sipa> yes?
13:22 < sipa> but not individually
13:22 < sipa> a vector has a single allocated block with all its elements in it
13:22 < jonasschnelli> Okay. I'll use sizeof(struct) and good point about shrink_to_fit!
13:22 < jonasschnelli> thanks.
13:27 < jonasschnelli> sipa: sizeof(struct) = 32, memusage::DynamicUsage(vector)/size = 52?!
13:28 < jonasschnelli> calculating the amount of items to remove based on sizeof(struct) is not precise to get the memory usage target
13:28 < sipa> jonasschnelli: look at vector.capacity)(
13:28 < sipa> instead of size
13:29 < sipa> vectors allocate more than what is requested, so that they don't need to reallocate whenever a new element is added
13:29 < sipa> jtimon: i think it's very ugly to have a single set of flags that contains both block level validation rules and script level validation rules
13:30 < jonasschnelli> sipa: /vector.capacity() == sizeof(struct) ... thanks!
13:31 < jtimon> sipa: the script flags are hidden behind ScriptFlagsFromConsensus() I thought that was what you wanted
13:31 < sipa> jtimon: https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1#diff-cefdf710ea5108806289afadb6cf8717R13
13:32 < jtimon> sipa: so how many sets of flags do we want to expose in libconsensus?
13:32 < sipa> jtimon: one for every layer
13:32 < jtimon> is locktime a layer?
13:32 < sipa> there will be a script validation API and a block validation API, right?
13:32 < sipa> maybe a transaction validation API as well
13:32 < sipa> i think it's wrong to make them share flags
13:33 < sipa> what if there was a script change that only applied to transactions with nVersion>=5... you'd have a block level flag to enable the soft fork, but it wouldn't map one-to-one to the script flag
13:33 < jtimon> maybe a header validation API too, I think that would be the easiest thing to expose and discuss abstractions from storage
13:34 < jtimon> sipa:yeah, now they don't need to map, the non-script consensus flags don't need to be in the internal script flags
13:34 < jtimon> and some internal script flags are not exposed
13:36 < jtimon> I don't undesrtand your txversion>5 example
13:36 < jtimon> the flag would be used at the tx validation level either way, no?
13:37 < jtimon> oh, I see what you mean
13:37 < sipa> say we had a new OP_CHECKSIGAWESOME, but only enabled in UTXOs created by transactions with nVersion >= 5
13:38 < sipa> there would be SCRIPT_VERIFY_CHECKSIGAWESOME, and a BIP9 deployment AWESOME
13:38 < sipa> you'd pass AWESOME to the block validation functions
13:38 < jtimon> yes, you're saying that you would do the consensus-to-internal-script conversion outside of the conversion function and inside, say verifyTx
13:38 < sipa> right... there is not necessarily a clean mapping between the two
13:39 < sipa> what flags the script code is called with is block level logic
13:39 < jtimon> well, what we're exposing in libconsensus are the BIP9/older_sf flags, no?
13:39 < sipa> for the script layer, sure
13:39 < sipa> wait, no
13:39 < jtimon> for all layers, no?
13:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
13:39 < sipa> i'm confused :)
13:39 < sipa> i'm assuming there will be a enum for block level validation flags
13:40 < jtimon> the flags we expose in libconsensus right now are a subset of the script internal ones
13:40 < sipa> and an enum (which already exists) for script level validation flags
13:40 < sipa> for some softforks there will be a flag in both
13:40 < jtimon> there's no flag for say bip68 and bip113, because thouse would be needed for verifyTx, but not for verifyScript
13:41 < sipa> right
13:41 < jtimon> well, the "block level" flags include all the "script level" flags, right?
13:42 < sipa> not necessarily
13:42 < jtimon> how do you tell verifyblock to verify p2sh otherwise?
13:43 < jtimon> I mean, verifytx
13:43 < jtimon> verifyblock could call getflags internally I guess, but that's not the point
13:44 < sipa> i'd expect verifyblock to have something like BLOCK_VERIFY_CSV, and verifyscript to have something like SCRIPT_VERIFY_CHECKSEQUENCEVERIFY
13:45 < jtimon> say I want to call verifytx specifying that I want p2sh and bip113 validated
13:45 < sipa> sure, CSV implies that CHECKSEQUENCEVERIFY is passed to script
13:45 < sipa> but CSV does much more than that
13:45 < sipa> it also enabled nsequence behaviour
13:45 < sipa> which has nothing to do with script
13:46 < jtimon> so BLOCK_VERIFY_CSV is mapped into bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH and then bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH into SCRIPT_VERIFY_P2SH
13:46 < jtimon> do we need also a TX_VERIFY_P2SH for exposing verifyTx ?
13:47 < sipa> i'd keep the tx-level flags and block-level flags the same
13:47 < sipa> but script flags seem separate
13:47 < jtimon> well, the flags for BIP68 and for BIP112 are separated in that branch
13:48 < sipa> that's just my opinion, btw... maybe other people feel that script and block flags should be combined
13:48 < jtimon> they are separated: there's "all consensus flags" and "all consensus flags related to script plus some more script specific flags"
13:49 < jtimon> well, from previous talks I thought this was exactly what you wanted, still not sure what would you prefer
13:49 < sipa> yes, i feel they should be completely separate
13:49 < sipa> not one being an extension of the other
13:50 < jtimon> like not repeating p2sh in both of them? I don't undesrtand
13:50 < sipa> but maybe others disagree... that's fine
13:50 < sipa> yes, P2SH would be in both
13:50 < jtimon> in this case one is not an extension of the other, what do you mean?
13:50 < jtimon> they share some (they currently share)
13:51 < sipa> https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-consensus-flags?expand=1#diff-cefdf710ea5108806289afadb6cf8717R13
13:51 < sipa> you're just copying the script flags there
13:51 < sipa> and then adding other things
13:51 < sipa> just make it a completely independent enum
13:52 < jtimon> not from the script, see https://github.com/bitcoin/bitcoin/commit/82bf11faf9a1d915eb0fc40ea6db10da9908df2a
13:52 < paveljanik> cfields, thanks for review!
13:52 < jtimon> I'm just adding new non-script flags there
13:52 < sipa> bitcoinconsensus_BIP16, bitcoinconsensus_BIP66, bitcoinconsensus_BIP65, bitcoinconsensus_BIP68, ... for example
13:52 < jtimon> the script ones were already exposed in libconsensus
13:53 < sipa> and BIP16 would map to script verify P2SH
13:53 < jtimon> they already do by hardcoding the same bit positions in both, I'm trying to solve that
13:54 < jtimon> that's what ScriptFlagsFromConsensus() is supposed to solve
13:54 < sipa> well why do you have both LOCKTIME_VERIFY_SEQUENCE and bitcoinconsensus_SCRIPT_FLAGS_VERIFY_CHECKSEQUENCEVERIFY in the same enum?
13:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:54 < sipa> at the block level they're the same thing
13:56 < jtimon> because I'm not creating a new enum for libconsensus, there's currently one for libconsensus and another for scripts, I'm keeping it that way, just decoupling each other from the bit positions having to match
13:56 < sipa> to verifyblock you would just pass "CSV is enabled", and it would trigger all necessary things... including locktime nsequence checking and script checksequenceverify
13:56 < jtimon> let's say in libconsensus the "block level" flags would be reused for verifyTx and verfiyScript, does that make sense?
13:57 < sipa> i don't know what you mean by that
13:57 < jtimon> I see, you want the block level ones to correspond with deployments, ie bip68 and bip112 go together
13:58 < sipa> well if there is a reason why they would be implemented separately, they can be separate
13:58 < sipa> it's about abstraction... the caller of blockverify shouldn't need to know what every softfork corresponds to internally
13:59 < jtimon> but you don't want verifyScript to receive a CSV_bip68_bip112 flag that it internally maps to SCRIPT_VERIFY_CHECKSEQUENCEVERIFY (ignoring bip68 because at the script level it doesn't care)
13:59 < sipa> that enum you have there feels to me like you want to expose all internal choices to the caller... that isn't necessary
13:59 < sipa> right... have block validation flags that correspond to deployments/softforks, and script validation flags that correspond to script rules
13:59 < jtimon> yeah they can be separated, we could also have a bool param for every option
14:00 < sipa> some block validation flags will correspond to one or more script flags... some may not
14:00 < sipa> but the caller shouldn't need to know that
14:00 < sipa> again... all of that is just my opinion
14:00 < sipa> i'd like to hear some others too
14:01 < jtimon> agree on what you said about the caller, disagree that I want to expose more details than necessary to the caller, I'm happy to merge bip68 and bip112 flags, that seems orthogonal
14:01 < sipa> just the naming of your flags is exposing things :)
14:01 < jtimon> the main question is how many enums do we want and what should it be in them
14:01 < jtimon> oh, come on, I expect people to bike-shedd
14:02 < jtimon> don't tell me that's the main complain
14:02 < sipa> at the block/tx level, you'd have bip16, bip34, bip66, bip65, bip68_112_113, bip141
14:02 < cfields> paveljanik: np. the serialization one will require more effort.
14:02 < sipa> at the script level, you'd have what already exists
14:02 < jtimon> asume you fully decide the names in the enum
14:02 < cfields> paveljanik: imo changing the name for those would be helpful, the version serialization is quite confusing as-is
14:02 < sipa> jtimon: i don't care about the name... i care about the fact that it's mixing several layers!
14:02 < jtimon> why are bip68_112_113 together?
14:03 < jtimon> bip113 was deployed separately
14:03 < sipa> because someone calling verifyblock shouldn't need to know that part of it is a script rule and part of it is not
14:03 < jtimon> for the libconsensus caller, all he cares about is deployments, no?
14:03 < sipa> IMHO, there should not be any flags at all, and you just give it the block headers :)
14:04 < sipa> but i understand we're not there yet
14:04 < jtimon> with my approach all they need to know is that each flag is a deployment
14:04 < sipa> ok, i don't like it, sorry
14:04 < sipa> that's not a NACK
14:04 < sipa> but i'm tired of discussing it
14:04 < jtimon> well, we can expose consensus::getflags
14:04 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev []
14:05 < jtimon> but are you saying that verifyTx should call getflags internally?
14:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kokrjmtruxobhryl] has quit [Quit: Connection closed for inactivity]
14:05 < paveljanik> cfields, yes. I took me a lot of time to get it done. This was my third attempt to do so.
14:06 < cfields> paveljanik: understood. it's much appreciated.
14:06 < paveljanik> cfields, I have more huge task... LOCK inside LOCK
14:06 < cfields> paveljanik: one high-level request: if the param isn't used, please just leave the var unspecified
14:06 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
14:07 < paveljanik> cfields, I thought about it too (esp. nVersion...) but this would make review more difficult.
14:07 < cfields> paveljanik: otherwise we're not getting any closer to being able to enable -Wunused-parameter :)
14:07 < cfields> paveljanik: how so?
14:08 < paveljanik> every reviewer must read the whole function code...
14:08 < paveljanik> without this change, it is almost enough to read the context
14:10 < cfields> ok, fair enough
14:10 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
14:12 < paveljanik> of course the compilation can find problems there...
14:13 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
14:14 -!- english- [~red@unaffiliated/english-] has joined #bitcoin-core-dev
14:16 < paveljanik> BTW - LOCK inside LOCK problem: LOCK macro defines a local variable CCriticalBlock criticalblock. And thus LOCK inside LOCK shadows it.
14:16 < paveljanik> I do not want to make the change in the syntax of LOCK, so I have to change the macro.
14:16 < gmaxwell> thats presumably why there are LOCKN macros?
14:17 < paveljanik> yes, but... LOCK2 at the beginning of the function grabs both at the beginning.
14:17 < paveljanik> I do not think this is wanted.
14:18 < paveljanik> I had an idea to change the name of the variable somehow - e.g. criticalblockLINENR or so.
14:18 < paveljanik> but implementing this in the preprocessor's ## ## ## is currently above my knowledge ;-)
14:19 < paveljanik> see e.g. ProcessGetData in main.cpp.
14:19 < sipa> paveljanik: use the file number in the name of the variable :)
14:19 < sipa> eh, line number
14:19 < paveljanik> that was my plan :-) But not so easy to write it 8)
14:20 < sipa> i'll try
14:23 < cfields> can't you just use the incoming param's name?
14:25 < sipa> cfields: what do you if it's called pnode->buf[(int)(sin(x)*35)].cs?
14:25 < NicolasDorier> jtimon: I think we shoudl talk about that in ##libconsensus on my side I'm still not decided whther I prefer the one flag approach of my approach (https://github.com/bitcoin/bitcoin/pull/8339/commits/a59f79dfb7a996e9b309aa43d699499339b1a7c4)
14:25 < jtimon> NicolasDorier: sure we can move there
14:28 < cfields> sipa: heh, ok. that's a stretch, though :)
14:28 < paveljanik> cfields, self-assing: good catch. Look like I do not even understand the original code 8) https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L289
14:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
14:30 < sipa> paveljanik: 
14:31 < sipa> #define LOCK(cs) CCriticalBlock criticalblock ## __LINE__(cs, #cs, __FILE__, __LINE__)
14:31 < sipa> does that not work?
14:31 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
14:31 < paveljanik> IIRC I have already tried this. Will try again
14:33 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev
14:33 < cfields> sipa: (on one line) std::mutex m1; std::mutex m2; LOCK(m1); LOCK(m2);
14:33 < sipa> cfields: ?
14:34 < paveljanik> both variables will be named the same.
14:34 < sipa> ah.
14:34 < paveljanik> main.cpp:6543:28: note: previous declaration is here
14:34 < paveljanik>             CCriticalBlock criticalblock__LINE__(pto->cs_inventory, "pto->cs_inventory", "main.cpp", 6543);
14:34 < sipa> ok, that looks wrong
14:34 < cfields> sipa: only because you poked a hole in mine first :)
14:35 < sipa> cfields: well use LOCK2 in that case
14:35 < paveljanik> :-)
14:36 < sipa> paveljanik: bip112
14:37 < sipa> eh
14:37 < sipa> paveljanik: http://stackoverflow.com/a/1597129
14:37 < sipa> __COUNTER__ looks even nicer
14:39 < paveljanik> I'll see.
14:40 < sipa> #define paste1(a,b) a ## b
14:40 < sipa> #define paste(a,b) paste1(a,b)
14:40 < sipa> #define LOCK(cs) CCriticalBlock paste(criticalblock,__COUNTER__)(cs, #cs, __FILE__, __LINE__)
14:40 < paveljanik> #define TOKENPASTE(x, y) x ## y
14:40 < paveljanik> #define TOKENPASTE2(x, y) TOKENPASTE(x, y)
14:40 < paveljanik> #define LOCK(cs) CCriticalBlock TOKENPASTE2(criticalblock, __LINE__)(cs, #cs, __FILE__, __LINE__)
14:40 < paveljanik> seems to work
14:41 < sipa> \o/
14:41 < paveljanik> will try COUNTER here
14:42 < paveljanik> works as well
14:43 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
14:45 < paveljanik> thank you sipa!
14:45 < paveljanik> Looks like I need some sleep 8)
14:46 < sipa> night
14:47 -!- zooko`` [~user@2601:281:8000:8387:e144:a18c:9f1:1fb] has quit [Ping timeout: 250 seconds]
14:50 -!- english- [~red@unaffiliated/english-] has quit [Quit: Leaving]
14:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tcdpmzpgubewrinq] has joined #bitcoin-core-dev
15:02 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Remote host closed the connection]
15:03 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:07 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Client Quit]
15:12 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:21 -!- dvsdude [~dude@unaffiliated/dvsdude] has joined #bitcoin-core-dev
15:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:30 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Read error: Connection reset by peer]
15:31 -!- cryptapus is now known as cryptapus_afk
15:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:39 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 240 seconds]
15:40 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:43 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
15:51 -!- dvsdude [~dude@unaffiliated/dvsdude] has left #bitcoin-core-dev []
15:52 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: Leaving]
15:54 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
15:54 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
15:54 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
15:58 -!- cryptapus_afk is now known as cryptapus
15:59 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
16:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
16:00 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 252 seconds]
16:05 -!- cryptapus is now known as cryptapus_afk
16:24 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:28 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:28 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer]
16:51 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
16:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
16:53 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
17:01 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 264 seconds]
17:15 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Quit: END OF LINE]
17:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:30 -!- felipelalli [~felipelal@unaffiliated/felipelalli] has joined #bitcoin-core-dev
17:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tcdpmzpgubewrinq] has quit [Quit: Connection closed for inactivity]
18:20 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uamxzsilsqmqncvu] has quit [Quit: Connection closed for inactivity]
18:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:26 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
18:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:27 -!- pigeons [~pigeons@94.242.209.214] has quit [Remote host closed the connection]
18:28 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
18:28 -!- pigeons is now known as Guest21622
18:34 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:37 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
18:41 -!- Guest21622 is now known as pigeons
18:44 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
18:48 < GitHub6> [bitcoin] Christewart opened pull request #8469: [POC] Introducing property based testing to Core (master...rapidcheck) https://github.com/bitcoin/bitcoin/pull/8469
18:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
19:13 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
19:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:28 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:31 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 276 seconds]
19:38 -!- dvsdude [~dude@unaffiliated/dvsdude] has joined #bitcoin-core-dev
19:48 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
19:49 -!- pigeons is now known as Guest80390
19:52 -!- Guest80390 is now known as pigeons
19:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:07 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
20:08 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
20:08 < jeremyrubin> How do I use travis without pushing to my PR? 
20:09 < jeremyrubin> I'd like to confirm what I think is causing some build fails without having to push
20:09 < jeremyrubin> testing locally is a bit mroe difficult
20:10 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 240 seconds]
20:10 -!- blur3d [~blur3d@49.187.12.150] has joined #bitcoin-core-dev
20:11 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
20:11 -!- pigeons is now known as Guest19508
20:12 -!- FNinTak [~jonhbit@dhcp-18-111-10-93.dyn.mit.edu] has joined #bitcoin-core-dev
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:24 -!- Guest19508 [~pigeons@94.242.209.214] has quit [Ping timeout: 252 seconds]
20:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
20:25 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-rmlmrflropeoozsh] has joined #bitcoin-core-dev
20:29 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
20:29 -!- pigeons is now known as Guest79503
20:36 < jeremyrubin> ah i guess I hadn't looked at the pull_tester before... should be resolved.
20:38 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
20:42 < sipa> jeremyrubin: you can't run the tests locally?
20:54 -!- blur3d [~blur3d@49.187.12.150] has quit [Quit: blur3d]
21:00 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]
21:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
21:06 -!- sonlin [~androirc@CPE00fc8d25fde3-CM00fc8d25fde0.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev
21:07 < sonlin> Thoughts on implementing the dev subsidy feature?
21:07 < sipa> what feature?
21:08 < sonlin> It takes for example 20% of block reward and fees and distributes it to devs.
21:09 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]
21:09 < sonlin> The exact % can be changed.
21:09 < sipa> why would anyone accept that?
21:09 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
21:10 < sipa> especially with the current developers not asking for such a thing
21:10 < sonlin> It seems like a good way to distribute coins instead of just pow as it is currently.
21:10 < sipa> it requires a centralized development team
21:10 < sipa> whose identity is hardcoded in the protocol
21:10 < sonlin> Right now there is no direct reward for developing.
21:11 < sipa> it seems to work fine without
21:11 < sonlin> Once there is then there will be competition between developers to do things better.
21:11 < gmaxwell> the reward is that we get to argue with ignorant people on the internet.
21:11 < sipa> sonlin: no, there would be an incentive for developers to start pumping the price and do marketing
21:11 < sonlin> Dsd in my opinion could fix a lot of this politics bs in the dev space.
21:12 < sipa> security and features don't drive the price... empty promises do
21:12 -!- dvsdude [~dude@unaffiliated/dvsdude] has left #bitcoin-core-dev []
21:12 < gmaxwell> sonlin: by having protocol hardcoded developers... you think that would fix a lot of politics?
21:13 < kanzure> also see other weird problems with transaction fees from wallets and wallet developers
21:13 < sonlin> Developers wouldn't necessarily be hard coded.
21:13 < sonlin> And it's funny you brought that up.
21:13 < sipa> sonlin: then who has the right to update the list of developers?
21:13 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-core-dev []
21:13 < sipa> who get the subsidy?
21:13 < sonlin> Because right now it's almost like devs are hardcoded in.
21:13 < sipa> what?
21:13 < sonlin> There is such a closed off community of devs.
21:14 < sonlin> That pushes some other devs away.
21:14 < sipa> how would your proposal fix that?
21:14 < sipa> who gets to decide which developers get the money?
21:15 < sonlin> Bitcoin holders and a combination of other methods.
21:15 < sipa> how do bitcoin holders decide?
21:15 < sonlin> Dsd is still being developed.
21:15 < sipa> what is Dsd?
21:15 < sonlin> Developer subsidy distribution
21:15 < kanzure> how do you evaluate whether the community is closed off? have you tried to write code?
21:16 < sipa> there have been altcoins that tried this model
21:16 < sonlin> I currently have a team of developers writing the code.
21:16 < sipa> it doesn't seem to work
21:16 < sipa> in any case, off topic for this channel
21:16 < kanzure> and what payments did you make to join this irc channel? it doesn't seem particularly closed to me..
21:16 < kanzure> ok fine
21:16 < sonlin> I just want bitcoin to progress.
21:17 < sonlin> That's why I'm going to implement this.
21:17 < kanzure> i think that a developer subsidy might be possible, but it will need a better idea, because existing implementations of your idea have shown the model to be fairly broken
21:17 < sipa> you can do so without introducing a point of centralization
21:17 < sonlin> It will be hard to get this implemented though.
21:17 < sonlin> Because I'm fairly sure no miners will allow this.
21:17 < sipa> i think it's a terrible idea... speaking as someone who would possibly be at the receiving end of your idea :)
21:18 < sipa> and we all want bitcoin to progress, but i don't think you do that by radically changing its economics
21:19 < sonlin> Ok 20% might be to high
21:19 < sonlin> But let's say 5% gos towards dsd
21:19 < sipa> even if it was 0.001%
21:19 < sonlin> That's $50k a day at current price that gos towards development.
21:19 < sipa> i think it's fundamentally a perversion of incentives
21:19 < kanzure> the funny thing is that altcoins should probably hard-code their developer subsidies to pay bitcoin developers, so that the bitcoin developers continue to work, since altcoins benefit mainly from that development activity, and that subsidy doesn't interfere with the bitcoin protocol definition. however, iirc, developers in the past have said they would not touch any of those subsidy payments anyway.
21:20 < sipa> feel free to discuss the idea once you have worked out the exact mechanism on the mailing list
21:21 < kanzure> (e.g. they wouldn't touch any of it on principle and because perversion of incentive reasons and because having someone decide where the payments go is itself contentious and difficult to solve)
21:21 < sipa> but i expect most developers to dislike it
21:21 < sipa> before you even know how users get to decide the distribution there is not much to talk about
21:22 < sonlin> I'm not the one actually developing it that's why.
21:22 < kanzure> sipa: what about altcoins distributing payments to bitcoin developers as part of their protocol definitions?
21:22 < kanzure> ok anyway off-topic i guess
21:22 < sipa> kanzure: now you give bitcoin developers an incentive to go pump those altcoins :p
21:23 < sipa> please, don't give them idea
21:23 < sonlin> But i was told by the developers that are making dsd that basically all bitcoin devs would switch over at once.
21:23 < sonlin> It's to good to pass up.
21:23 < sipa> sonlin: i believe you're misinformed
21:23 < sipa> also, bitcoin developers don't set the rules
21:24 < sonlin> I know that's the thing.
21:24 < kanzure> "all developers would switch over at once" would only make sense if developers were doing development for payment (and most of them are unpaid, which seems to indicate otherwise)
21:24 < sipa> if bitcoin core were to introduce such a rule, i hope the community would refuse to run it
21:24 < luke-jr> kanzure: sipa: Devcoin already did that.
21:24 < sipa> right, devcoin
21:25 < sonlin> It's human  nature, developers will not refuse this subsidy.
21:25 < luke-jr> sonlin: Devcoin seems pretty dead.
21:25 < kanzure> sonlin: it seems pretty easy to me to refuse a subsidy.
21:25 < sipa> sonlin: as a developer, i believe it would strongly undermine trust in bitcoin as an independent decentralized currency
21:26 < sipa> sonlin: as such, i would oppose it
21:26 < sipa> even if it would pay me
21:26 < sonlin> That's because devcoin was an irelevent alt
21:26 < sonlin> It would put an end to development stagnation
21:26 < sipa> what?
21:26 < sipa> development is going faster than ever
21:27 < sonlin> There is to much time wasted with politics
21:27 < sipa> and you think adding more money to the equation would reduce politics? :o
21:27 < sonlin> Once there is financial incentive things will start to inovate and speed up.
21:27 < kanzure> they seem to be writing code instead of doing politics. this is increasingly off-topic. i think you should move to another channel to discuss this.
21:28 < sipa> sonlin: i think you're totally wrong
21:28 < sipa> sonlin: people were trying to innovate long before bitcoin had any value. increased value brought economic interest in influencing development with all associated politics
21:30 < sipa> anyway, this is getting far off topic
21:30 < sipa> this channel is about development of bitcoin core
21:30 < sipa> i doubt many people involved with bitcoin core development are interested in this
21:31 < sonlin> We shall see
21:39 -!- sonlin [~androirc@CPE00fc8d25fde3-CM00fc8d25fde0.cpe.net.cable.rogers.com] has quit [Ping timeout: 244 seconds]
21:39 < midnightmagic> \o/
21:50 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev
21:55 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Ping timeout: 258 seconds]
22:05 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
22:42 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
23:27 < GitHub43> [bitcoin] luke-jr opened pull request #8471: Key origin metadata, with HD wallet support (master...keyorigin_hd) https://github.com/bitcoin/bitcoin/pull/8471
23:36 -!- felipelalli [~felipelal@unaffiliated/felipelalli] has quit [Ping timeout: 258 seconds]