12016-02-05T00:04:21  *** dcousens has quit IRC
  22016-02-05T00:21:50  *** Evel-Knievel has quit IRC
  32016-02-05T00:25:17  *** Evel-Knievel has joined #bitcoin-core-dev
  42016-02-05T00:26:55  *** arubi has quit IRC
  52016-02-05T00:43:56  *** Evel-Knievel has quit IRC
  62016-02-05T00:44:03  *** Evel-Knievel has joined #bitcoin-core-dev
  72016-02-05T00:56:06  *** frankenmint has joined #bitcoin-core-dev
  82016-02-05T01:00:32  *** frankenmint has quit IRC
  92016-02-05T01:08:28  *** AaronvanW has quit IRC
 102016-02-05T01:09:11  *** AaronvanW has joined #bitcoin-core-dev
 112016-02-05T01:30:29  *** frankenmint has joined #bitcoin-core-dev
 122016-02-05T01:43:20  <cfields> michagogo: hmm?
 132016-02-05T01:49:47  *** randy-waterhouse has joined #bitcoin-core-dev
 142016-02-05T01:50:13  <cfields> gitian builders: sigs for rc3 have been pushed
 152016-02-05T01:51:44  <cfields> a few extra +1s from Windows testers would be great. rc3 switches us to a new cert using sha2, in order to comply with Microsoft's new rules this year
 162016-02-05T01:52:09  *** belcher has quit IRC
 172016-02-05T01:58:24  *** Ylbam has quit IRC
 182016-02-05T01:59:49  <gijensen> I upgraded from 0.12RC2 to 0.12RC3, now bitcoind crashes seemingly at random during a reindex. Here's the crash error and debug.log tail: https://pastee.org/th29d any ideas?
 192016-02-05T02:00:36  *** AaronvanW has quit IRC
 202016-02-05T02:12:00  <gijensen> I'll just open an issue
 212016-02-05T02:20:00  *** p15 has joined #bitcoin-core-dev
 222016-02-05T02:23:11  * zooko looks at https://pastee.org/th29d
 232016-02-05T02:23:12  <zooko> gross.
 242016-02-05T02:24:28  *** p15 has quit IRC
 252016-02-05T02:24:49  *** bityogi has quit IRC
 262016-02-05T02:25:53  *** bityogi has joined #bitcoin-core-dev
 272016-02-05T02:32:33  *** p15 has joined #bitcoin-core-dev
 282016-02-05T03:03:48  *** jtimon has quit IRC
 292016-02-05T03:11:28  <wumpus> despite it probably being a false positive, the lock usage in the network code is pretty gross in places, cfields how's the net rework going? :)
 302016-02-05T03:11:55  <cfields> heh
 312016-02-05T03:12:12  <cfields> wumpus: i've been distracted by segwit for a few weeks, but i got back to cleaning it up yesterday
 322016-02-05T03:13:36  <wumpus> cfields: ok, good to hear
 332016-02-05T03:23:15  <wumpus> I have trouble parsing *which* locks are conflicting from that log message though. It's supposed to detect A->B  B->A lock conflicts, but it looks like, except cs_main the two sequences have nothing in common?
 342016-02-05T03:23:54  *** bityogi has quit IRC
 352016-02-05T03:29:31  *** brg444 has joined #bitcoin-core-dev
 362016-02-05T03:32:26  <PRab> cfields: With the new windows cert, the email address is unknown.
 372016-02-05T03:32:51  <PRab> The old one was hello@bitcoinfoundation.org
 382016-02-05T03:33:13  <PRab> I don't think its a problem, just different.
 392016-02-05T03:34:11  <wumpus> doesn't seem like an issue, unless it prevents it from validating
 402016-02-05T03:34:49  <PRab> Also, if the point of going to a new cert was to use sha2, I'm not sure if it worked. When I bring up the cert, I still see "COMODO SHA-1 Time Stamping Signer" as the Countersignature.
 412016-02-05T03:36:36  <PRab> For good news, rc3 just passed my super simple smoke test. (It installed and launched without issue)
 422016-02-05T03:37:06  <wumpus> ouch! But seems that's the name of the signer, maybe COMODO didn't change that. Is there a direct way to check the algorithm?
 432016-02-05T03:37:19  <cfields> PRab: the rules are... complicated.
 442016-02-05T03:37:20  <PRab> checking...
 452016-02-05T03:38:06  <cfields> our new cert is sha256. From what i gather, for compat, best bet is still using an actual sha1 digest for the payload, and sha1 for the timestamp
 462016-02-05T03:38:49  <PRab> gotcha. I'm just poking around the various View Certificate pages and see a pretty good mix of sha2 and sha1.
 472016-02-05T03:39:19  *** xiangfu has joined #bitcoin-core-dev
 482016-02-05T03:39:37  <wumpus> so it uses sha256 only for the value to sign. Doesn't seem much safer if the cert still contains sha1 hashes, but okay, if it makes microsoft happy
 492016-02-05T03:40:12  <cfields> PRab: yes. for the most part, sha1 is still fine "until pre-image attacks are possible". It's the cert's algo that matters.
 502016-02-05T03:40:26  <PRab> For example, on the cert the "Signature hash algorithm" is sha256, but "Thumbprint algorithm" is sha1.
 512016-02-05T03:40:29  <cfields> wumpus: heh, you'd think. the actual signed value can still be md5 even
 522016-02-05T03:40:38  <wumpus> (may be easier to generate a collision on the cert than on the payload or timestamp)
 532016-02-05T03:40:42  <wumpus> right
 542016-02-05T03:40:56  <PRab> Gotcha. Well from my point of view, it installed without any warning on Win 7 64bit.
 552016-02-05T03:41:44  <cfields> wumpus: i assumed the idea was that if collisions became possible, you can always re-sign yourself. But if your cert is vulnerable, you're screwed.
 562016-02-05T03:42:49  <cfields> *re-sign with a stronger hash
 572016-02-05T03:47:16  <wumpus> but, seems to me, the idea of win7 forcing the hash algo change is to preempt abuse by stopping to use an algorithm that may be compromised in the near future. If you need to resign you're probably too late, someone could have published corrupted executables with your name on it
 582016-02-05T03:49:07  <wumpus> anyhow, the canonical way of checking if bitcoin core executables are untampered with is by checking the GPG signature (which uses sha256), or checking the sha256 hash against the gitian signatures. The windows signing is pretty much because windows requires it.
 592016-02-05T03:49:32  <wumpus> GPG signature on SHA256SUMS.asc, that is
 602016-02-05T03:51:36  <cfields> wumpus: i think a ton of the complication comes from the fact that there's an ugly overlap in what some OS versions requre vs. what they permit
 612016-02-05T03:51:57  <cfields> ie i think winxp and maybe even win7 will flag if you use sha256 across the board
 622016-02-05T03:52:54  <cfields> eventually i just settled with what _seemed_ to be the most compatible based on what i can find, since as you said, we only do it because it's required
 632016-02-05T03:53:23  <cfields> but by all means if there's a better combination we could be using, we should do so
 642016-02-05T03:54:52  <PRab> Honestly, the level of build reproducibility and verification that bitcoin core has is so far ahead of pretty much anything else that I don't worry about it too much.
 652016-02-05T03:55:26  <wumpus> it's not completely theoretical, e.g. the Flame malware used a collided MD5 signature to pose as certified windows kernel driver. But compatibility is most important here, I agree.
 662016-02-05T03:55:47  <PRab> I'm more worried that somebody could create a signature hash collision on a windows update and mitm a windows machine.
 672016-02-05T03:58:24  <wumpus> (or did it use that to hijack windows update? I think that happened too, though I don't remember precisely. Anyhow, SHA1 isn't by far as broken yet as MD5)
 682016-02-05T03:59:02  <cfields> wumpus: either way, I'll pr a change that adds a script for signing, same as how OSX is done. That way the paramaters are in git and not something the signer can tweak arbitrarily
 692016-02-05T03:59:39  <wumpus> makes sense
 702016-02-05T04:12:26  *** Chris_Stewart_5 has quit IRC
 712016-02-05T04:20:11  <Luke-Jr> cfields: did you manage to get two? how difficult is the process?
 722016-02-05T04:44:36  *** brg444 has quit IRC
 732016-02-05T04:47:42  *** xiangfu has quit IRC
 742016-02-05T04:52:05  *** Thireus has joined #bitcoin-core-dev
 752016-02-05T05:17:01  *** Alopex has quit IRC
 762016-02-05T05:18:06  *** Alopex has joined #bitcoin-core-dev
 772016-02-05T05:25:51  *** adnn has joined #bitcoin-core-dev
 782016-02-05T05:28:22  *** adnn__ has quit IRC
 792016-02-05T05:58:34  *** arubi has joined #bitcoin-core-dev
 802016-02-05T06:26:27  *** wallet42 has joined #bitcoin-core-dev
 812016-02-05T06:52:23  *** arowser has quit IRC
 822016-02-05T06:59:57  *** arowser has joined #bitcoin-core-dev
 832016-02-05T07:07:09  *** Ylbam has joined #bitcoin-core-dev
 842016-02-05T07:10:23  *** arowser has quit IRC
 852016-02-05T07:10:45  *** arowser has joined #bitcoin-core-dev
 862016-02-05T07:11:07  *** pmienk has quit IRC
 872016-02-05T07:19:11  *** pmienk has joined #bitcoin-core-dev
 882016-02-05T07:38:30  *** wallet42 has quit IRC
 892016-02-05T07:41:23  *** wallet42 has joined #bitcoin-core-dev
 902016-02-05T07:45:06  *** Alopex has quit IRC
 912016-02-05T07:46:11  *** Alopex has joined #bitcoin-core-dev
 922016-02-05T07:53:48  *** Tasoshi has quit IRC
 932016-02-05T07:54:16  *** Tasoshi has joined #bitcoin-core-dev
 942016-02-05T08:28:58  *** adam3us has quit IRC
 952016-02-05T08:39:01  *** adam3us has joined #bitcoin-core-dev
 962016-02-05T08:44:49  *** BashCo has quit IRC
 972016-02-05T08:51:47  *** arowser has quit IRC
 982016-02-05T08:52:09  *** arowser has joined #bitcoin-core-dev
 992016-02-05T08:53:56  *** frankenmint has quit IRC
