1 2016-11-17 00:39:27	0|jtimon|petertodd: regarding your last comment on the removign ISM thread...do you mean restoring ISM and then adding your new rule as a SF?
  2 2016-11-17 00:40:44	0|jtimon|is the point to remove ISM later with a coordinated HF?
  3 2016-11-17 00:44:34	0|BlueMatt|-rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log
  4 2016-11-17 00:44:36	0|BlueMatt|lol
  5 2016-11-17 01:52:12	0|shangzhou|bitcoin.org's download link.
  6 2016-11-17 01:52:12	0|shangzhou|gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is
  7 2016-11-17 02:22:17	0|bitcoin-git|[13bitcoin] 15Christewart opened pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9174
  8 2016-11-17 03:17:20	0|veleiro|herro, tag release 13.1 on debian stretch 'make' gives me this: https://paste.debian.net/plain/896347 wat wrong :(
  9 2016-11-17 04:11:47	0|sipa|veleiro: my guess is that you have too little memory
 10 2016-11-17 04:28:28	0|veleiro|sipa: youre probably right. i'm so sure to doing make -j4? it uses too many resources is my guess
 11 2016-11-17 04:28:45	0|veleiro|i just did a normal 'make' and it was a success..
 12 2016-11-17 04:29:12	0|veleiro|s/i'm so sure/i'm so use
 13 2016-11-17 04:29:29	0|veleiro|thanks~
 14 2016-11-17 04:39:40	0|luke-jr|#bitcoin is the support channel btw
 15 2016-11-17 04:44:31	0|veleiro|sorry luke-jr, its a big community now days. i didnt mean to bloat this chan
 16 2016-11-17 04:45:38	0|luke-jr|np, just clarifying for next time
 17 2016-11-17 04:49:42	0|bitcoin-git|[13bitcoin] 15mruddy opened pull request #9175: remove script checking dependency on checkpoints (06master...06script_check) 02https://github.com/bitcoin/bitcoin/pull/9175
 18 2016-11-17 06:45:46	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts() (06master...060.13-chainparams-loadblockindexguts) 02https://github.com/bitcoin/bitcoin/pull/9176
 19 2016-11-17 07:01:08	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #9177: NOMERGE: WIP: Support block signed custom testchains (06master...060.13-blocksign) 02https://github.com/bitcoin/bitcoin/pull/9177
 20 2016-11-17 09:29:22	0|petertodd|jtimon: no, I mean, making chains other than the existing one invalid unless they follow the new rules
 21 2016-11-17 09:29:52	0|petertodd|jtimon: that still allows reorgs - it's not a checkpoint - but allows you to remove all the ISM logic.
 22 2016-11-17 09:30:38	0|petertodd|jtimon: of course, by "allows reorgs" - it mainly only allows truly massive reorgs, but I think that's sufficient to keep this from being a checkpoint
 23 2016-11-17 11:49:46	0|morcos|petertodd: yes that is what i was saying as well, i just don't know how to do that efficiently
 24 2016-11-17 12:58:05	0|wumpus|what is the proper way to pass arguments to the secp256k1 configure script that is invoked by bitcoin's?
 25 2016-11-17 13:03:16	0|wumpus|oh nm I can just pass "--with-asm=arm --enable-experimental" to the outer configure and it works. doh
 26 2016-11-17 13:04:11	0|wumpus|... I'd been manually patching configure.ac all that time :-)
 27 2016-11-17 13:07:51	0|luke-jr|hehe
 28 2016-11-17 13:09:02	0|wumpus|never tried as I expected it to croak on unknown arguments
 29 2016-11-17 13:10:00	0|luke-jr|there's an argument to make it not even warn :D
 30 2016-11-17 13:15:31	0|bitcoin-git|13bitcoin/06master 145f274a1 15jnewbery: log block size and weight correctly.
 31 2016-11-17 13:15:31	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cb2ed300a89e...f6db48ad1c8f
 32 2016-11-17 13:15:32	0|bitcoin-git|13bitcoin/06master 14f6db48a 15Wladimir J. van der Laan: Merge #8838: Calculate size and weight of block correctly in CreateNewBlock()...
 33 2016-11-17 13:19:19	0|bitcoin-git|[13bitcoin] 15Christewart closed pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9174
 34 2016-11-17 13:39:39	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (06master...06Mf1611-doc) 02https://github.com/bitcoin/bitcoin/pull/9178
 35 2016-11-17 14:29:26	0|bitcoin-git|13bitcoin/06master 14fa63ee8 15MarcoFalke: Doxygen: Set PROJECT_NAME = "Bitcoin Core"
 36 2016-11-17 14:29:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f6db48ad1c8f...aaca05c0dabd
 37 2016-11-17 14:29:27	0|bitcoin-git|13bitcoin/06master 14aaca05c 15Wladimir J. van der Laan: Merge #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core"...
 38 2016-11-17 14:29:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (06master...06Mf1611-doc) 02https://github.com/bitcoin/bitcoin/pull/9178
 39 2016-11-17 14:50:52	0|instagibbs|Chris_Stewart_5, so malleability in this context is not txid malleability
 40 2016-11-17 14:51:12	0|instagibbs|rather witness malleability. Some joker relayer could stuff transactions with junk data and the transaction is still valid
 41 2016-11-17 14:54:52	0|Chris_Stewart_5|instagibbs: I still don't understand the 'empty byte array' thing, and I also can't seem to find where this empty byte array is pushed onto the stack in the codebase
 42 2016-11-17 14:55:13	0|Chris_Stewart_5|I get why we have all the other checks inside of CheckSignatureEncoding: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
 43 2016-11-17 14:56:25	0|Chris_Stewart_5|The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
 44 2016-11-17 14:56:42	0|Chris_Stewart_5|https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#nullfail
 45 2016-11-17 15:06:28	0|bitcoin-git|13bitcoin/06master 14d8274bc 15Jonas Schnelli: Add compile and link options echo to configure
 46 2016-11-17 15:06:28	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/aaca05c0dabd...a8b2a82618be
 47 2016-11-17 15:06:29	0|bitcoin-git|13bitcoin/06master 14a8b2a82 15Wladimir J. van der Laan: Merge #9156: Add compile and link options echo to configure...
 48 2016-11-17 15:06:43	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9156: Add compile and link options echo to configure (06master...062016/11/configure) 02https://github.com/bitcoin/bitcoin/pull/9156
 49 2016-11-17 15:56:01	0|instagibbs|Chris_Stewart_5, not sure how you are confused here: "If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array."
 50 2016-11-17 15:56:18	0|instagibbs|if a checksig is to fail, signatures must be false as well
 51 2016-11-17 15:57:02	0|instagibbs|false aka ""
 52 2016-11-17 16:28:26	0|sipa|Chris_Stewart_5: it is not talking about OP_FALSE, but about a FALSE returned by checksig
 53 2016-11-17 16:45:09	0|morcos|cfields: yeah i ran a longer test and your new branch doesn't really provide any benefit but the old one still provides a significant improvement
 54 2016-11-17 16:45:38	0|Chris_Stewart_5|sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
 55 2016-11-17 16:47:38	0|Chris_Stewart_5|and if so, how can this fail immediately without checking the signature: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L880
 56 2016-11-17 16:54:17	0|sipa|Chris_Stewart_5: see 4 lines up
 57 2016-11-17 17:02:45	0|Chris_Stewart_5|Is the only difference between CheckSignatureEncoding & IsValidSignatureEncoding the LOW_S check & trivially passes the empty byte array as a sig
 58 2016-11-17 17:10:28	0|Chris_Stewart_5|I guess my real question is could 'F' in the examples be a LOW_S sig https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#examples
 59 2016-11-17 17:11:00	0|Chris_Stewart_5|sorry HIGH_S I guess
 60 2016-11-17 19:01:13	0|achow101|meeting?
 61 2016-11-17 19:01:14	0|CodeShark|Meeting time?
 62 2016-11-17 19:01:44	0|jcorgan|whew, though i borked up the time zone again
 63 2016-11-17 19:01:50	0|jcorgan|*thought
 64 2016-11-17 19:01:58	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
 65 2016-11-17 19:02:02	0|jonasschnelli|here
 66 2016-11-17 19:02:06	0|kanzure|hi.
 67 2016-11-17 19:02:07	0|BlueMatt|oh, hey
 68 2016-11-17 19:02:11	0|instagibbs|hello
 69 2016-11-17 19:02:21	0|petertodd|hi
 70 2016-11-17 19:03:14	0|cfields|grr, flaky inet. here now.
 71 2016-11-17 19:03:14	0|michagogo|o/
 72 2016-11-17 19:03:22	0|michagogo|Wait, isn't it in an hour?
 73 2016-11-17 19:03:31	0|michagogo|Or is the time defined in UTC?
 74 2016-11-17 19:03:37	0|achow101|michagogo: UTC
 75 2016-11-17 19:03:56	0|jtimon|hi
 76 2016-11-17 19:04:10	0|michagogo|Ah. I guess I've just missed them all since we switched off of DST
 77 2016-11-17 19:04:11	0|jtimon|proposed topics?
 78 2016-11-17 19:04:22	0|jonasschnelli|#startmeeting
 79 2016-11-17 19:04:22	0|lightningbot|Meeting started Thu Nov 17 19:04:21 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
 80 2016-11-17 19:04:22	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 81 2016-11-17 19:04:27	0|wumpus|hello
 82 2016-11-17 19:05:09	0|sipa|present
 83 2016-11-17 19:05:35	0|CodeShark|Hi
 84 2016-11-17 19:05:37	0|jonasschnelli|No topic proposals?
 85 2016-11-17 19:05:50	0|MarcoFalke_web|Short meeting, then :P
 86 2016-11-17 19:06:03	0|instagibbs|ideas for account removal/replacement? I'm getting annoyed at account code :)
 87 2016-11-17 19:06:03	0|sipa|can i ask a bit about shared_ptr changes?
 88 2016-11-17 19:06:33	0|jonasschnelli|#topic shared_ptr
 89 2016-11-17 19:06:43	0|morcos|i have a topic, i'd like tot alk about priority
 90 2016-11-17 19:07:01	0|sipa|the #topic is only recognized when said by the chair, i think
 91 2016-11-17 19:07:06	0|morcos|also +1 instagibbs
 92 2016-11-17 19:07:14	0|jonasschnelli|I'm the chair
 93 2016-11-17 19:07:19	0|sipa|oh!
 94 2016-11-17 19:07:29	0|instagibbs|sipa, better watch yourself ;)
 95 2016-11-17 19:07:44	0|sipa|so, i have a series of 3 PRs to introduce shared_ptr in more places
 96 2016-11-17 19:08:14	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/9125
 97 2016-11-17 19:08:21	0|sipa|#9125, #8580, #8589
 98 2016-11-17 19:08:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
 99 2016-11-17 19:08:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
