1 2016-12-13T00:20:26  *** alpalp has joined #bitcoin-core-dev
  2 2016-12-13T00:27:49  *** alpalp has quit IRC
  3 2016-12-13T00:51:03  *** alpalp has joined #bitcoin-core-dev
  4 2016-12-13T00:51:04  *** alpalp has joined #bitcoin-core-dev
  5 2016-12-13T00:59:39  *** alpalp has quit IRC
  6 2016-12-13T01:01:26  *** alpalp has joined #bitcoin-core-dev
  7 2016-12-13T01:17:10  *** alpalp has quit IRC
  8 2016-12-13T01:27:15  *** alpalp has joined #bitcoin-core-dev
  9 2016-12-13T01:27:16  *** alpalp has joined #bitcoin-core-dev
 10 2016-12-13T01:31:42  *** crescendo has quit IRC
 11 2016-12-13T01:38:23  *** wasi has quit IRC
 12 2016-12-13T01:39:01  *** wasi has joined #bitcoin-core-dev
 13 2016-12-13T01:45:52  *** abpa_ has quit IRC
 14 2016-12-13T01:48:45  *** abpa has joined #bitcoin-core-dev
 15 2016-12-13T01:58:01  *** abpa has quit IRC
 16 2016-12-13T02:00:43  <Lightsword> think it would be reasonable to remove this TestBlockValidity check in 0.13 for miners? https://github.com/bitcoin/bitcoin/blob/0.13/src/miner.cpp#L193-L195
 17 2016-12-13T02:01:20  <Lightsword> I would assume if there were any issues there someone would have hit them by now
 18 2016-12-13T02:07:22  *** Ylbam has quit IRC
 19 2016-12-13T02:16:43  *** btcdrak has joined #bitcoin-core-dev
 20 2016-12-13T02:31:46  *** jtimon has quit IRC
 21 2016-12-13T03:09:22  *** MykelSIlver has quit IRC
 22 2016-12-13T03:09:35  *** MykelSIlver has joined #bitcoin-core-dev
 23 2016-12-13T03:11:14  *** abpa has joined #bitcoin-core-dev
 24 2016-12-13T03:20:01  *** Alopex has quit IRC
 25 2016-12-13T03:21:06  *** Alopex has joined #bitcoin-core-dev
 26 2016-12-13T03:25:26  <morcos> Lightsword: For what purpose?  Do we think its important to have block creation happen 100ms faster?  I'd be hesitant to do it unless someone could make a good argument that it's really beneficial to save the time
 27 2016-12-13T03:26:17  <gmaxwell> morcos: I think it could move into the background with basically no hit on reliablity... and then get rid of the 100ms concern.
 28 2016-12-13T03:26:24  <Lightsword> morcos, to speed up GBT and potentially reduce the need for validationless mining
 29 2016-12-13T03:26:26  <morcos> I suppose after a tip change, it makes sense to get a new block 100ms faster...  I wonder if we could just skip it in that case...
 30 2016-12-13T03:26:35  <Lightsword> gmaxwell, I think we couldn’t do that due to cs_main locks
 31 2016-12-13T03:27:25  <morcos> gmaxwell: i agree. we could move it to the background...  but i think you just want to be a tad careful that we don't view that as free, since it still locks cs_main for 100ms
 32 2016-12-13T03:28:24  <Lightsword> I’m pretty sure the cs_main lock itself is the problem
 33 2016-12-13T03:29:07  <gmaxwell> the lock is irrelevant from the perspective of time to response for the response itself.
 34 2016-12-13T03:30:03  <morcos> anyway... this late in the game i'd view that as a bit aggressive for 0.14...
 35 2016-12-13T03:30:07  <morcos> (any of it)
 36 2016-12-13T03:31:19  <gmaxwell> Lightsword: in 0.12 we made a number of fairly agressive changes to how block construction trusts the integrity of the mempool, with the argument that the test would catch any corruption that happened.
 37 2016-12-13T03:31:53  <gmaxwell> We've had mempool corruption bugs in the past. So totally running without ever having a test seems risky-- turns random mempool optimizations into possible quiet consensus bugs.
 38 2016-12-13T03:31:53  <Lightsword> well…we haven’t had anyone get a failure of TBV yet right?
 39 2016-12-13T03:32:11  <gmaxwell> No but we had failures of the internal mempool tests that we've since removed.
 40 2016-12-13T03:32:58  <gmaxwell> In any case, what I'd prefer to do is just get the TBV out of the critical path rather than never run it.
 41 2016-12-13T03:33:13  <gmaxwell> and it would also be fine as far as I'm concerned if it ran less often.
 42 2016-12-13T03:36:26  *** alpalp has quit IRC
 43 2016-12-13T03:38:18  <Lightsword> gmaxwell, can we get the cs_main lock out of the critical path as well?
 44 2016-12-13T03:40:22  <Lightsword> main thing I’m noticing is a huge GBT call time variance reduction when I removed these 4 lines https://github.com/bitcoin/bitcoin/blob/0.13/src/miner.cpp#L192-L195
 45 2016-12-13T03:41:13  <Lightsword> I removed the TBV call first without removing CValidationState state; but that had minimal effect, removing CValidationState state; however seems to have made a pretty decent difference
 46 2016-12-13T03:41:43  <gmaxwell> how much time are you talking about?
 47 2016-12-13T03:42:13  <Lightsword> it seems vary a lot unless I remove CValidationState state;
 48 2016-12-13T03:42:27  <Lightsword> over 100ms gbt call time differences
 49 2016-12-13T03:42:34  <Lightsword> just between successive calls
 50 2016-12-13T03:42:43  <Lightsword> vs close to 20 with it removed
 51 2016-12-13T03:51:01  <morcos> I'm not sure what you mean about CValidationState, the only line doing anything is the TBV, but yes I think that sounds about right....  CreateNewBlock = 20ms + 100ms for TBV where there is a lot of variance in the 100ms part
 52 2016-12-13T03:52:26  <Lightsword> hmm, maybe I’m mixing that up
 53 2016-12-13T03:52:38  <Lightsword> anyways direct comparing def is much more consistant
 54 2016-12-13T03:53:00  <Lightsword> without TBV
 55 2016-12-13T04:13:35  *** Atomicat has quit IRC
 56 2016-12-13T04:13:50  *** Atomicat has joined #bitcoin-core-dev
 57 2016-12-13T04:41:04  <bitcoin-git> [bitcoin] rebroad opened pull request #9338: Stripe downloads to reduce stallers occuring (master...ReduceStalling) https://github.com/bitcoin/bitcoin/pull/9338
 58 2016-12-13T04:45:48  *** brg444 has quit IRC
 59 2016-12-13T04:51:55  *** warren has quit IRC
 60 2016-12-13T04:51:55  *** adam3us has quit IRC
 61 2016-12-13T05:54:04  *** baldur has quit IRC
 62 2016-12-13T06:06:32  *** baldur has joined #bitcoin-core-dev
 63 2016-12-13T06:06:38  *** windsok has quit IRC
 64 2016-12-13T06:07:14  *** justanotheruser has quit IRC
 65 2016-12-13T06:20:24  *** windsok has joined #bitcoin-core-dev
 66 2016-12-13T06:42:07  *** Alopex has quit IRC
 67 2016-12-13T06:43:12  *** Alopex has joined #bitcoin-core-dev
 68 2016-12-13T06:48:56  *** To7 has quit IRC
 69 2016-12-13T06:49:33  *** Ylbam has joined #bitcoin-core-dev
 70 2016-12-13T07:00:11  *** dermoth has quit IRC
 71 2016-12-13T07:03:03  *** dermoth has joined #bitcoin-core-dev
 72 2016-12-13T07:11:22  *** moli has quit IRC
 73 2016-12-13T07:12:00  *** moli has joined #bitcoin-core-dev
 74 2016-12-13T07:53:31  *** BashCo has quit IRC
 75 2016-12-13T07:54:11  *** BashCo has joined #bitcoin-core-dev
 76 2016-12-13T07:59:15  *** BashCo has quit IRC
 77 2016-12-13T08:17:33  *** BashCo has joined #bitcoin-core-dev
 78 2016-12-13T08:30:55  *** Giszmo has quit IRC
 79 2016-12-13T08:34:11  *** abpa has quit IRC
 80 2016-12-13T09:32:38  *** ryanofsky_ has quit IRC
 81 2016-12-13T09:32:57  *** morcos has quit IRC
 82 2016-12-13T09:32:58  *** sdaftuar has quit IRC
 83 2016-12-13T09:32:59  *** zxzzt has quit IRC
 84 2016-12-13T09:33:16  *** laurentmt has joined #bitcoin-core-dev
 85 2016-12-13T09:34:18  *** zxzzt has joined #bitcoin-core-dev
 86 2016-12-13T09:34:43  *** morcos has joined #bitcoin-core-dev
 87 2016-12-13T09:34:51  *** sdaftuar has joined #bitcoin-core-dev
 88 2016-12-13T09:34:51  *** sdaftuar has joined #bitcoin-core-dev
 89 2016-12-13T09:35:28  *** laurentmt has quit IRC
 90 2016-12-13T09:39:12  <bitcoin-git> [bitcoin] goku1997 opened pull request #9339: Revert segwit. Increase block size to 8MB for Bitcoin Ocho. Bitcoin Ocho is the future. (master...master) https://github.com/bitcoin/bitcoin/pull/9339
 91 2016-12-13T09:40:13  <rabidus_> :E
 92 2016-12-13T09:43:07  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9339: Revert segwit. Increase block size to 8MB for Bitcoin Ocho. Bitcoin Ocho is the future. (master...master) https://github.com/bitcoin/bitcoin/pull/9339
 93 2016-12-13T09:43:34  *** MarcoFalke has joined #bitcoin-core-dev
 94 2016-12-13T09:45:53  *** ryanofsky_ has joined #bitcoin-core-dev
 95 2016-12-13T09:50:01  <luke-jr> sigh
 96 2016-12-13T09:58:21  *** laurentmt has joined #bitcoin-core-dev
 97 2016-12-13T10:00:40  <Lauda> You should listen ti maxwell's advice regarding that one.
 98 2016-12-13T10:08:48  <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #9064: unify capitalization of "bitcoin address" (master...changeCaps) https://github.com/bitcoin/bitcoin/pull/9064
 99 2016-12-13T10:09:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/76fcd9d50341...e6ba5068f107