1002016-02-05T09:05:44  *** BashCo has joined #bitcoin-core-dev
1012016-02-05T09:13:43  <michagogo> cfields: one of them does 64-bit and then 32, the other is the opposite. That's mildly annoying when you're trying to gauge progress from tailing the log.
1022016-02-05T09:16:02  <michagogo> 5:51:57 <cfields> ie i think winxp and maybe even win7 will flag if you use sha256 across the board <-- Um, do we actually still support XP?
1032016-02-05T09:17:21  <wumpus> we should add the "system requirement for buildling" back in the build-unix.md, it's gone a few days and we have someone complaining you can't compile with 512MB of memory https://github.com/bitcoin/bitcoin/issues/7471
1042016-02-05T09:17:40  <wumpus> the corrent wording suggest that tweaking gcc will make it possible to compile with any amount of memory
1052016-02-05T09:18:22  <wumpus> michagogo: we've never officially dropped support for winxp, so I suppose so. I wouldn't recommend using it but as long as it is easy to support too, why not. 70% of PCs on the world probably still runs it :p
1062016-02-05T09:19:45  <wumpus> (while those tweaks are already needed to compile *with 1GB* of memory)
1072016-02-05T09:20:37  *** Guyver2 has joined #bitcoin-core-dev
1082016-02-05T09:26:55  *** frankenmint has joined #bitcoin-core-dev
1092016-02-05T09:27:41  <Luke-Jr> wumpus: Microsoft doesn't support XP AFAIK?
1102016-02-05T09:28:03  <Luke-Jr> in an ideal world, unmaintained systems would be banned from the internet :P
1112016-02-05T09:36:18  *** randy-waterhouse has quit IRC
1122016-02-05T09:38:27  <wumpus> the BOFH in me tends to agree, but realizing that'd probably mean banning all poor countries from the internet I'm not sure that's an ideal world :P
1132016-02-05T09:38:51  *** AaronvanW has joined #bitcoin-core-dev
1142016-02-05T09:41:28  <wumpus> and although Microsoft did offer a free upgrade to windows 10, that doesn't apply to XP
1152016-02-05T09:49:05  <GitHub8> [bitcoin] laanwj opened pull request #7472: rpc: Add WWW-Authenticate header to 401 response (master...2016_02_www_authenticate) https://github.com/bitcoin/bitcoin/pull/7472
1162016-02-05T09:54:51  <wumpus> ... also barring hardware which wouldn't have drivers for W10 anyway so the upgrade would be bricking
1172016-02-05T09:55:24  <wumpus> in an ideal world, they would just use some free OS
1182016-02-05T09:56:13  <Luke-Jr> :P
1192016-02-05T10:00:06  <GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/152a8216cc7b...e7eeb945cd2d
1202016-02-05T10:00:07  <GitHub69> bitcoin/master 0830552 Matt: Fix spelling: misbeha{b,v}ing
1212016-02-05T10:00:07  <GitHub69> bitcoin/master e7eeb94 Wladimir J. van der Laan: Merge #7469: net.h fix spelling: misbeha{b,v}ing...
1222016-02-05T10:00:15  <GitHub59> [bitcoin] laanwj closed pull request #7469: net.h fix spelling: misbeha{b,v}ing (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7469
1232016-02-05T10:18:12  <GitHub71> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e7eeb945cd2d...cf63d5c710ed
1242016-02-05T10:18:12  <GitHub71> bitcoin/master 7689041 mrbandrews: [rpc-tests] Change solve() to use rehash
1252016-02-05T10:18:13  <GitHub71> bitcoin/master cf63d5c Wladimir J. van der Laan: Merge #7468: [rpc-tests] Change solve() to use rehash...
1262016-02-05T10:18:22  <GitHub176> [bitcoin] laanwj closed pull request #7468: [rpc-tests] Change solve() to use rehash (master...ba-fix-rehash) https://github.com/bitcoin/bitcoin/pull/7468
1272016-02-05T10:20:01  <GitHub53> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf63d5c710ed...e7ea5db0c190
1282016-02-05T10:20:02  <GitHub53> bitcoin/master f3757a0 Jorge Timón: Consensus: Decouple pow.cpp from util.h
1292016-02-05T10:20:02  <GitHub53> bitcoin/master e7ea5db Wladimir J. van der Laan: Merge #7459: Consensus: Decouple pow.o from util.o...
1302016-02-05T10:20:11  <GitHub169> [bitcoin] laanwj closed pull request #7459: Consensus: Decouple pow.o from util.o (master...consensus-pow-from-util-0.12.99) https://github.com/bitcoin/bitcoin/pull/7459
1312016-02-05T10:21:58  *** Guyver2 has quit IRC
1322016-02-05T10:30:56  *** BashCo has quit IRC
1332016-02-05T10:34:40  *** BashCo has joined #bitcoin-core-dev
1342016-02-05T11:00:45  *** afk11 has quit IRC
1352016-02-05T11:09:54  *** grubles1 has joined #bitcoin-core-dev
1362016-02-05T11:11:27  *** gribble has quit IRC
1372016-02-05T11:11:36  *** grubles has quit IRC
1382016-02-05T11:11:36  *** bad_duck has quit IRC
1392016-02-05T11:12:12  *** arubi has quit IRC
1402016-02-05T11:12:12  *** justanotheruser has quit IRC
1412016-02-05T11:12:12  *** zxzzt has quit IRC
1422016-02-05T11:12:13  *** nOgAnOo has quit IRC
1432016-02-05T11:12:17  *** laurentmt has joined #bitcoin-core-dev
1442016-02-05T11:13:41  *** zxzzt has joined #bitcoin-core-dev
1452016-02-05T11:15:47  *** justanotheruser has joined #bitcoin-core-dev
1462016-02-05T11:16:53  *** bad_duck has joined #bitcoin-core-dev
1472016-02-05T11:19:47  *** gribble has joined #bitcoin-core-dev
1482016-02-05T11:30:45  *** adnn_ has joined #bitcoin-core-dev
1492016-02-05T11:30:51  *** arubi has joined #bitcoin-core-dev
1502016-02-05T11:32:10  *** adnn has quit IRC
1512016-02-05T11:35:25  *** adnn has joined #bitcoin-core-dev
1522016-02-05T11:35:46  *** adnn_ has quit IRC
1532016-02-05T11:46:30  *** frankenmint has quit IRC
1542016-02-05T11:55:37  *** wallet42 has quit IRC
1552016-02-05T12:18:26  *** arubi has quit IRC
1562016-02-05T12:18:57  *** fuirbob has joined #bitcoin-core-dev
1572016-02-05T12:21:49  *** arubi has joined #bitcoin-core-dev
1582016-02-05T13:29:56  *** danielsocials has joined #bitcoin-core-dev
1592016-02-05T13:35:57  *** danielsocials has quit IRC
1602016-02-05T13:38:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1612016-02-05T13:58:46  *** p15 has quit IRC
1622016-02-05T14:07:34  <GitHub16> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/996c27d1d916d41ed06fa31af9c25b8ae0be139a
1632016-02-05T14:07:35  <GitHub16> bitcoin/0.12 996c27d Wladimir J. van der Laan: doc: add PR authors to release notes...
1642016-02-05T14:14:47  *** adnn has quit IRC
1652016-02-05T14:26:48  *** zooko has quit IRC
1662016-02-05T14:35:51  *** fuirbob has quit IRC
1672016-02-05T14:38:38  *** AaronvanW has quit IRC
1682016-02-05T14:44:07  *** Chris_Stewart_5 has quit IRC
1692016-02-05T14:57:46  *** arubi has quit IRC
1702016-02-05T15:21:40  *** Rebroad has quit IRC
1712016-02-05T15:22:11  *** AaronvanW has joined #bitcoin-core-dev
1722016-02-05T15:22:12  *** AaronvanW has quit IRC
1732016-02-05T15:22:12  *** AaronvanW has joined #bitcoin-core-dev
1742016-02-05T15:24:16  *** arubi has joined #bitcoin-core-dev
1752016-02-05T15:38:48  *** gevs has joined #bitcoin-core-dev
1762016-02-05T15:47:22  *** loltastic has joined #bitcoin-core-dev
1772016-02-05T15:51:40  *** loltastic has quit IRC
1782016-02-05T15:53:30  *** dgenr8 has quit IRC
1792016-02-05T15:58:51  *** dgenr8 has joined #bitcoin-core-dev
1802016-02-05T16:03:53  *** dgenr8 has quit IRC
1812016-02-05T16:05:05  *** zibbo_ has joined #bitcoin-core-dev
1822016-02-05T16:05:13  *** instagibbs_ has joined #bitcoin-core-dev
1832016-02-05T16:07:31  *** sotisoti_ has joined #bitcoin-core-dev
1842016-02-05T16:07:54  *** BashCo_ has joined #bitcoin-core-dev
1852016-02-05T16:08:11  *** Eliel has joined #bitcoin-core-dev
1862016-02-05T16:10:26  *** dgenr8 has joined #bitcoin-core-dev
1872016-02-05T16:14:31  *** BashCo has quit IRC
1882016-02-05T16:14:31  *** instagibbs has quit IRC
1892016-02-05T16:14:31  *** Eliel_ has quit IRC
1902016-02-05T16:14:31  *** sotisoti has quit IRC
1912016-02-05T16:14:31  *** zibbo has quit IRC
1922016-02-05T16:15:22  *** zooko has joined #bitcoin-core-dev
1932016-02-05T16:17:26  *** instagibbs_ is now known as instagibbs
1942016-02-05T16:24:16  *** grubles1 is now known as grubles
1952016-02-05T16:24:33  *** grubles has quit IRC
1962016-02-05T16:24:34  *** grubles has joined #bitcoin-core-dev
1972016-02-05T16:59:30  <cfields> michagogo: ah
1982016-02-05T16:59:55  <cfields> michagogo: switching them around would be reasonable then, sure
1992016-02-05T17:00:49  <cfields> Luke-Jr: no, sorry. Didn't apply for new certs this time around, to avoid complications. Just replaced our old one with a new one without updating any info, in order to avoid the verification process
2002016-02-05T17:09:08  *** danielsocials has joined #bitcoin-core-dev
2012016-02-05T17:13:26  *** danielsocials has quit IRC
2022016-02-05T17:20:12  *** BashCo_ has quit IRC
2032016-02-05T17:44:37  *** BashCo has joined #bitcoin-core-dev
2042016-02-05T17:53:10  *** laurentmt has quit IRC
2052016-02-05T17:54:50  *** Omega-Xi has quit IRC
2062016-02-05T17:55:35  *** arubi has quit IRC
2072016-02-05T17:58:11  *** arubi has joined #bitcoin-core-dev
2082016-02-05T18:01:32  *** laurentmt has joined #bitcoin-core-dev
2092016-02-05T18:06:32  *** davec has quit IRC
2102016-02-05T18:12:23  *** davec has joined #bitcoin-core-dev
2112016-02-05T18:12:51  *** danielsocials has joined #bitcoin-core-dev
2122016-02-05T18:15:19  *** danielsocials has quit IRC
2132016-02-05T18:30:24  <Luke-Jr> cfields: oh, so it'll be BCF cert still? O.o
2142016-02-05T18:32:11  <cfields> Luke-Jr: yes. Otherwise, I was afraid it would trigger a verification of "Bitcoin Core", which of course doesn't exist as a corporate entity. That could've made the process drag on for a while, so I took the easy route this time and just fixed the sha256 issue, leaving all else the same
2152016-02-05T18:33:56  <Luke-Jr> i c
2162016-02-05T19:12:17  *** raedah has joined #bitcoin-core-dev
2172016-02-05T19:26:13  <morcos> gmaxwell: can i pick your brain about a couple of things?  i'm trying to think of some longer term projects to work on and had some questions
2182016-02-05T19:27:03  <morcos> #1 It appears 300M for a mempool is much more ample than I was guessing.  I think its quite unlikely we'd need a disk based mempool anytime soon.  It appears to be quite rare that we have more than few M's backed up with any fee
2192016-02-05T19:27:23  <morcos> And the rest of the mempool is just shoved full of 1 sat/kB txs
2202016-02-05T19:28:03  <morcos> Along those lines, I wonder if there is any cost to all these 1 sat/B  (sorry B, not kB)  txs bouncing around
2212016-02-05T19:28:47  <morcos> we had made the calculation that the slow decay of rolling min rate combined with the limit on free relay would be enough to keep these low
2222016-02-05T19:29:20  <morcos> but i'm not sure we fully though through all the system effects, espeically the fact that some communication happens trying to inv and send these same txs over and over
2232016-02-05T19:29:48  <morcos> Is there anybody working on measuring all of this bandwidth utilaztion to know whether its worth worrying about?
2242016-02-05T19:30:05  <gmaxwell> INV traffic on a node is already most of the bandwidth.
2252016-02-05T19:30:08  <morcos> What do we think about adding ban points of some kind for bad P2P behavior?
2262016-02-05T19:30:16  <gmaxwell> (at least when it has a full compliment of peers)
2272016-02-05T19:30:23  <morcos> IS there any reason we don't send the fee rate with the inv for txs
2282016-02-05T19:30:26  <morcos> ?
2292016-02-05T19:30:30  <gmaxwell> we do have the reject filter so that we'll not waste time rerequesting things.
2302016-02-05T19:30:41  <morcos> The reject filter gets reset after a block though right?
2312016-02-05T19:31:26  <gmaxwell> Just not in the protocol though it would be a good idea... or even better: being able to tell out peers not to even bother INVing transactions below some threshold towards us (because we'll not fetch them)
2322016-02-05T19:32:49  <gmaxwell> since INVs are already so much of the bandwidth it's more important to suppress them than to suppress sending the transaction.
2332016-02-05T19:33:05  <morcos> Also I was thinking about this idea of extending fee estimation for longer time horizons, but its not clear to me if the idea that there is usage that doesn't care about immediate confirmation is theoretical or actually exists
2342016-02-05T19:33:19  <gmaxwell> (the reason for this is that the inv is 38 bytes, but you send or recieve it from _every_ peer, while the transaction is transfered less)
2352016-02-05T19:33:33  <morcos> Yes, I think it could be reasonable to send a min threshold which expires after some time, and you coudl update it more frequently than that timeout
2362016-02-05T19:34:33  <morcos> You could even assume that each of your peers minimums decays
2372016-02-05T19:35:02  <gmaxwell> There are absolute use cases for non-immediate confirmation; but the UI and human factors (people worrying that it'll never go through) probably diminish them a lot.
2382016-02-05T19:35:13  <morcos> This of course all ties into free/priority txs.  I.e. Are we ok getting rid of FREE txs regardless of making a decision about priority.
2392016-02-05T19:36:09  <gmaxwell> that question is probably 80% of why a fee filter wasn't done two years ago. Of course one could also say "send me things with priority over X" ... but then thats more functionality to specify.
2402016-02-05T19:36:13  <gmaxwell> and implement.
2412016-02-05T19:36:55  <gmaxwell> BBIAB.
2422016-02-05T19:37:29  *** treehug88 has joined #bitcoin-core-dev
2432016-02-05T19:44:35  *** Guyver2 has joined #bitcoin-core-dev
2442016-02-05T19:56:27  * gmaxwell back
2452016-02-05T19:57:06  *** zooko has quit IRC
2462016-02-05T20:01:34  <morcos> gmaxwell: i think the simple version of just sending a feefilter threshold every X minutes and having it expire after Y minutes would work pretty well
2472016-02-05T20:01:44  <morcos> and wouldn't really change the free tx use case
2482016-02-05T20:02:01  <morcos> that is once your mempool is no longer limited and you're accepting free txs you'd just send a 0
2492016-02-05T20:02:37  <morcos> free rate limiting i suppose still might trigger excess invs...
2502016-02-05T20:02:53  <phantomcircuit> morcos, or you set the fee filter to match the mempool minimum fee amount
2512016-02-05T20:03:03  <morcos> phantomcircuit: yes thats what i meant
2522016-02-05T20:03:20  <phantomcircuit> that would actually significantly reduce bandwidth
2532016-02-05T20:05:09  <gmaxwell> morcos: is there any reason for it to expire?
2542016-02-05T20:05:20  <gmaxwell> (if you want it gone you can just send a filter of 0)
2552016-02-05T20:05:34  <morcos> gmaxwell: well the way mempool limiting works is your effective min decays
2562016-02-05T20:06:10  <morcos> so for instance imagine the case where there is a temporary huge fee boost and everyones mempool b/c limited to some relatively significant fee
2572016-02-05T20:06:19  <morcos> your own acceptance decays
2582016-02-05T20:06:27  <morcos> accentance threshold that is
2592016-02-05T20:06:41  <morcos> so you'd want your peers to decay your filter for you or just periodically update them
2602016-02-05T20:06:50  <gmaxwell> right, so after a block that cleared things back, you'd end up sending a new value. ... but sending a filter update message once per block isn't a ton of overhead.
2612016-02-05T20:07:05  <gmaxwell> The amount of decay is highly dependant on local state and policy.
2622016-02-05T20:07:24  <morcos> yeah i was thinking like phantomcircuit said you just watch your own threshold, and when it has deviated signficantly then you send an update
2632016-02-05T20:07:43  <morcos> but yeah maybe the expiry isn't needed
2642016-02-05T20:08:03  <morcos> just seemed safer
2652016-02-05T20:09:39  <gmaxwell> My intuition about the expiration is that it's another periodic counter to manage, and you have some racing around the expiration. (meaning that e.g. banning peers that send you things you don't want might be less sane)
2662016-02-05T20:09:52  <gmaxwell> One question I have:  feerate or ancestor feerate?
2672016-02-05T20:10:19  <morcos> it has to be the same as what governs admittance to your mempool
2682016-02-05T20:10:20  <gmaxwell> I guess without a way to relay a group as a group that question isn't so useful.
2692016-02-05T20:10:28  <morcos> which is feerate
2702016-02-05T20:10:46  <morcos> if that changes then yeah we'd need a way to change
2712016-02-05T20:11:35  <gmaxwell> well perhaps the way we'd change that is with a package relay. And then it's just something that offers a package, and the filter just applies to the feerate of the package.
2722016-02-05T20:11:44  <morcos> right, i think that would work
2732016-02-05T20:13:44  <Tasoshi> Sorry to interupt, but I suppose I must ask if I may. Our community is so terribly divided gmaxwell, is there a way to return to the cheerful days?
2742016-02-05T20:14:54  <morcos> sending packages gets dangerous though, b/c of the asymmetry between ancestor and descendant branching.  but thats a problem for the future.  need CPFP mining first.
2752016-02-05T20:15:08  <Tasoshi> The unthinkable is happening with r/bitcoin being censored/banned, that affects all for it breaches all principles
2762016-02-05T20:15:26  <Tasoshi> hard forks are being considered
2772016-02-05T20:15:37  <Tasoshi> these are difficult times for bitcoin
2782016-02-05T20:15:46  <morcos> Tasoshi: Thats a good coverstion, but sometimes we need to step away from it for our sanity.  This channel is not the place.  This is where we try to get work done.
2792016-02-05T20:15:51  <Tasoshi> it shouldnt be so
2802016-02-05T20:16:22  <Tasoshi> morcos gmaxwell is not accesible anywhere as far as I am aware
2812016-02-05T20:16:39  <Tasoshi> I understand of course it is difficult for him too
2822016-02-05T20:16:49  <morcos> Not on this channel please
2832016-02-05T20:16:58  <Tasoshi> but I thought to ask, if I may
2842016-02-05T20:17:15  <Tasoshi> are we to burn the world?
2852016-02-05T20:19:50  <Tasoshi> how can bitcoin operate when r/bitcoin is banned and censored, on what basis would anyone find this community welcoming at all
2862016-02-05T20:19:59  <Tasoshi> I know you want to focus on the code
2872016-02-05T20:22:41  *** gmaxwell has left #bitcoin-core-dev
2882016-02-05T20:22:54  <Tasoshi> there you are...
2892016-02-05T20:23:21  *** adnn has joined #bitcoin-core-dev
2902016-02-05T20:26:41  *** adnn_ has joined #bitcoin-core-dev
2912016-02-05T20:27:45  *** adnn has quit IRC
2922016-02-05T20:35:56  *** Tasoshi has left #bitcoin-core-dev
2932016-02-05T20:51:11  *** zooko has joined #bitcoin-core-dev
2942016-02-05T20:54:12  *** adnn_ has quit IRC
2952016-02-05T21:04:22  *** randy-waterhouse has joined #bitcoin-core-dev
2962016-02-05T21:11:36  *** adnn has joined #bitcoin-core-dev
2972016-02-05T21:12:41  *** adnn has quit IRC
2982016-02-05T21:13:44  *** Nuief has joined #bitcoin-core-dev
2992016-02-05T21:15:45  *** wallet42 has joined #bitcoin-core-dev
3002016-02-05T21:44:54  *** brg444 has joined #bitcoin-core-dev
3012016-02-05T21:51:54  *** Thireus has quit IRC
3022016-02-05T21:57:17  *** Thireus has joined #bitcoin-core-dev
3032016-02-05T22:02:06  *** zooko has quit IRC
3042016-02-05T22:06:32  *** raedah has quit IRC
3052016-02-05T22:15:06  *** laurentmt has quit IRC
3062016-02-05T22:16:07  *** PaulCapestany has quit IRC
3072016-02-05T22:16:36  *** PaulCapestany has joined #bitcoin-core-dev
3082016-02-05T22:16:50  *** PaulCapestany has quit IRC
3092016-02-05T22:17:30  *** treehug88 has quit IRC
3102016-02-05T22:18:25  *** PaulCapestany has joined #bitcoin-core-dev
3112016-02-05T22:23:29  *** instagibbs has quit IRC
3122016-02-05T22:30:12  *** instagibbs has joined #bitcoin-core-dev
3132016-02-05T22:37:35  *** bsm117532 has quit IRC
3142016-02-05T23:03:34  *** wallet42 has quit IRC
3152016-02-05T23:17:31  <Luke-Jr> morcos: CPFP mining has been live on the network since 2012 (or 2011)
3162016-02-05T23:37:35  *** belcher has joined #bitcoin-core-dev