1 2017-08-10 03:13:32	0|jimpo|What does fOneShot mean in the net code? Seems to be set for connections to seed nodes?
  2 2017-08-10 03:22:22	0|jimpo|Ah, is the idea that we only use seed nodes to get addresses then disconnect?
  3 2017-08-10 04:18:50	0|venzen|The fact SegWit activation comes with a 4x blocksize limit increase is reason for concern
  4 2017-08-10 04:19:34	0|venzen|My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations
  5 2017-08-10 04:20:15	0|sipa|venzen: it does not come with a 4x validation cost increase, however
  6 2017-08-10 04:20:23	0|venzen|since there is no longer a "big block" contingent to appease, would a 2x increase perhaps be more appropriate and safe?
  7 2017-08-10 04:20:24	0|sipa|nor a 4x utxo growth
  8 2017-08-10 04:21:17	0|venzen|sipa: true, i have read aantonop's explanation of the incentive to reduce UTXO set growth and your BIP makes that clear
  9 2017-08-10 04:21:24	0|gmaxwell|venzen: segwit eliminates the block size limit, replaces it with a block weight limit. Weight is designed to better reflect the cost of transactions to the network.
 10 2017-08-10 04:21:57	0|gmaxwell|because weight is limited instead of size, the maximum amount of size is variable depending on the content.
 11 2017-08-10 04:22:17	0|venzen|gmaxwell: sipa: apologies for my confusion but I am receiving mixed messages - some are saying that real 4MB blocks are possible, is this true?
 12 2017-08-10 04:22:25	0|gmaxwell|Similar to how the number of 1 bits in a block varry.
 13 2017-08-10 04:22:34	0|venzen|ok
 14 2017-08-10 04:22:42	0|sipa|venzen: in theory, yes
 15 2017-08-10 04:22:50	0|gmaxwell|venzen: sure, if you construct transactions that have low weight you can put more of them in a block.
 16 2017-08-10 04:23:45	0|venzen|gmaxwell: sipa: are there substantive reasons why it should be 4MB and not a more concervative 2MB limit?
 17 2017-08-10 04:23:49	0|gmaxwell|Similar to how normally a block has only about 500,000 1 bits, but you could construct a block with nearly 1,000,000 one bits, if you constructed the transactions right.. because (pre segwit) the system limits the size not the number of 1 bits.
 18 2017-08-10 04:24:02	0|sipa|venzen: the size of blocks is not that relevant
 19 2017-08-10 04:24:08	0|sipa|their validation cost is
 20 2017-08-10 04:24:39	0|gmaxwell|venzen: because limiting weight increases capacity and dampens attacks. Size of some particular serialization is not a good measure of the resource usage of a block.
 21 2017-08-10 04:24:39	0|venzen|sipa: validation as in CPU resources across the network?
 22 2017-08-10 04:25:45	0|venzen|gmaxwell: sipa: ok, i guess i'm stil stuck in the induced demand paradigm, let me do some reading and thinking - thanks for your explanations
 23 2017-08-10 04:26:29	0|gmaxwell|venzen: you are making a reasoning error in privledging size.
 24 2017-08-10 04:27:31	0|gmaxwell|Size doesn't necessairly have a strong relationship to anything that matters... blocks are sent a the tip with compact blocks.
 25 2017-08-10 04:28:02	0|gmaxwell|In the future historical blocks may be sent with compact seralization (which is 25%) smaller and compression, or not sent at all.
 26 2017-08-10 04:28:48	0|gmaxwell|Size ignores the impact on the UTXO set.. so as time goes on size increasingly has little to do with anything that matters.
 27 2017-08-10 04:35:50	0|venzen|gmaxwell: ok, i will process the information, i'm obviously failing to grasp a fundamental concept and will find it
 28 2017-08-10 04:37:21	0|venzen|if the devs unanimously agree that a 4MB blocksize limit is ok with a block weight decider then I believe that
 29 2017-08-10 04:38:19	0|sipa|venzen: see it this way, segwit does not at all increase the maximum number of outputs or inputs can have
 30 2017-08-10 04:38:26	0|sipa|*a block
 31 2017-08-10 04:39:36	0|sipa|yes, the number of bytes on disk may increase faster but 1) since compact blocks, latency is no longer impacted by the number of bytes in a block 2) with pruning, storage of old blocks doesn't matter
 32 2017-08-10 04:40:32	0|sipa|so the only real increase is the cost of transaction relay, which is in the order of kilobytes/sec
 33 2017-08-10 04:43:34	0|venzen|sipa: i'm assuming that the primary consideration is at the UTXO level, so number of txns per block is the wrong way to think about this? Even so, we can expect an increase in the number of "traditional" P2PKH txns per block after activation?
 34 2017-08-10 05:05:45	0|venzen|sipa: i assume you're not responding because the answers are already contained in your and gmaxwell 's responses above. I will meditate upon those. Thank you very much for taking the time to explain to a layman - you guys are international treasures and history will acknowledge you.
 35 2017-08-10 05:24:03	0|sipa|venzen: number of transactions never matters... inputs and outputs do, the conplexity of their scripts, database growth, ...
 36 2017-08-10 05:24:31	0|sipa|but many transactions with few in/out, or few transactions with many in/out can be equivalent
 37 2017-08-10 05:48:35	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #11019: [wallet] Abandon transactions that fail to go into the mempool (06master...06abandon-longchain-failed-tx) 02https://github.com/bitcoin/bitcoin/pull/11019
 38 2017-08-10 07:05:30	0|wumpus|aj: sorry but bad time to ask now, I don't have much time to look at features, trying to focus on the 0.15 branch-off and 0.15.0rc1 release
 39 2017-08-10 07:06:39	0|wumpus|aj: the includeconf stuff looks good at a high level but haven't looked in detail, eg. whether it doesn't make the initialization and config reading code even less understandable
 40 2017-08-10 07:36:58	0|aj|wumpus: yup figured, no worries
 41 2017-08-10 07:39:02	0|wumpus|aj: I promise to look at it as one of the first things after the branch
 42 2017-08-10 07:40:16	0|aj|wumpus: post celebratory beverage or similar i trust!
 43 2017-08-10 07:42:11	0|wumpus|aj: the thing I'm most worried with regard to risk of changes in that area of the code is that a) the qt/bitcoind initialization sequences start to diverge or b) the precedence of options between commandline/configuration file/qt settings becomes different. There's a lot that can go wrong there and we don't have tests for that :(
 44 2017-08-10 07:45:57	0|kallewoof|Why would includeconf PR cause divergence with QT? It feels like QT-side could have the same feature. (If not, I can look into that.) Maybe I misunderstand the point.
 45 2017-08-10 07:47:51	0|jonasschnelli|BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
 46 2017-08-10 07:48:22	0|aj|wumpus: yeah, i was a bit surprised to see the init code was duplicated there, rather than just a common function of some sort
 47 2017-08-10 07:49:05	0|aj|wumpus: (the error reporting makes that not a trivial fix though)
 48 2017-08-10 07:49:07	0|wumpus|kallewoof: yes, the qt-side should have the same feature, that's exactly "why", but it might conflict with other things there as there's an extra settings source
 49 2017-08-10 07:49:32	0|wumpus|aj: yes, error reporting as well as qsettings, translations handling, etc makes that different and hard to unify
 50 2017-08-10 07:49:48	0|wumpus|aj: the qt setup sequence is much more complex
 51 2017-08-10 07:49:56	0|wumpus|aj: ideally we'd have tests, that'd be much more reassuring
 52 2017-08-10 07:50:33	0|wumpus|pretty much a preconditioning for refactoring there
 53 2017-08-10 07:52:25	0|aj|wumpus: hmm, can travis start qt/bitcoin, or would local-only tests be sufficient at least to start?
 54 2017-08-10 07:54:11	0|wumpus|if the test is not interested in windowed output w/ QT_QPA_PLATFORM=minimal you can avoid the X dependency, this is what the bitcoin-qt unit-tests in src/qt/test do
 55 2017-08-10 07:54:57	0|wumpus|also in principle you can run all the functional tests with bitcoin-qt instead of bitcoind (but that's not useful for travis :-)
 56 2017-08-10 07:55:34	0|wumpus|in any case even locla-only tests are an improvement to having nothing
 57 2017-08-10 07:55:52	0|wumpus|travis/build support can be sorted out later
 58 2017-08-10 08:07:07	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #11020: [wallet] getbalance: Add option to include non-mempool UTXOs (06master...06unspendable-utxo-handling) 02https://github.com/bitcoin/bitcoin/pull/11020
 59 2017-08-10 08:14:55	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10442: add a -bip148 option (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10442
 60 2017-08-10 08:27:06	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10532: -bip148 option (06master...06bip148) 02https://github.com/bitcoin/bitcoin/pull/10532
 61 2017-08-10 09:41:56	0|bitcoin-git|[13bitcoin] 15AkioNak opened pull request #11021: fix getchaintxstats() (06master...06fix_getchaintxstats) 02https://github.com/bitcoin/bitcoin/pull/11021
 62 2017-08-10 13:26:18	0|venzen|sipa: gmaxwell: thanks, i'm processing, your explanations helped a great deal
 63 2017-08-10 13:54:52	0|sdaftuar|jtimon: this is incorrect - https://twitter.com/timoncc/status/895559780231593984
 64 2017-08-10 13:55:11	0|sdaftuar|0.14.2 certainly can sign segwit transactions
 65 2017-08-10 13:56:09	0|sdaftuar|the wallet doesn't use segwit by default though, and only lets you (easily) create p2sh-wrapped segwit addresses after segwit activates.
 66 2017-08-10 14:26:11	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11022: Basic keypool topup (06master...06basic_keypool_topup) 02https://github.com/bitcoin/bitcoin/pull/11022
 67 2017-08-10 16:53:25	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11023: [tests] Add option to attach a python debugger if functional test fails (06master...06func_test_pdb) 02https://github.com/bitcoin/bitcoin/pull/11023
 68 2017-08-10 17:10:14	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11024: tests: Free the OpenSSL error queue as part of the wallet_crypto/OldDecrypt test cleanup (06master...06OldDecrypt-cleanup) 02https://github.com/bitcoin/bitcoin/pull/11024
 69 2017-08-10 18:03:15	0|earlz|I'm trying to setup a new Gitian VM and I can't remember what I did to fix this error "failed to mound /dev/shm" using LXC
 70 2017-08-10 18:26:02	0|wumpus|no google hits either?
 71 2017-08-10 18:27:44	0|wumpus|it sounds like a common lxc/vm issue, not specific to gitian
 72 2017-08-10 18:28:50	0|earlz|Everything I've tried has been nothing so far
 73 2017-08-10 18:29:03	0|earlz|just following exact directions as in the gitian-building.md doc
 74 2017-08-10 18:29:15	0|earlz|lxc-execute: Mount of 'shm' onto '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm' was onto a symlink!
 75 2017-08-10 18:29:18	0|earlz|lxc-execute: File exists - failed to mount 'shm' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm'
 76 2017-08-10 18:29:43	0|wumpus|might be that some steps code-rotted, due to debian version drift
 77 2017-08-10 18:30:20	0|wumpus|ideally someone would try to follow it every so often, from scratch, and make corrections where needed
 78 2017-08-10 18:30:27	0|earlz|I did this same process a week ago and ran into 2 completely different problems, 1 where I just needed to reboot, and 1 where I ahd to do something to make network connections work
 79 2017-08-10 18:30:47	0|achow101|earlz: that should have been fixed by https://github.com/devrandom/gitian-builder/pull/150
 80 2017-08-10 18:31:11	0|achow101|did you pull in the latest version of gitian-builder?
 81 2017-08-10 18:32:31	0|earlz|I just cloned it today, so yes. I'm using debian 8.5 as used in the walkthrough also, so I don't think it's the same issue
 82 2017-08-10 18:33:43	0|earlz|Might try rolling back that commit and seeing what happens
 83 2017-08-10 18:35:00	0|earlz|yep, rolling back the bit for shm fixed the initial problem at least. I'll report a bug there
 84 2017-08-10 18:35:38	0|wumpus|so another source of drift would be gitian-builder updates :)
 85 2017-08-10 18:58:09	0|frogstar|clarkmoody!
 86 2017-08-10 18:58:14	0|frogstar|I love your charts!
 87 2017-08-10 18:58:52	0|kanzure|wrong channel
 88 2017-08-10 19:00:11	0|achow101|meeting?
 89 2017-08-10 19:00:17	0|lightningbot|Meeting started Thu Aug 10 19:00:16 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 90 2017-08-10 19:00:17	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 91 2017-08-10 19:00:17	0|wumpus|#startmeeting
 92 2017-08-10 19:00:21	0|jonasschnelli|hi
 93 2017-08-10 19:00:23	0|achow101|hi
 94 2017-08-10 19:00:25	0|Chris_Stewart_5|ello
 95 2017-08-10 19:00:27	0|sdaftuar|hey
 96 2017-08-10 19:00:46	0|instagibbs|hi
 97 2017-08-10 19:01:00	0|wumpus|any topics?
 98 2017-08-10 19:01:19	0|jnewbery|#10882 please
 99 2017-08-10 19:01:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
100 2017-08-10 19:01:43	0|wumpus|good idea
101 2017-08-10 19:01:44	0|wumpus|#topic Stop advancing best block and shutdown node if keypool drops below critical threshold
102 2017-08-10 19:02:08	0|cfields|hi
103 2017-08-10 19:02:20	0|jonasschnelli|jnewbery: is that the alternative for keypool topup for 0.15?
104 2017-08-10 19:02:24	0|kanzure|hi.
105 2017-08-10 19:02:27	0|wumpus|that replaced #11022 for 015.0?
106 2017-08-10 19:02:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
107 2017-08-10 19:02:55	0|jonasschnelli|What was/is wrong with 11022?
108 2017-08-10 19:03:12	0|achow101|jonasschnelli: 11022 is part of 10882 split into a separate pr
109 2017-08-10 19:03:17	0|luke-jr|if the node shuts down, how can users recover? O.o
110 2017-08-10 19:03:19	0|wumpus|it was getting too large IIRC
111 2017-08-10 19:03:30	0|jnewbery|#10882 is the same as it has been for the last few days (mark-used if later key from keypool used, try to topup, stop node if can't, etc)
112 2017-08-10 19:03:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
113 2017-08-10 19:03:42	0|jonasschnelli|Ah. Same problem I had with my original PR. :/
114 2017-08-10 19:03:49	0|jnewbery|I split #11022 off as the (hopefully) uncontroversial changes
115 2017-08-10 19:03:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
116 2017-08-10 19:04:13	0|jnewbery|it just marks keys as used and tops up the keypool. No stop node/don't advance best block
117 2017-08-10 19:04:21	0|gmaxwell|I was making the recommendation that we split out the part that marks used and refills the pool and get that merged. It is a strict improvement with no downsides or extra considerations.
118 2017-08-10 19:04:30	0|gmaxwell|that one!
119 2017-08-10 19:04:42	0|kanzure|(nick ping)
120 2017-08-10 19:04:56	0|cfields|gmaxwell: can you do your hilite reminder? almost missed this
121 2017-08-10 19:04:59	0|cfields|yes, that :)
122 2017-08-10 19:05:36	0|wumpus|sounds like a good idea to factor out the critical, lower-risk changes so that it can still make 0.15.0rc1
123 2017-08-10 19:05:54	0|wumpus|though this does mean it needs a new review round
124 2017-08-10 19:06:00	0|gmaxwell|I believe all the shutdown ones have unanswered questions.
125 2017-08-10 19:06:08	0|wumpus|#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 jl2012 achow101
126 2017-08-10 19:06:22	0|gmaxwell|cfields: mine seems to be broken. Thanks wumpus.
127 2017-08-10 19:06:26	0|cfields|thanks
128 2017-08-10 19:06:31	0|sipa|present
129 2017-08-10 19:06:37	0|CodeShark|hello all
130 2017-08-10 19:06:43	0|paveljanik|here
131 2017-08-10 19:06:56	0|luke-jr|the startmeeting command should do it <.<
132 2017-08-10 19:06:59	0|Murch|hullo
133 2017-08-10 19:07:05	0|sipa|wumpus: the initial commits are the same
134 2017-08-10 19:07:07	0|jnewbery|I thought we were very close with 10882, with ACKs from several people. Greg - could you ask your unanswered questions in the PR? Your comments have mostly been in IRC and it's difficult to keep track of what your current concerns are
135 2017-08-10 19:07:33	0|wumpus|sipa: yes
136 2017-08-10 19:09:09	0|wumpus|10882 was kind of a miscommunication, I almost merged than when it turned out that there were still critical concerns with it
137 2017-08-10 19:09:41	0|gmaxwell|jnewbery: it's not with your implementation specifically, but the correct behavior.  Shutting down on never-behind wallets who just drained their keypools (or never had a big keypool) is undesirable, but it doesn't appear to be possible to detect if a wallet had potentially been behind or not. (e.g. the only during rescan hurestic will fail in some places where the node and the wallet were both
138 2017-08-10 19:09:47	0|gmaxwell|behind; as a simple example: backup your whole .bitcoin directory and later restor the backup)
139 2017-08-10 19:10:18	0|MarcoFalke|so 11022 is for 0.15 and 10882 should be removed from the milestone?
140 2017-08-10 19:10:21	0|gmaxwell|restore*
141 2017-08-10 19:11:04	0|wumpus|MarcoFalke: huh
142 2017-08-10 19:11:19	0|luke-jr|IMO the correct behaviour would be an interface for pruning locks in general (usable by external wallets too), and track the best chain independently from where the UTXO set is. but this is way too complicated IMO. :/
143 2017-08-10 19:11:21	0|wumpus|wasn't it the other way around?
144 2017-08-10 19:11:39	0|gmaxwell|MarcoFalke: that was my suggestion: merge the part we know is done. I don't think we can make a 10882 right now that won't result in strange behavior in some corner cases.
145 2017-08-10 19:11:40	0|sipa|luke-jr: yes, that's the eventual goal - agree, but we don't have to go there in one step
146 2017-08-10 19:11:52	0|jnewbery|wumpus : MarcoFalke has it right. 11022 is the simple subset
147 2017-08-10 19:11:54	0|achow101|wumpus: 11022 is newer than 10882
148 2017-08-10 19:11:54	0|wumpus|11022 was removed from 0.15, and 10882 replaced it
149 2017-08-10 19:12:01	0|gmaxwell|(at least not in short order)
150 2017-08-10 19:12:04	0|wumpus|why and who did that then?
151 2017-08-10 19:12:18	0|gmaxwell|11022 is a massive improvement and safty increase.
152 2017-08-10 19:12:27	0|achow101|wumpus: 10882 was created, 11022 was split out from 10882
153 2017-08-10 19:12:27	0|sipa|11022 is 10882 without the shutdown logic
154 2017-08-10 19:12:31	0|wumpus|what can we realistically finish in say, a week?
155 2017-08-10 19:12:47	0|gmaxwell|wumpus: there was a thid PR you're thinking of 11022 is new, as of a few hours ago.
156 2017-08-10 19:12:59	0|luke-jr|what if we just stop pruning, and let the normal low-disk-space shutdown do the job? ;)
157 2017-08-10 19:13:06	0|sipa|luke-jr: die
158 2017-08-10 19:13:11	0|luke-jr|:|
159 2017-08-10 19:13:13	0|gmaxwell|luke-jr: pruning is also not the only issue.
160 2017-08-10 19:13:15	0|wumpus|we can't continue adding things for 0.15 as that fix grows in scope more and more
161 2017-08-10 19:13:24	0|sipa|wumpus: 11022 is a reduction in scope
162 2017-08-10 19:13:35	0|sipa|i think 11022 can be ready to merge today or so
163 2017-08-10 19:13:39	0|wumpus|as this all deals with something that is not a regression in 0.15, I'm starting to be really doubtful about this
164 2017-08-10 19:13:45	0|gmaxwell|wumpus: that new PR radically reduced the scope, to the core part that has been in every PR so far.
165 2017-08-10 19:13:46	0|luke-jr|gmaxwell: what am I missing?
166 2017-08-10 19:14:00	0|sipa|*today
167 2017-08-10 19:14:13	0|jnewbery|11022 is ready now. It needs rereview by people, but it should be uncontroversial as it's a subset of what's already been ACKed
168 2017-08-10 19:14:57	0|wumpus|ah yes I was confused with the other 'keypool topup' PR
169 2017-08-10 19:15:44	0|MarcoFalke|ok, changed the milestones.
170 2017-08-10 19:15:54	0|wumpus|thanks
171 2017-08-10 19:16:04	0|gmaxwell|luke-jr: you could start by already reading the comments that are there.  Each version has failed in different corner cases.  I'll go update the PR with a longer list but after spending an hour talking to Pieter about it I'm just dispondent that it's all a mess that we won't fix quickly (again, not due to the code; but due to what behavior would actually be acceptable.)
172 2017-08-10 19:16:09	0|jnewbery|full history: Jonas's PR was 10240. I rebased and cleaned that up as 10830. I then reduced the scope and incorporated a bunch of feedback in 10882. I've now reduced the scope again in 11022
173 2017-08-10 19:16:40	0|wumpus|jnewbery: that's a painful history, thanks for sticking with it
174 2017-08-10 19:17:13	0|jnewbery|painful is a pretty accurate description!
175 2017-08-10 19:17:35	0|jonasschnelli|;-)
176 2017-08-10 19:17:43	0|gmaxwell|luke-jr: but in general, versions that shutdown based on low keypool have a problem with existing wallets failing to work when users upgrade, and efforts to avoid that can create cases where we'll fail to force a shutdown when we should. (for example if the user backed up and restored a whole .bitcoin directory).
177 2017-08-10 19:17:57	0|jnewbery|but let's try to get 11022 reviewed, and if gmaxwell could leave a nice long comment on 10882 about edge cases perhaps we can try again after 0.15
178 2017-08-10 19:18:21	0|gmaxwell|luke-jr: and I think now that a whole subfamily of suggestions I was making are just impossible to actually make work right, for which I am very sorry.
179 2017-08-10 19:18:35	0|gmaxwell|jnewbery: will do
180 2017-08-10 19:18:47	0|jnewbery|gmaxwell thanks
181 2017-08-10 19:19:33	0|jnewbery|sipa ryanofsky morcos bluematt instagibbs reviewed 10882. Should be a straightforward task for them to rereview 11022
182 2017-08-10 19:19:40	0|sipa|jnewbery: on it
183 2017-08-10 19:19:44	0|instagibbs|gotcha
184 2017-08-10 19:19:46	0|sipa|(right now)
185 2017-08-10 19:19:48	0|wumpus|We can't rule all out edge cases. Tthe most important thing is that people upgrading won't automatically run into the issue because 0.15 sets a larger keypool default.
186 2017-08-10 19:20:10	0|jnewbery|upgrade isn't an issue in 11022
187 2017-08-10 19:20:22	0|wumpus|good!
188 2017-08-10 19:20:26	0|instagibbs|will review today
189 2017-08-10 19:20:32	0|jnewbery|(and actually isn't in 10882 as it's now implemented, but let's not get into that)
190 2017-08-10 19:20:48	0|wumpus|do we have a test for that? :)
191 2017-08-10 19:21:11	0|jnewbery|no, as far as I'm aware we have no upgrade tests. It'd be nice to have them
192 2017-08-10 19:21:42	0|sipa|(gmaxwell went offline)
193 2017-08-10 19:21:57	0|wumpus|no, we don't have any upgrade tests
194 2017-08-10 19:22:11	0|instagibbs|jnewbery, to refresh memory: "Notably, it does not stop the node or prevent the best block from advancing if the keypool drops below a threshold" this is only in case of crypted?
195 2017-08-10 19:22:49	0|sipa|instagibbs: my belief is that it'll just succesfully top up when unlocked
196 2017-08-10 19:23:25	0|jnewbery|instagibbs, in 10882 we would only ever prevent best block advancing/stop node when top up was unsuccessful (ie encrypted locked wallet)
197 2017-08-10 19:23:39	0|sipa|jnewbery: great
198 2017-08-10 19:23:40	0|jnewbery|11022 removes all prevent best block advancing/stop node behaviour
199 2017-08-10 19:23:58	0|instagibbs|got it
200 2017-08-10 19:24:17	0|wumpus|even better would it be if we had test cases for all of gmaxwell's edge cases
201 2017-08-10 19:24:19	0|jnewbery|11022 is really very simple. It has a bunch of refactor commits, but the functional change is fairly small
202 2017-08-10 19:24:19	0|sipa|<gmaxwell> we can now have rescan instructions in our relwase notes: unlock the wallet and run rescan rpc
203 2017-08-10 19:25:20	0|jnewbery|if we can get bitcoin-wallet-tool and offline topup into v0.16 we have a very nice way of sidestepping most of the problems I believe
204 2017-08-10 19:25:44	0|gmaxwell|jnewbery: sipa was just saying something like that to me.
205 2017-08-10 19:25:54	0|sipa|jnewbery: alternatively, make the dynamic-load-wallet RPC fail in case of too low keypool, and make it take an optional passphrase
206 2017-08-10 19:25:56	0|luke-jr|at least GUI can block on a passphrase
207 2017-08-10 19:26:01	0|sipa|luke-jr: that too
208 2017-08-10 19:26:04	0|jnewbery|yes!
209 2017-08-10 19:26:08	0|luke-jr|sipa: oooh, that's an excellent approach for bitcoind
210 2017-08-10 19:26:23	0|gmaxwell|but all to much for 0.15 now.  But at least 11022 massively narrows the window and creates a workaround.
211 2017-08-10 19:26:27	0|sipa|agree
212 2017-08-10 19:27:20	0|sipa|any other 0.15-related topics?
213 2017-08-10 19:27:45	0|wumpus|although harder to implement there's no reason bitcoind couldn't block on a passphrase, justblock everything until a walletpassphrase command
214 2017-08-10 19:27:55	0|jnewbery|yuck
215 2017-08-10 19:28:05	0|jnewbery|multiwallet?
216 2017-08-10 19:28:05	0|luke-jr|if I prioritise rebasing the optional default-wallet, would it be considered for inclusion?
217 2017-08-10 19:28:51	0|luke-jr|wumpus: can RPC run without the node running?
218 2017-08-10 19:29:53	0|wumpus|luke-jr: in the same way the GUI can I guess
219 2017-08-10 19:30:10	0|gmaxwell|jnewbery: I think that is less yuck than some other options.  Though really it's block until passphrase or the critical key level is changed.
220 2017-08-10 19:30:35	0|wumpus|holding up RPC commands for a long time is bound to run into timeouts though
221 2017-08-10 19:30:54	0|luke-jr|wumpus: we already throw exceptions during init
222 2017-08-10 19:31:04	0|luke-jr|so we'd just need to make an exception for walletpassphrase
223 2017-08-10 19:31:14	0|wumpus|yes it's kind of yuck, it's opposite from anything we want to do, with the wallet being able to block the node
224 2017-08-10 19:31:18	0|luke-jr|the catch to this (and GUI prompting I guess) is that we need to load the wallet earlier
225 2017-08-10 19:32:18	0|gmaxwell|longer term we'll need ways to rescan wallets when there is pruning.  E.g. PIR wallet queries. But that is a research project with a 1yr horizon or so.
226 2017-08-10 19:32:41	0|gmaxwell|once we have something like this I think much of this mess goes away.
227 2017-08-10 19:32:51	0|jnewbery|Are there any other circumstances where bitcoind waits for stdin? I think it might inadvertently break peoples assumptions
228 2017-08-10 19:32:53	0|jonasschnelli|pir?
229 2017-08-10 19:33:08	0|sipa|jonasschnelli: https://en.wikipedia.org/wiki/Private_information_retrieval
230 2017-08-10 19:33:09	0|jnewbery|also it's messy if multiwallets are prompting for passphrases
231 2017-08-10 19:33:20	0|jonasschnelli|thy
232 2017-08-10 19:33:33	0|gmaxwell|jnewbery: not stdin, but accepting rpc connections and throwing the not ready yet error for all but walletpassphrase.
233 2017-08-10 19:33:45	0|gmaxwell|(like we do when loading the block index)
234 2017-08-10 19:34:17	0|jnewbery|oh ok, yeah that's not so bad
235 2017-08-10 19:34:28	0|gmaxwell|now I understand the yuck better. :)
236 2017-08-10 19:34:28	0|jnewbery|but to be clear, not for 0.15 :)
237 2017-08-10 19:34:31	0|gmaxwell|yes.
238 2017-08-10 19:34:32	0|wumpus|luke-jr: you mean going back into warmup mode? hmm then all clients would have to handle that
239 2017-08-10 19:35:03	0|luke-jr|wumpus: I mean never leaving warmup mode :p
240 2017-08-10 19:35:03	0|wumpus|oh certainly not stdin
241 2017-08-10 19:35:13	0|wumpus|luke-jr: that'd make sense
242 2017-08-10 19:35:43	0|wumpus|luke-jr: I somehow assumed it was something that could happen at runtime
243 2017-08-10 19:35:55	0|wumpus|anyhow, yes not for 0.15
244 2017-08-10 19:36:07	0|luke-jr|it probably can
245 2017-08-10 19:36:17	0|luke-jr|keypool size is still configurable I assume
246 2017-08-10 19:36:29	0|wumpus|but for dynamic wallet loading optionally passing the passphrase on load makes sense
247 2017-08-10 19:37:24	0|wumpus|ok - any other topics?
248 2017-08-10 19:37:26	0|jnewbery|Being able to run commands on load was my main motivation for #10740 . Unlocking and topping-up keypool fits well with that
249 2017-08-10 19:38:09	0|gmaxwell|I'd like to remind people that we all need to be testing on master hard right now. :)
250 2017-08-10 19:38:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
251 2017-08-10 19:38:45	0|wumpus|if only we had rc1 out everyone could be testing on rc1 :)
252 2017-08-10 19:40:11	0|sdaftuar|where are we on the segwit address format?
253 2017-08-10 19:40:21	0|wumpus|#topic segwit address format
254 2017-08-10 19:41:03	0|sipa|sdaftuar: https://github.com/sipa/bech32/pull/21
255 2017-08-10 19:41:20	0|sipa|almost done with a C++ reference version (though gmaxwell keeps finding untested cases)
256 2017-08-10 19:41:31	0|sipa|when that's done, i'll submit a PR to core to integrate it
257 2017-08-10 19:41:34	0|sdaftuar|great!
258 2017-08-10 19:41:39	0|jonasschnelli|nice
259 2017-08-10 19:41:40	0|cfields|sipa: great. will review that.
260 2017-08-10 19:42:03	0|sipa|which will need some refactor to get rid of CBitcoinAddress (i'm sorry for ever introducing that... there is no point for that to be a separate class...)
261 2017-08-10 19:42:26	0|Chris_Stewart_5|Is this going to be in 0.15.0 or 0.15.1?
262 2017-08-10 19:42:36	0|cfields|sipa: maybe best to just cram it into CBitcoinAddress first for easy 0.15 backport ?
263 2017-08-10 19:42:41	0|sdaftuar|not 0.15.0
264 2017-08-10 19:42:44	0|wumpus|certainly not 0.15.0
265 2017-08-10 19:42:45	0|Chris_Stewart_5|ok good
266 2017-08-10 19:42:49	0|jonasschnelli|Chris_Stewart_5: not in 0.15.0 maybe in 0.15.SW
267 2017-08-10 19:43:00	0|sipa|cfields: i'll see what i can do
268 2017-08-10 19:43:45	0|cfields|ok
269 2017-08-10 19:44:22	0|wumpus|any other topics?
270 2017-08-10 19:44:26	0|CodeShark|I have a quick one
271 2017-08-10 19:44:46	0|luke-jr|the hardest topics to discuss are the ones that are not disclosed. :P
272 2017-08-10 19:45:04	0|CodeShark|I would need to rebase, but now that SegWit is activating I'd really like to merge https://github.com/bitcoin/bitcoin/pull/10350
273 2017-08-10 19:46:04	0|wumpus|#topic Added support for MSG_FILTERED_WITNESS_BLOCK messages
274 2017-08-10 19:47:01	0|jonasschnelli|Wound't that require a bip first?
275 2017-08-10 19:47:18	0|CodeShark|is it really worth the effort?
276 2017-08-10 19:47:23	0|CodeShark|it's getting deprecated eventually
277 2017-08-10 19:47:26	0|CodeShark|probably pretty soon
278 2017-08-10 19:47:34	0|gmaxwell|well obviously not merged now, but perhaps in the .SW release. It needs a bip. unconditionally but it would be a trivial spec.
279 2017-08-10 19:47:42	0|CodeShark|ok
280 2017-08-10 19:47:46	0|gmaxwell|I can help with the bip.
281 2017-08-10 19:47:54	0|sipa|it doesn't look like it's too much work to add a witness proof
282 2017-08-10 19:47:55	0|wumpus|yeah it's a network protocol change so it needs some kind of BIP
283 2017-08-10 19:47:56	0|gmaxwell|(show of good will, since I really dislike the feature. :) )
284 2017-08-10 19:48:01	0|CodeShark|thanks, gmaxwell
285 2017-08-10 19:48:20	0|wumpus|if only to be able to refer to it in bips.md and such
286 2017-08-10 19:48:27	0|gmaxwell|(not due to it itself, but due to increasing the scope of BIP37)
287 2017-08-10 19:48:33	0|jonasschnelli|CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
288 2017-08-10 19:48:39	0|CodeShark|jonasschnelli: yes
289 2017-08-10 19:48:44	0|luke-jr|if it's literally only for short-term use by mSIGNA, I'm not sure it strictly NEEDS a BIP.
290 2017-08-10 19:48:55	0|gmaxwell|luke-jr: it's trivial to specify however.
291 2017-08-10 19:48:57	0|luke-jr|sure
292 2017-08-10 19:49:05	0|CodeShark|yeah, probably should stick to process
293 2017-08-10 19:49:08	0|wumpus|why not? it's good to have some kind of documentation
294 2017-08-10 19:49:19	0|gmaxwell|and the spec can also do things like tell people it is intended to be short lived.
295 2017-08-10 19:49:21	0|jonasschnelli|I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
296 2017-08-10 19:49:22	0|wumpus|others might want to use it too
297 2017-08-10 19:49:46	0|luke-jr|CodeShark: if you can rebase it quickly, maybe we can throw it in Knots until it's ready for Core
298 2017-08-10 19:49:58	0|CodeShark|sure :)
299 2017-08-10 19:50:00	0|jonasschnelli|I'm strongly advice for a BIP. Other may be interested and we don't want more specification within the code.
300 2017-08-10 19:50:07	0|gmaxwell|jonasschnelli: you can still do better things for that case, like send them the addresses explicitly.
301 2017-08-10 19:50:26	0|jonasschnelli|gmaxwell: Yes. But would require more work to do. :)
302 2017-08-10 19:50:28	0|sipa|i'd really like to see the addition of witness proofs, though - i understand that for your exact use case (which implies a trusted full node) that's unnecessary, but i don't think we should go that route in protocol extensions
303 2017-08-10 19:50:43	0|wumpus|gmaxwell: heh yes, if the connection is encrypted and the peer is trusted, why not, why even bother with a bloom filter
304 2017-08-10 19:50:56	0|gmaxwell|in any case basically any argument against doing a BIP is an argument for one too... it's trivial.  it's intended to be short lived (BIP would tell people that).
305 2017-08-10 19:51:10	0|gmaxwell|sipa: it would be a trivial change to make it do the witness proofs, no? just root on the other tree.
306 2017-08-10 19:51:30	0|sipa|gmaxwell: and give the coinbase, and normal merkle proof for the coinbase
307 2017-08-10 19:51:37	0|CodeShark|sipa: I am still not convinced it's worth the effort to add the witness proof
308 2017-08-10 19:51:43	0|wumpus|then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
309 2017-08-10 19:51:53	0|CodeShark|the coinbase issue means we need an entire new data structure
310 2017-08-10 19:51:54	0|sipa|CodeShark: then i would be opposed to supporting it
311 2017-08-10 19:52:07	0|sipa|CodeShark: use RPC instead
312 2017-08-10 19:52:11	0|CodeShark|huh?!
313 2017-08-10 19:52:14	0|gmaxwell|CodeShark: it's just a existing thing for the coinbase, and then one more rooted in it.
314 2017-08-10 19:52:55	0|CodeShark|it already takes me hours to sync back just a few weeks
315 2017-08-10 19:53:01	0|CodeShark|RPC would mean it takes forever
316 2017-08-10 19:53:03	0|sipa|CodeShark: you're asking to add a feature, available to every P2P client, which can only be safely used in a trusted setting
317 2017-08-10 19:53:04	0|luke-jr|why would you need a witness proof in this case anyway?
318 2017-08-10 19:53:15	0|CodeShark|sipa: ah, I see your point
319 2017-08-10 19:53:16	0|sipa|luke-jr: because the full node can lie
320 2017-08-10 19:53:38	0|luke-jr|sipa: about what? these peers don't have any need for the witness data at all
321 2017-08-10 19:53:39	0|CodeShark|agree that the trusted mode is distinct from p2p, but the HTTP server approach just won't do ;)
322 2017-08-10 19:53:46	0|sipa|luke-jr: read the PR
323 2017-08-10 19:53:55	0|wumpus|sipa has a good point, if it's to be on the P2P network, it has to be possible to use it untrusted
324 2017-08-10 19:53:58	0|sipa|luke-jr: CodeShark needs it to determine which subset of multisig signers spent the coins
325 2017-08-10 19:54:11	0|luke-jr|oh!
326 2017-08-10 19:54:13	0|wumpus|if not you'd have to wait for BIP150 (authentication)
327 2017-08-10 19:54:27	0|wumpus|and allow it to authenticated peers only
328 2017-08-10 19:54:43	0|sipa|yes, that would be private extensions easier
329 2017-08-10 19:55:15	0|sipa|CodeShark: but honestly, i don't think adding a proof for the witnesses is that hard; just send two structures (one with normal proof for coinbase, one with witness proof for the rest)
330 2017-08-10 19:55:38	0|CodeShark|it requires a lot of additional clientside modifications as well, I'd rather focus on clientside filtering
331 2017-08-10 19:55:44	0|gmaxwell|yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
332 2017-08-10 19:57:13	0|CodeShark|not saying it's hard - just time I think would be better invested elsewhere
333 2017-08-10 19:57:27	0|sipa|yes, like helping with client side filtering :)
334 2017-08-10 19:57:31	0|CodeShark|indeed
335 2017-08-10 19:57:40	0|sdaftuar|also though, if you intend to only use something on trusted nodes you could just carry a custom patch, no?  i mean, if there's not much other demand for this extension.
336 2017-08-10 19:57:51	0|achow101|does client side filtering have a bip?
337 2017-08-10 19:57:56	0|jonasschnelli|Could you not impelement directly the client side filtering?
338 2017-08-10 19:58:07	0|sipa|jonasschnelli: it's a nontrivial effort
339 2017-08-10 19:58:11	0|jonasschnelli|achow101: roasbeef hasn't opened the PR (last state is the ML post)
340 2017-08-10 19:58:14	0|sipa|needs stored bloom filters for all blocks on disk etc
341 2017-08-10 19:58:34	0|wumpus|achow101: not afaik
342 2017-08-10 19:59:01	0|jonasschnelli|sipa: Yes. But a long term strategy and there are a couple of people willing to contribute
343 2017-08-10 19:59:05	0|sipa|sure
344 2017-08-10 19:59:06	0|luke-jr|I assumed jonasschnelli meant implement BIP37 client-side
345 2017-08-10 19:59:20	0|jonasschnelli|not bip37
346 2017-08-10 19:59:21	0|CodeShark|lol, BIP37 needs to eventually die
347 2017-08-10 19:59:25	0|gmaxwell|I don't thin the spec has been updated to eliminate the divisions yet.
348 2017-08-10 20:00:11	0|wumpus|meeting time is over
349 2017-08-10 20:00:19	0|wumpus|#endmeeting
350 2017-08-10 20:00:20	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.log.html
351 2017-08-10 20:00:20	0|lightningbot|Meeting ended Thu Aug 10 20:00:18 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
352 2017-08-10 20:00:20	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.html
353 2017-08-10 20:00:20	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.txt
354 2017-08-10 20:00:22	0|luke-jr|but I just pinged roasbeef for the meeting :P
355 2017-08-10 20:00:37	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11025: qa: Fix inv race in example_test (06master...06Mf1708-qaInvExampleTest) 02https://github.com/bitcoin/bitcoin/pull/11025
356 2017-08-10 20:00:37	0|wumpus|:P
357 2017-08-10 20:00:40	0|roasbeef|achow101: there's a BIP draft, but I've been side tracked on another project. I need to incorporate suggestions for optimizations, then wrap up some TODO's and i'll officially request a #
358 2017-08-10 20:00:54	0|roasbeef|will be able to finish it up in a week or two
359 2017-08-10 20:01:04	0|jonasschnelli|roasbeef: Thanks for working on this!
360 2017-08-10 20:01:18	0|achow101|roasbeef: cool
361 2017-08-10 20:01:19	0|CodeShark|yes, roasbeef  +1
362 2017-08-10 20:07:29	0|instagibbs|roasbeef, does the other project rhyme with brightening
363 2017-08-10 20:09:03	0|roasbeef|something that just occured to me is also that it would be possible for pruned nodes to still serve light clients, assuming they still keep the filters on disk
364 2017-08-10 20:09:04	0|sipa|instagibbs: not in my understanding of english pronounciation
365 2017-08-10 20:09:11	0|roasbeef|instagibbs: maaaybe
366 2017-08-10 20:44:59	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11026: Bugfix: Use testnet RequireStandard for -acceptnonstdtxn default (06master...06bugfix_acceptnonstd_def) 02https://github.com/bitcoin/bitcoin/pull/11026
367 2017-08-10 23:09:04	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #11027: [RPC] Only return hex field once in getrawtransaction (06master...06fix-getrawtx) 02https://github.com/bitcoin/bitcoin/pull/11027
368 2017-08-10 23:33:25	0|sipa|happy block 0x75300 everyone
369 2017-08-10 23:34:02	0|sipa|it doesn't look at good in hex :(
370 2017-08-10 23:58:51	0|luke-jr|XD