100 2016-11-17 19:08:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
101 2016-11-17 19:09:05	0|sipa|the first i hope is a clear improvement and necessary refactor for the ones that follow (and it's 3-4% reindex performance improvement)
102 2016-11-17 19:09:05	0|wumpus|I'm testing #9125
103 2016-11-17 19:09:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
104 2016-11-17 19:09:29	0|jonasschnelli|Do I understand it right that one of the key benefits of the shared_ptr transition are the concurrency benefits with less locking?
105 2016-11-17 19:09:44	0|sipa|that is a potential future advantage
106 2016-11-17 19:09:45	0|BlueMatt|sipa: concept ack+1000
107 2016-11-17 19:09:45	0|wumpus|also less copying
108 2016-11-17 19:09:46	0|gmaxwell|No.
109 2016-11-17 19:09:46	0|jonasschnelli|and less copis
110 2016-11-17 19:09:48	0|BlueMatt|to all of them
111 2016-11-17 19:09:55	0|sipa|but less copying is the immediate reason
112 2016-11-17 19:09:59	0|gmaxwell|Thats an abstract advantage of shared pointers.
113 2016-11-17 19:10:02	0|jonasschnelli|Okay.
114 2016-11-17 19:10:16	0|gmaxwell|But right avoiding copies is that it accomplishes here.
115 2016-11-17 19:10:28	0|jonasschnelli|So performance and memory? Right?
116 2016-11-17 19:10:29	0|sipa|the second one may be more controversial, as it affects the wallet code significantly, making CWalletTx not inherit from CTransaction anymore, and move it to a field
117 2016-11-17 19:10:32	0|cfields|sipa: is there any specific part of the first that you think needs extra scrutiny/testing?
118 2016-11-17 19:10:39	0|wumpus|sipa: YES
119 2016-11-17 19:11:00	0|sipa|wumpus: YES as in "do it" or YES as in "it's more controversial"
120 2016-11-17 19:11:03	0|wumpus|CWalleTx is pretty much the example of an abuse of inheritance
121 2016-11-17 19:11:05	0|wumpus|in OOP
122 2016-11-17 19:11:12	0|gmaxwell|wumpus: that was exactly my response.
123 2016-11-17 19:11:12	0|sipa|ok, glad you agree on that
124 2016-11-17 19:11:38	0|jonasschnelli|Yes. Also, is there a reason for the extra CMerkleTx inheritance?
125 2016-11-17 19:11:46	0|sipa|jonasschnelli: abuse of C++
126 2016-11-17 19:11:50	0|wumpus|wallettx should *contain* a line-level tx, plus metadata
127 2016-11-17 19:11:51	0|jonasschnelli|heh
128 2016-11-17 19:12:03	0|sipa|jonasschnelli: meaning you don't need to copy the interface
129 2016-11-17 19:12:46	0|sipa|and then inlining CTxInWitness is to just simplify the code
130 2016-11-17 19:13:04	0|sipa|(which is likely a small performance regression for non-witness txn, but an improvement for witness txn)
131 2016-11-17 19:13:45	0|sipa|if no further comments on that, i'm done with the topic
132 2016-11-17 19:13:51	0|jonasschnelli|While were at it, we should also remove "main.h" and "txmempool.h" from wallet.c (slightly OT) to avoid the circular dependency.
133 2016-11-17 19:13:54	0|wumpus|no comments, i think it's the way forward
134 2016-11-17 19:14:11	0|jonasschnelli|sipa: ack
135 2016-11-17 19:14:11	0|sipa|jonasschnelli: why is that a circular dependency?
136 2016-11-17 19:14:12	0|gmaxwell|why isn't it all done and merged yet? :P
137 2016-11-17 19:14:24	0|sipa|jonasschnelli: main and txmempool should not depend on wallet
138 2016-11-17 19:14:33	0|sipa|but wallet depending on main seems perfectly expected for me
139 2016-11-17 19:14:35	0|wumpus|wallet is allowed to depend on stuff in libbitcoin_server
140 2016-11-17 19:14:42	0|wumpus|just not the other way around
141 2016-11-17 19:14:44	0|jonasschnelli|sipa: have a look at https://github.com/bitcoin/bitcoin/pull/8745
142 2016-11-17 19:15:24	0|sipa|what should i see there?
143 2016-11-17 19:15:37	0|wumpus|I think we can discuss this outside the meeting? other more urgent topics?
144 2016-11-17 19:15:45	0|sipa|ah, i understnad
145 2016-11-17 19:15:51	0|jonasschnelli|Yes. Outside the meeting.
146 2016-11-17 19:15:52	0|sipa|yes, let's discuss design at another time
147 2016-11-17 19:16:10	0|jonasschnelli|morcos had the topic proposal "priority"
148 2016-11-17 19:16:17	0|morcos|Lets talk about potential for account or priority removal (2 separate topics)
149 2016-11-17 19:16:28	0|sipa|agree on topic
150 2016-11-17 19:16:31	0|jonasschnelli|#action account or priority removal
151 2016-11-17 19:16:36	0|jonasschnelli|#topic account or priority removal
152 2016-11-17 19:16:37	0|gmaxwell|lol
153 2016-11-17 19:16:41	0|jonasschnelli|:/
154 2016-11-17 19:16:53	0|morcos|I think luke-jr was the main proponent of keeping priority around, so if he's not here, maybe we need to postpone further discussion
155 2016-11-17 19:17:09	0|morcos|but it was my hope that we could all be in agreeement that it serves not much of a function any more
156 2016-11-17 19:17:32	0|morcos|Perhaps we can set a target for 0.15 if 0.14 is too close, but it would be nice to remove ALL of the priority code
157 2016-11-17 19:17:46	0|morcos|it would clean a lot of things up
158 2016-11-17 19:17:49	0|wumpus|I think that ship has already sailed?
159 2016-11-17 19:17:54	0|BlueMatt|morcos: ACK, but maybe 0.15
160 2016-11-17 19:17:59	0|BlueMatt|deprecate more formally in 0.14
161 2016-11-17 19:18:09	0|wumpus|I mean, we merged some stuff on the way for priority removal already
162 2016-11-17 19:18:10	0|morcos|BlueMatt: that makes sense to me
163 2016-11-17 19:18:15	0|BlueMatt|wumpus: not even eligius is doing any priority selection now...at the time maybe luke could have argued for it, but now.....
164 2016-11-17 19:18:21	0|sipa|we removed priority estimation
165 2016-11-17 19:18:39	0|jcorgan|is there any empirical data on miner behavior?
166 2016-11-17 19:18:41	0|morcos|wumpus: i mostly agree, but the removal of priority estimation was because it wasn't functional any more, so it was an easier decision
167 2016-11-17 19:18:42	0|sipa|all that is left is priority based mining, i think
168 2016-11-17 19:19:05	0|sipa|if it serves no function (and maybe we need a bit more data on that), it should be equally easy imho
169 2016-11-17 19:19:13	0|gmaxwell|I agree, I think any desire to keep it around could be answered by intelligent automatic use of fee delta. But this is going to get rehashed with luke later anyways. I think it's likely that everyone who regularly attends the meetings except luke agrees.
170 2016-11-17 19:19:26	0|morcos|there is also the free transactoin and rate limiting code
171 2016-11-17 19:19:28	0|wumpus|users can still set prioritizetransaction
172 2016-11-17 19:20:10	0|achow101|does priority estimation even work? estimatepriority just gives me -1 regardless
173 2016-11-17 19:20:18	0|sipa|achow101: priority estimation is removed
174 2016-11-17 19:20:19	0|morcos|achow101: thats why it is removed for 0.14
175 2016-11-17 19:20:29	0|sipa|achow101: the RPC remains for backward compatibility, but is a stub
176 2016-11-17 19:20:31	0|gmaxwell|jcorgan: some had been collected in the past when it was defaulted to off.  general result is that its not used ~anywhere anymore.
177 2016-11-17 19:20:33	0|wumpus|so if prioritization on some criterion that is not fee it can still be implemented outside of bitcoind
178 2016-11-17 19:20:45	0|morcos|it works, its just correctly telling you that no priority is high enough to get you mined quickluy
179 2016-11-17 19:20:50	0|achow101|ah, i see
180 2016-11-17 19:21:01	0|wumpus|heh
181 2016-11-17 19:22:00	0|morcos|back in a couple min
182 2016-11-17 19:22:10	0|jtimon|so I thought we were waiting on 0.14 for removing the priority, now we wait for 0.15?
183 2016-11-17 19:22:48	0|wumpus|is there any reason to hurry?
184 2016-11-17 19:22:55	0|sipa|jtimon: there seem to be at least 4 components to "removing the priority", i'm not sure they all need to happen simultaneously
185 2016-11-17 19:23:11	0|sipa|(rpc, estimation, mining, relay)
186 2016-11-17 19:23:29	0|jtimon|wumpus: no, any reason to wait ?
187 2016-11-17 19:23:35	0|wumpus|I'm sure no one is really waiting for it to be removed, it can be removed part by part and 0.15 is a fine target
188 2016-11-17 19:23:40	0|gmaxwell|relay is the only one I really care much about, because it currently causes bandwidth wasting relaying around junk that won't get mined.
189 2016-11-17 19:23:50	0|jtimon|if people want to work on that, I don't see why they should wait
190 2016-11-17 19:23:53	0|wumpus|jtimon: there are always other "priorities"
191 2016-11-17 19:24:10	0|MarcoFalke_web|Can we disable relay by default for .14?
192 2016-11-17 19:24:46	0|jonasschnelli|ack on DEFAULT_RELAYPRIORITY = false; for 0.14
193 2016-11-17 19:25:06	0|gmaxwell|I'd support that, if we don't go further.
194 2016-11-17 19:25:24	0|sipa|agree
195 2016-11-17 19:25:25	0|MarcoFalke_web|What do you mean with "go further"?
196 2016-11-17 19:25:32	0|wumpus|disabling by default always makes sense as a first step
197 2016-11-17 19:25:37	0|gmaxwell|MarcoFalke_web: remove the code entirely.
198 2016-11-17 19:25:47	0|MarcoFalke_web|#action DEFAULT_RELAYPRIORITY = false; for 0.14
199 2016-11-17 19:26:00	0|wumpus|even if you rip out the code two days later...
200 2016-11-17 19:26:14	0|jtimon|ok, I see, disable for 0.14 first what you want to remove for 0.15, that makes sense
201 2016-11-17 19:26:35	0|sipa|ok, account removal?
202 2016-11-17 19:26:42	0|MarcoFalke_web|next topic
203 2016-11-17 19:26:55	0|morcos|wait i'm confused
204 2016-11-17 19:27:03	0|gmaxwell|uh oh.
205 2016-11-17 19:27:09	0|morcos|what are the proposed changes to relay
206 2016-11-17 19:27:23	0|morcos|that priority doesn't let you skip the rate limiting
207 2016-11-17 19:28:17	0|morcos|ok nm, ignore me.  we are proposing that you always have to have minrelaytxfee
208 2016-11-17 19:28:22	0|gmaxwell|Yes.
209 2016-11-17 19:28:29	0|jonasschnelli|#topic "account removal"
210 2016-11-17 19:28:39	0|morcos|i don't think thats going to help too much with junk, but agree it would be good change
211 2016-11-17 19:28:40	0|gmaxwell|also, the help text for relaypriority is wrong/confusing. :P
212 2016-11-17 19:29:14	0|MarcoFalke_web|I think we already have a pull open for this #7729
213 2016-11-17 19:29:14	0|morcos|account removal is more tricky
214 2016-11-17 19:29:17	0|wumpus|so I proposed a label API to replace accounts at the start of this year, it still hasn't had much review yet: https://github.com/bitcoin/bitcoin/pull/7729
215 2016-11-17 19:29:18	0|jonasschnelli|There is sill an open PR from wumpus to #7729 which is a step towards account removal
216 2016-11-17 19:29:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
217 2016-11-17 19:29:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
218 2016-11-17 19:29:22	0|jonasschnelli|heh
219 2016-11-17 19:29:24	0|wumpus|not sure there's anything new to discuss there
220 2016-11-17 19:29:33	0|gmaxwell|"Bitcoin developers oppose accountability."
221 2016-11-17 19:30:04	0|morcos|so the idea would be we have to have labels first
222 2016-11-17 19:30:09	0|jonasschnelli|morcos: what would be your approach for the removal-transition?
223 2016-11-17 19:30:09	0|morcos|maybe for a release or two
224 2016-11-17 19:30:15	0|morcos|and then we coudl remove accounts?
225 2016-11-17 19:30:18	0|wumpus|if people are ok with that proposal I'll go forward with it, but there's always so little attention on wallet related changes, let alone deprecating features
226 2016-11-17 19:30:24	0|wumpus|morcos: yes
227 2016-11-17 19:30:27	0|instagibbs|yes labels would have to come first
228 2016-11-17 19:30:32	0|morcos|i mean i wish we could just rip them out, they're terrible.  but it seems like people still depend on them
229 2016-11-17 19:30:33	0|gmaxwell|I think I had just managed to miss 7729.
230 2016-11-17 19:30:44	0|gmaxwell|Doing both lavels and accounts means more breaking API changes, no?
231 2016-11-17 19:30:55	0|MarcoFalke_web|wumpus: You mentioned that this may cause problems when people use the account AND label api?
232 2016-11-17 19:31:09	0|wumpus|MarcoFalke_web: there may need to be protection against that, yes
233 2016-11-17 19:31:21	0|gmaxwell|morcos: most of the time I see them mentioned, they are being used as labels.
234 2016-11-17 19:31:22	0|wumpus|MarcoFalke_web: though the same already happens if you use accounts and the GUI
235 2016-11-17 19:31:32	0|wumpus|MarcoFalke_web: and there is no protection against that either
236 2016-11-17 19:31:34	0|jtimon|can't we replace accounts with labels all at once?
237 2016-11-17 19:32:04	0|gmaxwell|morcos: and people are confused when the accounts centric behavior shows up...  or, alternatively, they're confused when they don't control "from" addresses (that they're not seperate wallets).
238 2016-11-17 19:32:05	0|jtimon|it's not like we haven't been warning against the use of accounts for ages
239 2016-11-17 19:32:07	0|wumpus|can we first *agree* on the label api?
240 2016-11-17 19:32:20	0|instagibbs|jtimon, at some point I don't think people believe the deprecated warning
241 2016-11-17 19:32:22	0|sipa|jtimon: go review 7729 (and i should do the same)
242 2016-11-17 19:32:25	0|instagibbs|we should put scary ascii art :)
243 2016-11-17 19:32:26	0|gmaxwell|so proposed action: everyone go comment on 7729.
244 2016-11-17 19:32:31	0|instagibbs|action yes
245 2016-11-17 19:32:33	0|morcos|ok, lets all read 7729 again and discuss on there
246 2016-11-17 19:32:36	0|instagibbs|ack
247 2016-11-17 19:32:37	0|morcos|damn i type too slow
248 2016-11-17 19:32:38	0|jtimon|sipa: right
249 2016-11-17 19:32:39	0|gmaxwell|yea, it sounds great.
250 2016-11-17 19:32:53	0|instagibbs|also who uses labels that we talk to? dooglus?
251 2016-11-17 19:32:55	0|MarcoFalke_web|#action look at https://github.com/bitcoin/bitcoin/pull/7729
252 2016-11-17 19:33:15	0|jonasschnelli|Removing the accounting system entirely will be difficult (especially old wallet migration)
253 2016-11-17 19:33:30	0|wumpus|whether to rip accounts at the same time as introducing labels is for later discussion, none of this is hard to implement, but deciding what API we want is more difficult
254 2016-11-17 19:33:37	0|wumpus|jonasschnelli: no, it's not difficult at all
255 2016-11-17 19:34:14	0|wumpus|jonasschnelli: you could even keep the accounting records around and just ignore them and treat previous accounts as labels instead
256 2016-11-17 19:34:23	0|gmaxwell|^ is what I expected.
257 2016-11-17 19:34:23	0|sipa|just the concept of 'balance of a label/account' disappears, not the ability to selectively list transactions affecting labels/accounts
258 2016-11-17 19:34:26	0|jonasschnelli|I once did it in a test branch and it took me a long time to get it right... but maybe I was overcomplicating stuff there
259 2016-11-17 19:34:39	0|MarcoFalke_web|I think dooglus use case would be covered by the new label api, but better someone ping him on the pr
260 2016-11-17 19:34:41	0|wumpus|jonasschnelli: it's mainly a matter of deleting code
261 2016-11-17 19:34:56	0|jonasschnelli|Right. I removed it with no labels migration
262 2016-11-17 19:35:07	0|gmaxwell|I expected the account->label change would mostly be a matter of getting rid of balance related functionality. And otherwise not much perhaps beyond some new label centric features.
263 2016-11-17 19:35:11	0|sipa|jonasschnelli: i think you're overcomplicating
264 2016-11-17 19:35:16	0|wumpus|gmaxwell: yes
265 2016-11-17 19:35:34	0|wumpus|gmaxwell: and just to be claear *account* RPCs are renamed to *label*, basically
266 2016-11-17 19:35:36	0|sipa|jonasschnelli: it's literally just removing the balance RPCs, and then dropping the 'from account' field in send RPC, and renaming the rest account->label
267 2016-11-17 19:35:45	0|wumpus|yes
268 2016-11-17 19:35:49	0|gmaxwell|(e.g. of 'obvious' additional features: multiple labels on items, being able to label a single transaction without labling any involved addresses)
269 2016-11-17 19:36:23	0|wumpus|well at first it just implements the GUI label API, which doesn't allow labeling transactions either
270 2016-11-17 19:36:31	0|wumpus|I think that's a whole different thing
271 2016-11-17 19:36:32	0|gmaxwell|yep. makes sense.
272 2016-11-17 19:36:59	0|jonasschnelli|you can label addresses but not transactions, right?
273 2016-11-17 19:37:04	0|wumpus|right
274 2016-11-17 19:37:05	0|jonasschnelli|We have a comment feature for transaction
275 2016-11-17 19:37:08	0|jtimon|isn't the move call also affected (if we still have that)?
276 2016-11-17 19:37:13	0|jonasschnelli|(which is sadly not really used and exposed)
277 2016-11-17 19:37:13	0|morcos|perhaps as an immediate step, we could more forcefully declare accounts unsupported and deprecated for 0.14
278 2016-11-17 19:37:17	0|wumpus|move will disappear jtimon
279 2016-11-17 19:37:26	0|jtimon|wumpus: k
280 2016-11-17 19:37:26	0|wumpus|please actually read #7729 :(
281 2016-11-17 19:37:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
282 2016-11-17 19:37:31	0|morcos|so that in the course of adding labels, we don't have to worry about any edge case mixing of the 2
283 2016-11-17 19:37:36	0|gmaxwell|morcos: that would be negative for the many people who use accounts as labels today, however.
284 2016-11-17 19:38:12	0|wumpus|first introduce labels
285 2016-11-17 19:38:15	0|morcos|gmaxwell: yeah but i don't mean we're actually going to change it,  i just worry that in the course of adding labels around accounts we'll give ourselves extra work, but maybe not.
286 2016-11-17 19:38:22	0|wumpus|only then I'll agree on doing anything more to deprecate accounts
287 2016-11-17 19:38:35	0|wumpus|if we don't move forward for labels, we'll stay in this state forever
288 2016-11-17 19:38:43	0|gmaxwell|I need to read the PR to comment more!
289 2016-11-17 19:38:48	0|instagibbs|2 spooky
290 2016-11-17 19:40:03	0|instagibbs|any other topics?
291 2016-11-17 19:40:04	0|wumpus|making more noise about removing accounts before we have a labels API will just make people (such as dooglus) panicked
292 2016-11-17 19:41:11	0|gmaxwell|okay, I think we should take the proposed action of everyone reading and commenting on 7729 and move to another subject.
293 2016-11-17 19:41:12	0|jonasschnelli|I guess he's afk
294 2016-11-17 19:41:19	0|wumpus|yes
295 2016-11-17 19:41:55	0|gmaxwell|Or otherwise, we could instead engage in the age old art of completely uninformed combat.
296 2016-11-17 19:42:16	0|morcos|you want to talk about block size?
297 2016-11-17 19:42:18	0|jtimon|morcos: are you saying remove accounts before labels or just do both at the same time (to not worry about incompatibilities between the 2)?
298 2016-11-17 19:42:24	0|gmaxwell|"I haven't read 7729 but I oppose any change that causes blindness in small children!"
299 2016-11-17 19:42:34	0|petertodd|gmaxwell: I didn't read your last comment, but ACK
300 2016-11-17 19:42:54	0|jonasschnelli|If there are no other topic, we could talk about "auxiliary block requests" if some are interested in it?
301 2016-11-17 19:42:54	0|jtimon|other topics?
302 2016-11-17 19:43:09	0|jtimon|what is that?
303 2016-11-17 19:43:14	0|jonasschnelli|#9171
304 2016-11-17 19:43:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
305 2016-11-17 19:43:20	0|gmaxwell|jonasschnelli: will that cause blindness in small children?
306 2016-11-17 19:43:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
307 2016-11-17 19:43:44	0|gmaxwell|jtimon: it provides hot and cold running blocks.
308 2016-11-17 19:43:45	0|sipa|gmaxwell: yes, through xkcd 378
309 2016-11-17 19:43:46	0|jonasschnelli|jtimon "auxiliary block requests" is a requirement for SPV
310 2016-11-17 19:43:48	0|instagibbs|BlueMatt, thanks, added to queue
311 2016-11-17 19:44:01	0|jonasschnelli|It allows you to request blocks during IBD... which not getting validated
312 2016-11-17 19:44:19	0|morcos|jonasschnelli: is there some more general description of how all that would work.  i started to look at it, but i wasn't sure what the high level design was
313 2016-11-17 19:44:31	0|instagibbs|ACK morcos I couldn't grasp immediately
314 2016-11-17 19:44:40	0|jonasschnelli|Hmm... I can write a paper?
315 2016-11-17 19:45:03	0|morcos|it doesn't have to be formal
316 2016-11-17 19:45:23	0|jonasschnelli|It's simple: you ask your node, "giveme blocks D, F, G", node downloads blocks "D, F, G" and pass it though the signals with validate=fale"
317 2016-11-17 19:45:28	0|BlueMatt|jonasschnelli: note that I'm working to remove fForceProcessing/etc from ProcessNewBlock...please do not pass the blockRequest object all the way in...
318 2016-11-17 19:45:38	0|gmaxwell|I have to admit I expirenced some groan related to "oh no, yet another block fetching modality" -- but the application of being able to on demand randomly request blocks is perfectly reasonsable.  More description would be helpful.
319 2016-11-17 19:45:54	0|jonasschnelli|It uses all the available mechanisms.
320 2016-11-17 19:46:05	0|BlueMatt|jonasschnelli: I'd kinda prefer this not call AcceptBlock at all...do we need to store the block or can we just pass to wallet?
321 2016-11-17 19:46:10	0|jonasschnelli|It just "prioritize the requested blocks"
322 2016-11-17 19:46:14	0|sipa|overall concept ack, but i think the implementation will need to change with the ongoing network processing refactors
323 2016-11-17 19:46:51	0|gmaxwell|BlueMatt: seems foolish to download blocks twice... which would happen if we didn't store them.
324 2016-11-17 19:46:58	0|BlueMatt|hum, true
325 2016-11-17 19:46:58	0|jonasschnelli|BlueMatt: Right. We could factor out the on-disk-storing part
326 2016-11-17 19:47:09	0|BlueMatt|still, would be nice to not store unless we need to
327 2016-11-17 19:47:15	0|wumpus|it needs to get the chance to store it, atl east
328 2016-11-17 19:47:20	0|gmaxwell|^ yep.
329 2016-11-17 19:47:24	0|BlueMatt|gmaxwell: we could also use the needs-download logic in the p2p logic to dedup download
330 2016-11-17 19:47:24	0|sipa|BlueMatt: it would integrate into some callback for downloaded blocks, i would guess
331 2016-11-17 19:47:31	0|gmaxwell|Interaction with pruning seems somewhat complicated.
332 2016-11-17 19:47:40	0|BlueMatt|that way the p2p logic could decide to hand to ProcessNewBlock...or not
333 2016-11-17 19:47:43	0|wumpus|there may be further policy not to store it, e.g. based on pruning and such
334 2016-11-17 19:47:45	0|BlueMatt|gmaxwell: thats part of my concern
335 2016-11-17 19:47:56	0|wumpus|but for a full IBD you'd really want to pre-fill blocks
336 2016-11-17 19:48:02	0|BlueMatt|just seems kinda broken to have the block-processing logic process a block which it explicitly doesnt want
337 2016-11-17 19:48:15	0|gmaxwell|BlueMatt: but the main application now is a node that starts off with a spv mode wallet while it syncs up in the background.  Such nodes will likely also be pruned.
338 2016-11-17 19:48:18	0|wumpus|it will likely want it later
339 2016-11-17 19:48:27	0|sipa|i guess there should be a separation of "which blocks to download" and "which blocks to process" logic
340 2016-11-17 19:48:33	0|sipa|where the second can ask the first
341 2016-11-17 19:48:38	0|jonasschnelli|I think to make it work with pruning is not very hard... just step after step
342 2016-11-17 19:48:57	0|BlueMatt|wumpus: yes, I'm saying if we have a full-spv mode then the p2p logic should be able to not pass it to ProcessNewBlock....alternatively it can choose to do so if it thinks block-logic needs it
343 2016-11-17 19:48:58	0|wumpus|could e.g. store it for later processing
344 2016-11-17 19:49:16	0|wumpus|discarding by default would be stupid, at least
345 2016-11-17 19:49:29	0|BlueMatt|wumpus: sure, but we have logic to figure out if we want a block or not, already
346 2016-11-17 19:49:37	0|BlueMatt|jonasschnelli: note that I have a pr to change the stuff there to deserialize blocks into shared_ptrs, so passing it over to wallet should use that
347 2016-11-17 19:50:02	0|BlueMatt|#9014, though its blocked on #9075
348 2016-11-17 19:50:03	0|gmaxwell|blocks as sharedptr, hurrah
349 2016-11-17 19:50:03	0|jonasschnelli|BlueMatt: okay. Though #9171 aims to be a wallet free PR
350 2016-11-17 19:50:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
351 2016-11-17 19:50:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
352 2016-11-17 19:50:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
353 2016-11-17 19:50:33	0|sipa|BlueMatt: note that after 9125, deserializing into a share_ptr is literally just "std::shared_ptr<const CBlock> ptr; ss >> ptr; "
354 2016-11-17 19:50:41	0|BlueMatt|sipa: cool
355 2016-11-17 19:52:54	0|jonasschnelli|more topics? 8m to go.
356 2016-11-17 19:53:27	0|wumpus|*crickets*
357 2016-11-17 19:53:28	0|Chris_Stewart_5|jonasschnelli: What is the use case for that? Why request the full block if we aren't validating?
358 2016-11-17 19:53:40	0|sipa|Chris_Stewart_5: light wallet support
359 2016-11-17 19:53:49	0|gmaxwell|Chris_Stewart_5: so we can scan it for wallet transactions.
360 2016-11-17 19:53:51	0|instagibbs|Chris_Stewart_5, you download blocks based on age of your wallet
361 2016-11-17 19:53:56	0|jonasschnelli|Chris_Stewart_5: allow receiving and sending transactions in "client" mode
362 2016-11-17 19:54:00	0|sipa|Chris_Stewart_5: the ability to use the wallet before you're fully synced
363 2016-11-17 19:54:11	0|instagibbs|"Where did my money go" <---
364 2016-11-17 19:54:14	0|wumpus|let's take basic questions to outside the meeting
365 2016-11-17 19:54:32	0|Chris_Stewart_5|This is alt solution to BIP37 then, or complementary?
366 2016-11-17 19:54:44	0|gmaxwell|Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
367 2016-11-17 19:54:57	0|jonasschnelli|Chris_Stewart_5: its a safer solution then BIP37...
368 2016-11-17 19:55:38	0|gmaxwell|(BIP37 is also vulnerable to txn being hidden from you)
369 2016-11-17 19:55:55	0|wumpus|yes, BIP37 is a bad idea, we're not going to use it in core
370 2016-11-17 19:56:38	0|Chris_Stewart_5|Yes I understand that part, I'm trying to piece together how new spv mode will function i guess.
371 2016-11-17 19:56:39	0|wumpus|(bad idea with untrusted peers at least, and that's the use case here)
372 2016-11-17 19:56:53	0|jonasschnelli|I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
373 2016-11-17 19:56:54	0|wumpus|any other topics?
374 2016-11-17 19:56:57	0|wumpus|the meeting is derailed
375 2016-11-17 19:57:13	0|wumpus|otherwise better to close it
376 2016-11-17 19:57:15	0|instagibbs|3 minutes, no topics, bound to
377 2016-11-17 19:57:18	0|MarcoFalke_web|#endsmeeting
378 2016-11-17 19:57:23	0|jonasschnelli|#endmeeting
379 2016-11-17 19:57:23	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.log.html
380 2016-11-17 19:57:23	0|lightningbot|Meeting ended Thu Nov 17 19:57:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
381 2016-11-17 19:57:23	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.html
382 2016-11-17 19:57:23	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.txt
383 2016-11-17 19:57:28	0|gmaxwell|If you end the meeting will it be classified as back on track or forever derailed?
384 2016-11-17 19:57:32	0|sipa|Chris_Stewart_5: it will just download full blocks
385 2016-11-17 19:57:43	0|achow101|will we have a meeting next week? It's a holiday in the US
386 2016-11-17 19:57:43	0|sipa|Chris_Stewart_5: and possibly remember them for validation later
387 2016-11-17 19:57:46	0|jonasschnelli|sipa: \o/ new navigation on http://bitcoin.sipa.be
388 2016-11-17 19:57:49	0|jonasschnelli|hurra
389 2016-11-17 19:57:58	0|sipa|jonasschnelli: yes, thanks to jameson lopp
390 2016-11-17 19:58:11	0|jonasschnelli|achow101: US? is that the place where they just abandoned politics?
391 2016-11-17 19:58:14	0|instagibbs|Chris_Stewart_5, I'm a new full node, wallet is a week or two old. Then you can grab the last two weeks of blocks and find payments
392 2016-11-17 19:58:21	0|achow101|jonasschnelli: yeah, that one
393 2016-11-17 19:58:23	0|instagibbs|meanwhile background you're still validating
394 2016-11-17 19:58:30	0|gmaxwell|jonasschnelli: political discussion to ##bitcoin.
395 2016-11-17 19:58:46	0|Chris_Stewart_5|What about bandwidth usage? Doesn't this require much more bandwidth? Not a concern?
396 2016-11-17 19:58:48	0|gmaxwell|achow101: the meetings stop for nothing except almost everyone being gone at once. :P
397 2016-11-17 19:58:50	0|wumpus|gmaxwell: well I think this meeting will stay derailed no matter waht, there's no way to un-log what is logged :)
398 2016-11-17 19:59:02	0|jonasschnelli|Chris_Stewart_5: if you want to do a full validation, you need to block anyways.
399 2016-11-17 19:59:15	0|jonasschnelli|So you have some already downloaded blocks around the tip
400 2016-11-17 19:59:18	0|Chris_Stewart_5|and if you don't?
401 2016-11-17 19:59:40	0|jonasschnelli|You waste bandwidth
402 2016-11-17 19:59:44	0|jonasschnelli|which can be okay.
403 2016-11-17 19:59:45	0|wumpus|Chris_Stewart_5: it's just a different compromise
404 2016-11-17 19:59:51	0|gmaxwell|Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye.
405 2016-11-17 19:59:58	0|jonasschnelli|either you waste pricavy or bandwidth... you can choose.
406 2016-11-17 20:00:06	0|wumpus|right
407 2016-11-17 20:00:08	0|instagibbs|even if you don't want to catch up, it's still better than bloom filters or centralized nodes
408 2016-11-17 20:00:15	0|Chris_Stewart_5|jonasschnelli: If we are removing BIP37 there isn't a choice.
409 2016-11-17 20:00:21	0|gmaxwell|STOP
410 2016-11-17 20:00:22	0|gmaxwell|die
411 2016-11-17 20:00:29	0|gmaxwell|okay, now that you are all dead...
412 2016-11-17 20:00:29	0|wumpus|no one is *removing* BIP37
413 2016-11-17 20:00:33	0|gmaxwell|^ that.
414 2016-11-17 20:00:35	0|jonasschnelli|heh
415 2016-11-17 20:00:43	0|jonasschnelli|(rofl)
416 2016-11-17 20:00:44	0|wumpus|can people stop FUDing and panicking about everything we do?
417 2016-11-17 20:00:45	0|wumpus|thank you
418 2016-11-17 20:00:51	0|achow101|panic panic
419 2016-11-17 20:01:21	0|gmaxwell|When in danger or in doubt run in terror, scream and shout.
420 2016-11-17 20:01:22	0|wumpus|we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
421 2016-11-17 20:01:41	0|wumpus|it's a big internet and you don't need to do what we do
422 2016-11-17 20:01:53	0|jonasschnelli|Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
423 2016-11-17 20:01:58	0|bsm1175321|I'm interested in making an update to BIP37 to improve light wallet security...
424 2016-11-17 20:02:09	0|gmaxwell|Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
425 2016-11-17 20:02:10	0|jonasschnelli|That's IMO impossible..
426 2016-11-17 20:02:15	0|wumpus|many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
427 2016-11-17 20:02:18	0|jonasschnelli|Maybe Bloom Filter Commitments
428 2016-11-17 20:02:22	0|wumpus|they care about privacy, though
429 2016-11-17 20:02:51	0|jonasschnelli|People are downloading a 10GB movie just to rent it for 24h... why would they not be willing to download 10GB to get financial privacy?
430 2016-11-17 20:03:14	0|sipa|bsm1175321: the only proposal i know that improves it is pretty radically different (bloom filter commitments)
431 2016-11-17 20:03:16	0|wumpus|yeah, it's simply a choice/compromise, I don't understand what is so difficult about understanding that
432 2016-11-17 20:03:41	0|jcorgan|why interpret ambiguity in a way that gives the speaker the benefit of the doubt when you can construe anything they say in the worst possible way to reinforce your pre-existing conclusions?
433 2016-11-17 20:03:43	0|gmaxwell|jonasschnelli: the filter commitment scheme can also be done without the commitments. (just loses the censorship resistance).
434 2016-11-17 20:03:55	0|bsm1175321|sipa: I'll read up.  Any links?  I'm also interested in UTXO set commitments.
435 2016-11-17 20:04:21	0|bsm1175321|Also perfectly happy with something pretty radically different.
436 2016-11-17 20:04:34	0|jonasschnelli|gmaxwell: do you have a post or paper about this?
437 2016-11-17 20:04:46	0|sipa|bsm1175321: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
438 2016-11-17 20:05:26	0|gmaxwell|jonasschnelli: the post describing the commited filters mentions that it can be done without the commitment. The only thing the commitment adds is the inability for nodes to lie about the filter content. Which is good, but it doesn't have to be delivered right away.
439 2016-11-17 20:05:39	0|bsm1175321|sipa: thanks!
440 2016-11-17 20:05:47	0|jonasschnelli|Okay. Thanks for the link sipa
441 2016-11-17 20:05:52	0|gmaxwell|My view is that it would best be accomplished by implementing it without the commitment but in a way that would be sutiable for commitment later.
442 2016-11-17 20:06:47	0|gmaxwell|also, as an aside, cuckoo filters are likely a better data structure for this than bloom filters... but there is a big area for research here.
443 2016-11-17 20:07:57	0|bsm1175321|+1 on cuckoo filters.  Waaaay faster and the performance characteristics are more understandable (one fewer parameter)
444 2016-11-17 20:08:22	0|gmaxwell|segwit also opens up a new option, which is just fetching full blocks without witnesses.
445 2016-11-17 20:09:34	0|gmaxwell|If segwit were used exclusively the size of a full block without the witness would be about 500k... not exactly as small as a filter, but still perfectly private.
446 2016-11-17 20:10:29	0|sipa|jcorgan: what was that a response to?
447 2016-11-17 20:11:00	0|bsm1175321|I wonder if some kind of oblivious transfer protocol would be practical for light wallet privacy?
448 2016-11-17 20:11:12	0|jcorgan|?
449 2016-11-17 20:12:14	0|jcorgan|oh, earlier, that was about Chris_Stewart_5 comment
450 2016-11-17 20:13:07	0|jcorgan|a snark that lost its context when too many other comments flew by while i was typing
451 2016-11-17 20:14:26	0|bitcoin-git|[13bitcoin] 15mruddy closed pull request #9175: WIP: remove script checking dependency on checkpoints (06master...06script_check) 02https://github.com/bitcoin/bitcoin/pull/9175
452 2016-11-17 20:15:03	0|Chris_Stewart_5|jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
453 2016-11-17 20:15:30	0|bsm1175321|e.g. http://percy.sourceforge.net/
454 2016-11-17 20:30:13	0|meownow|hi all
455 2016-11-17 21:24:12	0|bitcoin-git|[13bitcoin] 15sipa pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a8b2a82618be...9346f8429957
456 2016-11-17 21:24:13	0|bitcoin-git|13bitcoin/06master 147c98ce5 15Matt Corallo: Remove pfrom parameter from ProcessNewBlock...
457 2016-11-17 21:24:13	0|bitcoin-git|13bitcoin/06master 14e2e069d 15Matt Corallo: Revert "RPC: Give more details when "generate" fails"...
458 2016-11-17 21:24:14	0|bitcoin-git|13bitcoin/06master 14ae22357 15Matt Corallo: Replace CValidationState param in ProcessNewBlock with BlockChecked
459 2016-11-17 21:24:27	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (06master...06net_processing_4) 02https://github.com/bitcoin/bitcoin/pull/9075
460 2016-11-17 22:09:26	0|meownow|main.cpp is the best place to start in terms of trying to understand the source code, correct?
461 2016-11-17 22:11:10	0|MarcoFalke_web|Carefully reviewing pull requests is the best place to start in terms of trying to understand the source code :P
462 2016-11-17 22:14:22	0|meownow|ok, will do that then!
463 2016-11-17 22:15:15	0|MarcoFalke_web|#9142 looks ready for merge.
464 2016-11-17 22:15:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9142 | Move -salvagewallet, -zap(wtx) to where they belong by jonasschnelli · Pull Request #9142 · bitcoin/bitcoin · GitHub
465 2016-11-17 22:38:07	0|meownow|could someone do an ELI5 for the debate that occurs RE this pull request? i kind of get it but at the same time am a bit confused
466 2016-11-17 22:38:45	0|meownow|oops, this pull request: https://github.com/bitcoin/bitcoin/pull/63
467 2016-11-17 22:41:18	0|sipa|meownow: it was later proposed as a BIP, and implemented in #707
468 2016-11-17 22:41:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
469 2016-11-17 22:46:14	0|meownow|ty will check that out
470 2016-11-17 23:12:59	0|jtimon|sipa: another related question why is https://github.com/bitcoin/bitcoin/pull/9125/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR382 necessary?
471 2016-11-17 23:13:06	0|BlueMatt|jtimon/sipa do we care about https://github.com/bitcoin/bitcoin/pull/9075/files#r88568772 ?
472 2016-11-17 23:19:30	0|jtimon|BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
473 2016-11-17 23:23:42	0|jtimon|sipa: never mind, read more about move
474 2016-11-17 23:28:04	0|bitcoin-git|[13bitcoin] 15TheBlueMatt reopened pull request #9014: Fix block-connection performance regression (06master...062016-10-fix-tx-regression) 02https://github.com/bitcoin/bitcoin/pull/9014
475 2016-11-17 23:28:40	0|BlueMatt|sipa: do you want me to go ahead and rebase ^ on the shared_ptr serialization from 9125?
476 2016-11-17 23:32:40	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute (06master...06Mf1611-blockFreeTxs) 02https://github.com/bitcoin/bitcoin/pull/9179
477 2016-11-17 23:43:09	0|bitcoin-git|[13bitcoin] 15mruddy opened pull request #9180: WIP: remove script checking dependency on checkpoints v2 (06master...06isburied) 02https://github.com/bitcoin/bitcoin/pull/9180