100 2016-12-13T10:09:28  <bitcoin-git> bitcoin/master e49a252 Richard Kiss: Fix spelling.
101 2016-12-13T10:09:29  <bitcoin-git> bitcoin/master e6ba506 MarcoFalke: Merge #9335: Fix typo in test/data/tx_valid.json...
102 2016-12-13T10:09:42  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9335: Fix typo in test/data/tx_valid.json (master...feature/typo) https://github.com/bitcoin/bitcoin/pull/9335
103 2016-12-13T10:18:07  *** laurentmt has quit IRC
104 2016-12-13T10:27:19  *** AaronvanW has quit IRC
105 2016-12-13T10:29:05  *** laurentmt has joined #bitcoin-core-dev
106 2016-12-13T10:33:55  <MarcoFalke> I think #9302 and #9290 are reviewed to death, ready for merge
107 2016-12-13T10:33:57  <gribble> https://github.com/bitcoin/bitcoin/issues/9302 | Return txid even if ATMP fails for new transaction by sipa · Pull Request #9302 · bitcoin/bitcoin · GitHub
108 2016-12-13T10:33:59  <gribble> https://github.com/bitcoin/bitcoin/issues/9290 | Make RelayWalletTransaction attempt to AcceptToMemoryPool. by gmaxwell · Pull Request #9290 · bitcoin/bitcoin · GitHub
109 2016-12-13T10:36:33  <MarcoFalke> > wumpus
110 2016-12-13T10:36:36  <MarcoFalke> can people please notify me if there is a pull which is clearly ready for merging?
111 2016-12-13T10:38:27  *** laurentmt has quit IRC
112 2016-12-13T10:44:15  *** jtimon has joined #bitcoin-core-dev
113 2016-12-13T10:48:37  *** MarcoFalke has left #bitcoin-core-dev
114 2016-12-13T10:50:18  *** jtimon has quit IRC
115 2016-12-13T11:03:49  *** AaronvanW has joined #bitcoin-core-dev
116 2016-12-13T11:03:50  *** AaronvanW has quit IRC
117 2016-12-13T11:03:50  *** AaronvanW has joined #bitcoin-core-dev
118 2016-12-13T11:15:54  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e6ba5068f107...b6abdc77d39c
119 2016-12-13T11:15:54  <bitcoin-git> bitcoin/master b3a7410 Pieter Wuille: Return txid even if ATMP fails for new transaction
120 2016-12-13T11:15:55  <bitcoin-git> bitcoin/master b6abdc7 Wladimir J. van der Laan: Merge #9302: Return txid even if ATMP fails for new transaction...
121 2016-12-13T11:16:09  <bitcoin-git> [bitcoin] laanwj closed pull request #9302: Return txid even if ATMP fails for new transaction (master...failedtxid) https://github.com/bitcoin/bitcoin/pull/9302
122 2016-12-13T11:17:08  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b6abdc77d39c...cfd5e6b1dc32
123 2016-12-13T11:17:09  <bitcoin-git> bitcoin/master 7b49f22 Pieter Wuille: Squashed 'src/secp256k1/' changes from 7a49cac..8225239...
124 2016-12-13T11:17:10  <bitcoin-git> bitcoin/master 547a53d Pieter Wuille: Update libsecp256k1 to master
125 2016-12-13T11:17:10  <bitcoin-git> bitcoin/master cfd5e6b Wladimir J. van der Laan: Merge #9334: Update to latest libsecp256k1...
126 2016-12-13T11:17:24  <bitcoin-git> [bitcoin] laanwj closed pull request #9334: Update to latest libsecp256k1 (master...secp) https://github.com/bitcoin/bitcoin/pull/9334
127 2016-12-13T11:21:39  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfd5e6b1dc32...5233aefa3f52
128 2016-12-13T11:21:40  <bitcoin-git> bitcoin/master 8c1dbc5 Karl-Johan Alm: Refactor: Removed begin/end_ptr functions.
129 2016-12-13T11:21:40  <bitcoin-git> bitcoin/master 5233aef Wladimir J. van der Laan: Merge #9305: Refactor: Removed begin/end_ptr functions....
130 2016-12-13T11:21:54  <bitcoin-git> [bitcoin] laanwj closed pull request #9305: Refactor: Removed begin/end_ptr functions. (master...remove-begin-end_ptr-usage) https://github.com/bitcoin/bitcoin/pull/9305
131 2016-12-13T11:22:50  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5233aefa3f52...26fe5c98ab6a
132 2016-12-13T11:22:51  <bitcoin-git> bitcoin/master bae1eef Gregory Maxwell: Fix wallet/test/crypto_tests.cpp for OpenSSL 1.1 API....
133 2016-12-13T11:22:51  <bitcoin-git> bitcoin/master b05b1af Gregory Maxwell: Fix qt/paymentrequestplus.cpp for OpenSSL 1.1 API....
134 2016-12-13T11:22:52  <bitcoin-git> bitcoin/master 26fe5c9 Wladimir J. van der Laan: Merge #9326: Update for OpenSSL 1.1 API....
135 2016-12-13T11:23:05  <bitcoin-git> [bitcoin] laanwj closed pull request #9326: Update for OpenSSL 1.1 API. (master...openssl_api11) https://github.com/bitcoin/bitcoin/pull/9326
136 2016-12-13T11:25:09  *** atroxes has quit IRC
137 2016-12-13T11:33:41  *** MarcoFalke has joined #bitcoin-core-dev
138 2016-12-13T11:34:30  *** atroxes has joined #bitcoin-core-dev
139 2016-12-13T11:34:37  <MarcoFalke> I am going to create a pull for the subtree update on 0.13, because it is not possible to jsut backport
140 2016-12-13T11:41:45  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9340: [0.13] Update secp256k1 subtree (0.13...Mf1612-013subtree) https://github.com/bitcoin/bitcoin/pull/9340
141 2016-12-13T11:46:24  *** jtimon has joined #bitcoin-core-dev
142 2016-12-13T11:50:37  *** MarcoFalke has left #bitcoin-core-dev
143 2016-12-13T12:00:54  *** jtimon has quit IRC
144 2016-12-13T12:07:37  *** laurentmt has joined #bitcoin-core-dev
145 2016-12-13T12:08:08  *** laurentmt has quit IRC
146 2016-12-13T12:24:28  *** jtimon has joined #bitcoin-core-dev
147 2016-12-13T12:32:11  *** chris200_ has joined #bitcoin-core-dev
148 2016-12-13T12:44:35  *** jtimon has quit IRC
149 2016-12-13T12:58:05  *** jtimon has joined #bitcoin-core-dev
150 2016-12-13T13:08:56  *** btcdrak has quit IRC
151 2016-12-13T13:09:50  *** justanotheruser has joined #bitcoin-core-dev
152 2016-12-13T13:10:50  *** jtimon has quit IRC
153 2016-12-13T13:16:24  *** arubi has quit IRC
154 2016-12-13T13:24:57  *** goregrind has quit IRC
155 2016-12-13T13:28:14  *** goregrind has joined #bitcoin-core-dev
156 2016-12-13T13:49:51  *** Atomicat has quit IRC
157 2016-12-13T13:53:51  *** Atomicat has joined #bitcoin-core-dev
158 2016-12-13T13:54:00  *** arubi has joined #bitcoin-core-dev
159 2016-12-13T13:57:14  *** wasi has quit IRC
160 2016-12-13T14:02:37  *** wasi has joined #bitcoin-core-dev
161 2016-12-13T14:04:38  <jonasschnelli> luke-jr: the question is, if we really want to support commands like cmd(arg,,) resulting in `cmd arg "" ""`
162 2016-12-13T14:04:47  <jonasschnelli> IMO the later is fine... but not sure about cmd(arg,,)
163 2016-12-13T14:05:16  <jonasschnelli> Empty arguments in a bracket-like syntax looks strange to me.
164 2016-12-13T14:05:28  *** Chris_Stewart_5 has quit IRC
165 2016-12-13T14:07:02  *** protomar has joined #bitcoin-core-dev
166 2016-12-13T14:07:23  <luke-jr> jonasschnelli: IMO either it should be supported, or an error ;)
167 2016-12-13T14:07:58  <jonasschnelli> luke-jr: Yes. Agree. IMO it should thrown an error... I'll fix that.
168 2016-12-13T14:12:58  *** laurentmt has joined #bitcoin-core-dev
169 2016-12-13T14:19:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
170 2016-12-13T14:42:21  *** Guyver2 has joined #bitcoin-core-dev
171 2016-12-13T14:44:15  *** Chris_Stewart_5 has quit IRC
172 2016-12-13T14:44:27  *** Sosumi has joined #bitcoin-core-dev
173 2016-12-13T14:48:56  *** To7 has joined #bitcoin-core-dev
174 2016-12-13T14:50:56  *** jtimon has joined #bitcoin-core-dev
175 2016-12-13T14:53:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
176 2016-12-13T14:56:13  <phantomcircuit> jonasschnelli, is this for nested calls?
177 2016-12-13T15:23:33  *** JackH has joined #bitcoin-core-dev
178 2016-12-13T15:24:33  *** Giszmo has joined #bitcoin-core-dev
179 2016-12-13T15:45:33  <jtimon> sorry, can't access github now, but rebased https://github.com/bitcoin/bitcoin/pull/9279 and the windows builds keep failing in a way I cannot understand or reproduce, it says "int64_t does not name a type". Any help welcomed
180 2016-12-13T15:59:02  *** abpa has joined #bitcoin-core-dev
181 2016-12-13T16:03:05  <bitcoin-git> [bitcoin] richardkiss opened pull request #9342: Change SIG_NULLFAIL => NULLFAIL. (master...feature/unify_nullfail) https://github.com/bitcoin/bitcoin/pull/9342
182 2016-12-13T16:30:16  <ryanofsky_> jtimon: maybe it needs an #include <stdint.h>
183 2016-12-13T16:32:44  <jtimon> ryanofsky_: it has an #include <stdlib.h> but it may be just that, thanks, I'll try that
184 2016-12-13T16:34:46  *** laurentmt has quit IRC
185 2016-12-13T16:35:37  *** laurentmt has joined #bitcoin-core-dev
186 2016-12-13T16:37:22  *** Ylbam has quit IRC
187 2016-12-13T16:45:21  *** btcdrak has joined #bitcoin-core-dev
188 2016-12-13T16:49:10  *** abpa has joined #bitcoin-core-dev
189 2016-12-13T16:54:40  *** Ylbam has joined #bitcoin-core-dev
190 2016-12-13T17:25:24  *** protomar has quit IRC
191 2016-12-13T17:26:15  *** laurentmt has quit IRC
192 2016-12-13T17:46:38  *** laurentmt has joined #bitcoin-core-dev
193 2016-12-13T17:47:02  *** laurentmt has quit IRC
194 2016-12-13T17:48:05  *** BashCo has quit IRC
195 2016-12-13T18:07:40  *** BashCo has joined #bitcoin-core-dev
196 2016-12-13T18:08:35  *** atroxes has quit IRC
197 2016-12-13T18:09:50  *** atroxes has joined #bitcoin-core-dev
198 2016-12-13T18:13:38  *** paveljanik has joined #bitcoin-core-dev
199 2016-12-13T18:25:38  *** aalex_ has quit IRC
200 2016-12-13T18:53:11  <gmaxwell> wumpus: thanks for the merges!
201 2016-12-13T19:03:23  *** aalex has joined #bitcoin-core-dev
202 2016-12-13T19:17:48  *** bsm117532 has quit IRC
203 2016-12-13T19:24:01  *** timothy has quit IRC
204 2016-12-13T19:26:04  <morcos> I'm working on a PR to properly distinguish all the different uses of minRelayTxFee.  It is my opinion that the dust threshold should not be arbitrarily changed by a desire to increase your minimum relay fee.  Changing the definition of dust has a negative effect on the network by causing some txs to be non-standard, and potentially get stuck in your mempool.
205 2016-12-13T19:26:55  <sipa> morcos: i'm working on a per-txout chainstate... this simplifies so much
206 2016-12-13T19:27:10  <morcos> My question is, does it makes sense to be able to control the dust limit with a command line option... Or do we think it's only something that needs a hard-coded constant, that could be changed in a future release if we've had several releases that already use a higher value for tx creation
207 2016-12-13T19:27:38  <morcos> sipa: ah, i had some ideas about maybe how to do that.. i'll be curious to see what you come up with!  i agree.  it'll be good
208 2016-12-13T19:27:55  <sipa> morcos: doing it a very naive way, hoping that leveldb properly deduplicates the txids
209 2016-12-13T19:28:15  <morcos> won't take long to figure that out.. ha
210 2016-12-13T19:28:47  <sipa> but no need for CCoinsModifier etc anymore... just an AddCoins and SpendCoins function, which never need to call GetCoins on the lower-level, just HaveCoins to know whether to mark something as fresh
211 2016-12-13T19:29:21  <gmaxwell> morcos: I think our practice has been to make things configurable, so thats what you should probably do. (though I think this is often a mistake and it's not really here)
212 2016-12-13T19:30:02  *** bsm117532 has joined #bitcoin-core-dev
213 2016-12-13T19:30:09  <sipa> morcos: regarding dust... it's my opinion that a rational wallet should never create dust outputs by such a wide margin that the actual value of the dust threshold does not matter
214 2016-12-13T19:30:11  <morcos> ok already adding -incrementalrelayfee and -blockmintxfee , was hoping to avoid so many new command line options that wumpus reached through my screen to choke me
215 2016-12-13T19:30:35  <gmaxwell> (it's not really needed here, loast a word)
216 2016-12-13T19:30:45  <gmaxwell> sipa:  you could put down the eng work on that for a moment, and make a quick change to adjust how the records work in leveldb. to see if it's a non-starter.
217 2016-12-13T19:31:53  <morcos> sipa: yes, thats goign to be among the changes i make..   we actually do an OK job of that now because of MIN_CHANGE, but we still have soem safety checks against IsDust which should be against a higher limit I think...
218 2016-12-13T19:32:53  <morcos> Unfortunately..  you can't put too much of a safety margin, otherwise you start having non-trivial amounts , which is espeically a problem when you are subtracting fees from recipients..  (where if your change would have been dust, then you take more money from the recipients to make your change higher!)
219 2016-12-13T19:41:15  *** jtimon has quit IRC
220 2016-12-13T19:41:31  *** jtimon has joined #bitcoin-core-dev
221 2016-12-13T19:41:33  <morcos> sipa: so aside from change, it makes sense for our wallet to refuse to pay someone an amount between dust and safetyMargin*dust as well?
222 2016-12-13T19:45:53  <sipa> morcos: i don't know about outputs... but for change, we shouldn't make anything between changeOutputWeight * effectiveRelayFee
223 2016-12-13T19:45:59  <sipa> s/between/below/
224 2016-12-13T19:47:36  <morcos> sipa: my idea is that what is important is that the txs your wallet creates will likely be considered standard for sometime
225 2016-12-13T19:48:12  <morcos> so minChange takes care of making a best-efforts basis to not produce anything uneconomical
226 2016-12-13T19:48:47  <morcos> but it would makes sense to have some dustCreationTheshold = SafetyMargin * dustThreshold
227 2016-12-13T19:48:53  <morcos> that applies to everything...
228 2016-12-13T19:49:23  <morcos> then if ever need to change dustThreshold..   we're not causing old wallets to create unrelayable/unminable txs by accident
229 2016-12-13T19:54:42  *** shesek has quit IRC
230 2016-12-13T19:59:25  *** timothy has joined #bitcoin-core-dev
231 2016-12-13T20:05:55  *** jtimon has quit IRC
232 2016-12-13T20:06:03  *** jtimon has joined #bitcoin-core-dev
233 2016-12-13T20:14:38  <morcos> Can we add one of those checkboxes that lets bitcoin-qt send back diagnostics to us about how it's actually used so we can improve it?  :)
234 2016-12-13T20:21:14  *** Chris_Stewart_5 has quit IRC
235 2016-12-13T20:31:20  <jtimon> btw ryanofsky_ thanks was that
236 2016-12-13T20:35:59  <jtimon> morcos: mhmm, of -incrementalrelayfee and -blockmintxfee which one is the one for the dust? I assume the second, what about calling it -dusttxfee ?
237 2016-12-13T20:36:34  <morcos> jtimon: ha.  neither!  thats why i was hoping to avoid a third.
238 2016-12-13T20:36:55  <jtimon> oh, mhmm, I lack the context on why you need 2 already
239 2016-12-13T20:37:01  <morcos> will explain in the PR
240 2016-12-13T20:37:07  <gmaxwell> morcos: be sure to include private keys.
241 2016-12-13T20:37:08  <jtimon> sure, no hurry
242 2016-12-13T20:37:31  *** jtimon has quit IRC
243 2016-12-13T20:37:40  *** jtimon has joined #bitcoin-core-dev
244 2016-12-13T20:37:55  <gmaxwell> morcos: so long as what the wallet targets and what the network enforces are seperate settings, then we don't have any problem with changing it in the future... (wallet must be changed amply ahead of the network, if the network will become more restrictive)
245 2016-12-13T20:38:07  <gmaxwell> I hope there is no reason to make the network more restrictive of dust in the future.
246 2016-12-13T20:40:42  <paveljanik> gmaxwell, ;-) I expect it will be rbtced in 5, 4, 3, ... ;-)
247 2016-12-13T20:40:47  <jtimon> btw, morcos, your change to the dust variable will probably less painful after https://github.com/bitcoin/bitcoin/pull/9279/commits/59ed6874612a0c4c410fc6016c21cdde68c42601
248 2016-12-13T20:45:38  *** Sosumi has quit IRC
249 2016-12-13T20:55:38  *** timothy has quit IRC
250 2016-12-13T20:59:17  <morcos> jtimon: yes, certainly don't object to moving it out of consensus, but I think it's actually useful that you can pass in a feerate to use.  For instance what we were talkign about with gmaxwell , you might want to use a higher threshold for creation than the policy dust limit.
251 2016-12-13T21:02:52  <jtimon> mhmm, I hadn't though about that, maybe a reason to modify #9279 ...
252 2016-12-13T21:02:54  <gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
253 2016-12-13T21:03:24  <jtimon> I was hoping to encapsulate the variable behind a policy class at some point...
254 2016-12-13T21:06:16  <jtimon> I guess another option would be to have 2 functions/methods that call the same one internally
255 2016-12-13T21:10:50  *** timothy has joined #bitcoin-core-dev
256 2016-12-13T21:12:47  <morcos> jtimon: yeah i think that would be fine and an easy change:  GDT(txout) { return GDT(txout, ::minRelayTxFee); }
257 2016-12-13T21:13:28  <jtimon> I mean, if we plan to encapsulate the value later that's 2 rounds of disruption instead of one
258 2016-12-13T21:13:40  <morcos> and could even just make that change later if you don't want to now..  maybe i will wait on my dust change until yours get merged, but i'd really like to have dust stop changing every time you change the minrelaytxfee
259 2016-12-13T21:14:17  <jtimon> I mean, didn't mean to stop you
260 2016-12-13T21:15:36  <morcos> well i like your change.. and i have to potentially change all the IsDust call sites too, so no reason to do it multiple times.   I think the change you made to them makes sense, and then maybe some of them will later take an optional feerate argument if we want to use a higher dust creation threshold
261 2016-12-13T21:16:41  <jtimon> my point about was we could have policy.IsDust(txOut) and policy.IsDustCreate(txOut) if we want  ot have 2 dust rates, but I'm not sure I understand the purpose of the create one
262 2016-12-13T21:17:14  <jtimon> or that
263 2016-12-13T21:17:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
264 2016-12-13T21:17:32  <jtimon> optionally taking another one if we maybe want to have more than 2 rates
265 2016-12-13T21:18:17  <gmaxwell> jtimon: any time there is a limit on relay behavior there really should be two limits-- one used for relay and one equal or more conservative one for the wallet.
266 2016-12-13T21:18:32  <gmaxwell> Otherwise it is impossible to change the limit without causing the creation of limit violating transactions.
267 2016-12-13T21:19:02  <jtimon> I see
268 2016-12-13T21:38:03  *** bsm117532 has quit IRC
269 2016-12-13T21:38:29  *** bsm117532 has joined #bitcoin-core-dev
270 2016-12-13T21:42:47  *** bsm117532 has quit IRC
271 2016-12-13T21:43:15  *** bsm117532 has joined #bitcoin-core-dev
272 2016-12-13T21:48:33  *** Guyver2 has quit IRC
273 2016-12-13T21:49:55  <bitcoin-git> [bitcoin] morcos opened pull request #9343: Don't create change at dust limit (master...noneconomicchange) https://github.com/bitcoin/bitcoin/pull/9343
274 2016-12-13T21:51:04  <morcos> gmaxwell: ^ just a first step to avoid having to deal with a complicated edge case... but maybe it won't be acceptable to people.  it seems odd to me that this would be a case that is hit very often, as i expect subtractFeeFromAmount is used when you want to send whole balances or coins.
275 2016-12-13T21:51:17  <morcos> but i admit i don't know how its used....
276 2016-12-13T22:29:04  *** brg444 has joined #bitcoin-core-dev
277 2016-12-13T22:47:21  *** arubi has quit IRC
278 2016-12-13T23:30:43  *** JackH has quit IRC