--- Day changed Thu Nov 17 2016
00:16 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 246 seconds]     
00:16 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 265 seconds]     
00:17 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
00:18 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
00:27 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 248 seconds]     
00:28 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
00:30 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev     
00:32 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 245 seconds]     
00:34 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
00:39 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 256 seconds]     
00:40 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
01:04 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 246 seconds]     
01:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:11 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
01:19 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]     
01:20 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
01:26 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]     
01:29 < petertodd> jtimon: no, I mean, making chains other than the existing one invalid unless they follow the new rules
01:29 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
01:29 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
01:29 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:29 < petertodd> jtimon: that still allows reorgs - it's not a checkpoint - but allows you to remove all the ISM logic.
01:30 < petertodd> jtimon: of course, by "allows reorgs" - it mainly only allows truly massive reorgs, but I think that's sufficient to keep this from being a checkpoint
01:33 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 268 seconds]     
01:33 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
01:38 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
01:43 -!- laurentmt [~Thunderbi@80.215.234.110] has joined #bitcoin-core-dev     
01:43 -!- laurentmt [~Thunderbi@80.215.234.110] has quit [Client Quit]     
01:47 -!- DigiByteDev [~JT2@218.250.11.174] has quit [Quit: DigiByteDev]     
01:57 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]     
02:00 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
02:07 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
02:07 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 252 seconds]     
02:08 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
02:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds]     
02:24 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]     
02:26 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
02:29 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]     
02:34 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev     
02:43 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit []     
02:44 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
02:47 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 268 seconds]     
02:48 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
02:53 -!- DigiByteDev [~JT2@118.140.106.58] has joined #bitcoin-core-dev     
02:53 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 246 seconds]     
02:54 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
02:56 -!- DigiByteDev [~JT2@118.140.106.58] has quit [Client Quit]     
03:07 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 260 seconds]     
03:09 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
03:27 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 252 seconds]     
03:28 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
03:49 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
03:49 < morcos> petertodd: yes that is what i was saying as well, i just don't know how to do that efficiently
03:50 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Remote host closed the connection]     
03:56 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 268 seconds]     
03:57 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
04:23 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]     
04:26 -!- Guyver2__ is now known as Guyver2     
04:41 -!- shesek [~shesek@bzq-84-110-176-21.red.bezeqint.net] has quit [Ping timeout: 248 seconds]     
04:41 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]     
04:45 -!- Guyver2__ is now known as Guyver2     
04:54 -!- shesek [~shesek@2.55.142.155] has joined #bitcoin-core-dev     
04:58 <@wumpus> what is the proper way to pass arguments to the secp256k1 configure script that is invoked by bitcoin's?
05:01 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 265 seconds]     
05:03 <@wumpus> oh nm I can just pass "--with-asm=arm --enable-experimental" to the outer configure and it works. doh
05:04 <@wumpus> ... I'd been manually patching configure.ac all that time :-)
05:06 -!- cryptapus [~cryptapus@87.254.202.129] has joined #bitcoin-core-dev     
05:06 -!- cryptapus [~cryptapus@87.254.202.129] has quit [Changing host]     
05:06 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
05:07 < luke-jr> hehe
05:09 <@wumpus> never tried as I expected it to croak on unknown arguments
05:10 < luke-jr> there's an argument to make it not even warn :D
05:10 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
05:11 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 260 seconds]     
05:11 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
05:15 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb2ed300a89e...f6db48ad1c8f
05:15 < bitcoin-git> bitcoin/master 5f274a1 jnewbery: log block size and weight correctly.
05:15 < bitcoin-git> bitcoin/master f6db48a Wladimir J. van der Laan: Merge #8838: Calculate size and weight of block correctly in CreateNewBlock()...
05:19 < bitcoin-git> [bitcoin] Christewart closed pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
05:25 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
05:26 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 268 seconds]     
05:27 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
05:32 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 260 seconds]     
05:33 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
05:34 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
05:35 -!- MarcoFalke [~marco@host43-2.natpool.mwn.de] has joined #bitcoin-core-dev     
05:39 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev     
05:39 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
05:40 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]     
05:49 -!- MarcoFalke [~marco@host43-2.natpool.mwn.de] has quit [Ping timeout: 244 seconds]     
05:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:51 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
05:51 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
05:51 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
06:10 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
06:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
06:24 -!- shesek [~shesek@2.55.142.155] has quit [Read error: Connection reset by peer]     
06:29 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6db48ad1c8f...aaca05c0dabd
06:29 < bitcoin-git> bitcoin/master fa63ee8 MarcoFalke: Doxygen: Set PROJECT_NAME = "Bitcoin Core"
06:29 < bitcoin-git> bitcoin/master aaca05c Wladimir J. van der Laan: Merge #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core"...
06:29 < bitcoin-git> [bitcoin] laanwj closed pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
06:30 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
06:32 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev     
06:35 -!- harrymm [~wayne@104.222.140.47] has quit [Ping timeout: 258 seconds]     
06:38 -!- harrymm [~wayne@104.222.140.55] has joined #bitcoin-core-dev     
06:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:44 -!- shesek [~shesek@bzq-84-110-54-135.cablep.bezeqint.net] has joined #bitcoin-core-dev     
06:45 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds]     
06:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:50 < instagibbs> Chris_Stewart_5, so malleability in this context is not txid malleability
06:51 < instagibbs> rather witness malleability. Some joker relayer could stuff transactions with junk data and the transaction is still valid
06:51 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
06:53 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
06:54 < Chris_Stewart_5> instagibbs: I still don't understand the 'empty byte array' thing, and I also can't seem to find where this empty byte array is pushed onto the stack in the codebase 
06:55 < Chris_Stewart_5> I get why we have all the other checks inside of CheckSignatureEncoding: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
06:56 < Chris_Stewart_5> The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
06:56 < Chris_Stewart_5> https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#nullfail
06:58 -!- cannon-c [adda1d51@gateway/web/freenode/ip.173.218.29.81] has joined #bitcoin-core-dev     
06:58 -!- cannon-c [adda1d51@gateway/web/freenode/ip.173.218.29.81] has left #bitcoin-core-dev []     
07:06 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aaca05c0dabd...a8b2a82618be
07:06 < bitcoin-git> bitcoin/master d8274bc Jonas Schnelli: Add compile and link options echo to configure
07:06 < bitcoin-git> bitcoin/master a8b2a82 Wladimir J. van der Laan: Merge #9156: Add compile and link options echo to configure...
07:06 < bitcoin-git> [bitcoin] laanwj closed pull request #9156: Add compile and link options echo to configure (master...2016/11/configure) https://github.com/bitcoin/bitcoin/pull/9156
07:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
07:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:23 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 260 seconds]     
07:24 -!- laurentmt [~Thunderbi@80.215.138.68] has joined #bitcoin-core-dev     
07:26 -!- laurentmt [~Thunderbi@80.215.138.68] has quit [Client Quit]     
07:56 < instagibbs> Chris_Stewart_5, not sure how you are confused here: "If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array."
07:56 < instagibbs> if a checksig is to fail, signatures must be false as well
07:57 < instagibbs> false aka ""
08:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
08:15 -!- laurentmt [~Thunderbi@80.215.138.68] has joined #bitcoin-core-dev     
08:16 -!- laurentmt [~Thunderbi@80.215.138.68] has quit [Client Quit]     
08:18 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
08:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
08:28 < sipa> Chris_Stewart_5: it is not talking about OP_FALSE, but about a FALSE returned by checksig
08:32 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
08:45 < morcos> cfields: yeah i ran a longer test and your new branch doesn't really provide any benefit but the old one still provides a significant improvement
08:45 < Chris_Stewart_5> sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right? 
08:47 < Chris_Stewart_5> and if so, how can this fail immediately without checking the signature: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L880
08:54 < sipa> Chris_Stewart_5: see 4 lines up
09:01 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
09:02 < Chris_Stewart_5> Is the only difference between CheckSignatureEncoding & IsValidSignatureEncoding the LOW_S check & trivially passes the empty byte array as a sig 
09:10 < Chris_Stewart_5> I guess my real question is could 'F' in the examples be a LOW_S sig https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#examples
09:10 < Chris_Stewart_5> sorry HIGH_S I guess 
09:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD]     
09:23 -!- rubensayshi [~ruben@82.201.92.138] has quit [Ping timeout: 244 seconds]     
09:31 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:35 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
09:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
09:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:53 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Read error: Connection reset by peer]     
09:57 -!- MarcoFalke [~marco@host43-2.natpool.mwn.de] has joined #bitcoin-core-dev     
10:05 -!- MarcoFalke [~marco@host43-2.natpool.mwn.de] has left #bitcoin-core-dev []     
10:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
10:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:10 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:48 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 252 seconds]     
10:50 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
10:56 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has joined #bitcoin-core-dev     
11:01 < achow101> meeting?
11:01 < CodeShark> Meeting time?
11:01 < jcorgan> whew, though i borked up the time zone again
11:01 < jcorgan> *thought
11:01 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
11:02 < jonasschnelli> here
11:02 < kanzure> hi.     
11:02 < BlueMatt> oh, hey
11:02 < instagibbs> hello
11:02 < petertodd> hi     
11:03 < michagogo> o/     
11:03 < cfields> grr, flaky inet. here now.
11:03 < michagogo> Wait, isn't it in an hour?
11:03 < michagogo> Or is the time defined in UTC?
11:03 < achow101> michagogo: UTC
11:03 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
11:03 < jtimon> hi     
11:04 < michagogo> Ah. I guess I've just missed them all since we switched off of DST
11:04 < jtimon> proposed topics?
11:04 < jonasschnelli> #startmeeting
11:04 < lightningbot> Meeting started Thu Nov 17 19:04:21 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:04 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:04 <@wumpus> hello
11:05 < sipa> present
11:05  * michagogo looks at wumpus's @
11:05 < CodeShark> Hi     
11:05 < jonasschnelli> No topic proposals?
11:05 < MarcoFalke_web> Short meeting, then :P
11:06 < instagibbs> ideas for account removal/replacement? I'm getting annoyed at account code :)
11:06 < sipa> can i ask a bit about shared_ptr changes?
11:06 < jonasschnelli> #topic shared_ptr
11:06 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ     
11:06 < morcos> i have a topic, i'd like tot alk about priority
11:07 < sipa> the #topic is only recognized when said by the chair, i think
11:07 < morcos> also +1 instagibbs
11:07 < jonasschnelli> I'm the chair
11:07 < sipa> oh!     
11:07 < instagibbs> sipa, better watch yourself ;)
11:07  * sipa will go stand in the corner
11:07 < sipa> so, i have a series of 3 PRs to introduce shared_ptr in more places
11:08 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9125
11:08 < sipa> #9125, #8580, #8589
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
11:09 < wumpus> I'm testing #9125
11:09 < sipa> the first i hope is a clear improvement and necessary refactor for the ones that follow (and it's 3-4% reindex performance improvement)
11:09 < gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
11:09 < jonasschnelli> Do I understand it right that one of the key benefits of the shared_ptr transition are the concurrency benefits with less locking?
11:09 < sipa> that is a potential future advantage
11:09 < BlueMatt> sipa: concept ack+1000
11:09 < wumpus> also less copying
11:09 < gmaxwell> No.     
11:09 < jonasschnelli> and less copis
11:09 < BlueMatt> to all of them
11:09 < sipa> but less copying is the immediate reason
11:09 < gmaxwell> Thats an abstract advantage of shared pointers.
11:10 < jonasschnelli> Okay.
11:10 < gmaxwell> But right avoiding copies is that it accomplishes here.
11:10 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
11:10 < jonasschnelli> So performance and memory? Right?
11:10 < sipa> the second one may be more controversial, as it affects the wallet code significantly, making CWalletTx not inherit from CTransaction anymore, and move it to a field
11:10 < cfields> sipa: is there any specific part of the first that you think needs extra scrutiny/testing?
11:10 < wumpus> sipa: YES
11:10 < sipa> wumpus: YES as in "do it" or YES as in "it's more controversial"
11:11 < wumpus> CWalleTx is pretty much the example of an abuse of inheritance
11:11 < wumpus> in OOP
11:11 < gmaxwell> wumpus: that was exactly my response.
11:11 < sipa> ok, glad you agree on that
11:11 < jonasschnelli> Yes. Also, is there a reason for the extra CMerkleTx inheritance?
11:11 < sipa> jonasschnelli: abuse of C++
11:11 < wumpus> wallettx should *contain* a line-level tx, plus metadata
11:11 < jonasschnelli> heh     
11:12 < sipa> jonasschnelli: meaning you don't need to copy the interface
11:12 < sipa> and then inlining CTxInWitness is to just simplify the code
11:13 < sipa> (which is likely a small performance regression for non-witness txn, but an improvement for witness txn)
11:13 < sipa> if no further comments on that, i'm done with the topic
11:13 < jonasschnelli> While were at it, we should also remove "main.h" and "txmempool.h" from wallet.c (slightly OT) to avoid the circular dependency.
11:13 < wumpus> no comments, i think it's the way forward
11:14 < sipa> jonasschnelli: why is that a circular dependency?
11:14 < jonasschnelli> sipa: ack
11:14 < gmaxwell> why isn't it all done and merged yet? :P
11:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds]     
11:14 < sipa> jonasschnelli: main and txmempool should not depend on wallet
11:14 < sipa> but wallet depending on main seems perfectly expected for me
11:14 < wumpus> wallet is allowed to depend on stuff in libbitcoin_server
11:14 < wumpus> just not the other way around
11:14 < jonasschnelli> sipa: have a look at https://github.com/bitcoin/bitcoin/pull/8745
11:15 < sipa> what should i see there?
11:15 < wumpus> I think we can discuss this outside the meeting? other more urgent topics?
11:15 < sipa> ah, i understnad
11:15 < jonasschnelli> Yes. Outside the meeting.
11:15 < sipa> yes, let's discuss design at another time
11:16 < jonasschnelli> morcos had the topic proposal "priority"
11:16 < morcos> Lets talk about potential for account or priority removal (2 separate topics)
11:16 < sipa> agree on topic
11:16 < jonasschnelli> #action account or priority removal
11:16 < jonasschnelli> #topic account or priority removal
11:16 < gmaxwell> lol     
11:16 < jonasschnelli> :/     
11:16 < morcos> I think luke-jr was the main proponent of keeping priority around, so if he's not here, maybe we need to postpone further discussion
11:17 < morcos> but it was my hope that we could all be in agreeement that it serves not much of a function any more
11:17 < morcos> Perhaps we can set a target for 0.15 if 0.14 is too close, but it would be nice to remove ALL of the priority code
11:17 < morcos> it would clean a lot of things up
11:17 < wumpus> I think that ship has already sailed?
11:17 < BlueMatt> morcos: ACK, but maybe 0.15
11:17 < BlueMatt> deprecate more formally in 0.14
11:18 < wumpus> I mean, we merged some stuff on the way for priority removal already
11:18 < morcos> BlueMatt: that makes sense to me
11:18 < BlueMatt> wumpus: not even eligius is doing any priority selection now...at the time maybe luke could have argued for it, but now.....
11:18 < sipa> we removed priority estimation
11:18 < jcorgan> is there any empirical data on miner behavior?
11:18 < morcos> wumpus: i mostly agree, but the removal of priority estimation was because it wasn't functional any more, so it was an easier decision
11:18 < sipa> all that is left is priority based mining, i think
11:19 < sipa> if it serves no function (and maybe we need a bit more data on that), it should be equally easy imho
11:19 < gmaxwell> I agree, I think any desire to keep it around could be answered by intelligent automatic use of fee delta. But this is going to get rehashed with luke later anyways. I think it's likely that everyone who regularly attends the meetings except luke agrees.
11:19 < morcos> there is also the free transactoin and rate limiting code
11:19 < wumpus> users can still set prioritizetransaction
11:20 < achow101> does priority estimation even work? estimatepriority just gives me -1 regardless
11:20 < sipa> achow101: priority estimation is removed
11:20 < morcos> achow101: thats why it is removed for 0.14
11:20 < sipa> achow101: the RPC remains for backward compatibility, but is a stub
11:20 < gmaxwell> jcorgan: some had been collected in the past when it was defaulted to off.  general result is that its not used ~anywhere anymore.
11:20 < wumpus> so if prioritization on some criterion that is not fee it can still be implemented outside of bitcoind
11:20 < morcos> it works, its just correctly telling you that no priority is high enough to get you mined quickluy
11:20 < achow101> ah, i see
11:21 < wumpus> heh     
11:22 < morcos> back in a couple min
11:22 < jtimon> so I thought we were waiting on 0.14 for removing the priority, now we wait for 0.15?
11:22 < wumpus> is there any reason to hurry?
11:22 < sipa> jtimon: there seem to be at least 4 components to "removing the priority", i'm not sure they all need to happen simultaneously
11:23 < sipa> (rpc, estimation, mining, relay)
11:23 < jtimon> wumpus: no, any reason to wait ?
11:23 < wumpus> I'm sure no one is really waiting for it to be removed, it can be removed part by part and 0.15 is a fine target
11:23 < gmaxwell> relay is the only one I really care much about, because it currently causes bandwidth wasting relaying around junk that won't get mined.
11:23 < jtimon> if people want to work on that, I don't see why they should wait
11:23 < wumpus> jtimon: there are always other "priorities"
11:24 < MarcoFalke_web> Can we disable relay by default for .14?
11:24 < jonasschnelli> ack on DEFAULT_RELAYPRIORITY = false; for 0.14
11:25 < gmaxwell> I'd support that, if we don't go further.
11:25 < sipa> agree
11:25 < MarcoFalke_web> What do you mean with "go further"?
11:25 < wumpus> disabling by default always makes sense as a first step
11:25 < gmaxwell> MarcoFalke_web: remove the code entirely.
11:25 < MarcoFalke_web> #action DEFAULT_RELAYPRIORITY = false; for 0.14
11:25 < wumpus> even if you rip out the code two days later...
11:26 < jtimon> ok, I see, disable for 0.14 first what you want to remove for 0.15, that makes sense
11:26 < sipa> ok, account removal?
11:26 < MarcoFalke_web> next topic
11:26 -!- cannon-c [~user@173.218.29.81] has joined #bitcoin-core-dev     
11:26 < morcos> wait i'm confused
11:27 < gmaxwell> uh oh.
11:27 < morcos> what are the proposed changes to relay
11:27 < morcos> that priority doesn't let you skip the rate limiting
11:28 < morcos> ok nm, ignore me.  we are proposing that you always have to have minrelaytxfee
11:28 < gmaxwell> Yes.
11:28 < jonasschnelli> #topic "account removal"
11:28 < morcos> i don't think thats going to help too much with junk, but agree it would be good change
11:28 < gmaxwell> also, the help text for relaypriority is wrong/confusing. :P
11:28 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
11:29 < MarcoFalke_web> I think we already have a pull open for this #7729
11:29 < morcos> account removal is more tricky
11:29 < wumpus> so I proposed a label API to replace accounts at the start of this year, it still hasn't had much review yet: https://github.com/bitcoin/bitcoin/pull/7729
11:29 < jonasschnelli> There is sill an open PR from wumpus to #7729 which is a step towards account removal
11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:29 < jonasschnelli> heh     
11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:29 < wumpus> not sure there's anything new to discuss there
11:29 < gmaxwell> "Bitcoin developers oppose accountability."
11:30 < morcos> so the idea would be we have to have labels first
11:30 < morcos> maybe for a release or two
11:30 < jonasschnelli> morcos: what would be your approach for the removal-transition?
11:30 < morcos> and then we coudl remove accounts?
11:30 < wumpus> if people are ok with that proposal I'll go forward with it, but there's always so little attention on wallet related changes, let alone deprecating features
11:30 < wumpus> morcos: yes
11:30 < instagibbs> yes labels would have to come first
11:30 < morcos> i mean i wish we could just rip them out, they're terrible.  but it seems like people still depend on them
11:30 < gmaxwell> I think I had just managed to miss 7729.
11:30 < gmaxwell> Doing both lavels and accounts means more breaking API changes, no?
11:30 < MarcoFalke_web> wumpus: You mentioned that this may cause problems when people use the account AND label api?
11:31 < wumpus> MarcoFalke_web: there may need to be protection against that, yes
11:31 < gmaxwell> morcos: most of the time I see them mentioned, they are being used as labels.
11:31 < wumpus> MarcoFalke_web: though the same already happens if you use accounts and the GUI
11:31 < wumpus> MarcoFalke_web: and there is no protection against that either
11:31 < jtimon> can't we replace accounts with labels all at once?
11:32 < gmaxwell> morcos: and people are confused when the accounts centric behavior shows up...  or, alternatively, they're confused when they don't control "from" addresses (that they're not seperate wallets).
11:32 < jtimon> it's not like we haven't been warning against the use of accounts for ages
11:32 < wumpus> can we first *agree* on the label api?
11:32 < instagibbs> jtimon, at some point I don't think people believe the deprecated warning
11:32 < sipa> jtimon: go review 7729 (and i should do the same)
11:32 < instagibbs> we should put scary ascii art :)
11:32 < gmaxwell> so proposed action: everyone go comment on 7729.
11:32 < instagibbs> action yes
11:32 < morcos> ok, lets all read 7729 again and discuss on there
11:32 < instagibbs> ack     
11:32 < morcos> damn i type too slow
11:32 < jtimon> sipa: right
11:32 < gmaxwell> yea, it sounds great.
11:32 < instagibbs> also who uses labels that we talk to? dooglus?
11:32 < MarcoFalke_web> #action look at https://github.com/bitcoin/bitcoin/pull/7729
11:33 < jonasschnelli> Removing the accounting system entirely will be difficult (especially old wallet migration)
11:33 < wumpus> whether to rip accounts at the same time as introducing labels is for later discussion, none of this is hard to implement, but deciding what API we want is more difficult
11:33 < wumpus> jonasschnelli: no, it's not difficult at all
11:34 < wumpus> jonasschnelli: you could even keep the accounting records around and just ignore them and treat previous accounts as labels instead
11:34 < gmaxwell> ^ is what I expected.
11:34 < sipa> just the concept of 'balance of a label/account' disappears, not the ability to selectively list transactions affecting labels/accounts
11:34 < jonasschnelli> I once did it in a test branch and it took me a long time to get it right... but maybe I was overcomplicating stuff there
11:34 < MarcoFalke_web> I think dooglus use case would be covered by the new label api, but better someone ping him on the pr
11:34 < wumpus> jonasschnelli: it's mainly a matter of deleting code
11:34 < jonasschnelli> Right. I removed it with no labels migration
11:35 < gmaxwell> I expected the account->label change would mostly be a matter of getting rid of balance related functionality. And otherwise not much perhaps beyond some new label centric features. 
11:35 < sipa> jonasschnelli: i think you're overcomplicating
11:35 < wumpus> gmaxwell: yes
11:35 < wumpus> gmaxwell: and just to be claear *account* RPCs are renamed to *label*, basically
11:35 < sipa> jonasschnelli: it's literally just removing the balance RPCs, and then dropping the 'from account' field in send RPC, and renaming the rest account->label
11:35 < wumpus> yes     
11:35 < gmaxwell> (e.g. of 'obvious' additional features: multiple labels on items, being able to label a single transaction without labling any involved addresses)
11:36 < wumpus> well at first it just implements the GUI label API, which doesn't allow labeling transactions either
11:36 < wumpus> I think that's a whole different thing
11:36 < gmaxwell> yep. makes sense.
11:36 < jonasschnelli> you can label addresses but not transactions, right?
11:37 < wumpus> right
11:37 < jonasschnelli> We have a comment feature for transaction
11:37 < jtimon> isn't the move call also affected (if we still have that)?
11:37 < morcos> perhaps as an immediate step, we could more forcefully declare accounts unsupported and deprecated for 0.14
11:37 < jonasschnelli> (which is sadly not really used and exposed)
11:37 < wumpus> move will disappear jtimon 
11:37 < wumpus> please actually read #7729 :(
11:37 < jtimon> wumpus: k
11:37 < gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:37 < morcos> so that in the course of adding labels, we don't have to worry about any edge case mixing of the 2
11:37 < gmaxwell> morcos: that would be negative for the many people who use accounts as labels today, however.
11:38 < wumpus> first introduce labels
11:38 < morcos> gmaxwell: yeah but i don't mean we're actually going to change it,  i just worry that in the course of adding labels around accounts we'll give ourselves extra work, but maybe not.
11:38 < wumpus> only then I'll agree on doing anything more to deprecate accounts
11:38 < wumpus> if we don't move forward for labels, we'll stay in this state forever
11:38 < gmaxwell> I need to read the PR to comment more!
11:38 < instagibbs> 2 spooky 
11:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
11:40 < instagibbs> any other topics?
11:40 < wumpus> making more noise about removing accounts before we have a labels API will just make people (such as dooglus) panicked
11:40  * gmaxwell looks at btcdrak pining #joinmarket and contemplates ^ :P
11:41 < gmaxwell> okay, I think we should take the proposed action of everyone reading and commenting on 7729 and move to another subject.
11:41 < jonasschnelli> I guess he's afk
11:41 < wumpus> yes     
11:41 < gmaxwell> Or otherwise, we could instead engage in the age old art of completely uninformed combat.
11:42 < morcos> you want to talk about block size?
11:42 < jtimon> morcos: are you saying remove accounts before labels or just do both at the same time (to not worry about incompatibilities between the 2)?
11:42 < gmaxwell> "I haven't read 7729 but I oppose any change that causes blindness in small children!"
11:42 < petertodd> gmaxwell: I didn't read your last comment, but ACK
11:42 < jtimon> other topics?
11:42 < jonasschnelli> If there are no other topic, we could talk about "auxiliary block requests" if some are interested in it?
11:43 < jtimon> what is that?
11:43 < jonasschnelli> #9171
11:43 < gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
11:43 < gmaxwell> jonasschnelli: will that cause blindness in small children?
11:43  * BlueMatt petitions for one more review on #9075
11:43 < gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
11:43 < gmaxwell> jtimon: it provides hot and cold running blocks.
11:43 < sipa> gmaxwell: yes, through xkcd 378
11:43 < jonasschnelli> jtimon "auxiliary block requests" is a requirement for SPV
11:43 < instagibbs> BlueMatt, thanks, added to queue
11:44 < jonasschnelli> It allows you to request blocks during IBD... which not getting validated
11:44 < morcos> jonasschnelli: is there some more general description of how all that would work.  i started to look at it, but i wasn't sure what the high level design was
11:44 < instagibbs> ACK morcos I couldn't grasp immediately
11:44 < jonasschnelli> Hmm... I can write a paper?
11:45 < morcos> it doesn't have to be formal
11:45 < jonasschnelli> It's simple: you ask your node, "giveme blocks D, F, G", node downloads blocks "D, F, G" and pass it though the signals with validate=fale"
11:45 < BlueMatt> jonasschnelli: note that I'm working to remove fForceProcessing/etc from ProcessNewBlock...please do not pass the blockRequest object all the way in...
11:45 < gmaxwell> I have to admit I expirenced some groan related to "oh no, yet another block fetching modality" -- but the application of being able to on demand randomly request blocks is perfectly reasonsable.  More description would be helpful.
11:45 < jonasschnelli> It uses all the available mechanisms.
11:46 < BlueMatt> jonasschnelli: I'd kinda prefer this not call AcceptBlock at all...do we need to store the block or can we just pass to wallet?
11:46 < jonasschnelli> It just "prioritize the requested blocks"
11:46 < sipa> overall concept ack, but i think the implementation will need to change with the ongoing network processing refactors
11:46 < gmaxwell> BlueMatt: seems foolish to download blocks twice... which would happen if we didn't store them.
11:46 < BlueMatt> hum, true
11:46 < jonasschnelli> BlueMatt: Right. We could factor out the on-disk-storing part
11:47 < BlueMatt> still, would be nice to not store unless we need to
11:47 < wumpus> it needs to get the chance to store it, atl east
11:47 < gmaxwell> ^ yep.
11:47 < BlueMatt> gmaxwell: we could also use the needs-download logic in the p2p logic to dedup download
11:47 < sipa> BlueMatt: it would integrate into some callback for downloaded blocks, i would guess
11:47 < gmaxwell> Interaction with pruning seems somewhat complicated.
11:47 < BlueMatt> that way the p2p logic could decide to hand to ProcessNewBlock...or not
11:47 < wumpus> there may be further policy not to store it, e.g. based on pruning and such
11:47 < BlueMatt> gmaxwell: thats part of my concern
11:47 < wumpus> but for a full IBD you'd really want to pre-fill blocks
11:48 < BlueMatt> just seems kinda broken to have the block-processing logic process a block which it explicitly doesnt want
11:48 < gmaxwell> BlueMatt: but the main application now is a node that starts off with a spv mode wallet while it syncs up in the background.  Such nodes will likely also be pruned.
11:48 < wumpus> it will likely want it later
11:48 < sipa> i guess there should be a separation of "which blocks to download" and "which blocks to process" logic
11:48 < sipa> where the second can ask the first
11:48 < jonasschnelli> I think to make it work with pruning is not very hard... just step after step
11:48 < BlueMatt> wumpus: yes, I'm saying if we have a full-spv mode then the p2p logic should be able to not pass it to ProcessNewBlock....alternatively it can choose to do so if it thinks block-logic needs it
11:48 < wumpus> could e.g. store it for later processing
11:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:49 < wumpus> discarding by default would be stupid, at least
11:49 < BlueMatt> wumpus: sure, but we have logic to figure out if we want a block or not, already
11:49 < BlueMatt> jonasschnelli: note that I have a pr to change the stuff there to deserialize blocks into shared_ptrs, so passing it over to wallet should use that
11:50 < BlueMatt> #9014, though its blocked on #9075
11:50 < gmaxwell> blocks as sharedptr, hurrah
11:50 < jonasschnelli> BlueMatt: okay. Though #9171 aims to be a wallet free PR
11:50 < gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
11:50 < gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
11:50 < gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
11:50 < sipa> BlueMatt: note that after 9125, deserializing into a share_ptr is literally just "std::shared_ptr<const CBlock> ptr; ss >> ptr; "
11:50 < BlueMatt> sipa: cool
11:52 < jonasschnelli> more topics? 8m to go.
11:53 < wumpus> *crickets*
11:53 < Chris_Stewart_5> jonasschnelli: What is the use case for that? Why request the full block if we aren't validating? 
11:53 < sipa> Chris_Stewart_5: light wallet support
11:53 < gmaxwell> Chris_Stewart_5: so we can scan it for wallet transactions.
11:53 < instagibbs> Chris_Stewart_5, you download blocks based on age of your wallet
11:53 < jonasschnelli> Chris_Stewart_5: allow receiving and sending transactions in "client" mode
11:54 < sipa> Chris_Stewart_5: the ability to use the wallet before you're fully synced
11:54 < instagibbs> "Where did my money go" <---
11:54 < wumpus> let's take basic questions to outside the meeting
11:54 < Chris_Stewart_5> This is alt solution to BIP37 then, or complementary? 
11:54 < gmaxwell> Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
11:54 < jonasschnelli> Chris_Stewart_5: its a safer solution then BIP37...
11:55 < gmaxwell> (BIP37 is also vulnerable to txn being hidden from you)
11:55 < wumpus> yes, BIP37 is a bad idea, we're not going to use it in core
11:56 < Chris_Stewart_5> Yes I understand that part, I'm trying to piece together how new spv mode will function i guess. 
11:56 < wumpus> (bad idea with untrusted peers at least, and that's the use case here)
11:56 < jonasschnelli> I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
11:56 < wumpus> any other topics?
11:56 < wumpus> the meeting is derailed
11:57 < wumpus> otherwise better to close it
11:57 < instagibbs> 3 minutes, no topics, bound to
11:57 < MarcoFalke_web> #endsmeeting
11:57 < jonasschnelli> #endmeeting
11:57 < lightningbot> Meeting ended Thu Nov 17 19:57:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:57 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.html
11:57 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.txt
11:57 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.log.html
11:57 < gmaxwell> If you end the meeting will it be classified as back on track or forever derailed?
11:57 < sipa> Chris_Stewart_5: it will just download full blocks
11:57 < achow101> will we have a meeting next week? It's a holiday in the US
11:57 < sipa> Chris_Stewart_5: and possibly remember them for validation later
11:57 < jonasschnelli> sipa: \o/ new navigation on http://bitcoin.sipa.be
11:57 < jonasschnelli> hurra
11:57 < sipa> jonasschnelli: yes, thanks to jameson lopp
11:58 < jonasschnelli> achow101: US? is that the place where they just abandoned politics?
11:58 < instagibbs> Chris_Stewart_5, I'm a new full node, wallet is a week or two old. Then you can grab the last two weeks of blocks and find payments
11:58 < achow101> jonasschnelli: yeah, that one
11:58 < instagibbs> meanwhile background you're still validating
11:58 < gmaxwell> jonasschnelli: political discussion to ##bitcoin.
11:58 < Chris_Stewart_5> What about bandwidth usage? Doesn't this require much more bandwidth? Not a concern? 
11:58 < gmaxwell> achow101: the meetings stop for nothing except almost everyone being gone at once. :P
11:58 < wumpus> gmaxwell: well I think this meeting will stay derailed no matter waht, there's no way to un-log what is logged :)
11:59 < jonasschnelli> Chris_Stewart_5: if you want to do a full validation, you need to block anyways.
11:59 < jonasschnelli> So you have some already downloaded blocks around the tip
11:59 < Chris_Stewart_5> and if you don't?
11:59 < jonasschnelli> You waste bandwidth
11:59 < jonasschnelli> which can be okay.
11:59 < wumpus> Chris_Stewart_5: it's just a different compromise
11:59 < gmaxwell> Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye. 
11:59 < jonasschnelli> either you waste pricavy or bandwidth... you can choose.
12:00 < wumpus> right
12:00 < instagibbs> even if you don't want to catch up, it's still better than bloom filters or centralized nodes
12:00 < Chris_Stewart_5> jonasschnelli: If we are removing BIP37 there isn't a choice. 
12:00 < gmaxwell> STOP
12:00 < gmaxwell> die     
12:00 < gmaxwell> okay, now that you are all dead...
12:00 < wumpus> no one is *removing* BIP37
12:00 < gmaxwell> ^ that.
12:00 < jonasschnelli> heh     
12:00 < jonasschnelli> (rofl)
12:00 < wumpus> can people stop FUDing and panicking about everything we do?
12:00 < wumpus> thank you
12:00 < achow101> panic panic
12:01 < gmaxwell> When in danger or in doubt run in terror, scream and shout.
12:01 < wumpus> we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
12:01 < wumpus> it's a big internet and you don't need to do what we do
12:01 < jonasschnelli> Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
12:01 < bsm1175321> I'm interested in making an update to BIP37 to improve light wallet security...
12:02 < gmaxwell> Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
12:02 < jonasschnelli> That's IMO impossible..
12:02 < wumpus> many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
12:02 < jonasschnelli> Maybe Bloom Filter Commitments
12:02 < wumpus> they care about privacy, though
12:02 < jonasschnelli> People are downloading a 10GB movie just to rent it for 24h... why would they not be willing to download 10GB to get financial privacy?
12:03 < sipa> bsm1175321: the only proposal i know that improves it is pretty radically different (bloom filter commitments)
12:03 < wumpus> yeah, it's simply a choice/compromise, I don't understand what is so difficult about understanding that
12:03 < jcorgan> why interpret ambiguity in a way that gives the speaker the benefit of the doubt when you can construe anything they say in the worst possible way to reinforce your pre-existing conclusions?
12:03 < gmaxwell> jonasschnelli: the filter commitment scheme can also be done without the commitments. (just loses the censorship resistance).
12:03 < bsm1175321> sipa: I'll read up.  Any links?  I'm also interested in UTXO set commitments.
12:04 < bsm1175321> Also perfectly happy with something pretty radically different.
12:04 < jonasschnelli> gmaxwell: do you have a post or paper about this?
12:04 < sipa> bsm1175321: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
12:05 < gmaxwell> jonasschnelli: the post describing the commited filters mentions that it can be done without the commitment. The only thing the commitment adds is the inability for nodes to lie about the filter content. Which is good, but it doesn't have to be delivered right away.
12:05 < bsm1175321> sipa: thanks!
12:05 < jonasschnelli> Okay. Thanks for the link sipa 
12:05 < gmaxwell> My view is that it would best be accomplished by implementing it without the commitment but in a way that would be sutiable for commitment later.
12:06 < gmaxwell> also, as an aside, cuckoo filters are likely a better data structure for this than bloom filters... but there is a big area for research here.
12:07 < bsm1175321> +1 on cuckoo filters.  Waaaay faster and the performance characteristics are more understandable (one fewer parameter)
12:08 < gmaxwell> segwit also opens up a new option, which is just fetching full blocks without witnesses.
12:09 < gmaxwell> If segwit were used exclusively the size of a full block without the witness would be about 500k... not exactly as small as a filter, but still perfectly private. 
12:10 < sipa> jcorgan: what was that a response to?
12:10 < bsm1175321> I wonder if some kind of oblivious transfer protocol would be practical for light wallet privacy?
12:11 < jcorgan> ?     
12:12 < jcorgan> oh, earlier, that was about Chris_Stewart_5 comment
12:13 < jcorgan> a snark that lost its context when too many other comments flew by while i was typing 
12:14 -!- cannon-c [~user@173.218.29.81] has quit [Ping timeout: 244 seconds]     
12:14 < bitcoin-git> [bitcoin] mruddy closed pull request #9175: WIP: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
12:15 < Chris_Stewart_5> jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)  
12:15 < bsm1175321> e.g. http://percy.sourceforge.net/
12:21 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 248 seconds]     
12:28 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
12:30 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
12:30 < meownow> hi all
13:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]     
13:02 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]     
13:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
13:24 < bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/a8b2a82618be...9346f8429957
13:24 < bitcoin-git> bitcoin/master e2e069d Matt Corallo: Revert "RPC: Give more details when "generate" fails"...
13:24 < bitcoin-git> bitcoin/master 7c98ce5 Matt Corallo: Remove pfrom parameter from ProcessNewBlock...
13:24 < bitcoin-git> bitcoin/master ae22357 Matt Corallo: Replace CValidationState param in ProcessNewBlock with BlockChecked
13:24 < bitcoin-git> [bitcoin] sipa closed pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (master...net_processing_4) https://github.com/bitcoin/bitcoin/pull/9075
13:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
14:03 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
14:09 < meownow> main.cpp is the best place to start in terms of trying to understand the source code, correct?
14:10 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
14:11 < MarcoFalke_web> Carefully reviewing pull requests is the best place to start in terms of trying to understand the source code :P
14:14 < meownow> ok, will do that then!
14:15 < MarcoFalke_web> #9142 looks ready for merge.
14:15 < gribble> https://github.com/bitcoin/bitcoin/issues/9142 | Move -salvagewallet, -zap(wtx) to where they belong by jonasschnelli · Pull Request #9142 · bitcoin/bitcoin · GitHub
14:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
14:38 < meownow> could someone do an ELI5 for the debate that occurs RE this pull request? i kind of get it but at the same time am a bit confused
14:38 < meownow> oops, this pull request: https://github.com/bitcoin/bitcoin/pull/63
14:39 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
14:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:41 < sipa> meownow: it was later proposed as a BIP, and implemented in #707
14:41 < gribble> https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
14:46 < meownow> ty will check that out
15:12 < jtimon> sipa: another related question why is https://github.com/bitcoin/bitcoin/pull/9125/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR382 necessary?
15:13 < BlueMatt> jtimon/sipa do we care about https://github.com/bitcoin/bitcoin/pull/9075/files#r88568772 ?
15:13 -!- achow101 [~achow101@unaffiliated/achow101] has left #bitcoin-core-dev ["Leaving"]     
15:18 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]     
15:19 < jtimon> BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
15:23 < jtimon> sipa: never mind, read more about move
15:24 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 246 seconds]     
15:28 < bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
15:28 < BlueMatt> sipa: do you want me to go ahead and rebase ^ on the shared_ptr serialization from 9125?
15:31 -!- Alina-malina [~Alina-mal@37.157.216.188] has joined #bitcoin-core-dev     
15:32 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute (master...Mf1611-blockFreeTxs) https://github.com/bitcoin/bitcoin/pull/9179
15:34 -!- MarcoFalke_web [8af602fa@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.250] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
15:43 < bitcoin-git> [bitcoin] mruddy opened pull request #9180: WIP: remove script checking dependency on checkpoints v2 (master...isburied) https://github.com/bitcoin/bitcoin/pull/9180
15:53 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has left #bitcoin-core-dev []     
15:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
16:04 < sipa> BlueMatt: sure
16:04 < gmaxwell> 8ad0a328584b0be86df79c4335c043b0e3bbb2a380023fec55933f357b57edae
16:05 < sipa> BlueMatt: i was wrong about only needing a std::shared_block<const CBlock> and deserializing into it. You'll also need to add a deserialize_t constructor in CBlock (whose body can just be 'ss >> *this')
16:06 < sipa> petertodd: re twitter... i was certainly aware that something like segwit could be done in an extension block like way... what was new was that it was 1) doable 2) backward compatible with old wallets
16:08 < sipa> gmaxwell: ?
16:13 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds]     
16:14 -!- AdrianG [~User@unaffiliated/amphetamine] has quit [Ping timeout: 240 seconds]     
16:14 -!- jyap [~jyap@unaffiliated/jyap] has quit [Ping timeout: 240 seconds]     
16:14 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev     
16:14 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host]     
16:14 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev     
16:16 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
16:16 -!- AdrianG [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev     
16:18 < BlueMatt> sipa: ahh...well if its more of a patch I'm gonna skip it until you have it written
16:18 < BlueMatt> and, maybe #9014 will be merged first :p
16:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
16:22 -!- Pasha is now known as Cory     
16:36 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
16:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
16:37 < sipa> cfields: i don't know whether caching the result of a dereference actually has that much of an effect... there are no concurrency guarantees on shared_ptr dereferences, so i expect the compiler to just cache the result
16:37 < sipa> through common subexpression elimination
16:46 < cfields> sipa: hmm, I'd always assumed that dereferencing required an atomic operation, but a quick look says otherwise. Makes sense, since it's guaranteed to be in scope. TIL.
16:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
16:47 < sipa> cfields: using multiple shared_ptr objects that refer to the same pointed-to object is threadsafe
16:47 < sipa> cfields: using the same shared_ptr from multiple threads is not
16:51 < jtimon> sipa: did you change 9125 or just rebase?
16:51 < sipa> jtimon: both
16:51 < sipa> jtimon: i'll comment on the changes
16:52 < jtimon> cool, I tried https://github.com/sipa/bitcoin/compare/9bc6cbc4e24ef856ad4c803226378f276acc14ff...39e832c90012db03822f61009060712a47f7f81d but did work :p
16:53 < cfields> sipa: got it, thanks
16:53 < sipa> cfields: so as long as you're not creating/destroying/copying shared_ptr's, they are effectively identical to accessing a simple pointer
16:54 < cfields> sipa: I see that now. I had a pretty fundamental misunderstanding about the overhead. That's very cool.
17:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:12 < BlueMatt> cfields: see pm?
17:14 < btcdrak> cfields: roasbeef said he's restarting those scripts
17:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]     
17:23 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has joined #bitcoin-core-dev     
17:26 < cfields> btcdrak: thanks
17:26 < cfields> roasbeef: thanks too :)
17:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
17:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:56 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:57 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Remote host closed the connection]     
18:09  * jtimon re-asks for review on https://github.com/bitcoin/bitcoin/pull/8855
18:09 < sipa> jtimon: i was looking at it right now!
18:10 < jtimon> sipa: cool, but you're the one who already looked at it :p it was for the others
18:11 < jtimon> I mean, I'm definitely interested in kowing if the nits are solved
18:11 < jtimon> knowing
18:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
18:20 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
18:20 < roasbeef> hmm, chjj and I seem to be encountering some odd behavior with segwit enabled core nodes on testnet: they aren't including witness_tx inv's in their getdata's when fetching transactions, so they fetch witness output spending transactions without the witness data (though the service bit is set). this should cause an immediate rejecvt due to the clean-stack rules, but they keep accepting the txns, sending a delayed reject minutes afterwards
18:26 < sipa> roasbeef: they send MSG_TX getdatas instead of MSG_WITNESS_TX ?
18:27 < roasbeef> sipa: yeh
18:27 < chjj> sipa: yes. we have witness service bits, so do they. they repeatedly request our witness txs as non-witness.
18:27 < roasbeef> the delayed reject is nonstd-script-verify due to empty witness
18:27 < roasbeef> this then repeats as they aren't added to the reject cache
18:28 < chjj> sipa: seems to be both 13.0 and 13.1 nodes
18:29 < sipa> chjj, roasbeef: thanks, looking
18:30 < roasbeef> hypothesis: these nodes have been online since before segwit activated on testnet, and somehow the service bit they check isn't the most up-do-date version within GetFetchFlags
18:31 < sipa> found bug: getdatas of transactions sent in response to received transactions with missing inputs are always MSG_TX
18:31 < roasbeef> ahh yeah he's generating  really long chain of multi-sigs
18:32 < roasbeef> a really* 
18:32 < chjj> oh, haha
18:32 < chjj> yeah, 3k nested transactions
18:32 < chjj> yeah, that would do it. potential dos vector found i guess. i should spam the network more often. :)
18:33 < sipa> thank you so much
18:33  * roasbeef giggles
18:34 < gmaxwell> yea, thats an issue. 
18:35 < gmaxwell> We just added the orphan fetching in 0.13, so it won't work with witness txn. Considering that we've managed to go this long without having that orphan fetching at all, the world won't end. But that'll be good to get fixed in 0.13.2.
18:35 < gmaxwell> chjj, roasbeef thanks for finding that!!
18:36 < sipa> what do you mean by 3k nester transactions? if that's the length of the chain, we won't ever accept that into the mempool
18:36 < gmaxwell> chjj: I don't know what 3k nested txn means, but we won't take an unconfirmed chain longer than 25 in the mempool.
18:37 < chjj> gmaxwell sipa: no problem. we were sitting here for the past hour dumbfounded. glad we figured it out here.
18:37 < roasbeef> he means that he's generating a really long chain, they accept up to 25 (or reject them), but then the remainder are sent but at that point they're have orphan inputs from their PoV
18:37 < chjj> sipa: yeah, but it's a bunch of orphans. too-long-mempool-chain isn't checked for those i guess.
18:38 < gmaxwell> yea, doesn't really check any of the consistency, orphan pool is mostly a big bag of transactions.
18:38 < gmaxwell> And the 'fetch missing parents' is really just treating the orphan transaction like an implicit inv.
18:39 < chjj> yeah
18:39 < chjj> i was just signing a bunch of nested txs because roasbeef wanted me to. he wanted some big witness blocks. :)
18:39 < roasbeef> yeh, I put him up to it ;) 
18:39 < chjj> wrote a script to endlessly sign and broadcast them
18:40 < sipa> filed an issue
18:40 < roasbeef> dope
18:42 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
18:57 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
19:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:17 -!- meownow [80366150@gateway/web/freenode/ip.128.54.97.80] has quit [Ping timeout: 260 seconds]     
19:27 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
19:28 < bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930
19:29 < BlueMatt> ^ last pull before the final main.cpp split :)
19:29 < BlueMatt> there are some minor fixes in the main.cpp split pull, but should be easy-ish to review
19:30 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev     
19:30 < BlueMatt> and they seem to be getting smaller and smaller as we go :)
19:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
19:35 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9183: Final Preparation for main.cpp Split (master...net_processing_5) https://github.com/bitcoin/bitcoin/pull/9183
19:38 < crescendo> heh, glad I reconnected in time to see that one come across.  great work, @BlueMatt
19:39 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]     
19:39 < sipa> BlueMatt: yay
19:44 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
19:54 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
19:54 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
20:10 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
20:22 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
20:29 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 250 seconds]     
20:31 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
20:37 -!- K4i7ok1d [b2c1dd75@gateway/web/freenode/ip.178.193.221.117] has joined #bitcoin-core-dev     
20:43 -!- dermoth [~thomas@43-78.162.dsl.aei.ca] has joined #bitcoin-core-dev     
20:47 < dermoth> Hi there... I'm maintaining an opensource block explorer that calculate stats such as total bitcoins in circulations and btc days destroyed... Those stats are based not only on created coins but also permanently destroyed ones.
20:47 < dermoth> Obviously there is no way to know about *all* destroyed coins, but there are obvious ways to destroy them which are factored in...
20:48 < dermoth> Is there an official place to look for what should count as destroyed coins?
20:57 < btcdrak> dermoth: there are some known unspendable addresses, like the counterparty burn, and 1bitcoineater etc. Certain type of counterparty and other type transactions which encode various messages are also known to be unspendable.
21:04 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
21:05 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has quit [Ping timeout: 256 seconds]     
21:08 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 260 seconds]     
21:09 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
21:21 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
21:30 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
21:30 < midnightmagic> dermoth: there are piles of proveable unspendable outputs, including e.g. the genesis block coinbase tx, the duplicated coinbase tx, the OP_RETURN spam, etc. As for the addresses -- the 1eater address and similar is probably not easily detected algorithmically. How can you tell for certain which addresses are constructed and which are in fact legitimate addresses.
21:30 < sipa> dermoth: i list some of them here http://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually
21:31 < midnightmagic> dermoth: Meanwhile, how do you categorize e.g. those fees which were destroyed by miner underpays, and do you want to distinguish those from the fees+reward underpay that I did (which as far as I can tell I'm the only one to do it.)
21:31 < midnightmagic> Is coin which never existed, actually destroyed?
21:32 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
21:34 < midnightmagic> "Due to various bugs and miners experimenting with code, some blocks claim less than allowed."  <-- That is very kind of you sipa. :)
21:34 < sipa> lock 124724 tried to intentionally claim 0.00000001 BTC less than allowed, but accidentally also failed to claim the fees, losing 0.01000001 BTC.
21:34 < sipa> ^- that refers to you, i think
21:35 < midnightmagic> sipa: In retrospect, if I knew then what I know now, I wouldn't have changed it--causing 0.00000001 to never have come into existence is a better way of doing it.
21:35 < midnightmagic> BlueMatt: thanks for the idea!
21:35  * midnightmagic tips hat
21:49 -!- bear13yte [187e9437@gateway/web/freenode/ip.24.126.148.55] has joined #bitcoin-core-dev     
21:59 -!- bear13yte [187e9437@gateway/web/freenode/ip.24.126.148.55] has quit [Quit: Page closed]     
22:00 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]     
22:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
22:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:11 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Ping timeout: 246 seconds]     
22:11 < dermoth> Thanks... I'm aware of how many ways coins can be destroyed... and indeed I never thought of underpay; I assumed reward+fee always matched first tx inputs (it could even have been enforced...)
22:11 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
22:12 < dermoth> I was just curious if there was an "official" list as far as stats calculations are concerned, so that everyone can compute stats the same way and more easily detect errors.
22:12 < sipa> dermoth: i think that's hopeless
22:13 < sipa> there may be 100000s or millions of BTC lost due to destroyed/forgotten/... wallets
22:13 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
22:18 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gftgfwwtiqbvxgcq] has quit [Ping timeout: 245 seconds]     
22:18 < dermoth> I know it's hopeless... between lost keys, valid address that were creates without the private side, custom scripts we have no way to verify they'll ever be usable.... That why I think there should be an official list of ways to destroy coins... I think underpay, OP_RETURN, null address, genesys/dup coinbases for a start... maybe addresses that are provably undependable (i.e. you can quickly and mathematically prove there is no private key
22:18 < dermoth> s).     
22:18 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-jskgwcvjnretzuij] has joined #bitcoin-core-dev     
22:19 < dermoth> I don't think we should start going into more complex address even if we know some of them are impossible to create as a key pair, because there is not clear limit where to stop
22:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yqdqfcolkzapzhkm] has quit [Quit: Connection closed for inactivity]     
22:23 < dermoth> BTW, I proposed a long time ago that all unspent coins after x blocks (many years) could be scavenged and redistributed to miners as a way to recycle destroyed coins (avoid inavoidable depletion) and keep miner's fee higher. For some reason ppl rejected that idea withotu much thought.
22:27 < dermoth> I think after a certain number of bitcoin cycles (210k blocks) we could scavenge all unspent coins from the oldest 210k block, put them in a pool and let miners siphon 1/210000th of that pool every block. At that point the older part of the chain could be completely dropped as it would no longer have any use, and pooling the fund would ensure miners get a predictable reward.
22:29 < gmaxwell> sounds like a great reason to refuse to mine peoples' transactions near that boundary.
22:29 < gmaxwell> You might want to assume less about what people have given thought to and haven't.
22:30 < dermoth> well that is definitively a good point
22:30 < rabidus> you would kill the "store of value" property of bitcoin
22:30 < dermoth> and it wasn'T the reason given back then
22:30 < rabidus> if i would need to move my voins from year to year just to ensure that i own them
22:32 < dermoth> rabidus, what's wrong with that? but yeah, gmaxwell's point is quite an issue...
22:32 < rabidus> if i might lose my coins just because i didn't move them, it is not very good store of value.
22:35 < dermoth> right now these tx would be prioritized already... I guess the only way would be to add even further priority (ex no count toward block size, aggressive p2p forwarding...) and a system to reject blocks that include less than a specific % amount of the pool os these tx'es... And now I could understand why we wouldn'T want that
22:37 < gmaxwell> "would be prioritized already" huh?
22:37 < dermoth> if you know after how long you need to resend the coins, there's not excuses to loose them. I was thinking at least 10+ years before they would drop anyway
22:38 < dermoth> tx that moves very old coins are prioritized aren't they?
22:38 < dermoth> priority = sum(input_value_in_base_units * input_age)/size_in_bytes
22:38 < rabidus> i love to put my bitcoins into trezor, and forget it into safe or somewhere, just to be found for my grand children after 20 years
22:39 < rabidus> oops, it's empty.
22:39 < dermoth> which - another think - I think tx with less outputs than inputs should be prioritized too, since they help reducing the utxo size
22:40 < dermoth> or to find that tour trezor's no longed functional, and your paper backup's ink washed out
22:42 < sipa> dermoth: there is only one rational prioritization rule, and that's fee per byte
22:42 < sipa> in the past, a few policies have existed that permitted old/larger coins, but they're no longer used by miners
22:42 < luke-jr> some miners still use them
22:42 < gmaxwell> jonasschnelli: the coin control gui sorts amounts lexographically!
22:43 < sipa> dermoth, rabidus: also, please take this to #bitcoin
22:43 < dermoth> sipa, don't you think at equal size a tx that reduce the node's uxto size should have hither priority than one that increase it?
22:43  * luke-jr thinks right now they sort by txid in that scenario
22:43 < dermoth> yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
22:44 < sipa> dermoth: yes, i think they should. but the only way to make that happen is by having consensus rules that make that strategy actually rational for miners to follow
22:44 < sipa> dermoth: which segwit improves upon (but not enough, imo)
22:47 -!- Alina-malina [~Alina-mal@37.157.216.188] has quit [Changing host]     
22:47 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
22:47 < luke-jr> or miners just decide to do the better thing
22:51 < sipa> luke-jr: we should build a system that incentivizes the right behaviour, not just hope for it
22:51 < jonasschnelli> gmaxwell: my CoinControl sorts it per value per default
22:52 < jonasschnelli> On which column do you have the "sort arrow"?
22:52 < luke-jr> sipa: protocol changes need consensus. we can't force them on people. but it only takes good willed miners to use pro-Bitcoin policys.
22:54 < jonasschnelli> gmaxwell: Qt persists the last sort order and column.
22:54 < sipa> luke-jr: if we're going to depend on miners beibg the judges of good and bad, i'd rather remove PoW, give them identities, and hold them accountable
22:55 < luke-jr> that would also be a protocol change.
22:55 < luke-jr> also, this isn't a matter of dependency
22:56 < luke-jr> the system doesn't fail if miners choose bad policies. it just works better if they choose good ones.
22:56 < luke-jr> and a better working system makes their bitcoins more valuable, so arguably it's already incentivised
22:58 < sipa> in the same way that a central bank is incentivised to not destroy a country's economy
23:00 -!- dermoth [~thomas@43-78.162.dsl.aei.ca] has quit [Read error: Connection reset by peer]     
23:00 < sipa> anyway, probably off topic here
23:00 < luke-jr> all incentives come down to value anyway
23:01 -!- dermoth [~thomas@43-78.162.dsl.aei.ca] has joined #bitcoin-core-dev     
23:01 < luke-jr> eg, it would be pretty stupid for miners to fill blocks with 100% super-high-fee spam for months on end, if it meant their rewards devalued to zero at the same time
23:05 < gmaxwell> jonasschnelli: if I click "amount" it swaps ascending and decending order, but the sort is not numeric.
23:05 < gmaxwell> e.g. it goes 1 10 2. 
23:06 < jonasschnelli> gmaxwell: Ah.. I see your point...
23:06 < jonasschnelli> gmaxwell: strange... works on my end.
23:06 < gmaxwell> hm. qt difference perhaps?
23:07 < jonasschnelli> 1 2.4 9 10 25
23:07 < jonasschnelli> I'm using Qt5.7
23:07 < jonasschnelli> Testing now on 5.6
23:09 < jonasschnelli> Also works with Qt5.6.1 (gitian)
23:09 < jonasschnelli> (OSX)
23:11 < gmaxwell> 5.4.2 here. okay, well if it's just me then I won't worry about it!
23:11  * jonasschnelli booting up Ubuntu
23:14 < gmaxwell> Unrelated, I think the GUI interface that says "N hours behind" is sometimes misunderstood to mean that it will take N hours to catch up.
23:14 < jonasschnelli> gmaxwell: Bug confirmed on Ubuntu with master built with gitian Qt5.6.1
23:15 < gmaxwell> \O/     
23:15 < jonasschnelli> though... probably an upstream bug.
23:15 < wumpus> don't call it upstream bug too soon, qt is pretty good at sorting :p
23:15 < jonasschnelli> "probably"
23:15 < jonasschnelli> But the fact that its working on OSX and not on Ubuntu makes me think its very likely upstream
23:16 < gmaxwell> I should use the GUI more, it does a lot of things nicely.
23:17 < jonasschnelli> sortView(COLUMN_AMOUNT_INT64, Qt::DescendingOrder);
23:18 < wumpus> itemOutput->setText(COLUMN_AMOUNT_INT64, strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
23:18 < jonasschnelli> Ah... there is a hack involves.
23:18 < jonasschnelli> involved
23:18 < wumpus> eh ... :-(
23:19 < cfields> strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
23:19 < cfields> bah!
23:19 < cfields> beat me to it!
23:19 < wumpus> I somehow don't think that's the canonical way to do that
23:19 < jonasschnelli> Hey! Where is @Cozz... 
23:20 < wumpus> you shouldn't need to define extra hidden columns to get sorting right, IIRC you can give the model a separate data item that will be used for sorting
23:20 < wumpus> but yes I don't think any of us ever deeply looked at that code
23:20 < jonasschnelli> Yes.
23:21 < jonasschnelli> The hack was probably made because of the QTreeWidgetItem
23:21 < wumpus> it was not the prettiest code but works pretty well, generall
23:21 < jonasschnelli> Which maybe has some differences internally over a QTableView
23:23 < jonasschnelli> Qt code:
23:23 < jonasschnelli> bool QTreeWidgetItem::operator<(const QTreeWidgetItem &other) const
23:23 < jonasschnelli> return text(column) < other.text(column);
23:23 < jonasschnelli> :(     
23:26 < wumpus> they can be subclassed though
23:26 < jonasschnelli> Yes. Trying to do that.
23:26 < jonasschnelli> But why is it working on OSX?
23:27 < wumpus> maybe some event handling difference, causing the hidden column not to be used for sorting?
23:27 < wumpus> either that or strPad(QString::number(out.tx->vout[out.i].nValue) returns something different on different OS but that soounds unlikely.
23:28  * wumpus wonders why there's an inefficiently implemented strPad when Qt has a perfectly fine rightJustified() method on QString
23:28 < Victorsueca> morning
23:29 < jonasschnelli> hi     
23:30 < Victorsueca> how the hell does one remember so many Qt element calls?
23:31 < sipa> Victorsueca: google is your friend
23:31 < Victorsueca> yeah lol
23:31 < wumpus> use the search/grep/google whatever you prefer
23:32 < wumpus> you don't have to remember every detail, just where to find things when you need them
23:33 < sipa> exactly, you remember what things are possible, and how to use those
23:33 < sipa> you can always find the details of how to do them again later
23:33 < Victorsueca> yeah that's what I do with linux commands
23:34 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
23:35 < wumpus> jonasschnelli: most common suggestion seems indeed to be to override QTreeWidgetItem <
23:36 < Victorsueca> but when you're coding google not always brings the best way to do something for your specific case
23:36 < wumpus> oh sure there's still some skill involved
23:38 < wumpus> most important is that you're able to judge whether something is a good solution or not, so you can reject bad ones
23:41 < wumpus> jonasschnelli: so probably our tree widget item subclass should have int64 fields for the amount and date, which are used for sorting instead of the text in the column, for those columns
23:41 -!- K4i7ok1d [b2c1dd75@gateway/web/freenode/ip.178.193.221.117] has quit [Ping timeout: 260 seconds]     
23:41 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
23:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mjfvdulwkiavzwmt] has joined #bitcoin-core-dev     
23:47 < Lauda> https://bitcoincore.org/en/segwit_adoption/ minor mistake here:"(note signalling will start around the 20th November 2016) "
23:48 < sipa> it'll start about an hour from now
23:49 < gmaxwell> Lauda: yea, that was the projection at the time the text was written.
23:49 < Lauda> Indeed. 8 blocks left
23:52 < jonasschnelli> wumpus: yes. Working on a fix. Though, it not to most important thing. :)