--- Day changed Thu Feb 11 2016
00:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:10 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:bd7d:1c91:2a8d:9bd7] has quit [Ping timeout: 260 seconds]
00:24 -!- MazrimTaim [~mazrimtai@ool-18ba8bdf.dyn.optonline.net] has joined #bitcoin-core-dev
00:31 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:46 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds]
00:47 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
00:52 -!- Netsplit *.net <-> *.split quits: Thireus, midnightmagic
00:56 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
00:58 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
01:07 < GitHub88> [bitcoin] jmacwhyte opened pull request #7514: Fix IsInitialBlockDownload for testnet (master...fixisinitialblock) https://github.com/bitcoin/bitcoin/pull/7514
01:28 -!- qlql [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
01:50 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
01:50 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:55 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 260 seconds]
01:56 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-core-dev
01:59 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 250 seconds]
02:12 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
02:12 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
02:54 -!- adnn_ [adnn@gateway/vpn/mullvad/x-ejtzabppdwjizjoj] has joined #bitcoin-core-dev
02:54 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 264 seconds]
02:56 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has quit [Ping timeout: 256 seconds]
03:06 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
03:15 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:16 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:42 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 276 seconds]
03:43 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:05 -!- murch [~murch@p4FE389CC.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
04:33 -!- wallet42 [~wallet42@172.56.18.244] has joined #bitcoin-core-dev
04:33 -!- murch [~murch@p4FE389CC.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
04:36 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has quit [Ping timeout: 240 seconds]
04:37 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev
04:37 -!- wallet42 [~wallet42@172.56.18.244] has quit [Ping timeout: 240 seconds]
04:43 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 252 seconds]
04:48 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
04:51 -!- p15x [~p15x@58.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
04:57 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
05:16 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
05:24 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
05:30 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
05:37 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 245 seconds]
05:39 < da2ce7> it would be nice to get https://github.com/bitcoin/bitcoin/pull/7346 merged if there aren’t any further objections to it.
05:51 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
05:52 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
05:54 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
05:56 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:56 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
06:05 < sipa> wumpus: there is no release note entry for the new fundrawtransaction RPC
06:06 < wumpus> sipa: correct
06:07 < sipa> list of all new RPCs: disconnectnode, setban, listbanned, clearbanned, getblockheader, fundrawtransaction, estimatesmartfee, estimatesmartpriority, abandontransaction, importpubkey
06:07 < sipa> i forgot about most of these already...
06:08 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 248 seconds]
06:08 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
06:10 < wumpus> me too - could mention them shortly in the release notes, for documentation they can check 'help <rpc>', the release notes are already long enough that no one will see it anyhow :)
06:11 < sipa> maybe that's a reason for having more frequent releases? *ducks*
06:12 -!- p15 [~p15@71.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 250 seconds]
06:12 < wumpus> meh, I can't take the release stress more than twice a year
06:13 -!- p15x [~p15x@58.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 252 seconds]
06:13 < sipa> that's why i duck :)
06:13 < wumpus> maybe we could appoint someone to do the hammer-people-with-deadlines part for me
06:14 < wumpus> yeah :)
06:14 < sipa> damn, there are so many release note entries that maybe they should be organized per topic
06:14 < sipa> RPC changes, wallet changes, P2P changes, policy changes
06:16 < wumpus> other people think we should sort by other criteria https://github.com/bitcoin/bitcoin/pull/7429
06:16 < wumpus> I wonder if everyone would ever agree on a sorting :)
06:17 < wumpus> I mean, sorting by category would make some sense, on the other hand e.g. not all wallet changes are of the same importance to most users
06:18 < sipa> ah, ok
06:18 -!- p15x [~p15x@111.193.165.219] has joined #bitcoin-core-dev
06:20 < wumpus> on the other hand the bottom list is already sorted by category so there is precedent
06:22 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
06:23 < wumpus> and if anyone wants to sort it this would be the time, it's unlikely there will still be major changes, well apart from 7346 but that one should be merged
06:30 < GitHub42> [bitcoin] laanwj closed pull request #7346: 0.12 release notes: Mining Policy Changes (0.12...0.12-release-notes-mining) https://github.com/bitcoin/bitcoin/pull/7346
06:30 < GitHub123> [bitcoin] laanwj pushed 6 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/772863583c35...04503f78c750
06:30 < GitHub123> bitcoin/0.12 4b8d2bc Luke Dashjr: release-notes: Cover priority changes correctly, removing mentions of possible futures
06:30 < GitHub123> bitcoin/0.12 73a0375 Luke Dashjr: release-notes: Mention possibility of priority removal in 0.13, uncertainty of priority calculation being changed back, and request community input
06:30 < GitHub123> bitcoin/0.12 d0dbb6d Luke Dashjr: release-notes: Remove suggestion to use 0.11
06:31 < morcos> heh, i wonder if i should explain what estimatesmart does?  nah..
06:31 < sipa> morcos: i honestly have no clue what it does
06:32 < morcos> the idea is i might add more functionality to it in the future, so didn't want people to start depending on it yet.  but the main advantage is if you ask for an estimate at a target of N and there is no estimate, it starts incrementing N until it can give you an estimate and then returns the target it was able to find an estimate at as well
06:33 < morcos> but it also does a couple other smart things like recognize mempool limiting min fees
06:36 < morcos> estimatesmart is what all the internal code uses now, but didn't want to break functionality that depended on the old API
06:42 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
06:53 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
06:57 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:58 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds]
07:01 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
07:07 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
07:07 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
07:08 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer]
07:09 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
07:11 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
07:18 -!- halovast__ [8abe2007@gateway/web/freenode/ip.138.190.32.7] has joined #bitcoin-core-dev
07:21 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:36 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev
07:42 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:42 -!- p15x [~p15x@111.193.165.219] has quit [Ping timeout: 264 seconds]
07:50 < GitHub71> [bitcoin] laanwj opened pull request #7517: test: script_error checking in script_invalid tests (master...2016_02_test_script_errors) https://github.com/bitcoin/bitcoin/pull/7517
07:51 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has quit [Ping timeout: 240 seconds]
07:53 -!- Prattler [~ttttt@78.60.12.33] has joined #bitcoin-core-dev
07:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-tbjdntsyisiyoteo] has quit [Ping timeout: 276 seconds]
08:05 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:07 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
08:09 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:09 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:10 -!- adam3us1 [~Adium@88-105-22-199.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
08:12 -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Ping timeout: 276 seconds]
08:15 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 245 seconds]
08:15 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
08:15 < Luke-Jr> wumpus: What kind of backwards compatibility issues do you mean for https://github.com/bitcoin/bitcoin/pull/7510 ?
08:16 -!- zooko` [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer]
08:16 < wumpus> the whole shitload of ways that various ways of setting settings can interact
08:16 < wumpus> and whether the right one takes precedence
08:17 < wumpus> we don't have any tests for that, certainly not for the GUI
08:18 < Luke-Jr> I got the param. interaction part, it's the backward compatibility part I don't understand.
08:19 < wumpus> that settings set through QSettings in a previous release still work
08:20 < Luke-Jr> k
08:20 < wumpus> I agree that's not necessarily a problem as long as the set of settings set through QSettings and through your mechanism is disjoint
08:20 < wumpus> but I was just trying to be general because I know you won't let it stay that way
08:21 < Luke-Jr> I had no real plans to change that, actually, but you're probably right that at least some should, and regardless testing QSettings seems reasonable
08:21 < wumpus> I think gui-only settings should at least stay in QSettings
08:21 < Luke-Jr> yeah, I agree with that
08:22 < Luke-Jr> wumpus: any thoughts on eliminating the enum? or is that just necessary?
08:23 < wumpus> I'm not sure. I like having an enumeration of settings, that's better than having arbitrary strings. Although something could be said for splitting GUI-only and core options.
08:23 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev
08:26 < Luke-Jr> seems like a lot of unnecessary code just to translate enumeration->string
08:26 < Luke-Jr> but I guess so far the 2 I added aren't that simple anywayh
08:26 < wumpus> the problem with the current core option handling is that it is sloppy, and part of that is due to using arbitrary magic strings everywhere
08:27 < wumpus> I don't necessarily want to import that into the GUI too :-)
08:27 < Luke-Jr> hm, so maybe the solution is to use an enum everywhere?
08:27 -!- adam3us1 [~Adium@88-105-22-199.dynamic.dsl.as9105.com] has quit [Quit: Leaving.]
08:27 < wumpus> possibly, I do think the options handling needs to be revamped at some point
08:27 < Luke-Jr> perhaps that would be best off as part of the setconfig RPC idea
08:27 -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-core-dev
08:27 < Luke-Jr> since it needs a registry of params anyway
08:27 < wumpus> so that it can report misspelled or otherwise invalid options, better value checking (at init time) etc
08:28 < wumpus> exactly
08:29 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:31 < wumpus> thinking about it, a global enumeration will not actually be possible; different sub-parts of the application can have their own settings, e.g. the wallet, and need to be able to register them independently
08:33 < Luke-Jr> wumpus: a registration class can abstract the enum part?
08:34 < wumpus> ok
08:37 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-core-dev
08:37 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-wxmabpmrqhklrimy] has quit [Ping timeout: 240 seconds]
08:38 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 240 seconds]
08:38 -!- Nuief [~Nuief__@2001:1900:2104:2::86] has quit [Ping timeout: 240 seconds]
08:39 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 240 seconds]
08:39 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
08:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:43 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev
08:51 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]
08:55 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Remote host closed the connection]
08:55 -!- Nuief [~Nuief__@2001:1900:2104:2::86] has joined #bitcoin-core-dev
08:55 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:58 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-obzfosxxgrrpzzcl] has joined #bitcoin-core-dev
09:02 < GitHub129> [bitcoin] promag opened pull request #7518: [RPC] Add changeAddress option to fundrawtransaction (master...enhancement/fundrawtransaction-with-changeaddress) https://github.com/bitcoin/bitcoin/pull/7518
09:03 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
09:06 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
09:09 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
09:09 -!- halovast__ [8abe2007@gateway/web/freenode/ip.138.190.32.7] has quit [Quit: Page closed]
09:09 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]
09:21 -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.]
09:21 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
09:21 -!- zooko` [~user@50.141.118.227] has joined #bitcoin-core-dev
09:21 -!- adam3us_ [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev
09:26 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 240 seconds]
09:33 -!- drnet [~drnett@91.141.1.203.wireless.dyn.drei.com] has joined #bitcoin-core-dev
09:33 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-core-dev
09:38 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
09:45 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
09:47 -!- murch [~murch@p4FE389CC.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:50 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
09:56 -!- drnet [~drnett@91.141.1.203.wireless.dyn.drei.com] has quit [Quit: Leaving]
09:58 -!- jarret [~jarret@162.216.46.72] has quit [Ping timeout: 250 seconds]
10:01 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev
10:03 -!- Tasoshi_ [~Tasoshi@unaffiliated/tasoshi] has quit [Ping timeout: 264 seconds]
10:08 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:19 -!- murch [~murch@p4FE389CC.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
10:20 -!- zooko` [~user@50.141.118.227] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
10:21 -!- zooko [~user@50.141.118.227] has joined #bitcoin-core-dev
10:33 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
10:33 -!- s1w [~s1w@unaffiliated/someoneweird] has quit [Ping timeout: 276 seconds]
10:40 -!- s1w [~s1w@128.199.100.16] has joined #bitcoin-core-dev
10:40 -!- s1w is now known as Guest42535
10:52 < morcos> anybody want to answer a question about CWalletTx's and save me deciphering a bunch of code?  I'm trying to figure out whether there is an easy way to calculate the fee of the tx from a CWalletTx or whether it would be easy to store this information if its not currently saved.
10:52 < morcos> But the Credit/Debit stuff confuses me
10:52 -!- bityogi [~textual@66-191-180-79.dhcp.spbg.sc.charter.com] has joined #bitcoin-core-dev
10:54 < wumpus> it confuses me too
10:54 < wumpus> but the code to compute the fee should be thre already?
10:55 < morcos> what i first looked at seemed to only compute the fee if the Debit > 0 (or vice versa or something)
10:56 < Luke-Jr> someone -m -dev pls
10:56 < Luke-Jr> also -i probably etc
10:58 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 240 seconds]
11:00 < cfields> wumpus: hmm, noticed after pushing that my rc5 win doesn't match yours
11:00 < cfields> others match
11:00 < cfields> checking now
11:01 < sipa> morcos: the wallet only knows how to compute the fee for transactions where all inputs are from us
11:03 < morcos> sipa: sigh, thats going to be annoying for my feefilter code
11:03 < sipa> we could pass it down, though
11:03 < sipa> but it wouldn't work in a potential future SPV mode
11:04 < morcos> what do you mean by pass it down?
11:04 < sipa> through the signal that informs the wallet of new transactions
11:05 < morcos> and save it in the database?
11:05 < sipa> yes
11:05 < sipa> what do you need it for?
11:05 < morcos> i want to have a filter on RelayTransaction
11:06 < morcos> everywhere other than the wallet that that gets called is right after ATMP so i can return the fee from ATMP
11:06 < morcos> but the wallet resends txs
11:06 < sipa> RelayTransaction could be moved to main, where it has access to the UTXO set
11:07 -!- achow101 [~achow101@166.170.33.102] has joined #bitcoin-core-dev
11:07 < morcos> you dont' want to relook it up though everywhere.  
11:07 < morcos> maybe that would be ok for the wallet resend though
11:07 < morcos> oh, sdaftuar points out that in all the other use cases when you look it up, you'll find it in the mempool... so maybe that would be ok too
11:07 < morcos> ok i'll play around
11:11 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Max SendQ exceeded]
11:12 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
11:15 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
11:17 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
11:18 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit]
11:19 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
11:21 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
11:22 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
11:29 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
11:34 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
11:39 -!- achow101 [~achow101@166.170.33.102] has quit [Quit: Bye]
11:46 -!- adnn_ [adnn@gateway/vpn/mullvad/x-ejtzabppdwjizjoj] has quit [Read error: Connection reset by peer]
11:48 -!- bityogi [~textual@66-191-180-79.dhcp.spbg.sc.charter.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
11:54 -!- bityogi [~textual@66-191-180-79.dhcp.spbg.sc.charter.com] has joined #bitcoin-core-dev
12:00 -!- _dR [6dff5aff@gateway/web/freenode/ip.109.255.90.255] has joined #bitcoin-core-dev
12:01 -!- _dR [6dff5aff@gateway/web/freenode/ip.109.255.90.255] has quit [Client Quit]
12:03 < michagogo> cfields: can you pull my sigs? Having a PR outstanding is breaking my script
12:03 < michagogo> (I have rc5 sigs ready to push up, I think)
12:03 < cfields> michagogo: i don't see a PR?
12:04 < michagogo> Hm?
12:04  * michagogo looks
12:04 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-core-dev
12:04 < michagogo> Oops.
12:04 < michagogo> There we go
12:05 < michagogo> The problem is that my script relies on FFs to avoid things breaking
12:05 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:05 < michagogo> Which breaks things when there I try to use it multiple times before one session is fully resolved
12:06 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
12:07 < cfields> ah ok
12:07  * michagogo looks to see at what point his script crashed
12:08 < cfields> michagogo: rc5 sigs would be great when you've got them. wumpus and i have a mismatch
12:08 < cfields> i re-ran and got the same result as before
12:08 < michagogo> cfields: #301
12:08 < cfields> perfect, thanks. checking.
12:09 < GitHub175> [bitcoin] maaku closed pull request #6564: BIP-112: Mempool-only CHECKSEQUENCEVERIFY (master...checksequenceverify) https://github.com/bitcoin/bitcoin/pull/6564
12:09 < michagogo> The builds all finished, it just crashes out (set -e) on the git stuff, the first line of it being git pull --ff-only upstream master
12:09 < cfields> grr, you and wumpus match, mine's different
12:11 < wumpus> strange. Need me to upload any of the files?
12:11 < cfields> wumpus: comparing now to see what broke. thanks :)
12:11 < cfields> weird though, i used the same script as always
12:12  * helo chuckles
12:12 < wumpus> I also used the same script and base image as for all other 0.12.0 rcs
12:13 < wumpus> huh, I'm getting tons of non-final transactions on my node, is block 397955 up to date?
12:13 < morcos> what i have
12:14 < wumpus> (I could check w/ the others but I'm lazy and going to bed)
12:19 < cfields> hmm, deps match, only the binaries differ.
12:19 < cfields> wumpus: if you're still around, an upload would be great. otherwise i'll bother michagogo for one :)
12:20 < wumpus> cfields: which one?
12:21 < cfields> wumpus: bitcoin-0.12.0-win64.zip please
12:21 < wumpus> ok
12:23 < wumpus> cfields: https://dev.visucore.com/bitcoin/tmp/bitcoin-0.12.0-win64.zip
12:24 < cfields> wumpus: thanks!
12:24 -!- bityogi [~textual@66-191-180-79.dhcp.spbg.sc.charter.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
12:25 < GitHub160> [bitcoin] paveljanik opened pull request #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead (master...20160211_LibreSSL_compile_fix) https://github.com/bitcoin/bitcoin/pull/7520
12:27 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
12:28 -!- windsok [~windsok@45.63.59.8] has quit [Quit: No Ping reply in 180 seconds.]
12:29 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev
12:29 < wumpus> <wumpus> huh, I'm getting tons of non-final transactions on my node, is block 397955 up to date? <- never mind, I was confused, I'm logging reject messages from *other* nodes, and some of them are rejecting the transactions I relay with non-final
12:30 < wumpus> all probably pre-0.12 versions that still request transactions during IBD 
12:33 < sdaftuar> i think 0.12 also requests transactions during IBD if i remember right
12:34 < wumpus> ok, I was pretty sure there was a pull to change that, but I may be confused
12:34 < sdaftuar> it's in master, just missed the 0.12 cutoff i think
12:34 < wumpus> cfields: btw midnightmagic doesn't get windows gitian build to work for 0.12.0 at all https://github.com/bitcoin/bitcoin/issues/7492
12:35 < wumpus> sdaftuar: oh! ok  may make sense to label it for backport to 0.12.1
12:35 < sdaftuar> yeah that seems reasonable to me
12:35 < cfields> wumpus: hmm, more data. thanks.
12:37 < wumpus> sdaftuar: you were right https://github.com/bitcoin/bitcoin/pull/7164
12:39 < michagogo> wumpus: midnightmagic has always had weird stuff going on.
12:39 < michagogo> I don't know if anyone ever figured out what's different in his setuo
12:39 < michagogo> setup
12:42 < wumpus> michagogo: indeed
12:42 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
12:48 < morcos> sipa: what were you wondering about with regards to BIP68 and the wallet.  the previous implementation had code to indicate if your wallet txs were non-final which i removed.  but that should be quite rare as it won't end up in your mempool in the first place
12:53 < cfields> strange, i have tons of single-byte differences
12:58 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
13:07 < midnightmagic> the host is a straight Ubuntu LTS update + upgrade machine. There are KVM and LXC running alongside the gitian built. But it's not like it's some custom-rolled machine.
13:12 -!- jarret [~jarret@162.216.46.72] has joined #bitcoin-core-dev
13:16 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
13:18 < gmaxwell> Is there a strong argument against not to have the varrious pruning effects-- like unsetting node network-- not happen until pruning actually happens?   E.g. today you can't set pruning to 200GB and operate as a completely unpruned node until the history gets that large.
13:19 < paveljanik> Luke-Jr, hope everything is OK...
13:19 < paveljanik> Luke-Jr, https://github.com/bitcoin/bitcoin/commit/d5f46832de900cee0801ca40bba743c9564cccb8 where can I read more about ]AC_PACKAGE_NAME[ syntax? ;-)
13:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
13:20 -!- zooko` [~user@50.141.118.227] has joined #bitcoin-core-dev
13:21 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
13:21 -!- zooko [~user@50.141.118.227] has quit [Ping timeout: 240 seconds]
13:22 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev
13:22 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
13:22 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:25 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer]
13:25 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev
13:26 < michagogo> cfields: in what?
13:28 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:b8e2:1c9c:fe32:8ba2] has quit [Read error: Connection reset by peer]
13:33 < michagogo> gmaxwell: off the top of my head, I think you'd need to kick all your peers when you hit the limit
13:35 < michagogo> And considering some of the changes are in the form of things you can't do anymore (e.g. rescan), leaving that functionality active for a while and then suddenly turning it off with no warning could be a problem
13:35 < michagogo> IMO pruning is a big enough change that no part of it should happen without the user's explicit action
13:38 < midnightmagic> cfields: does your build completely finish? like does it build all the artifacts including the signed bins for win and osx?
13:43 -!- Prattler [~ttttt@78.60.12.33] has quit [Ping timeout: 272 seconds]
13:44 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 252 seconds]
13:44 -!- ryitpm [~ryitpm@87.121.52.41] has quit [Remote host closed the connection]
13:46 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev
13:46 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
13:47 < morcos> gmaxwell: got a privacy related question for you regarding ResendWalletTransactions
13:48 < morcos> Shouldn't your node not relay a wallet tx that your own node doesn't accept into its mempool?
13:48 < morcos> crap, this might be a regression
13:48 < gmaxwell> morcos: hm. We didn't use to. Did we manage to break that?
13:48 < morcos> before 0.12 GetDepthInMainChain was < 0 for things not in your mempool right?
13:49 < morcos> but now it is 0 unless it is conflicted?
13:49 < gmaxwell> bleh. hah.
13:49 < morcos> what do you want to do?
13:50 < morcos> it seems to me the proper fix is to test if its in your mempool and if so re-relay, and if not , re try to accept it into your mempool
13:50 < morcos> (and relay if successful)
13:50 < sipa> morcos: aw
13:51 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
13:51 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 250 seconds]
13:51 < cfields> midnightmagic: ah, i remember that problem
13:51 < gmaxwell> I believe that is the correct behavior.
13:51 < cfields> midnightmagic: long story short, nuke your gitian cache
13:51 < morcos> thats what you get when i try to find ways to avoid calculating the fee on wallet txs
13:51 < morcos> :)
13:51 < cfields> midnightmagic: it's due to not checking something that we need to check, i'll fix
13:51 < morcos> gmaxwell: but are we going to fix that for 0.12.0 ?
13:52 < gmaxwell> lets fix and see what the fix looks like?  It's a non-trivial privacy regression.
13:52 < morcos> ok, i can do it right now.
13:53 < morcos> i don' tthink its too much code, but i'm worried that it might need a bit of testing
13:53 < warren> Do we generally have an option to turn off transaction sending while allowing the wallet to create transactions?
13:54 < gmaxwell> resending is horrible for privacy period; a regression wouldn't be the _end_ of the world, but I would rather not have it.
13:54 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
13:54 < gmaxwell> warren: yes.
13:54 < gmaxwell> warren: walletbroadcast=0
13:56 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
13:59 -!- zooko` [~user@50.141.118.227] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
13:59 -!- zooko [~user@50.141.118.227] has joined #bitcoin-core-dev
14:14 < GitHub14> [bitcoin] morcos opened pull request #7521: Don't resend wallet txs that aren't in our own mempool (master...testBeforeRelay) https://github.com/bitcoin/bitcoin/pull/7521
14:15 < morcos> Ok I think this is the idea.  Not sure if you'd want it to look slightly different, was trying to keep the changes minimal.
14:15 < morcos> gmaxwell: ^
14:16 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
14:17 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
14:18 < gmaxwell> morcos: In what case is that force needed? I think for creation it doesn't attempt to relay if it can't be mempooled?
14:19 < morcos> yeah, it shouldn't do anything.  i think its safe to remove that and just use the mempool.exists() test to see if we need to try to accept it
14:20 < morcos> i'm happy to change it around a bit, but i wanted to sort of point out the two different ways this was called and emphasize that behavior is only changing in one of them
14:22 < midnightmagic> cfields: ahhh, yes thank you. I had updated, and rebuilt the gitian base image; the next was blowing everything away and starting right from scratch. I'll update the issue for that and report it fixed if that proves to be the solution.
14:22 < cfields> midnightmagic: yea, the issue is that you built the 0.12 branch before it switched to trusty
14:24 < cfields> the solution is adding the current compiler info to the dep packages hashid
14:25 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
14:26 < morcos> gmaxwell: I'm missing required locks.  Need to add those.  Want me to remove the bool?
14:27 < gmaxwell> morcos: would be a smaller diff without it.
14:27 < sipa> morcos: you can use IsTrusted, perhaps?
14:30 < morcos> sipa: you mean InMempool() ?  I can, but it locks mempool.cs even though exists locks it itself.  sigh...
14:30 < morcos> But I was referring to cs_main
14:31 < morcos> which is needed for AcceptToMemoryPool
14:31 < morcos> It looks like I'd need to lock it for the entire ResendWalletTransactionsBefore function (so its not locked after cs_wallet)
14:32 < morcos> Is that bad?
14:32 < midnightmagic> cfields: okay. if you have a PR or something I'd be glad to leave the system in a broken state and verify the fix for you
14:32 -!- zooko [~user@50.141.118.227] has quit [Ping timeout: 245 seconds]
14:32 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
14:33 < morcos> Alternatively we just skip trying to resend wallet txs that are no longer in our mempool, this would actually be most similar to old behavior i guess (although we didn't use to end up with those due to eviction beforehand)
14:33 < cfields> midnightmagic: no worries, no need to keep broken. it's easy enough to test. thanks though :)
14:33 < morcos> Also there would be this unfortunate string of ERRORS resulting from RBF replacements I think where you try to resend the old one that was RBF'ed
14:34 < morcos> Perhaps simpler to just do that then..  Check mempool.exists() and leave it at that?  better to use InMempool?
14:38 < midnightmagic> cfields: okie doke.
14:43 < morcos> gmaxwell: ok thats a much smaller diff. :)  but now if something gets evicted (or never made it in to your mempool), it will not automatically try to reaccept or rerelay, so this could be worse behavior depending on your point of view.
14:44 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
14:44 < morcos> this doesn't affect trying to reaccept wallet txs on startup though
14:46 < morcos> have to reboot, back in a few
14:46 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
14:49 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
14:50 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
14:56 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
15:01 < morcos> gmaxwell: sipa: i pushed the simple version which doesn't try to reaccpet, that would be my preference, it seems like you might not always want to automatically resend things that are no longer in your mempool for some reason.
15:01 < gmaxwell> you'll still try puting it back in on restart at least.
15:03 -!- JackH [~Jack@host-2-103-125-6.as13285.net] has quit [Ping timeout: 250 seconds]
15:03 < morcos> Yes, unless you have abandoned it.  Which seems reasonable.
15:04 < gmaxwell> my that is a smaller patch.
15:05 < morcos> I'll let you ask wumpus for an RC6
15:05 < gmaxwell> I am going to need offerings. Does anyone have a goat?
15:09 < midnightmagic> I know people who have goats!
15:11 < midnightmagic> Goats can eat poison ivy without passing it to their milk *and* will clean roadside brush like scotch broom! :-D
15:11 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Max SendQ exceeded]
15:12 -!- frankenmint [~frankenmi@c-76-115-142-189.hsd1.or.comcast.net] has joined #bitcoin-core-dev
15:15 < sipa> not sure that's worth doing another rc for
15:17 < gmaxwell> I think it would also be fine to include it in a release without RCing it, assuming we test it.
15:18 < morcos> sipa: i don't feel strongly, but i do think it would be a pretty big privacy difference
15:18 -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has joined #bitcoin-core-dev
15:19 < morcos> actually, also it'll be a network bandwidth issue
15:19 -!- frankenmint [~frankenmi@c-76-115-142-189.hsd1.or.comcast.net] has quit [Remote host closed the connection]
15:19 < morcos> everytime you have tx's evicted
15:19 < morcos> you'll periodically resend them to all your peers
15:19 < morcos> forever?
15:19 < sipa> until you abandon them, which is not in the GUI?
15:20 < morcos> correct, not in the gui
15:20 < sipa> ... i think it should be in the gui
15:20 < morcos> you're lucky its in at all, i had to fight for that
15:20 < sipa> but let's keep that for 0.12.1
15:20 < sipa> yeah, i know
15:20 < gmaxwell> I don't think it's actually a network bandwidth issue, at least not materially. If you're personally generating enough abandoned transactions... well...
15:20 < morcos> gmaxwell: its not just one persons txs.  look at it on the network scale
15:21 < morcos> all txs that are ever evicted are still locally bouncing around both inv an tx
15:22 < morcos> so right now for instance tx traffic in a period roughly equals number of nodes * number of txs in that period
15:23 < morcos> going forward it'll equal small constat * number of txs that were ever evicted  every X minutes
15:23 < morcos> sorry, not very rigorous, but you get the idea
15:23 < morcos> i might be changing my mind to think this is definitely worth fixing
15:24 -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has quit [Ping timeout: 252 seconds]
15:24 < gmaxwell> Right, -- this is a consquence of eviction generally. It isn't that bad because it's only thos which were evicted but are now placable (or do you just mean without the fix)
15:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
15:26 < morcos> yes i mean without the fix
15:28 < morcos> you could even sort of make an attack with this right by sending 1k sat/kB txs of small amounts to lots of random nodes
15:28 < morcos> then they'll do the work of rebroadcasting them all the time for you
15:28 < gmaxwell> Even on the privacy side, I was not thinking in terms of recieved. Thats a release blocker.
15:29 < morcos> oh yes, good point.  want to identify to which node an address belongs
15:29 < gmaxwell> (corner case bad behavior in a already privacy weak part of the system where only you can trigger it is one thing... where it can be remotely triggered is another) 
15:30 < morcos> sigh, eviction is complicated
15:30 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
15:30 < gmaxwell> really retransmission is a general privacy disaster. Even with this check-- if someone retransmits something you know they already sent you and should have had in their mempool: they are the origin.
15:31 < morcos> yeah actually, retransmit is kind of weird
15:32 < gmaxwell> this would be fixed if we moved more towards mempool reconciliation instead of transmission... also would be greatly improved if broadcasting was done in some private way... both things I want to work on in the not so far future... but for now, lets at least not make things worse.
15:32 < morcos> I suppose disabling that is too big a change
15:33 < morcos> There is already a manual way to do it
15:33 < gmaxwell> well you can all of this transmission it by setting walletbroadcast=0 so at least there is that.
15:35 < morcos> I don't think I'd ever realized how silly the resendwallettransactions is though.  it's emphasized by the fact that we think its better not to do it if its not in your mempool anymore.  well if its still in your mempool, why the hell wouldn't it still be in other mempools
15:35 < gmaxwell> because you've connected to different nodes. it's stull stupid.
15:35 < gmaxwell> s/stull/still/
15:36 < morcos> It seems like a simple privacy fix (even if not for this release) would be to just default that to off.  walletbroadcast=0 requires outside work of some kind.  but taking your chance with initial broadcast only is a reasonable middle ground.  shoudl at least be an option.
15:37 < morcos> anyway, ok so if we think we NEED to do something for 0.12.  what is that something?  the small change i made?  
15:37 < gmaxwell> I believe so!
15:37 < gmaxwell> (am testing it)
15:40 < Luke-Jr> paveljanik: search for autoconf/m4 manuals; admittedly, figuring out quoting is mostly trial-and-error for me
15:40 < morcos> i guess what i said before about integrating all previous evicted txs is an exaggeration of how bad it would be, because one they become conflicted they'd no longer get resent
15:41 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
15:43 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
15:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
15:49 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
15:54 -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has joined #bitcoin-core-dev
16:00 -!- frankenmint [~frankenmi@50.141.97.70] has joined #bitcoin-core-dev
16:00 -!- frankenmint [~frankenmi@50.141.97.70] has quit [Remote host closed the connection]
16:01 -!- frankenmint [~frankenmi@50.141.97.70] has joined #bitcoin-core-dev
16:05 -!- frankenmint [~frankenmi@50.141.97.70] has quit [Ping timeout: 240 seconds]
16:13 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
16:23 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
16:24 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
16:42 -!- zooko [~user@2601:281:8001:26aa:6483:fb26:c13:43f1] has joined #bitcoin-core-dev
16:43 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:43 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
16:45 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0/20160123151951]]
16:46 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:52 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Killed (rajaniemi.freenode.net (Nickname regained by services))]
16:53 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
16:53 -!- frankenmint [~frankenmi@50.141.97.35] has joined #bitcoin-core-dev
16:54 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
16:56 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
16:57 -!- mm_1 [bnc33@bnc33.nitrado.net] has quit [Remote host closed the connection]
16:58 -!- mm_1 [bnc33@bnc33.nitrado.net] has joined #bitcoin-core-dev
16:59 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 256 seconds]
17:03 -!- frankenmint [~frankenmi@50.141.97.35] has quit [Ping timeout: 252 seconds]
17:05 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
17:06 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
17:09 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
17:11 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:14 -!- frankenmint [~frankenmi@50.141.99.65] has joined #bitcoin-core-dev
17:16 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds]
17:18 -!- frankenmint [~frankenmi@50.141.99.65] has quit [Remote host closed the connection]
17:28 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
17:33 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 252 seconds]
17:48 -!- fkhan [weechat@gateway/vpn/mullvad/x-lqlskvnhjapevuje] has joined #bitcoin-core-dev
17:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rrmmiqojrakeklsd] has quit [Quit: Connection closed for inactivity]
18:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has quit [Read error: Connection reset by peer]
18:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has joined #bitcoin-core-dev
18:01 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has joined #bitcoin-core-dev
18:02 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 252 seconds]
18:15 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
18:16 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
18:18 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]
18:20 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:30 -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has quit [Ping timeout: 252 seconds]
18:41 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
18:47 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
18:47 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
18:56 < Luke-Jr> maybe it'd be easier to try to figure out 7521 here? [ gmaxwell morcos ]
18:56 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
18:57 < morcos> i'm here
18:57 < sipa> Luke-Jr: with or without 7521, an evicted transaction is not accepted back into the mempool
18:57 < sipa> without it, however, it does get rebroadcast
18:57 < Luke-Jr> ok, but I think that's the expected/desired behaviour
18:58 < Luke-Jr> how is it ever going to get mined if the sender/receiver don't rebroadcast it?
18:58 < morcos> If it got evicted, its not likely to ever get mined
18:58 < sipa> yes, that should be fixed
18:58 < sipa> we should retry to get it into the mempool, and when it does, rebroadcast
18:58 < sipa> but not rebroadcast despite violating your own rules
18:59 < morcos> sipa: so you don't like the fix in 7521?  or you just think we should eventually make a better one?
18:59 < sipa> morcos: i don't think it's enough, but it's an improvement
18:59 < morcos> i think its really unlikely to make it back into your own mempool 
18:59 < sipa> morcos: i think mempool pressure goes up and down
18:59 < Luke-Jr> morcos: stuck transactions are never good behaviour
18:59 < morcos> it would be much better to just abandon it and try again with a higher fee
19:00 < Luke-Jr> we don't have wallet RBF support in 0.12..
19:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has quit [Read error: Connection reset by peer]
19:00 < morcos> you don't need wallet support
19:00 < Luke-Jr> …
19:00 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-atzvnmmikqnatcuu] has quit [Remote host closed the connection]
19:00 < Luke-Jr> morcos: what you're proposing there results in transactions that are literally stuck forever and unrecoverable
19:00 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has joined #bitcoin-core-dev
19:01 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-euspmlsssclyckwf] has joined #bitcoin-core-dev
19:01 < morcos> that is what abandontransaction is for
19:01 < Luke-Jr> abandontransaction is not usable to users
19:01 < Luke-Jr> it shouldn't be encouraged, much less requied
19:02 < morcos> what about the attack i and gmaxwell described above
19:02  * Luke-Jr gets a sense we had that discussion before
19:02 < morcos> you send small very low fee txs to random addresses
19:03 < morcos> for instance if you send 1000 sat/kB txs repeatedly they'll eventually be accepted and then evicted/expired with high probability
19:03 < morcos> then the nodes you sent them to will continually rebroadcast them frequently
19:03 < Luke-Jr> 0.11 would do this too
19:03 < morcos> both contributing to a bandwidth DoS attack and compromising their privacy
19:03 < sipa> Luke-Jr: but with 0.11 you can't be certain
19:03 < Luke-Jr> sipa: ?
19:04 < Luke-Jr> 0.11 never prunes its mempool, so it will always be there
19:04 < sipa> Luke-Jr: with current 0.12, you can send a mempool command, and if the result doesn't contain the transaction, you know it's theirs
19:04 < Luke-Jr> ah
19:04 < Luke-Jr> so what sipa suggested, add to our own before rebroadcasting
19:05 < morcos> i tried that first
19:05 < Luke-Jr> if it fails, don't rebroadcast until it doesn't fail anymore
19:05 < morcos> as i mentioned on the PR
19:05 < Luke-Jr> also, how frequent is wallet rebroadcast? I thought it was some hours
19:05 < Luke-Jr> morcos: the lock shouldn't be a problem, why do you think it is?
19:05 -!- jujumax [~jujumax@host154.200-45-34.telecom.net.ar] has quit [Ping timeout: 256 seconds]
19:06 < morcos> some time in the next 30 mins
19:06 < morcos> it looks like
19:06 < Luke-Jr> still rare enough to be okay locking I think?
19:06 < Luke-Jr> (on that note, we should probably never rebroadcast to the same connection twice?)
19:06 < sipa> morcos: i wonder if rebroadcast could just call "ProcessMessage" and send a tx message to the node...
19:06 < morcos> well, my first attempt at figuring out how it would lock makes it seem like you would have to lock cs_main while you iterate through every tx in your wallet and then send the ones that need sending
19:07 < morcos> i think you guys are trying to solve for a non-existant problem
19:07 < Luke-Jr> sipa: my local hacks includes abstracting the "tx" message to a function so I can basically simulate that. maybe worth upstreaming for this
19:07 < sipa> morcos: nah, lock cs_wallet, copy the matching ones to a stack-allocated vector, unlock cs_wallet, accepttomemorypool
19:08 < morcos> if you have a very small mempool, then maybe you are right..  but at the size peoples mempools are now... if you get evicted/exprired...  you really have no business being rebroadcast
19:08 < Luke-Jr> morcos: it's not a problem because we don't have the bug you'd be introducing yet! :P
19:08 < morcos> i'd be introducting?
19:08 < Luke-Jr> morcos: right now, transactions never get stuck due to failure to rebroadcast
19:09 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
19:09 < morcos> sipa: yeah ok, i mean i agree its solvable.  but i just think its silly to solve
19:09 < morcos> i think you're trying to reaccept and rebroadcast garbage basically
19:10 < Luke-Jr> morcos: as soon as the fee rate goes up, you'd have a permanently stuck transaction
19:10 < Luke-Jr> and nothing the user could do to fix it
19:10 < sipa> morcos: there will always be transactions that are close to acceptable, and random variations push them below and above
19:11 < morcos> sipa: i think we made mempools big enough that the bottom of the mempool basically never gets confirmed
19:12 < morcos> i mean if we changed the rebroadcast interval to be once a week instead of once every 30 mins, then maybe it would make sense?  but do people really want txs that might get confirmed in a week or two
19:12 < Luke-Jr> morcos: if the mempool is filled with spam, it could be that ONLY the bottom gets confirmed ;)
19:12 < morcos> it seems like its just a cleaner UI to be be like, sorry, that tx probably didnt make it
19:13 < morcos> anywya, i certainly don't object to attempting to stick it in the mempool first
19:13 < Luke-Jr> morcos: it's only an attempt every 30 mins. if it fails for a week, it will take a week..
19:13 < morcos> i just think its a bigger change for no good reason
19:13 < morcos> so i'll let someone else make that change
19:13 < Luke-Jr> sorry, that tx probably didnt make it <-- we cannot say this until there is a recourse
19:13 < aj> Luke-Jr: how would that work? bottom of the mempool = high priority, so the middle (low fee, low pri) is never confirmed? or?
19:14 < morcos> personally i think we should turn off all wallet rebroadcast by default
19:14 < Luke-Jr> aj: middle/top gets ignored by miners with better spam filters
19:14 < morcos> i doubt it does any good
19:14 < Luke-Jr> morcos: …
19:14 < aj> Luke-Jr: how do you filter spam by anything other than fee/priority?
19:14 < morcos> once you have propagated your tx, its either going to get mined or not
19:14 < Luke-Jr> aj: some spammers use repeated patterns, for example
19:14 < morcos> trying again (especially frequently) is not a worthwhile effort
19:14 < aj> Luke-Jr: is there a blog post or something about that anywhere?
19:15 < Luke-Jr> aj: no
19:15 < aj> Luke-Jr: *arrgghhh*
19:15 < Luke-Jr> or maybe there is, but I wouldn't know because I don't spend time on blogs
19:15 < aj> Luke-Jr: s/or something/or an email thread, or a reddit post, or a paper, or.../
19:15 < Luke-Jr> morcos: right now, it is an assumption that wallets must rebroadcast if they want transactions to get mined
19:16 < Luke-Jr> morcos: any wallet that fails to do so is considered broken
19:16 < sipa> morcos: due to non-uniform policies across nodes on the network, i think rebroadcasting actually helps confirmation
19:16 < sipa> though that isn't relevant here; we still rebroadcast, just not after eviction
19:16 < aj> Luke-Jr: or a github repo with code that discriminates between spam txes?
19:17 < Luke-Jr> aj: I have a spamfilter branch that isn't entirely up to date.
19:17 < sipa> Luke-Jr: do you use it?
19:17 < Luke-Jr> sipa: spamfilter? of course
19:17 < Luke-Jr> (merged into a current branch)
19:17 < aj> Luke-Jr: !!!
19:18 < Luke-Jr> obsolete is better than nothing at all still ;)
19:21 < morcos> well like i said, i'm not opposed to trying to reaccept first and then relaying.  i just didn't personally think it was worth it.
19:24 < Luke-Jr> ok, so is someone working on this, or should I be?
19:25 < sipa> i'm having a look
20:12 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
20:14 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 276 seconds]
20:17 -!- adnn [~adnn@pool-98-116-191-141.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
20:29 < Luke-Jr> wumpus: I collected a bunch of bugfixes in master missing in 0.12 - I assume I should let them all wait for 0.12.1?
20:30 < Luke-Jr> mostly typos, the only ones I'd really consider are:
20:30 < Luke-Jr> * e54f412 peers.dat, banlist.dat recreated when missing
20:30 < Luke-Jr> * 54608c1 GUI: Disable tab navigation for peers tables.
20:38 -!- zooko [~user@2601:281:8001:26aa:6483:fb26:c13:43f1] has quit [Ping timeout: 250 seconds]
21:05 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
21:06 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
21:10 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Read error: Connection reset by peer]
21:10 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
21:10 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-euspmlsssclyckwf] has quit [Ping timeout: 250 seconds]
21:10 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
21:10 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
21:10 -!- Arnavion3 is now known as Arnavion
21:11 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 250 seconds]
21:12 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
21:19 -!- Pasha is now known as Cory
21:25 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-wieprzlbnlwwdzpw] has joined #bitcoin-core-dev
21:42 < GitHub22> [bitcoin] luke-jr opened pull request #7522: Bugfix: Only use git for build info if the repository is actually the right one (master...bugfix_gitdir) https://github.com/bitcoin/bitcoin/pull/7522
21:42 < paveljanik> Luke-Jr, I understand your attitude to it - the same applies to me :-) But during years I've got some decent knowledge of it and your notation - i.e. ]AC_...[ - with reversed parens got me 8)
21:43 < Luke-Jr> paveljanik: it's de-quoting so it's substituted
21:43 < paveljanik> I was even analysing our bitcoin_qt.m4 yesterday for missing quotes etc...
21:44 < Luke-Jr> [] are usually called brackets in English FWIW; () are parens ;)
21:45 < paveljanik> in Czech, they are round (kulaté) vs. rectangle [hranaté] parens (závorky) ;-)
21:46 < Luke-Jr> interesting
21:46 < Luke-Jr> {} are sometimes "curly brackets", but usually just "braces"
21:48 < Luke-Jr> paveljanik: can I convince you to in 20160211_LibreSSL_compile_fix do: git rebase HEAD^ --onto 3cd836c1d
21:49 < paveljanik> {složené} závorky
21:49 < paveljanik> Luke-Jr, sure
21:49 < Luke-Jr> what does složené mean?
21:50 < paveljanik> {} are slozene zavorky, where slozene means composed
21:50 < Luke-Jr> i c
21:51 < paveljanik> Luke-Jr, done
21:52 < Luke-Jr> paveljanik: thanks. that will merge cleanly to 0.12 and master both
21:52 < Luke-Jr> someone with repo push access: care to copy tags from my fork? branch-0.{9..12}
21:55 < Luke-Jr> (these are the last-common-commit for the branch and master)
21:59 < Luke-Jr> paveljanik: oh, your new LogPrintf is missing a space
21:59 < Luke-Jr> quick, before anyone else notices! :P
22:02 < paveljanik> :-))
22:04 < paveljanik> force pushed
22:10 < Luke-Jr> thanks, utACK'd
22:16 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 276 seconds]
22:22 < paveljanik> m4/autoconf is almost the same nightmare as sendmail's cf was.
22:40 < Luke-Jr> paveljanik: and somehow every attempt to replace it has been a disaster
22:56 < paveljanik> so called vendor-lock in ;-)
23:09 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
23:11 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
23:30 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
23:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:57 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 252 seconds]