1 2017-03-09 00:26:13	0|MarcoFalke|funny how the release announcement on twitter comes with a screenshot of java script code
  2 2017-03-09 00:26:31	0|gmaxwell|I laughed at that too.
  3 2017-03-09 00:26:54	0|MarcoFalke|it should come with a screenshot of the four redundant indentation levels
  4 2017-03-09 00:27:35	0|sipa|where does that picture come from?
  5 2017-03-09 00:27:43	0|sipa|it's not in the URL linked to
  6 2017-03-09 00:27:52	0|achow101|who controls the account?
  7 2017-03-09 00:28:09	0|MarcoFalke|maybe ask btcdrak
  8 2017-03-09 00:28:41	0|btcdrak|LOL, google image search
  9 2017-03-09 00:28:42	0|gmaxwell|there was some popular press article with that picture.
 10 2017-03-09 00:28:57	0|gmaxwell|oh no, actually a similar one.
 11 2017-03-09 00:29:08	0|gmaxwell|btcdrak: don't do that, for one-- copyright problems. :P
 12 2017-03-09 00:31:13	0|MarcoFalke|jonasschnelli:  has a nice one: https://bitcoin.jonasschnelli.ch/img/header.jpg
 13 2017-03-09 00:31:40	0|MarcoFalke|Needs more colors, though.
 14 2017-03-09 00:31:54	0|btcdrak|yeah
 15 2017-03-09 01:05:38	0|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.
 16 2017-03-09 01:06:46	0|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.)
 17 2017-03-09 01:08:07	0|gmaxwell|https://0bin.net/paste/zGcQVRFoTt7rsaZH#ZI5dYJ4GVIWYRFmeKzPQ6C3lorBGQ7LV6IrePetem2z  the 'threat'
 18 2017-03-09 01:08:32	0|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.
 19 2017-03-09 01:30:57	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (06master...062017-03-cnb-optimizations) 02https://github.com/bitcoin/bitcoin/pull/9959
 20 2017-03-09 01:37:13	0|gmaxwell|jeremyrubin: I can't make sense of your comment on #9955
 21 2017-03-09 01:37:14	0|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.
 22 2017-03-09 01:44:52	0|isle2983|plug for a bitcoin-maintainer-tools PR I just submitted:
 23 2017-03-09 01:44:57	0|isle2983|https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/10
 24 2017-03-09 01:45:33	0|isle2983|it is a set of functionality previously submitted to contrib/devtool, but closed because it was decided that was the wrong spot
 25 2017-03-09 01:46:11	0|isle2983|the pointer was to bitcoin-maintainer-tools, so I ran with that
 26 2017-03-09 01:46:31	0|isle2983|the scripts use a common shared framework
 27 2017-03-09 01:47:00	0|isle2983|hopefully it will help accelerate further automation in the future
 28 2017-03-09 02:33:24	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (06master...06consthd) 02https://github.com/bitcoin/bitcoin/pull/9960
 29 2017-03-09 03:50:03	0|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
 30 2017-03-09 03:50:24	0|jeremyrubin|gmaxwell: e.g., to keep room for the most-fee nonsegwit txns
 31 2017-03-09 04:12:30	0|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?
 32 2017-03-09 04:15:37	0|jeremyrubin|this still applies
 33 2017-03-09 04:15:46	0|jeremyrubin|they will make more money evicting segwit txs
 34 2017-03-09 04:25:45	0|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
 35 2017-03-09 05:12:44	0|jeremyrubin|luke-jr: false. they can still validate segwit blocks.
 36 2017-03-09 05:13:01	0|jeremyrubin|luke-jr: and check the witnesses (full validation)
 37 2017-03-09 05:13:08	0|luke-jr|jeremyrubin: all miners need to validate segwit blocks once it activates; that's not support, it's just mining
 38 2017-03-09 05:18:38	0|jeremyrubin|that's not completely true.
 39 2017-03-09 05:18:55	0|jeremyrubin|A miner can mine a non segwit block, it will just get orphaned by the segwit-mining majority
 40 2017-03-09 05:19:42	0|jeremyrubin|(if any of the txs have a witness)
 41 2017-03-09 05:20:22	0|jeremyrubin|and even in that case, such a miner might not want segwit transactions in their mempool if they can't mine them?
 42 2017-03-09 05:24:29	0|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.
 43 2017-03-09 05:31:22	0|jeremyrubin|warren: that sentence doesn't say anything
 44 2017-03-09 05:32:31	0|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
 45 2017-03-09 05:34:27	0|warren|jeremyrubin: pre-segwit nodes see segwit transactions as non-standard and it won't enter the mempool to begin with
 46 2017-03-09 05:36:21	0|warren|nevermind, I don't care enough about this to continue
 47 2017-03-09 05:37:45	0|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
 48 2017-03-09 05:37:47	0|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.
 49 2017-03-09 05:39:14	0|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)
 50 2017-03-09 05:40:53	0|luke-jr|jeremyrubin: it would be fairly irresponsible for a miner to have a mere 10 MB mempool in the first place..
 51 2017-03-09 05:41:27	0|luke-jr|the default of 300 MB is for non-mining nodes
 52 2017-03-09 05:42:41	0|jeremyrubin|luke-jr: was only for convenience picking a number.
 53 2017-03-09 05:43:00	0|luke-jr|point is they should have more than enough
 54 2017-03-09 05:43:03	0|jeremyrubin|no
 55 2017-03-09 05:43:44	0|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
 56 2017-03-09 05:44:48	0|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
 57 2017-03-09 05:45:00	0|jeremyrubin|all txns will be selected from that range always
 58 2017-03-09 05:46:00	0|jeremyrubin|so then, I issue 290 MB of txns that are at 9 sat/byte, with segwit, such that they won't be mined
 59 2017-03-09 05:46:37	0|jeremyrubin|let's say I also have a bunch on non-segwit txns at 9 sat/byte
 60 2017-03-09 05:46:49	0|jeremyrubin|I can push them out with my segwit txns
 61 2017-03-09 05:47:29	0|jeremyrubin|so that your less well resourced miner now has a mempool full of txns you can't mine
 62 2017-03-09 06:19:42	0|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.
 63 2017-03-09 06:20:35	0|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)
 64 2017-03-09 06:21:45	0|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.
 65 2017-03-09 06:22:54	0|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.
 66 2017-03-09 06:22:56	0|luke-jr|gmaxwell: I'm saying a small mempool is bad..
 67 2017-03-09 06:23:01	0|gmaxwell|oh okay!
 68 2017-03-09 06:23:22	0|gmaxwell|I had read your comment backwards.
 69 2017-03-09 06:23:51	0|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)
 70 2017-03-09 06:27:45	0|jeremyrubin|gmaxwell: that's fair; what I'm suggesting might be better off as a startup time argument
 71 2017-03-09 06:28:42	0|jeremyrubin|gmaxwell: I also think that you can relay a txn w/o having it in your mempool (e.g., to your immediate peers)
 72 2017-03-09 06:29:19	0|jeremyrubin|gmaxwell: w.r.t. fee estimation, you could collect the fee estimate information for such transactions without storing them
 73 2017-03-09 06:29:23	0|sipa|jeremyrubin: BIP152 relay speed depends on having transactions in your mempool
 74 2017-03-09 06:29:31	0|sipa|(or at least, stored somewhere)
 75 2017-03-09 06:29:32	0|gmaxwell|jeremyrubin: not as soon as there is a dependency, and we also use the mempool as a dynamic rate control.
 76 2017-03-09 06:29:45	0|jeremyrubin|yes, as I said, compact blocks is the place where it does make sense to keep them
 77 2017-03-09 06:30:17	0|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.
 78 2017-03-09 06:30:58	0|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.
 79 2017-03-09 06:32:19	0|jeremyrubin|yeah; this would only make sense where you know that none of your calls would need it
 80 2017-03-09 07:13:33	0|bitcoin-git|13bitcoin/06master 148a52281 15Karl-Johan Alm: Refactor: Remove using namespace <xxx> from wallet/
 81 2017-03-09 07:13:33	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6996e066b538...c047b1663d47
 82 2017-03-09 07:13:34	0|bitcoin-git|13bitcoin/06master 14a57845c 15Karl-Johan Alm: Refactor: Remove using namespace <xxx> from util*
 83 2017-03-09 07:13:35	0|bitcoin-git|13bitcoin/06master 14c047b16 15Wladimir J. van der Laan: Merge #9643: [refactor] Remove using namespace <xxx> from wallet/ & util*...
 84 2017-03-09 07:13:49	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9643: [refactor] Remove using namespace <xxx> from wallet/ & util* (06master...06no-using-namespace-wallet-util) 02https://github.com/bitcoin/bitcoin/pull/9643
 85 2017-03-09 07:16:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c047b1663d47...8152d3fe57a9
 86 2017-03-09 07:16:09	0|bitcoin-git|13bitcoin/06master 148cbfc4e 15Karl-Johan Alm: Refactor: Remove using namespace <xxx> from script/
 87 2017-03-09 07:16:09	0|bitcoin-git|13bitcoin/06master 14f3c264e 15Karl-Johan Alm: Refactor: Remove using namespace <xxx> from rpc/
 88 2017-03-09 07:16:10	0|bitcoin-git|13bitcoin/06master 148152d3f 15Wladimir J. van der Laan: Merge #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources...
 89 2017-03-09 07:16:19	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources (06master...06no-using-namespace-rpc-script) 02https://github.com/bitcoin/bitcoin/pull/9476
 90 2017-03-09 07:28:19	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (06master...06RPC_refactor) 02https://github.com/bitcoin/bitcoin/pull/9958
 91 2017-03-09 07:49:39	0|wumpus|okay, that removes the last uses of "using namespace" in the code (apart from one in the tests)
 92 2017-03-09 07:50:18	0|sipa|nice
 93 2017-03-09 07:51:22	0|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
 94 2017-03-09 07:53:13	0|paveljanik|small pain for big gain!
 95 2017-03-09 09:01:26	0|bitcoin-git|13bitcoin/06master 1454fae05 15practicalswift: Remove unreachable code (g_rpcSignals.PostCommand)
 96 2017-03-09 09:01:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8152d3fe57a9...6805c4112cfd
 97 2017-03-09 09:01:27	0|bitcoin-git|13bitcoin/06master 146805c41 15Wladimir J. van der Laan: Merge #9575: Remove unused, non-working RPC PostCommand signal...
 98 2017-03-09 09:01:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9575: Remove unused, non-working RPC PostCommand signal (06master...06never-executed-comment) 02https://github.com/bitcoin/bitcoin/pull/9575
 99 2017-03-09 09:02:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6805c4112cfd...02bd6e9bc6de
