12017-03-09T00:05:22 *** CubicEar_ has joined #bitcoin-core-dev
22017-03-09T00:06:43 *** CubicEarth has quit IRC
32017-03-09T00:10:31 *** MarcoFalke has joined #bitcoin-core-dev
42017-03-09T00:17:40 *** bityogi has quit IRC
52017-03-09T00:21:26 *** AaronvanW has quit IRC
62017-03-09T00:25:45 *** CubicEar_ has quit IRC
72017-03-09T00:26:12 <MarcoFalke> funny how the release announcement on twitter comes with a screenshot of java script code
82017-03-09T00:26:30 <gmaxwell> I laughed at that too.
92017-03-09T00:26:52 <MarcoFalke> it should come with a screenshot of the four redundant indentation levels
102017-03-09T00:27:34 <sipa> where does that picture come from?
112017-03-09T00:27:42 <sipa> it's not in the URL linked to
122017-03-09T00:27:50 <achow101> who controls the account?
132017-03-09T00:27:54 *** grubles has quit IRC
142017-03-09T00:28:07 <MarcoFalke> maybe ask btcdrak
152017-03-09T00:28:40 <btcdrak> LOL, google image search
162017-03-09T00:28:41 <gmaxwell> there was some popular press article with that picture.
172017-03-09T00:28:56 <gmaxwell> oh no, actually a similar one.
182017-03-09T00:29:07 <gmaxwell> btcdrak: don't do that, for one-- copyright problems. :P
192017-03-09T00:29:28 *** JackH has quit IRC
202017-03-09T00:30:37 *** grubles has joined #bitcoin-core-dev
212017-03-09T00:31:12 <MarcoFalke> jonasschnelli: has a nice one: https://bitcoin.jonasschnelli.ch/img/header.jpg
222017-03-09T00:31:38 <MarcoFalke> Needs more colors, though.
232017-03-09T00:31:53 <btcdrak> yeah
242017-03-09T00:45:37 *** goregrin1 has joined #bitcoin-core-dev
252017-03-09T00:48:35 *** goregrind has quit IRC
262017-03-09T00:59:45 *** abpa has quit IRC
272017-03-09T01:05:37 <gmaxwell> jonasschnelli: sipa: both of you are rehashing old arguments that have already been made to voskuil on the list. He is either flagrantly incompetent or actively working against the public interest. He is not worth your time or attention, and he gets _no say_ in this. Supporting authenticated links is something each indivigual node can decide to do for itself.
282017-03-09T01:06:45 <gmaxwell> sipa: your addnode argument was directly made my me previously in a private email, which he has dishonestly described as a threat (because I said that I thought I would write him to him privately before mentally writing him off, and he responded that this was 'a threat'-- absurd.)
292017-03-09T01:08:06 <gmaxwell> https://0bin.net/paste/zGcQVRFoTt7rsaZH#ZI5dYJ4GVIWYRFmeKzPQ6C3lorBGQ7LV6IrePetem2z the 'threat'
302017-03-09T01:08:30 <gmaxwell> Abusive asshole like that are a big part of the reason I unsubscribed. You just enable them when you argue with them where you don't have to.
312017-03-09T01:26:46 *** MarcoFalke has left #bitcoin-core-dev
322017-03-09T01:30:56 <bitcoin-git> [bitcoin] sdaftuar opened pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (master...2017-03-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/9959
332017-03-09T01:37:11 <gmaxwell> jeremyrubin: I can't make sense of your comment on #9955
342017-03-09T01:37:13 <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
352017-03-09T01:40:49 *** alpalp has joined #bitcoin-core-dev
362017-03-09T01:40:49 *** alpalp has joined #bitcoin-core-dev
372017-03-09T01:44:18 *** PaulCapestany has quit IRC
382017-03-09T01:44:50 <isle2983> plug for a bitcoin-maintainer-tools PR I just submitted:
392017-03-09T01:44:56 <isle2983> https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/10
402017-03-09T01:45:31 <isle2983> it is a set of functionality previously submitted to contrib/devtool, but closed because it was decided that was the wrong spot
412017-03-09T01:46:10 <isle2983> the pointer was to bitcoin-maintainer-tools, so I ran with that
422017-03-09T01:46:29 <isle2983> the scripts use a common shared framework
432017-03-09T01:46:31 *** PaulCapestany has joined #bitcoin-core-dev
442017-03-09T01:46:58 <isle2983> hopefully it will help accelerate further automation in the future
452017-03-09T01:54:04 *** Ylbam has quit IRC
462017-03-09T02:16:12 *** wudayoda_ has quit IRC
472017-03-09T02:33:23 <bitcoin-git> [bitcoin] NicolasDorier opened pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960
482017-03-09T02:49:05 *** harrymm has quit IRC
492017-03-09T02:51:25 *** harrymm has joined #bitcoin-core-dev
502017-03-09T02:55:17 *** wudayoda has joined #bitcoin-core-dev
512017-03-09T03:02:27 *** wudayoda has quit IRC
522017-03-09T03:04:12 *** wudayoda has joined #bitcoin-core-dev
532017-03-09T03:08:27 *** wudayoda has quit IRC
542017-03-09T03:13:48 *** wudayoda has joined #bitcoin-core-dev
552017-03-09T03:14:10 *** dodomojo has joined #bitcoin-core-dev
562017-03-09T03:18:27 *** wudayoda has quit IRC
572017-03-09T03:23:25 *** jannes has quit IRC
582017-03-09T03:44:04 *** alpalp has quit IRC
592017-03-09T03:50:02 <jeremyrubin> gmaxwell: if a miner doesn't want to support segwit, and won't mine them, maybe they should not keep such transactions in their memory pool
602017-03-09T03:50:23 <jeremyrubin> gmaxwell: e.g., to keep room for the most-fee nonsegwit txns
612017-03-09T04:12:29 <luke-jr> jeremyrubin: what if a miner does want to support segwit, but is locked-into mining software that doesn't support it, on some machines?
622017-03-09T04:15:36 <jeremyrubin> this still applies
632017-03-09T04:15:45 <jeremyrubin> they will make more money evicting segwit txs
642017-03-09T04:19:06 *** wudayoda has joined #bitcoin-core-dev
652017-03-09T04:23:10 *** jtimon has quit IRC
662017-03-09T04:25:43 <luke-jr> jeremyrubin: they won't be supporting segwit with that logic, and they might not make more money either so long as their mempool is a decent size
672017-03-09T04:26:09 *** Giszmo has quit IRC
682017-03-09T04:32:01 *** wasi has joined #bitcoin-core-dev
692017-03-09T04:45:57 *** wudayoda has quit IRC
702017-03-09T04:48:06 *** dodomojo has quit IRC
712017-03-09T04:49:02 *** dodomojo has joined #bitcoin-core-dev
722017-03-09T04:53:22 *** dodomojo has quit IRC
732017-03-09T05:12:43 <jeremyrubin> luke-jr: false. they can still validate segwit blocks.
742017-03-09T05:12:59 <jeremyrubin> luke-jr: and check the witnesses (full validation)
752017-03-09T05:13:07 <luke-jr> jeremyrubin: all miners need to validate segwit blocks once it activates; that's not support, it's just mining
762017-03-09T05:18:36 <jeremyrubin> that's not completely true.
772017-03-09T05:18:54 <jeremyrubin> A miner can mine a non segwit block, it will just get orphaned by the segwit-mining majority
782017-03-09T05:19:41 <jeremyrubin> (if any of the txs have a witness)
792017-03-09T05:20:20 <jeremyrubin> and even in that case, such a miner might not want segwit transactions in their mempool if they can't mine them?
802017-03-09T05:24:28 <warren> I suspect your discussion there may be confused by absolutism on one hand, and a common misconception that I also made on the other.
812017-03-09T05:31:21 <jeremyrubin> warren: that sentence doesn't say anything
822017-03-09T05:32:30 <jeremyrubin> In general, if I am a miner, and I have a 10 MB mempool (let's say), and there is a backlog of 100MB of transactions, and the top 10MB are all segwit transactions I absolutely want to exclude them from my mempool if I can't mine them
832017-03-09T05:34:25 <warren> jeremyrubin: pre-segwit nodes see segwit transactions as non-standard and it won't enter the mempool to begin with
842017-03-09T05:36:20 <warren> nevermind, I don't care enough about this to continue
852017-03-09T05:37:43 <jeremyrubin> warren: context is a miner wanting to be a fully validating segwit node running on the latest, but with segwit incompatible mining hardware #9955
862017-03-09T05:37:45 <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
872017-03-09T05:39:13 <jeremyrubin> The question is, if you're never going to mine a transaction why would you want it in your mempool? (other than, perhaps, compact blocks)
882017-03-09T05:40:52 <luke-jr> jeremyrubin: it would be fairly irresponsible for a miner to have a mere 10 MB mempool in the first place..
892017-03-09T05:41:26 <luke-jr> the default of 300 MB is for non-mining nodes
902017-03-09T05:42:39 <jeremyrubin> luke-jr: was only for convenience picking a number.
912017-03-09T05:42:58 <luke-jr> point is they should have more than enough
922017-03-09T05:43:02 <jeremyrubin> no
932017-03-09T05:43:30 *** dodomojo has joined #bitcoin-core-dev
942017-03-09T05:43:43 <jeremyrubin> there is actually an attack that you can do with a more well resourced miner (larger mempool) against a less well resourced node that can't mine segwit txns
952017-03-09T05:44:46 <jeremyrubin> e.g., let's say I have a consistent segwit fee around 10 sat/byte, filling up at all times the top 10MB of the mempool
962017-03-09T05:44:58 <jeremyrubin> all txns will be selected from that range always
972017-03-09T05:45:58 <jeremyrubin> so then, I issue 290 MB of txns that are at 9 sat/byte, with segwit, such that they won't be mined
982017-03-09T05:46:35 <jeremyrubin> let's say I also have a bunch on non-segwit txns at 9 sat/byte
992017-03-09T05:46:47 <jeremyrubin> I can push them out with my segwit txns
1002017-03-09T05:47:27 <jeremyrubin> so that your less well resourced miner now has a mempool full of txns you can't mine
1012017-03-09T05:47:58 *** dodomojo has quit IRC
1022017-03-09T06:19:41 <gmaxwell> jeremyrubin: we don't know in advance of someone calling GBT what they're going to call it with, and they may call it with a mix of arguments.
1032017-03-09T06:20:33 <gmaxwell> jeremyrubin: their normal operation as a node shouldn't be impared ... e.g. logical conclusion of what you suggest is that someone who doesn't mine shouldn't have a mempool at all-- which is clearly not true, as its integral to other functions of a node (fast block propagation, fee estimation, txn relay)
1042017-03-09T06:21:43 <gmaxwell> luke-jr: you say a lot of confusing things, there is nothing wrong with having a 300 mb mempool as a miner and CNB is effectively the same speed for all mempool sizes. Having a small mempool may also adversely impact your block reception speed.
1052017-03-09T06:22:53 <gmaxwell> tiny mempools also prevent users from being able to create low priority transactions that get mined in off hours... which is bad because without a supply of lower priority transactions the spare capacity will instead by used for less useful/efficient uses that continually rebroadcast.
1062017-03-09T06:22:55 <luke-jr> gmaxwell: I'm saying a small mempool is bad..
1072017-03-09T06:22:59 <gmaxwell> oh okay!
1082017-03-09T06:23:20 <gmaxwell> I had read your comment backwards.
1092017-03-09T06:23:49 <gmaxwell> jeremyrubin: okay thanks for at least clarifying what you meant. (I don't think it's a good idea at all-- but at least it makes logical sense to me now)
1102017-03-09T06:25:15 *** afk11 has quit IRC
1112017-03-09T06:25:56 *** afk11 has joined #bitcoin-core-dev
1122017-03-09T06:27:44 <jeremyrubin> gmaxwell: that's fair; what I'm suggesting might be better off as a startup time argument
1132017-03-09T06:28:40 <jeremyrubin> gmaxwell: I also think that you can relay a txn w/o having it in your mempool (e.g., to your immediate peers)
1142017-03-09T06:29:18 <jeremyrubin> gmaxwell: w.r.t. fee estimation, you could collect the fee estimate information for such transactions without storing them
1152017-03-09T06:29:21 <sipa> jeremyrubin: BIP152 relay speed depends on having transactions in your mempool
1162017-03-09T06:29:29 <sipa> (or at least, stored somewhere)
1172017-03-09T06:29:31 <gmaxwell> jeremyrubin: not as soon as there is a dependency, and we also use the mempool as a dynamic rate control.
1182017-03-09T06:29:43 <jeremyrubin> yes, as I said, compact blocks is the place where it does make sense to keep them
1192017-03-09T06:30:16 <gmaxwell> jeremyrubin: you have to remember information about them, it could be just their IDs and feerates, rather than the whole things. but you would get less accurate results since you'd overestimate the time it took for things that were evicted.
1202017-03-09T06:30:56 <gmaxwell> In any case what you are suggesting is 99% orthorgonal, since you do not know at the rest of operation what your future GBT calls will be.
1212017-03-09T06:32:18 <jeremyrubin> yeah; this would only make sense where you know that none of your calls would need it
1222017-03-09T06:35:22 *** arubi has quit IRC
1232017-03-09T06:35:49 *** arubi has joined #bitcoin-core-dev
1242017-03-09T06:37:32 *** dodomojo has joined #bitcoin-core-dev
1252017-03-09T06:41:01 *** juscamarena has quit IRC
1262017-03-09T06:41:52 *** dodomojo has quit IRC
1272017-03-09T06:42:05 *** juscamarena has joined #bitcoin-core-dev
1282017-03-09T06:42:45 *** chris2000 has joined #bitcoin-core-dev
1292017-03-09T06:43:28 *** wudayoda has joined #bitcoin-core-dev
1302017-03-09T06:43:37 *** chris2000 has joined #bitcoin-core-dev
1312017-03-09T06:47:57 *** wudayoda has quit IRC
1322017-03-09T07:13:31 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6996e066b538...c047b1663d47
1332017-03-09T07:13:32 <bitcoin-git> bitcoin/master 8a52281 Karl-Johan Alm: Refactor: Remove using namespace <xxx> from wallet/
1342017-03-09T07:13:32 <bitcoin-git> bitcoin/master a57845c Karl-Johan Alm: Refactor: Remove using namespace <xxx> from util*
1352017-03-09T07:13:33 <bitcoin-git> bitcoin/master c047b16 Wladimir J. van der Laan: Merge #9643: [refactor] Remove using namespace <xxx> from wallet/ & util*...
1362017-03-09T07:13:48 <bitcoin-git> [bitcoin] laanwj closed pull request #9643: [refactor] Remove using namespace <xxx> from wallet/ & util* (master...no-using-namespace-wallet-util) https://github.com/bitcoin/bitcoin/pull/9643
1372017-03-09T07:16:07 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c047b1663d47...8152d3fe57a9
1382017-03-09T07:16:08 <bitcoin-git> bitcoin/master f3c264e Karl-Johan Alm: Refactor: Remove using namespace <xxx> from rpc/
1392017-03-09T07:16:08 <bitcoin-git> bitcoin/master 8cbfc4e Karl-Johan Alm: Refactor: Remove using namespace <xxx> from script/
1402017-03-09T07:16:09 <bitcoin-git> bitcoin/master 8152d3f Wladimir J. van der Laan: Merge #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources...
1412017-03-09T07:16:18 <bitcoin-git> [bitcoin] laanwj closed pull request #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources (master...no-using-namespace-rpc-script) https://github.com/bitcoin/bitcoin/pull/9476
1422017-03-09T07:24:35 *** justanotheruser has quit IRC
1432017-03-09T07:28:18 <bitcoin-git> [bitcoin] laanwj closed pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (master...RPC_refactor) https://github.com/bitcoin/bitcoin/pull/9958
1442017-03-09T07:31:29 *** dodomojo has joined #bitcoin-core-dev
1452017-03-09T07:36:23 *** dodomojo has quit IRC
1462017-03-09T07:41:57 *** BashCo has quit IRC
1472017-03-09T07:49:38 <wumpus> okay, that removes the last uses of "using namespace" in the code (apart from one in the tests)
1482017-03-09T07:50:17 <sipa> nice
1492017-03-09T07:51:20 <wumpus> I can imagine it's a bit painful for some patches (I have some rebasing to do now, too) but at least this is only a one-time thing
1502017-03-09T07:53:11 <paveljanik> small pain for big gain!
1512017-03-09T07:53:15 *** Ylbam has joined #bitcoin-core-dev
1522017-03-09T08:04:05 *** Guyver2 has joined #bitcoin-core-dev
1532017-03-09T08:08:08 *** Victorsueca has quit IRC
1542017-03-09T08:08:13 *** BashCo has joined #bitcoin-core-dev
1552017-03-09T08:09:10 *** Victorsueca has joined #bitcoin-core-dev
1562017-03-09T08:10:04 *** veleiro has quit IRC
1572017-03-09T08:33:08 *** Victorsueca has quit IRC
1582017-03-09T08:33:17 *** Victor_sueca has joined #bitcoin-core-dev
1592017-03-09T08:33:30 *** Victor_sueca is now known as Victorsueca
1602017-03-09T08:44:11 *** wudayoda has joined #bitcoin-core-dev
1612017-03-09T08:48:57 *** wudayoda has quit IRC
1622017-03-09T08:51:41 *** juscamarena has quit IRC
1632017-03-09T08:52:06 *** juscamarena has joined #bitcoin-core-dev
1642017-03-09T09:01:25 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8152d3fe57a9...6805c4112cfd
1652017-03-09T09:01:25 <bitcoin-git> bitcoin/master 54fae05 practicalswift: Remove unreachable code (g_rpcSignals.PostCommand)
1662017-03-09T09:01:26 <bitcoin-git> bitcoin/master 6805c41 Wladimir J. van der Laan: Merge #9575: Remove unused, non-working RPC PostCommand signal...
1672017-03-09T09:01:36 <bitcoin-git> [bitcoin] laanwj closed pull request #9575: Remove unused, non-working RPC PostCommand signal (master...never-executed-comment) https://github.com/bitcoin/bitcoin/pull/9575
1682017-03-09T09:02:37 <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/6805c4112cfd...02bd6e9bc6de
1692017-03-09T09:02:38 <bitcoin-git> bitcoin/master 6d07c62 John Newbery: Return correct error codes in bumpfee()....
1702017-03-09T09:02:39 <bitcoin-git> bitcoin/master c119096 John Newbery: Return correct error codes in blockchain.cpp....
1712017-03-09T09:02:39 <bitcoin-git> bitcoin/master 960bc7f John Newbery: Return correct error codes in removeprunedfunds()....
1722017-03-09T09:03:01 <bitcoin-git> [bitcoin] laanwj closed pull request #9853: Fix error codes from various RPCs (master...fixerrorcodes) https://github.com/bitcoin/bitcoin/pull/9853
1732017-03-09T09:03:15 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/02bd6e9bc6de...b403ec5c0f2f
1742017-03-09T09:03:16 <bitcoin-git> bitcoin/master 292112f kobake: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
1752017-03-09T09:03:16 <bitcoin-git> bitcoin/master 8e0720b kobake: Fix msvc compiler error C4146 (unary minus operator applied to unsigned type)...
1762017-03-09T09:03:17 <bitcoin-git> bitcoin/master b403ec5 Wladimir J. van der Laan: Merge #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
1772017-03-09T09:03:36 <bitcoin-git> [bitcoin] laanwj closed pull request #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type) (master...fix-minus-operator-target-for-msvc-c4146) https://github.com/bitcoin/bitcoin/pull/9916
1782017-03-09T09:06:48 *** Victorsueca has quit IRC
1792017-03-09T09:07:20 *** Victorsueca has joined #bitcoin-core-dev
1802017-03-09T09:12:38 *** pavel_ has joined #bitcoin-core-dev
1812017-03-09T09:15:28 *** paveljanik has quit IRC
1822017-03-09T09:15:39 *** Guyver2 has quit IRC
1832017-03-09T09:19:57 *** dodomojo has joined #bitcoin-core-dev
1842017-03-09T09:19:59 <bitcoin-git> [bitcoin] practicalswift opened pull request #9962: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06 (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
1852017-03-09T09:22:49 *** BashCo_ has joined #bitcoin-core-dev
1862017-03-09T09:22:54 *** whphhg has quit IRC
1872017-03-09T09:23:11 *** Lauda has quit IRC
1882017-03-09T09:23:48 *** Victorsueca has quit IRC
1892017-03-09T09:23:55 *** Lauda has joined #bitcoin-core-dev
1902017-03-09T09:24:16 *** dodomojo has quit IRC
1912017-03-09T09:25:27 *** BashCo has quit IRC
1922017-03-09T09:25:55 *** Victorsueca has joined #bitcoin-core-dev
1932017-03-09T09:27:57 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b403ec5c0f2f...c71f0ca5f839
1942017-03-09T09:27:57 <bitcoin-git> bitcoin/master 3cef950 NicolasDorier: Trivial: Add const modifier to GetHDChain and IsHDEnabled
1952017-03-09T09:27:58 <bitcoin-git> bitcoin/master c71f0ca Wladimir J. van der Laan: Merge #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled...
1962017-03-09T09:28:15 <bitcoin-git> [bitcoin] laanwj closed pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960
1972017-03-09T09:31:41 *** pavel_ has quit IRC
1982017-03-09T09:33:48 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c71f0ca5f839...e3e7db829ecd
1992017-03-09T09:33:49 <bitcoin-git> bitcoin/master 53a2ba3 practicalswift: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)
2002017-03-09T09:33:49 <bitcoin-git> bitcoin/master e3e7db8 Wladimir J. van der Laan: Merge #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)...
2012017-03-09T09:34:01 <bitcoin-git> [bitcoin] laanwj closed pull request #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr) (master...remove-redundant-get-on-smartptr) https://github.com/bitcoin/bitcoin/pull/9538
2022017-03-09T09:41:08 *** chjj has quit IRC
2032017-03-09T09:47:09 *** whphhg has joined #bitcoin-core-dev
2042017-03-09T09:48:55 *** chjj has joined #bitcoin-core-dev
2052017-03-09T09:57:18 *** whphhg has quit IRC
2062017-03-09T10:03:51 *** JackH has joined #bitcoin-core-dev
2072017-03-09T10:14:16 *** whphhg has joined #bitcoin-core-dev
2082017-03-09T10:36:17 *** MarcoFalke has joined #bitcoin-core-dev
2092017-03-09T10:39:18 *** BirneGetreide_ has joined #bitcoin-core-dev
2102017-03-09T10:40:47 *** MarcoFalke has left #bitcoin-core-dev
2112017-03-09T10:42:30 <bitcoin-git> [bitcoin] laanwj opened pull request #9963: util: Properly handle errors during log message formatting (master...2017_03_handle_exception_tinyformat) https://github.com/bitcoin/bitcoin/pull/9963
2122017-03-09T10:44:58 *** wudayoda has joined #bitcoin-core-dev
2132017-03-09T10:47:03 *** BirneGetreide_ has quit IRC
2142017-03-09T10:48:25 *** BirneGetreide_ has joined #bitcoin-core-dev
2152017-03-09T10:49:27 *** wudayoda has quit IRC
2162017-03-09T10:49:57 *** MarcoFalke has joined #bitcoin-core-dev
2172017-03-09T10:51:06 *** BirneGetreide_ has quit IRC
2182017-03-09T10:57:59 *** chris200_ has joined #bitcoin-core-dev
2192017-03-09T11:01:56 *** chris2000 has quit IRC
2202017-03-09T11:02:27 <jonasschnelli> I still try to understand why importing a P2PKH address into the wallet leads to ISMINE_WATCH_UNSOLVABLE (and not ISMINE_WATCH_SOLVABLE).
2212017-03-09T11:02:41 <jonasschnelli> The comment for ISMINE_WATCH_SOLVABLE says: "Indicates that we know how to create a scriptSig that would solve this if we were given the appropriate private keys"
2222017-03-09T11:03:36 <jonasschnelli> Isn't this true for P2PKH (== importaddress could identify P2PKH)?
2232017-03-09T11:06:40 <luke-jr> I suspect the requirement of the public key might play a part
2242017-03-09T11:06:51 <luke-jr> you could calculate it from the private key, but that may not count
2252017-03-09T11:08:00 *** dodomojo has joined #bitcoin-core-dev
2262017-03-09T11:08:44 *** chris200_ has quit IRC
2272017-03-09T11:09:11 *** chris2000 has joined #bitcoin-core-dev
2282017-03-09T11:12:25 *** dodomojo has quit IRC
2292017-03-09T11:13:27 <jonasschnelli> luke-jr: Yes. When I import a pubkey it will marke the P2PKH watch-only as solveble.
2302017-03-09T11:13:51 <jonasschnelli> But I don't see a clear reason for that. I understand that for P2SH but not for P2PKH...
2312017-03-09T11:16:27 *** AaronvanW has joined #bitcoin-core-dev
2322017-03-09T11:19:09 *** jannes has joined #bitcoin-core-dev
2332017-03-09T11:34:55 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e3e7db829ecd...5703dff0939f
2342017-03-09T11:34:55 <bitcoin-git> bitcoin/master 9ea2490 practicalswift: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06...
2352017-03-09T11:34:56 <bitcoin-git> bitcoin/master 5703dff MarcoFalke: Merge #9962: [trivial] Fix typo in rpc/protocol.h...
2362017-03-09T11:35:16 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9962: [trivial] Fix typo in rpc/protocol.h (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
2372017-03-09T12:01:53 <wumpus> I just had the wallet RPC test pass... on a leveldb-based wallet on top of #9951. It's a bit of a hack right now but hopefully enough to be able to run all the RPC tests against the cloudabi bitcoind at some point.
2382017-03-09T12:01:54 <gribble> https://github.com/bitcoin/bitcoin/issues/9951 | Wallet database handling abstractions/simplifications by laanwj · Pull Request #9951 · bitcoin/bitcoin · GitHub
2392017-03-09T12:02:15 *** dodomojo has joined #bitcoin-core-dev
2402017-03-09T12:06:40 *** dodomojo has quit IRC
2412017-03-09T12:45:45 *** wudayoda has joined #bitcoin-core-dev
2422017-03-09T12:47:40 <bitcoin-git> [bitcoin] practicalswift opened pull request #9964: Add const to methods that do not modify the object for which it is called (master...const) https://github.com/bitcoin/bitcoin/pull/9964
2432017-03-09T12:50:18 *** wudayoda has quit IRC
2442017-03-09T13:01:52 *** adiabat has quit IRC
2452017-03-09T13:17:44 <wumpus> shouldn't we at least be logging a warning if pwallet->GetKey() returns false in https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcdump.cpp#L639? Or are there legitimate reasons why this could happen?
2462017-03-09T13:18:14 <wumpus> seems that a dump may be incomplete if it could not find all keys
2472017-03-09T13:27:27 *** justanotheruser has joined #bitcoin-core-dev
2482017-03-09T13:30:36 <wumpus> (not that I've ever seen an instance of that problem, but I just wonder that seeing the code)
2492017-03-09T13:46:12 *** chjj has quit IRC
2502017-03-09T13:46:45 *** paveljanik has joined #bitcoin-core-dev
2512017-03-09T13:50:16 *** dodomojo has joined #bitcoin-core-dev
2522017-03-09T13:50:17 *** alpalp has joined #bitcoin-core-dev
2532017-03-09T13:50:17 *** alpalp has joined #bitcoin-core-dev
2542017-03-09T13:54:54 *** dodomojo has quit IRC
2552017-03-09T14:00:14 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9965: Allow to use unsolveable P2PKH watch-only in fundrawtransaction (master...2017/03/watch_solve) https://github.com/bitcoin/bitcoin/pull/9965
2562017-03-09T14:27:56 *** bityogi has joined #bitcoin-core-dev
2572017-03-09T14:44:31 *** dodomojo has joined #bitcoin-core-dev
2582017-03-09T14:46:31 *** wudayoda has joined #bitcoin-core-dev
2592017-03-09T14:48:43 *** dodomojo has quit IRC
2602017-03-09T14:51:34 *** wudayoda has quit IRC
2612017-03-09T14:54:25 *** wudayoda has joined #bitcoin-core-dev
2622017-03-09T15:03:27 *** wudayoda has quit IRC
2632017-03-09T15:04:04 *** jtimon has joined #bitcoin-core-dev
2642017-03-09T15:11:47 *** wudayoda has joined #bitcoin-core-dev
2652017-03-09T15:23:43 *** Giszmo has joined #bitcoin-core-dev
2662017-03-09T15:38:38 *** dodomojo has joined #bitcoin-core-dev
2672017-03-09T15:42:58 *** dodomojo has quit IRC
2682017-03-09T15:54:51 *** Sosumi has joined #bitcoin-core-dev
2692017-03-09T15:59:34 *** rafalcpp_ has joined #bitcoin-core-dev
2702017-03-09T15:59:37 *** rafalcpp has quit IRC
2712017-03-09T16:07:21 *** veleiro has joined #bitcoin-core-dev
2722017-03-09T16:32:42 *** dodomojo has joined #bitcoin-core-dev
2732017-03-09T16:36:52 *** dodomojo has quit IRC
2742017-03-09T16:38:35 *** rafalcpp_ has quit IRC
2752017-03-09T16:38:57 *** rafalcpp has joined #bitcoin-core-dev
2762017-03-09T16:49:00 *** abpa has joined #bitcoin-core-dev
2772017-03-09T17:09:05 *** BashCo_ has quit IRC
2782017-03-09T17:28:21 *** CubicEarth has joined #bitcoin-core-dev
2792017-03-09T17:32:51 *** adiabat has joined #bitcoin-core-dev
2802017-03-09T17:46:34 *** BashCo has joined #bitcoin-core-dev
2812017-03-09T17:49:00 *** voyager_ has quit IRC
2822017-03-09T17:58:19 *** CubicEarth has quit IRC
2832017-03-09T18:04:16 *** CubicEarth has joined #bitcoin-core-dev
2842017-03-09T18:08:10 *** voyager_ has joined #bitcoin-core-dev
2852017-03-09T18:35:09 *** mol has joined #bitcoin-core-dev
2862017-03-09T18:37:52 *** veleiro has quit IRC
2872017-03-09T18:37:58 *** moli_ has quit IRC
2882017-03-09T18:44:15 *** CubicEarth has quit IRC
2892017-03-09T19:00:32 <sipa> ploink
2902017-03-09T19:00:39 *** molz_ has joined #bitcoin-core-dev
2912017-03-09T19:00:43 <wumpus> #startmeeting
2922017-03-09T19:00:43 <lightningbot> Meeting started Thu Mar 9 19:00:43 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2932017-03-09T19:00:43 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2942017-03-09T19:00:47 <jonasschnelli> hi
2952017-03-09T19:01:02 <sipa> short topic: great work on 0.14 all!
2962017-03-09T19:01:07 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
2972017-03-09T19:01:08 <wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
2982017-03-09T19:01:20 <wumpus> yes! congrats all on another great release
2992017-03-09T19:01:37 <btcdrak> +1
3002017-03-09T19:02:08 * BlueMatt has seen really great results for miners that have upgraded to 0.14 =D
3012017-03-09T19:02:08 <morcos> yes i feel like we did a good job getting most of the major things we wanted into it!
3022017-03-09T19:02:16 <BlueMatt> net seems to have really helped a lot
3032017-03-09T19:02:50 <achow101> hi
3042017-03-09T19:02:50 *** jnewbery has joined #bitcoin-core-dev
3052017-03-09T19:03:02 <wumpus> proposed topic: disclosure of alert key (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1534 reminded me)
3062017-03-09T19:03:16 <gmaxwell> Hi.
3072017-03-09T19:03:49 <gmaxwell> There are DOS vulnerablities in older verions that the final alert does not block. :(
3082017-03-09T19:03:55 <wumpus> #topic alert key disclosure timeline
3092017-03-09T19:04:00 *** mol has quit IRC
3102017-03-09T19:04:05 <sipa> gmaxwell: below what version?
3112017-03-09T19:04:12 <gmaxwell> (unfortunately the old code is stupid)
3122017-03-09T19:04:18 <achow101> what kind of DOS vulns?
3132017-03-09T19:04:21 <gmaxwell> All versions. They're worse in older ones.
3142017-03-09T19:04:38 <gmaxwell> (obviously all versions with alerts enabled)
3152017-03-09T19:04:51 <sipa> when was that changed?
3162017-03-09T19:04:53 <wumpus> yes, what kind? just a slowdown, or a crash, or potential remote code execution?
3172017-03-09T19:05:00 <sipa> OOM
3182017-03-09T19:05:04 <gmaxwell> No RCE, just OOM.
3192017-03-09T19:05:41 <btcdrak> so versions <0.12.0 affected?
3202017-03-09T19:05:52 <wumpus> well. some versions have already been marked as "insecure" on bitcoin.org due to other bugs. Let me see what the threshold is.
3212017-03-09T19:06:09 <sipa> when was the alert feature disabled by default?
3222017-03-09T19:06:16 <achow101> 0.12.1
3232017-03-09T19:06:29 <btcdrak> oh
3242017-03-09T19:06:39 <BlueMatt> wumpus: we have a list somewhere?
3252017-03-09T19:06:46 <sipa> are there any major altcoins forked before 0.12 that did not change the alaert key?
3262017-03-09T19:07:00 <wumpus> https://bitcoin.org/bin/insecure/
3272017-03-09T19:07:01 <gmaxwell> All the 0.14 nodes sending final alerts constantly is somewhat protective, but unforuntately not absoltely protective.
3282017-03-09T19:07:22 <gmaxwell> sipa: already looked for that, there were no major ones, but some obscure & dead ones that have been nagged.
3292017-03-09T19:07:40 <gmaxwell> There are also funds paid to the alert key in the network, I believe 0.01 BTC or so. :P
3302017-03-09T19:08:18 <wumpus> heheh
3312017-03-09T19:08:25 <cfields> heh
3322017-03-09T19:08:27 <gmaxwell> in any case, one possibility would be to not worry too much about it, announce again that version <0.12.1 are vulnerable (there is a lot else they're vulnerable too, I think).
3332017-03-09T19:08:29 <wumpus> surprised no one ever swiped that
3342017-03-09T19:08:46 <btcdrak> sipa: most altcoins are on <0.12 codebase, and many never changed the alter key
3352017-03-09T19:08:53 <gmaxwell> btcdrak: not so.
3362017-03-09T19:09:08 <wumpus> from what I've seen, altcoins generally do change the alert key, at least from the bitcoin one
3372017-03-09T19:09:15 <gmaxwell> btcdrak: (didn't change the _litecoin_ alert key, yes, but I searched extensively for this already, months ago.)
3382017-03-09T19:09:17 <wumpus> many have the litecoin or feathercoin key
3392017-03-09T19:09:20 <wumpus> yes :)
3402017-03-09T19:09:43 <sipa> ah
3412017-03-09T19:09:47 <btcdrak> ah yes, most coins forked from litecoin (and didnt change the network magic either)
3422017-03-09T19:09:59 <morcos> remind me again what the advantage is of disclosing the key?
3432017-03-09T19:10:23 <achow101> morcos: making the alert system entirely unreliable (as if it weren't already)
3442017-03-09T19:10:25 <gmaxwell> to not be responsible for someone else abusing it, among other things.
3452017-03-09T19:10:41 <gmaxwell> we don't believe the key is actually secure right now in any case.
3462017-03-09T19:10:54 <sipa> there is no hurry in disclosing it either
3472017-03-09T19:11:11 <sipa> just a nice to have to close that chapter
3482017-03-09T19:11:18 <wumpus> to force people to not use it anymore
3492017-03-09T19:11:24 <btcdrak> they key is useless now anyway that final alert is out.
3502017-03-09T19:11:25 <wumpus> and also for sake of history
3512017-03-09T19:11:26 <paveljanik> We can make people upgrade because of the planned alert key discolsure...
3522017-03-09T19:11:37 <luke-jr> not sure how litecoin alerts are affects if they use a different key
3532017-03-09T19:11:42 <gmaxwell> we can't make anyone upgrade, and even if we could we wouldn't. :)
3542017-03-09T19:11:43 <morcos> yes but if there is even nuisance harm that can be done with it.. i think we should announce that its not considred secure but that we're not going to aid people doing nuisance with it by publicly disclosing it until a) we see nuisance or b) some predetermine future point
3552017-03-09T19:11:52 <wumpus> litecoin is not affected luke-jr - what they do is up to them
3562017-03-09T19:12:13 <btcdrak> wumpus: they also removed the alert system, but there's a lot on 0.10.x nodes in litecoin
3572017-03-09T19:12:24 <gmaxwell> morcos: well we're at the predetermined future point now, we announced.. 6 months ago we'd do this after 0.14. The issue there is on careful review of the old code I found several DOS vulnerablities.
3582017-03-09T19:12:37 <wumpus> yes, this was announced on a timeline
3592017-03-09T19:12:56 <morcos> right, so change the predetermined point to be further out... the risk is only that someone blames us for nuisance right?
3602017-03-09T19:13:02 <achow101> maybe just push back the date even further until <0.12.1 nodes are even fewer?
3612017-03-09T19:13:25 <BlueMatt> yea, I would vote push another release given old 0.12.0 isnt otherwise insecure?
3622017-03-09T19:13:32 <wumpus> right, if anyone abuses the key now, they may blame us. If it is public knowledge not so much.
3632017-03-09T19:13:35 <gmaxwell> It's fine with me, we should emphasize that those older versions are insecure. If someone dosses them later it's not the end of the world.
3642017-03-09T19:13:52 <morcos> Except of course we will be blamed if we make it public and someone creates nuisance with it!
3652017-03-09T19:14:02 <gmaxwell> BlueMatt: I believe it is otherwise insecure at a greater magnitude than the alert DOS attacks.
3662017-03-09T19:14:06 <paveljanik> gmaxwell, yes, and by emphasizing it, maybe people update...
3672017-03-09T19:14:26 <gmaxwell> Well anything that has alerts is displaying the hardcoded final alert now...
3682017-03-09T19:14:33 <achow101> what version did BU remove the alert system? If it is in their 0.12.1, people could dos them, and I don't think they would take kindly to that (drama and FUD and all that)
3692017-03-09T19:14:42 <btcdrak> so let's announce the vulnerability first that should motivate more people to upgrade old systems or disable the alert system.
3702017-03-09T19:14:43 <gmaxwell> which says something like (allcaps) warning alert key compromised! upgrade required!.
3712017-03-09T19:14:53 <jtimon> ACK "<sipa> there is no hurry in disclosing it either"
3722017-03-09T19:15:34 <luke-jr> gmaxwell: can you get a CVE assigned for one or more of the old DoS?
3732017-03-09T19:15:38 <gmaxwell> I think some of you are underestimating the cost of this thing... but sure, no rush required.
3742017-03-09T19:15:44 <wumpus> anyhow, everyone with the alert key could disclose it, even anonymously
3752017-03-09T19:16:12 <wumpus> don't even know who has it exactly so...
3762017-03-09T19:16:14 <luke-jr> yes, nobody can be blamed individually if nobody knows who disclosed it
3772017-03-09T19:16:39 <wumpus> anyhow, any other topics?
3782017-03-09T19:17:27 <luke-jr> FWIW, ignoring alert keys, I see 539 vulnerable nodes (0.94%)
3792017-03-09T19:17:28 <gmaxwell> Can we get a clear plan of action here? We'll CVE old versions and remind people these old things are insecure? should we review other fixes and determine if we want to set a higher bar for holy-shit-dont-run-that than 0.12.1?
3802017-03-09T19:18:02 <luke-jr> updating http://luke.dashjr.org/programs/bitcoin/files/charts/security.html to consider <0.12.1 vulnerable, that goes to 2606 vulnerable nodes (4.54%)
3812017-03-09T19:18:37 <wumpus> you can't be entirely sure that all of them are vulnerable, they may have patched the code to remove the alert system
3822017-03-09T19:18:48 <luke-jr> sure, but that's unlikely
3832017-03-09T19:18:53 <gmaxwell> I think 5% dropping offline would be inconsequential, so avoiding the dos is just a politeness to the users to avoid disrupting other things they may have going on.
3842017-03-09T19:19:02 <wumpus> many are running old versions to be able to run their own (outdated) patches on top
3852017-03-09T19:19:25 <achow101> gmaxwell: how about CVE the dos vulns you found, post messages an all forums about vulnerable nodes, and then release the key a few weeks later?
3862017-03-09T19:19:32 <luke-jr> if we're really worried, we could release a 0.12.2 with just those exploits fixed
3872017-03-09T19:19:41 <luke-jr> or maybe simply disabling alerts
3882017-03-09T19:19:49 <gmaxwell> luke-jr: 0.12.1 has them disabled.
3892017-03-09T19:19:52 <achow101> luke-jr: 0.12.1 already disabled alrets
3902017-03-09T19:19:54 <morcos> if it was me, i wouldn't do any of it... lets put our effort where it matters.. 0.15
3912017-03-09T19:19:55 <luke-jr> oh, duh
3922017-03-09T19:20:09 <luke-jr> so why wouldn't people held back by patches just rebase?
3932017-03-09T19:20:13 <luke-jr> to 0.12.1
3942017-03-09T19:20:24 <wumpus> 0.12.0 can easily upgrad to 0.12.1, 0.11.x maybe less so
3952017-03-09T19:20:47 <btcdrak> considering there's an alert message broadcasting to all those vulnerable nodes right now saying they should upgrade, I think we've probably done enough.
3962017-03-09T19:20:55 <wumpus> not going to do a new 0.11.x release though
3972017-03-09T19:21:55 <luke-jr> get and publish a CVE, then 2 weeks later publish the key
3982017-03-09T19:21:57 <luke-jr> ?
3992017-03-09T19:22:23 <wumpus> I guess we could push a patch to the 0.11 branch that disables the alert system
4002017-03-09T19:22:33 <gmaxwell> it's a trivial patch.
4012017-03-09T19:22:40 <wumpus> yes
4022017-03-09T19:22:42 <achow101> luke-jr: +1
4032017-03-09T19:22:44 *** adiabat has quit IRC
4042017-03-09T19:23:08 <gmaxwell> nothing before 0.8 still works at all, and the 0.9x nodes I have looked at are all fake.
4052017-03-09T19:23:21 <gmaxwell> 0.10 / 0.11 are probably still running in practice.
4062017-03-09T19:23:56 <gmaxwell> luke-jr: okay fine with CVE and we can patch the old branch. thats enough plan for me for now.
4072017-03-09T19:24:11 <wumpus> it's a one-line patch, could even do a tag, just not going to build executables for them anymore
4082017-03-09T19:25:55 <gmaxwell> Thanks.
4092017-03-09T19:26:44 <sipa> sgtm
4102017-03-09T19:27:10 <achow101> I suppose the bitcoin.org alert page should be updated with that info then
4112017-03-09T19:27:11 <jtimon> I'm happy to review any backports for an alert patch, even if they're old, won't go below 0.8, sorry
4122017-03-09T19:28:29 <btcdrak> everything from 0.10 and below is EOL https://bitcoincore.org/en/lifecycle/#schedule
4132017-03-09T19:29:06 <sipa> btcdrak: 0.14 should be added to that page
4142017-03-09T19:29:29 <btcdrak> sipa: https://github.com/bitcoin-core/bitcoincore.org/pull/347
4152017-03-09T19:29:45 <gmaxwell> what other subjects?
4162017-03-09T19:30:54 <cfields> Is there a timeline for 0.14.1? Or just when deemed necessary?
4172017-03-09T19:31:07 <achow101> it seems that 0.10 is the only one that needs an alert disabling patch. 0.11 already has it, just not tagged
4182017-03-09T19:31:22 <wumpus> cfields: eh not really; any pressing reason you'd want one right away?
4192017-03-09T19:32:05 <wumpus> the more-than-8-addnode hang at shutdown problem is annoying but not enough to warrant an immediate release
4202017-03-09T19:32:10 <gmaxwell> I don't see a reason one couldn't wait a few weeks, though we do have material for one.
4212017-03-09T19:32:17 <cfields> wumpus: nope, just couldn't remember if we usually set a date or just wing it
4222017-03-09T19:32:29 <wumpus> no, we never set dates in advance for minor releases
4232017-03-09T19:32:46 <wumpus> for 0.15 I've posted the release schedule: https://github.com/bitcoin/bitcoin/issues/9961
4242017-03-09T19:33:09 <gmaxwell> I'm sure that some more things will show up for 0.14.1 in not too long as people start using some of the new features.
4252017-03-09T19:33:35 <wumpus> yes
4262017-03-09T19:33:36 <achow101> I feel like those should have been caught during RCs..
4272017-03-09T19:33:47 <wumpus> 'should have been'
4282017-03-09T19:33:54 <BlueMatt> #9959 and #9955 are interesting for 0.14.1
4292017-03-09T19:33:56 <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
4302017-03-09T19:33:57 <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
4312017-03-09T19:34:33 <wumpus> there's always issues in major releases that only get found when the final is tagged, it's a fact of life
4322017-03-09T19:34:42 <gmaxwell> achow101: any kind of bug that requires special configuration to find is much less likely to get caught, this is why you hear groans when people propose solving problems with more config options. :)
4332017-03-09T19:34:46 <wumpus> no number of rcs can solve that
4342017-03-09T19:34:46 <luke-jr> 9955 is more of a new feature IMO, but I don't care if people want to backport it
4352017-03-09T19:34:58 <morcos> agreed, we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release
4362017-03-09T19:35:08 <wumpus> ok tagging them
4372017-03-09T19:36:13 <cfields> wumpus: 0.15 schedule sgtm.
4382017-03-09T19:36:36 <luke-jr> note that backporting 9955 is likely a hazard since priority mining doesn't pay attention to fIncludeWitness I think
4392017-03-09T19:36:38 <wumpus> cfields: thanks, good to know
4402017-03-09T19:37:03 <luke-jr> should be a trivial thing to fix, but might not conflict
4412017-03-09T19:37:43 <achow101> are we going to do the release notes wiki thing again?
4422017-03-09T19:38:03 <wumpus> yes, at the end of the 0.15 release cycle
4432017-03-09T19:38:22 <achow101> ok
4442017-03-09T19:38:42 <sdaftuar> priority mining did pay attention to fIncludeWitness, so i think it would be fine, but i haven't tested
4452017-03-09T19:39:28 *** JackH has quit IRC
4462017-03-09T19:39:33 <wumpus> achow101: I think it worked quite well; the only problem that came up is merging it with that is in the tree. So better to leave it until the end when people start caring about writing release notes, and until then leave it up to pulls to add something there
4472017-03-09T19:39:47 <luke-jr> oh, it's tested in a different place, okay
4482017-03-09T19:41:48 <achow101> anything else?
4492017-03-09T19:43:25 <sipa> seems not
4502017-03-09T19:44:31 <wumpus> I don't think so
4512017-03-09T19:44:45 <wumpus> #endmeeting
4522017-03-09T19:44:45 <lightningbot> Meeting ended Thu Mar 9 19:44:45 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4532017-03-09T19:44:45 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html
4542017-03-09T19:44:45 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.txt
4552017-03-09T19:44:45 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.log.html
4562017-03-09T19:44:47 <achow101> a reminder that daylight savings time in the US begins this weekend so next week's meeting will be an hour later local time
4572017-03-09T19:45:23 <jl2012> Oh ended?
4582017-03-09T19:45:41 <jtimon> do you have a topic?
4592017-03-09T19:45:53 <jl2012> #9443
4602017-03-09T19:45:55 <gribble> https://github.com/bitcoin/bitcoin/issues/9443 | Repairing the large-work fork warning system by jl2012 · Pull Request #9443 · bitcoin/bitcoin · GitHub
4612017-03-09T19:45:55 <wumpus> here starting from march 26
4622017-03-09T19:46:32 <jl2012> This was tagged 0.14
4632017-03-09T19:46:46 <jl2012> Want to see any chance for 0.15
4642017-03-09T19:47:50 <jtimon> for some reason I thought that needed rebase
4652017-03-09T19:48:22 <jl2012> Rebased already
4662017-03-09T19:48:42 <jtimon> yeah, I see, thanks for the heads up, will review
4672017-03-09T19:48:53 *** Guyver2 has joined #bitcoin-core-dev
4682017-03-09T19:49:25 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/9cea1698132ab68b0d6b204ff5c8d154d9192b19
4692017-03-09T19:49:26 <bitcoin-git> bitcoin/0.10 9cea169 Wladimir J. van der Laan: net: Disable P2P alert system
4702017-03-09T19:49:36 <sdaftuar> jl2012: if i understand correctly, that PR would cause us to not ban peers who are on an incompatible chain?
4712017-03-09T19:50:00 <jl2012> It should ban
4722017-03-09T19:50:00 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/0bace8307995ac2911885c7c8b8dec19b864eaa3
4732017-03-09T19:50:00 <bitcoin-git> bitcoin/0.11 0bace83 Wladimir J. van der Laan: net: Disable P2P alert system
4742017-03-09T19:50:24 <sdaftuar> ah, i will re-read more carefully
4752017-03-09T19:50:34 <jl2012> It just stirs the header
4762017-03-09T19:50:49 *** JackH has joined #bitcoin-core-dev
4772017-03-09T19:50:52 <jl2012> Stores
4782017-03-09T19:50:53 <achow101> wumpus: coulda just set DEFAULT_ALERTS to false
4792017-03-09T19:51:14 <wumpus> achow101:did that exist in 0.10 and 0.11?
4802017-03-09T19:51:17 <achow101> yes
4812017-03-09T19:51:21 <achow101> 0.11 had it false too
4822017-03-09T19:51:26 <achow101> (but not tagged)
4832017-03-09T19:51:33 <wumpus> achow101: anyhow, this is complete and clear
4842017-03-09T19:53:13 <achow101> indeed
4852017-03-09T19:54:10 <jl2012> sdaftuar: it does not ban for sending header for childs of an invalid block
4862017-03-09T19:55:11 <wumpus> going to tag v0.11.3 and v0.10.5
4872017-03-09T19:55:21 <btcdrak> wumpus: ~1
4882017-03-09T19:55:23 <btcdrak> +1
4892017-03-09T19:55:23 <sdaftuar> jl2012: ah, ok. right now, banning peers who are on an incompatible chain is used to avoid being partitioned from the peers who share our consensus rules.
4902017-03-09T19:55:25 <wumpus> no RCs necessary for this, I'd say
4912017-03-09T19:55:38 <sdaftuar> jl2012: there's some discussion of this in #9530
4922017-03-09T19:55:39 <gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
4932017-03-09T19:57:37 <sdaftuar> jl2012: i think we can replace the banning with something else, like rotating outbound connections periodically and try dropping any outbound peers on an incompatible chain in favor of a new outbound peer, but i think we'd need to write that code first before we change the DoS banning behavior we have now
4942017-03-09T19:57:43 <btcdrak> wumpus: what is the EOL date for 0.12?
4952017-03-09T19:57:44 <kanzure> if some python-bitcoinlib users want to do some code review, here's a mock for bitcoin.rpc.Proxy-- https://github.com/petertodd/python-bitcoinlib/pull/136
4962017-03-09T19:57:57 *** chjj has joined #bitcoin-core-dev
4972017-03-09T19:58:43 <sdaftuar> jl2012: i am hoping to work on the topics in #9530 for 0.15 though, if possible
4982017-03-09T19:58:44 <gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
4992017-03-09T19:58:56 <wumpus> btcdrak: wouldn't that normally be the 0.14 release date?
5002017-03-09T19:59:16 <kanzure> oh, i assumed the meeting was over. 'scuse me.
5012017-03-09T19:59:25 <wumpus> yes, the meeting is closed
5022017-03-09T19:59:47 <wumpus> kanzure: will take a look
5032017-03-09T20:00:19 <kanzure> i don't think it's directly usable in bitcoin.git because the rpc tests need to actually use real rpc :) (and also we're not using petertodd/python-bitcoinlib in bitcoin rpc tests anyway)
5042017-03-09T20:00:19 <jl2012> sdaftuar: maybe giving a score lower than 100 for sending child of invalid block?
5052017-03-09T20:00:44 <jl2012> Before we have a new DoS system
5062017-03-09T20:01:30 <sipa> please, no more dos scoring
5072017-03-09T20:03:49 <jl2012> So the plan is completely removing that?
5082017-03-09T20:08:54 <sipa> i think so. things are either invalid and expensive, in which case we ban, or not, and we don't ban
5092017-03-09T20:09:45 <sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion, seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
5102017-03-09T20:11:56 <morcos> sipa: that wasn't super clear
5112017-03-09T20:12:08 <morcos> there is expensive to produce and expensive to consume
5122017-03-09T20:12:12 <morcos> both matter
5132017-03-09T20:14:30 <sipa> right, ratio between cost to the attacker and cost to us is what matters
5142017-03-09T20:17:30 <btcdrak> wumpus: yes maintenance end will be when 0.14 is released, but what about EOL.
5152017-03-09T20:18:06 <wumpus> btcdrak: what did we use for other releases?
5162017-03-09T20:18:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/5703dff0939f...8910b4717e5b
5172017-03-09T20:18:45 <bitcoin-git> bitcoin/master 0e6d23d John Newbery: Add logging to test_framework.py...
5182017-03-09T20:18:45 <bitcoin-git> bitcoin/master 553a976 John Newbery: Add logging to p2p-segwit.py
5192017-03-09T20:18:46 <bitcoin-git> bitcoin/master 6d0e325 John Newbery: Use logging in mininode.py...
5202017-03-09T20:18:50 <wumpus> I guess it's just maintenance end date + something?
5212017-03-09T20:19:03 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9768: [qa] Add logging to test_framework.py (master...rpctestlogging) https://github.com/bitcoin/bitcoin/pull/9768
5222017-03-09T20:19:57 <btcdrak> wumpus: seems to be around ~2 years.
5232017-03-09T20:21:33 <wumpus> btcdrak: sounds good to me
5242017-03-09T20:23:38 *** JackH has quit IRC
5252017-03-09T20:24:00 <btcdrak> wumpus:https://github.com/bitcoin-core/bitcoincore.org/pull/347/files
5262017-03-09T20:25:40 <wumpus> btcdrak: looks good to me
5272017-03-09T20:27:29 * luke-jr peers at race conditions not fixed by adding atomic<>
5282017-03-09T20:27:47 *** wudayoda_ has joined #bitcoin-core-dev
5292017-03-09T20:27:57 *** wudayoda has quit IRC
5302017-03-09T20:29:29 <gmaxwell> sipa: we can have another mechenism unrelated to DOS to make sure peers on incompatible chains aren't wasiting our slots and contributing to partioning us. Bans are a dumb way to accomplish that.
5312017-03-09T20:30:03 <wumpus> just kicking is usually enough
5322017-03-09T20:30:17 <sipa> gmaxwell: that's exactly what i said
5332017-03-09T20:30:23 <sipa> 12:09:44 < sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion,
5342017-03-09T20:30:26 <sipa> seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
5352017-03-09T20:30:32 <wumpus> only spy nodes are persistent enough to keep reconnecting to the same nodes
5362017-03-09T20:30:40 <gmaxwell> ah I missed the 'seemingly on the same chain'.
5372017-03-09T20:32:38 <gmaxwell> e.g. we can easily tell when a peer is on a chain we consider recently invalid. (if they advertise a block to us, we'll fetch back its headers, and eventually find it as a child of a block we rejected as invalid)
5382017-03-09T20:32:50 <gmaxwell> at that point he should be ranked as first to get dropped.
5392017-03-09T20:33:34 <sipa> right
5402017-03-09T20:34:55 <gmaxwell> can just be a flag, that gets set when we see he's on an invalid chain, unset if we get a valid block from him. and connection rotation could strictly prefer to punt ... all obvious.
5412017-03-09T20:43:42 <luke-jr> tfw you rebase something just to realise you forgot to pull master
5422017-03-09T20:48:43 <wumpus> 'well, that was easy!' 'oh no...'
5432017-03-09T21:11:26 *** CubicEarth has joined #bitcoin-core-dev
5442017-03-09T21:15:42 *** CubicEarth has quit IRC
5452017-03-09T21:18:25 *** CubicEarth has joined #bitcoin-core-dev
5462017-03-09T21:32:39 *** CubicEarth has quit IRC
5472017-03-09T21:35:02 *** CubicEarth has joined #bitcoin-core-dev
5482017-03-09T21:37:43 *** CubicEarth has quit IRC
5492017-03-09T21:44:26 *** MarcoFalke has left #bitcoin-core-dev
5502017-03-09T22:18:36 <luke-jr> I think #8694 needs fresh re-reviews :x
5512017-03-09T22:18:37 <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
5522017-03-09T22:19:19 *** randy-waterhouse has joined #bitcoin-core-dev
5532017-03-09T22:19:24 <bitcoin-git> [bitcoin] jnewbery opened pull request #9966: Control mempool persistence using a command line parameter (master...mempoolpersistenceoption) https://github.com/bitcoin/bitcoin/pull/9966
5542017-03-09T22:19:37 *** randy-waterhouse has quit IRC
5552017-03-09T22:19:37 *** randy-waterhouse has joined #bitcoin-core-dev
5562017-03-09T22:46:26 *** Guyver2 has quit IRC
5572017-03-09T22:46:53 *** gribble has quit IRC
5582017-03-09T23:01:33 *** wasi has quit IRC
5592017-03-09T23:01:58 *** wasi has joined #bitcoin-core-dev
5602017-03-09T23:29:00 *** gribble has joined #bitcoin-core-dev
5612017-03-09T23:30:48 <gmaxwell> apparently the latest electrum nags you to opt into RBF if you tell it to pay a low fee.
5622017-03-09T23:31:44 <dcousens_> gmaxwell: suprising, I'd of thought CPFP would be the easier route
5632017-03-09T23:32:09 <dcousens_> aka, UX escape hatch
5642017-03-09T23:33:05 <gmaxwell> dcousens_: CPFP is not that useful.
5652017-03-09T23:33:14 <gmaxwell> Requires that you have change, and involves 2x the transaction data.
5662017-03-09T23:33:21 <gmaxwell> I mean, it's useful, but RBF is more useful.
5672017-03-09T23:33:35 <dcousens_> gmaxwell: true, just remembered as you wrote that it would require the change
5682017-03-09T23:33:49 <gmaxwell> Think: you were trying to pay low fees and now you have to pay twice a high fee. .. and you don't even always have the option.
5692017-03-09T23:35:37 <BlueMatt> gmaxwell: that seems like a reasonable route
5702017-03-09T23:36:08 <gmaxwell> 15:34 < cbits_> gmaxwell: yep, if you slide the fee slider all the way to the left, the rbf box becomes visible and automatically checked. :-)
5712017-03-09T23:36:26 <dcousens_> gmaxwell: so RBF doesn't show unless its low fee?
5722017-03-09T23:36:29 <luke-jr> CPFP is more useful for the recipient than the sender, really.
5732017-03-09T23:36:47 <luke-jr> prompting to enable RBF for fallback fee seems like a good idea for Core
5742017-03-09T23:36:51 <gmaxwell> dcousens_: no, you could set it to default on in the prior version, but few users did until it was too late.
5752017-03-09T23:39:59 *** cbits_ has joined #bitcoin-core-dev
5762017-03-09T23:43:14 <cbits_> Electrum uses dynamic fees by default now. The last two slider options for fee preference are within 10 blocks, or within 25 blocks. The within 25 blocks option makes the rbf box visible and sets it on.
5772017-03-09T23:43:44 *** wudayoda_ has quit IRC
5782017-03-09T23:44:21 *** wudayoda has joined #bitcoin-core-dev
5792017-03-09T23:45:22 <luke-jr> cbits_: why isn't it always visible?
5802017-03-09T23:45:58 *** aalex__ has quit IRC
5812017-03-09T23:46:08 <cbits_> Not sure, probably to be neutral. Less boxes for users to check or figure out. You can make it always visible in settings.
5822017-03-09T23:46:44 <luke-jr> i c
5832017-03-09T23:48:53 *** gribble has quit IRC
5842017-03-09T23:56:25 <achow101> luke-jr: it can be set to always be visible
5852017-03-09T23:57:10 *** justanotheruser has quit IRC
5862017-03-09T23:59:20 *** justanotheruser has joined #bitcoin-core-dev