100 2017-03-09 09:02:40	0|bitcoin-git|13bitcoin/06master 146d07c62 15John Newbery: Return correct error codes in bumpfee()....
101 2017-03-09 09:02:40	0|bitcoin-git|13bitcoin/06master 14c119096 15John Newbery: Return correct error codes in blockchain.cpp....
102 2017-03-09 09:02:41	0|bitcoin-git|13bitcoin/06master 14960bc7f 15John Newbery: Return correct error codes in removeprunedfunds()....
103 2017-03-09 09:03:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9853: Fix error codes from various RPCs (06master...06fixerrorcodes) 02https://github.com/bitcoin/bitcoin/pull/9853
104 2017-03-09 09:03:16	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/02bd6e9bc6de...b403ec5c0f2f
105 2017-03-09 09:03:17	0|bitcoin-git|13bitcoin/06master 14292112f 15kobake: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
106 2017-03-09 09:03:18	0|bitcoin-git|13bitcoin/06master 148e0720b 15kobake: Fix msvc compiler error C4146 (unary minus operator applied to unsigned type)...
107 2017-03-09 09:03:18	0|bitcoin-git|13bitcoin/06master 14b403ec5 15Wladimir J. van der Laan: Merge #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
108 2017-03-09 09:03:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type) (06master...06fix-minus-operator-target-for-msvc-c4146) 02https://github.com/bitcoin/bitcoin/pull/9916
109 2017-03-09 09:20:00	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9962: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06 (06master...06fix-typo-in-protocol-h) 02https://github.com/bitcoin/bitcoin/pull/9962
110 2017-03-09 09:27:59	0|bitcoin-git|13bitcoin/06master 143cef950 15NicolasDorier: Trivial: Add const modifier to GetHDChain and IsHDEnabled
111 2017-03-09 09:27:59	0|bitcoin-git|13bitcoin/06master 14c71f0ca 15Wladimir J. van der Laan: Merge #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled...
112 2017-03-09 09:27:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b403ec5c0f2f...c71f0ca5f839
113 2017-03-09 09:28:17	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (06master...06consthd) 02https://github.com/bitcoin/bitcoin/pull/9960
114 2017-03-09 09:33:50	0|bitcoin-git|13bitcoin/06master 1453a2ba3 15practicalswift: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)
115 2017-03-09 09:33:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c71f0ca5f839...e3e7db829ecd
116 2017-03-09 09:33:51	0|bitcoin-git|13bitcoin/06master 14e3e7db8 15Wladimir J. van der Laan: Merge #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)...
117 2017-03-09 09:34:03	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr) (06master...06remove-redundant-get-on-smartptr) 02https://github.com/bitcoin/bitcoin/pull/9538
118 2017-03-09 10:42:31	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9963: util: Properly handle errors during log message formatting (06master...062017_03_handle_exception_tinyformat) 02https://github.com/bitcoin/bitcoin/pull/9963
119 2017-03-09 11:02:29	0|jonasschnelli|I still try to understand why importing a P2PKH address into the wallet leads to ISMINE_WATCH_UNSOLVABLE (and not ISMINE_WATCH_SOLVABLE).
120 2017-03-09 11:02:42	0|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"
121 2017-03-09 11:03:37	0|jonasschnelli|Isn't this true for P2PKH (== importaddress could identify P2PKH)?
122 2017-03-09 11:06:42	0|luke-jr|I suspect the requirement of the public key might play a part
123 2017-03-09 11:06:52	0|luke-jr|you could calculate it from the private key, but that may not count
124 2017-03-09 11:13:28	0|jonasschnelli|luke-jr: Yes. When I import a pubkey it will marke the P2PKH watch-only as solveble.
125 2017-03-09 11:13:52	0|jonasschnelli|But I don't see a clear reason for that. I understand that for P2SH but not for P2PKH...
126 2017-03-09 11:34:56	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e3e7db829ecd...5703dff0939f
127 2017-03-09 11:34:57	0|bitcoin-git|13bitcoin/06master 149ea2490 15practicalswift: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06...
128 2017-03-09 11:34:58	0|bitcoin-git|13bitcoin/06master 145703dff 15MarcoFalke: Merge #9962: [trivial] Fix typo in rpc/protocol.h...
129 2017-03-09 11:35:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9962: [trivial] Fix typo in rpc/protocol.h (06master...06fix-typo-in-protocol-h) 02https://github.com/bitcoin/bitcoin/pull/9962
130 2017-03-09 12:01:54	0|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.
131 2017-03-09 12:01:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/9951 | Wallet database handling abstractions/simplifications by laanwj · Pull Request #9951 · bitcoin/bitcoin · GitHub
132 2017-03-09 12:47:41	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9964: Add const to methods that do not modify the object for which it is called (06master...06const) 02https://github.com/bitcoin/bitcoin/pull/9964
133 2017-03-09 13:17:46	0|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?
134 2017-03-09 13:18:16	0|wumpus|seems that a dump may be incomplete if it could not find all keys
135 2017-03-09 13:30:38	0|wumpus|(not that I've ever seen an instance of that problem, but I just wonder that seeing the code)
136 2017-03-09 14:00:16	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9965: Allow to use unsolveable P2PKH watch-only in fundrawtransaction (06master...062017/03/watch_solve) 02https://github.com/bitcoin/bitcoin/pull/9965
137 2017-03-09 19:00:33	0|sipa|ploink
138 2017-03-09 19:00:44	0|wumpus|#startmeeting
139 2017-03-09 19:00:45	0|lightningbot|Meeting started Thu Mar  9 19:00:43 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
140 2017-03-09 19:00:45	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
141 2017-03-09 19:00:48	0|jonasschnelli|hi
142 2017-03-09 19:01:03	0|sipa|short topic: great work on 0.14 all!
143 2017-03-09 19:01:09	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
144 2017-03-09 19:01:09	0|wumpus|instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
145 2017-03-09 19:01:21	0|wumpus|yes! congrats all on another great release
146 2017-03-09 19:01:39	0|btcdrak|+1
147 2017-03-09 19:02:10	0|morcos|yes i feel like we did a good job getting most of the major things we wanted into it!
148 2017-03-09 19:02:17	0|BlueMatt|net seems to have really helped a lot
149 2017-03-09 19:02:52	0|achow101|hi
150 2017-03-09 19:03:03	0|wumpus|proposed topic: disclosure of alert key (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1534 reminded me)
151 2017-03-09 19:03:18	0|gmaxwell|Hi.
152 2017-03-09 19:03:50	0|gmaxwell|There are DOS vulnerablities in older verions that the final alert does not block. :(
153 2017-03-09 19:03:56	0|wumpus|#topic alert key disclosure timeline
154 2017-03-09 19:04:07	0|sipa|gmaxwell: below what version?
155 2017-03-09 19:04:14	0|gmaxwell|(unfortunately the old code is stupid)
156 2017-03-09 19:04:19	0|achow101|what kind of DOS vulns?
157 2017-03-09 19:04:23	0|gmaxwell|All versions. They're worse in older ones.
158 2017-03-09 19:04:40	0|gmaxwell|(obviously all versions with alerts enabled)
159 2017-03-09 19:04:52	0|sipa|when was that changed?
160 2017-03-09 19:04:54	0|wumpus|yes, what kind? just a slowdown, or a crash, or potential remote code execution?
161 2017-03-09 19:05:02	0|sipa|OOM
162 2017-03-09 19:05:06	0|gmaxwell|No RCE, just OOM.
163 2017-03-09 19:05:43	0|btcdrak|so versions <0.12.0 affected?
164 2017-03-09 19:05:53	0|wumpus|well. some versions have already been marked as "insecure" on bitcoin.org due to other bugs. Let me see what the threshold is.
165 2017-03-09 19:06:11	0|sipa|when was the alert feature disabled by default?
166 2017-03-09 19:06:18	0|achow101|0.12.1
167 2017-03-09 19:06:30	0|btcdrak|oh
168 2017-03-09 19:06:41	0|BlueMatt|wumpus: we have a list somewhere?
169 2017-03-09 19:06:47	0|sipa|are there any major altcoins forked before 0.12 that did not change the alaert key?
170 2017-03-09 19:07:01	0|wumpus|https://bitcoin.org/bin/insecure/
171 2017-03-09 19:07:02	0|gmaxwell|All the 0.14 nodes sending final alerts constantly is somewhat protective, but unforuntately not absoltely protective.
172 2017-03-09 19:07:24	0|gmaxwell|sipa: already looked for that, there were no major ones, but some obscure & dead ones that have been nagged.
173 2017-03-09 19:07:42	0|gmaxwell|There are also funds paid to the alert key in the network, I believe 0.01 BTC or so. :P
174 2017-03-09 19:08:19	0|wumpus|heheh
175 2017-03-09 19:08:27	0|cfields|heh
176 2017-03-09 19:08:29	0|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).
177 2017-03-09 19:08:31	0|wumpus|surprised no one ever swiped that
178 2017-03-09 19:08:47	0|btcdrak|sipa: most altcoins are on <0.12 codebase, and many never changed the alter key
179 2017-03-09 19:08:55	0|gmaxwell|btcdrak: not so.
180 2017-03-09 19:09:10	0|wumpus|from what I've seen, altcoins generally do change the alert key, at least from the bitcoin one
181 2017-03-09 19:09:17	0|gmaxwell|btcdrak: (didn't change the _litecoin_ alert key, yes, but I searched extensively for this already, months ago.)
182 2017-03-09 19:09:18	0|wumpus|many have the litecoin or feathercoin key
183 2017-03-09 19:09:22	0|wumpus|yes :)
184 2017-03-09 19:09:44	0|sipa|ah
185 2017-03-09 19:09:48	0|btcdrak|ah yes, most coins forked from litecoin (and didnt change the network magic either)
186 2017-03-09 19:10:01	0|morcos|remind me again what the advantage is of disclosing the key?
187 2017-03-09 19:10:24	0|achow101|morcos: making the alert system entirely unreliable (as if it weren't already)
188 2017-03-09 19:10:27	0|gmaxwell|to not be responsible for someone else abusing it, among other things.
189 2017-03-09 19:10:42	0|gmaxwell|we don't believe the key is actually secure right now in any case.
190 2017-03-09 19:10:55	0|sipa|there is no hurry in disclosing it either
191 2017-03-09 19:11:12	0|sipa|just a nice to have to close that chapter
192 2017-03-09 19:11:19	0|wumpus|to force people to not use it anymore
193 2017-03-09 19:11:25	0|btcdrak|they key is useless now anyway that final alert is out.
194 2017-03-09 19:11:26	0|wumpus|and also for sake of history
195 2017-03-09 19:11:28	0|paveljanik|We can make people upgrade because of the planned alert key discolsure...
196 2017-03-09 19:11:39	0|luke-jr|not sure how litecoin alerts are affects if they use a different key
197 2017-03-09 19:11:43	0|gmaxwell|we can't make anyone upgrade, and even if we could we wouldn't. :)
198 2017-03-09 19:11:45	0|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
199 2017-03-09 19:11:53	0|wumpus|litecoin is not affected luke-jr - what they do is up to them
200 2017-03-09 19:12:14	0|btcdrak|wumpus: they also removed the alert system, but there's a lot on 0.10.x nodes in litecoin
201 2017-03-09 19:12:25	0|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.
202 2017-03-09 19:12:38	0|wumpus|yes, this was announced on a timeline
203 2017-03-09 19:12:58	0|morcos|right, so change the predetermined point to be further out...  the risk is only that someone blames us for nuisance right?
204 2017-03-09 19:13:03	0|achow101|maybe just push back the date even further until <0.12.1 nodes are even fewer?
205 2017-03-09 19:13:27	0|BlueMatt|yea, I would vote push another release given old 0.12.0 isnt otherwise insecure?
206 2017-03-09 19:13:34	0|wumpus|right, if anyone abuses the key now, they may blame us. If it is public knowledge not so much.
207 2017-03-09 19:13:36	0|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.
208 2017-03-09 19:13:54	0|morcos|Except of course we will be blamed if we make it public and someone creates nuisance with it!
209 2017-03-09 19:14:04	0|gmaxwell|BlueMatt: I believe it is otherwise insecure at a greater magnitude than the alert DOS attacks.
210 2017-03-09 19:14:08	0|paveljanik|gmaxwell, yes, and by emphasizing it, maybe people update...
211 2017-03-09 19:14:28	0|gmaxwell|Well anything that has alerts is displaying the hardcoded final alert now...
212 2017-03-09 19:14:34	0|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)
213 2017-03-09 19:14:43	0|btcdrak|so let's announce the vulnerability first that should motivate more people to upgrade old systems or disable the alert system.
214 2017-03-09 19:14:44	0|gmaxwell|which says something like (allcaps) warning alert key compromised! upgrade required!.
215 2017-03-09 19:14:55	0|jtimon|ACK "<sipa> there is no hurry in disclosing it either"
216 2017-03-09 19:15:35	0|luke-jr|gmaxwell: can you get a CVE assigned for one or more of the old DoS?
217 2017-03-09 19:15:39	0|gmaxwell|I think some of you are underestimating the cost of this thing... but sure, no rush required.
218 2017-03-09 19:15:46	0|wumpus|anyhow, everyone with the alert key could disclose it, even anonymously
219 2017-03-09 19:16:13	0|wumpus|don't even know who has it exactly so...
220 2017-03-09 19:16:15	0|luke-jr|yes, nobody can be blamed individually if nobody knows who disclosed it
221 2017-03-09 19:16:40	0|wumpus|anyhow, any other topics?
222 2017-03-09 19:17:29	0|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?
223 2017-03-09 19:17:29	0|luke-jr|FWIW, ignoring alert keys, I see 539 vulnerable nodes (0.94%)
224 2017-03-09 19:18:03	0|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%)
225 2017-03-09 19:18:38	0|wumpus|you can't be entirely sure that all of them are vulnerable, they may have patched the code to remove the alert system
226 2017-03-09 19:18:50	0|luke-jr|sure, but that's unlikely
227 2017-03-09 19:18:54	0|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.
228 2017-03-09 19:19:04	0|wumpus|many are running old versions to be able to run their own (outdated) patches on top
229 2017-03-09 19:19:27	0|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?
230 2017-03-09 19:19:33	0|luke-jr|if we're really worried, we could release a 0.12.2 with just those exploits fixed
231 2017-03-09 19:19:43	0|luke-jr|or maybe simply disabling alerts
232 2017-03-09 19:19:51	0|gmaxwell|luke-jr: 0.12.1 has them disabled.
233 2017-03-09 19:19:53	0|achow101|luke-jr: 0.12.1 already disabled alrets
234 2017-03-09 19:19:55	0|morcos|if it was me, i wouldn't do any of it...  lets put our effort where it matters.. 0.15
235 2017-03-09 19:19:57	0|luke-jr|oh, duh
236 2017-03-09 19:20:10	0|luke-jr|so why wouldn't people held back by patches just rebase?
237 2017-03-09 19:20:14	0|luke-jr|to 0.12.1
238 2017-03-09 19:20:25	0|wumpus|0.12.0 can easily upgrad to 0.12.1, 0.11.x maybe less so
239 2017-03-09 19:20:48	0|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.
240 2017-03-09 19:20:56	0|wumpus|not going to do a new 0.11.x release though
241 2017-03-09 19:21:57	0|luke-jr|get and publish a CVE, then 2 weeks later publish the key
242 2017-03-09 19:21:58	0|luke-jr|?
243 2017-03-09 19:22:25	0|wumpus|I guess we could push a patch to the 0.11 branch that disables the alert system
244 2017-03-09 19:22:34	0|gmaxwell|it's a trivial patch.
245 2017-03-09 19:22:42	0|wumpus|yes
246 2017-03-09 19:22:44	0|achow101|luke-jr: +1
247 2017-03-09 19:23:09	0|gmaxwell|nothing before 0.8 still works at all, and the 0.9x nodes I have looked at are all fake.
248 2017-03-09 19:23:22	0|gmaxwell|0.10 / 0.11 are probably still running in practice.
249 2017-03-09 19:23:57	0|gmaxwell|luke-jr: okay fine with CVE and we can patch the old branch. thats enough plan for me for now.
250 2017-03-09 19:24:13	0|wumpus|it's a one-line patch, could even do a tag, just not going to build executables for them anymore
251 2017-03-09 19:25:56	0|gmaxwell|Thanks.
252 2017-03-09 19:26:46	0|sipa|sgtm
253 2017-03-09 19:27:12	0|achow101|I suppose the bitcoin.org alert page should be updated with that info then
254 2017-03-09 19:27:12	0|jtimon|I'm happy to review any backports for an alert patch, even if they're old, won't go below 0.8, sorry
255 2017-03-09 19:28:30	0|btcdrak|everything from 0.10 and below is EOL https://bitcoincore.org/en/lifecycle/#schedule
256 2017-03-09 19:29:07	0|sipa|btcdrak: 0.14 should be added to that page
257 2017-03-09 19:29:30	0|btcdrak|sipa: https://github.com/bitcoin-core/bitcoincore.org/pull/347
258 2017-03-09 19:29:46	0|gmaxwell|what other subjects?
259 2017-03-09 19:30:55	0|cfields|Is there a timeline for 0.14.1? Or just when deemed necessary?
260 2017-03-09 19:31:09	0|achow101|it seems that 0.10 is the only one that needs an alert disabling patch. 0.11 already has it, just not tagged
261 2017-03-09 19:31:24	0|wumpus|cfields: eh not really; any pressing reason you'd want one right away?
262 2017-03-09 19:32:07	0|wumpus|the more-than-8-addnode hang at shutdown problem is annoying but not enough to warrant an immediate release
263 2017-03-09 19:32:11	0|gmaxwell|I don't see a reason one couldn't wait a few weeks, though we do have material for one.
264 2017-03-09 19:32:19	0|cfields|wumpus: nope, just couldn't remember if we usually set a date or just wing it
265 2017-03-09 19:32:30	0|wumpus|no, we never set dates in advance for minor releases
266 2017-03-09 19:32:47	0|wumpus|for 0.15 I've posted the release schedule: https://github.com/bitcoin/bitcoin/issues/9961
267 2017-03-09 19:33:10	0|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.
268 2017-03-09 19:33:36	0|wumpus|yes
269 2017-03-09 19:33:38	0|achow101|I feel like those should have been caught during RCs..
270 2017-03-09 19:33:48	0|wumpus|'should have been'
271 2017-03-09 19:33:55	0|BlueMatt|#9959 and #9955 are interesting for 0.14.1
272 2017-03-09 19:33:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
273 2017-03-09 19:33:58	0|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.
274 2017-03-09 19:34:34	0|wumpus|there's always issues in major releases that only get found when the final is tagged, it's a fact of life
275 2017-03-09 19:34:43	0|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. :)
276 2017-03-09 19:34:47	0|wumpus|no number of rcs can solve that
277 2017-03-09 19:34:48	0|luke-jr|9955 is more of a new feature IMO, but I don't care if people want to backport it
278 2017-03-09 19:34:59	0|morcos|agreed, we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release
279 2017-03-09 19:35:09	0|wumpus|ok tagging them
280 2017-03-09 19:36:14	0|cfields|wumpus: 0.15 schedule sgtm.
281 2017-03-09 19:36:38	0|luke-jr|note that backporting 9955 is likely a hazard since priority mining doesn't pay attention to fIncludeWitness I think
282 2017-03-09 19:36:40	0|wumpus|cfields: thanks, good to know
283 2017-03-09 19:37:04	0|luke-jr|should be a trivial thing to fix, but might not conflict
284 2017-03-09 19:37:44	0|achow101|are we going to do the release notes wiki thing again?
285 2017-03-09 19:38:05	0|wumpus|yes, at the end of the 0.15 release cycle
286 2017-03-09 19:38:24	0|achow101|ok
287 2017-03-09 19:38:44	0|sdaftuar|priority mining did pay attention to fIncludeWitness, so i think it would be fine, but i haven't tested
288 2017-03-09 19:39:35	0|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
289 2017-03-09 19:39:48	0|luke-jr|oh, it's tested in a different place, okay
290 2017-03-09 19:41:49	0|achow101|anything else?
291 2017-03-09 19:43:26	0|sipa|seems not
292 2017-03-09 19:44:33	0|wumpus|I don't think so
293 2017-03-09 19:44:47	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.log.html
294 2017-03-09 19:44:47	0|lightningbot|Meeting ended Thu Mar  9 19:44:45 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
295 2017-03-09 19:44:47	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html
296 2017-03-09 19:44:47	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.txt
297 2017-03-09 19:44:47	0|wumpus|#endmeeting
298 2017-03-09 19:44:48	0|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
299 2017-03-09 19:45:24	0|jl2012|Oh ended?
300 2017-03-09 19:45:43	0|jtimon|do you have a topic?
301 2017-03-09 19:45:54	0|jl2012|#9443
302 2017-03-09 19:45:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/9443 | Repairing the large-work fork warning system by jl2012 · Pull Request #9443 · bitcoin/bitcoin · GitHub
303 2017-03-09 19:45:56	0|wumpus|here starting from march 26
304 2017-03-09 19:46:33	0|jl2012|This was tagged 0.14
305 2017-03-09 19:46:47	0|jl2012|Want to see any chance for 0.15
306 2017-03-09 19:47:51	0|jtimon|for some reason I thought that needed rebase
307 2017-03-09 19:48:23	0|jl2012|Rebased already
308 2017-03-09 19:48:43	0|jtimon|yeah, I see, thanks for the heads up, will review
309 2017-03-09 19:49:27	0|bitcoin-git|13bitcoin/060.10 149cea169 15Wladimir J. van der Laan: net: Disable P2P alert system
310 2017-03-09 19:49:27	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.10: 02https://github.com/bitcoin/bitcoin/commit/9cea1698132ab68b0d6b204ff5c8d154d9192b19
311 2017-03-09 19:49:37	0|sdaftuar|jl2012: if i understand correctly, that PR would cause us to not ban peers who are on an incompatible chain?
312 2017-03-09 19:50:01	0|jl2012|It should ban
313 2017-03-09 19:50:02	0|bitcoin-git|13bitcoin/060.11 140bace83 15Wladimir J. van der Laan: net: Disable P2P alert system
314 2017-03-09 19:50:02	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.11: 02https://github.com/bitcoin/bitcoin/commit/0bace8307995ac2911885c7c8b8dec19b864eaa3
315 2017-03-09 19:50:25	0|sdaftuar|ah, i will re-read more carefully
316 2017-03-09 19:50:35	0|jl2012|It just stirs the header
317 2017-03-09 19:50:53	0|jl2012|Stores
318 2017-03-09 19:50:55	0|achow101|wumpus: coulda just set DEFAULT_ALERTS to false
319 2017-03-09 19:51:15	0|wumpus|achow101:did that exist in 0.10 and 0.11?
320 2017-03-09 19:51:19	0|achow101|yes
321 2017-03-09 19:51:23	0|achow101|0.11 had it false too
322 2017-03-09 19:51:28	0|achow101|(but not tagged)
323 2017-03-09 19:51:34	0|wumpus|achow101: anyhow, this is complete and clear
324 2017-03-09 19:53:14	0|achow101|indeed
325 2017-03-09 19:54:11	0|jl2012|sdaftuar: it does not ban for sending header for childs of an invalid block
326 2017-03-09 19:55:12	0|wumpus|going to tag v0.11.3 and v0.10.5
327 2017-03-09 19:55:22	0|btcdrak|wumpus: ~1
328 2017-03-09 19:55:24	0|btcdrak|+1
329 2017-03-09 19:55:25	0|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.
330 2017-03-09 19:55:27	0|wumpus|no RCs necessary for this, I'd say
331 2017-03-09 19:55:39	0|sdaftuar|jl2012: there's some discussion of this in #9530
332 2017-03-09 19:55:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
333 2017-03-09 19:57:38	0|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
334 2017-03-09 19:57:44	0|btcdrak|wumpus: what is the EOL date for 0.12?
335 2017-03-09 19:57:46	0|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
336 2017-03-09 19:58:44	0|sdaftuar|jl2012: i am hoping to work on the topics in #9530 for 0.15 though, if possible
337 2017-03-09 19:58:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
338 2017-03-09 19:58:58	0|wumpus|btcdrak: wouldn't that normally be the 0.14 release date?
339 2017-03-09 19:59:17	0|kanzure|oh, i assumed the meeting was over. 'scuse me.
340 2017-03-09 19:59:26	0|wumpus|yes, the meeting is closed
341 2017-03-09 19:59:48	0|wumpus|kanzure: will take a look
342 2017-03-09 20:00:20	0|jl2012|sdaftuar: maybe giving a score lower than 100 for sending child of invalid block?
343 2017-03-09 20:00:20	0|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)
344 2017-03-09 20:00:45	0|jl2012|Before we have a new DoS system
345 2017-03-09 20:01:32	0|sipa|please, no more dos scoring
346 2017-03-09 20:03:50	0|jl2012|So the plan is completely removing that?
347 2017-03-09 20:08:55	0|sipa|i think so. things are either invalid and expensive, in which case we ban, or not, and we don't ban
348 2017-03-09 20:09:46	0|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)
349 2017-03-09 20:11:57	0|morcos|sipa: that wasn't super clear
350 2017-03-09 20:12:10	0|morcos|there is expensive to produce and expensive to consume
351 2017-03-09 20:12:14	0|morcos|both matter
352 2017-03-09 20:14:32	0|sipa|right, ratio between cost to the attacker and cost to us is what matters
353 2017-03-09 20:17:31	0|btcdrak|wumpus: yes maintenance end will be when 0.14 is released, but what about EOL.
354 2017-03-09 20:18:07	0|wumpus|btcdrak: what did we use for other releases?
355 2017-03-09 20:18:45	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 10 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5703dff0939f...8910b4717e5b
356 2017-03-09 20:18:46	0|bitcoin-git|13bitcoin/06master 140e6d23d 15John Newbery: Add logging to test_framework.py...
357 2017-03-09 20:18:46	0|bitcoin-git|13bitcoin/06master 14553a976 15John Newbery: Add logging to p2p-segwit.py
358 2017-03-09 20:18:47	0|bitcoin-git|13bitcoin/06master 146d0e325 15John Newbery: Use logging in mininode.py...
359 2017-03-09 20:18:51	0|wumpus|I guess it's just maintenance end date + something?
360 2017-03-09 20:19:05	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9768: [qa] Add logging to test_framework.py (06master...06rpctestlogging) 02https://github.com/bitcoin/bitcoin/pull/9768
361 2017-03-09 20:19:58	0|btcdrak|wumpus: seems to be around ~2 years.
362 2017-03-09 20:21:35	0|wumpus|btcdrak: sounds good to me
363 2017-03-09 20:24:01	0|btcdrak|wumpus:https://github.com/bitcoin-core/bitcoincore.org/pull/347/files
364 2017-03-09 20:25:41	0|wumpus|btcdrak: looks good to me
365 2017-03-09 20:29:30	0|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.
366 2017-03-09 20:30:05	0|wumpus|just kicking is usually enough
367 2017-03-09 20:30:18	0|sipa|gmaxwell: that's exactly what i said
368 2017-03-09 20:30:25	0|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,
369 2017-03-09 20:30:28	0|sipa|seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
370 2017-03-09 20:30:33	0|wumpus|only spy nodes are persistent enough to keep reconnecting to the same nodes
371 2017-03-09 20:30:41	0|gmaxwell|ah I missed the 'seemingly on the same chain'.
372 2017-03-09 20:32:39	0|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)
373 2017-03-09 20:32:51	0|gmaxwell|at that point he should be ranked as first to get dropped.
374 2017-03-09 20:33:35	0|sipa|right
375 2017-03-09 20:34:57	0|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.
376 2017-03-09 20:43:44	0|luke-jr|tfw you rebase something just to realise you forgot to pull master
377 2017-03-09 20:48:44	0|wumpus|'well, that was easy!' 'oh no...'
378 2017-03-09 22:18:37	0|luke-jr|I think #8694 needs fresh re-reviews :x
379 2017-03-09 22:18:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
380 2017-03-09 22:19:26	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9966: Control mempool persistence using a command line parameter (06master...06mempoolpersistenceoption) 02https://github.com/bitcoin/bitcoin/pull/9966
381 2017-03-09 23:30:49	0|gmaxwell|apparently the latest electrum nags you to opt into RBF if you tell it to pay a low fee.
382 2017-03-09 23:31:46	0|dcousens_|gmaxwell: suprising,  I'd of thought CPFP would be the easier route
383 2017-03-09 23:32:10	0|dcousens_|aka, UX escape hatch
384 2017-03-09 23:33:06	0|gmaxwell|dcousens_: CPFP is not that useful.
385 2017-03-09 23:33:16	0|gmaxwell|Requires that you have change, and involves 2x the transaction data.
386 2017-03-09 23:33:23	0|gmaxwell|I mean, it's useful, but RBF is more useful.
387 2017-03-09 23:33:37	0|dcousens_|gmaxwell: true,  just remembered as you wrote that it would require the change
388 2017-03-09 23:33:50	0|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.
389 2017-03-09 23:35:38	0|BlueMatt|gmaxwell: that seems like a reasonable route
390 2017-03-09 23:36:10	0|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.  :-)
391 2017-03-09 23:36:27	0|dcousens_|gmaxwell: so RBF doesn't show unless its low fee?
392 2017-03-09 23:36:30	0|luke-jr|CPFP is more useful for the recipient than the sender, really.
393 2017-03-09 23:36:49	0|luke-jr|prompting to enable RBF for fallback fee seems like a good idea for Core
394 2017-03-09 23:36:52	0|gmaxwell|dcousens_: no, you could set it to default on in the prior version, but few users did until it was too late.
395 2017-03-09 23:43:15	0|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.
396 2017-03-09 23:45:23	0|luke-jr|cbits_: why isn't it always visible?
397 2017-03-09 23:46:10	0|cbits_|Not sure, probably to be neutral. Less boxes for users to check or figure out. You can make it always visible in settings.
398 2017-03-09 23:46:46	0|luke-jr|i c
399 2017-03-09 23:56:26	0|achow101|luke-jr: it can be set to always be visible