12016-12-13T00:20:26  *** alpalp has joined #bitcoin-core-dev
  22016-12-13T00:27:49  *** alpalp has quit IRC
  32016-12-13T00:51:03  *** alpalp has joined #bitcoin-core-dev
  42016-12-13T00:51:04  *** alpalp has joined #bitcoin-core-dev
  52016-12-13T00:59:39  *** alpalp has quit IRC
  62016-12-13T01:01:26  *** alpalp has joined #bitcoin-core-dev
  72016-12-13T01:17:10  *** alpalp has quit IRC
  82016-12-13T01:27:15  *** alpalp has joined #bitcoin-core-dev
  92016-12-13T01:27:16  *** alpalp has joined #bitcoin-core-dev
 102016-12-13T01:31:42  *** crescendo has quit IRC
 112016-12-13T01:38:23  *** wasi has quit IRC
 122016-12-13T01:39:01  *** wasi has joined #bitcoin-core-dev
 132016-12-13T01:45:52  *** abpa_ has quit IRC
 142016-12-13T01:48:45  *** abpa has joined #bitcoin-core-dev
 152016-12-13T01:58:01  *** abpa has quit IRC
 162016-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
 172016-12-13T02:01:20  <Lightsword> I would assume if there were any issues there someone would have hit them by now
 182016-12-13T02:07:22  *** Ylbam has quit IRC
 192016-12-13T02:16:43  *** btcdrak has joined #bitcoin-core-dev
 202016-12-13T02:31:46  *** jtimon has quit IRC
 212016-12-13T03:09:22  *** MykelSIlver has quit IRC
 222016-12-13T03:09:35  *** MykelSIlver has joined #bitcoin-core-dev
 232016-12-13T03:11:14  *** abpa has joined #bitcoin-core-dev
 242016-12-13T03:20:01  *** Alopex has quit IRC
 252016-12-13T03:21:06  *** Alopex has joined #bitcoin-core-dev
 262016-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
 272016-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.
 282016-12-13T03:26:24  <Lightsword> morcos, to speed up GBT and potentially reduce the need for validationless mining
 292016-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...
 302016-12-13T03:26:35  <Lightsword> gmaxwell, I think we couldn’t do that due to cs_main locks
 312016-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
 322016-12-13T03:28:24  <Lightsword> I’m pretty sure the cs_main lock itself is the problem
 332016-12-13T03:29:07  <gmaxwell> the lock is irrelevant from the perspective of time to response for the response itself.
 342016-12-13T03:30:03  <morcos> anyway... this late in the game i'd view that as a bit aggressive for 0.14...
 352016-12-13T03:30:07  <morcos> (any of it)
 362016-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.
 372016-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.
 382016-12-13T03:31:53  <Lightsword> well…we haven’t had anyone get a failure of TBV yet right?
 392016-12-13T03:32:11  <gmaxwell> No but we had failures of the internal mempool tests that we've since removed.
 402016-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.
 412016-12-13T03:33:13  <gmaxwell> and it would also be fine as far as I'm concerned if it ran less often.
 422016-12-13T03:36:26  *** alpalp has quit IRC
 432016-12-13T03:38:18  <Lightsword> gmaxwell, can we get the cs_main lock out of the critical path as well?
 442016-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
 452016-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
 462016-12-13T03:41:43  <gmaxwell> how much time are you talking about?
 472016-12-13T03:42:13  <Lightsword> it seems vary a lot unless I remove CValidationState state;
 482016-12-13T03:42:27  <Lightsword> over 100ms gbt call time differences
 492016-12-13T03:42:34  <Lightsword> just between successive calls
 502016-12-13T03:42:43  <Lightsword> vs close to 20 with it removed
 512016-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
 522016-12-13T03:52:26  <Lightsword> hmm, maybe I’m mixing that up
 532016-12-13T03:52:38  <Lightsword> anyways direct comparing def is much more consistant
 542016-12-13T03:53:00  <Lightsword> without TBV
 552016-12-13T04:13:35  *** Atomicat has quit IRC
 562016-12-13T04:13:50  *** Atomicat has joined #bitcoin-core-dev
 572016-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
 582016-12-13T04:45:48  *** brg444 has quit IRC
 592016-12-13T04:51:55  *** warren has quit IRC
 602016-12-13T04:51:55  *** adam3us has quit IRC
 612016-12-13T05:54:04  *** baldur has quit IRC
 622016-12-13T06:06:32  *** baldur has joined #bitcoin-core-dev
 632016-12-13T06:06:38  *** windsok has quit IRC
 642016-12-13T06:07:14  *** justanotheruser has quit IRC
 652016-12-13T06:20:24  *** windsok has joined #bitcoin-core-dev
 662016-12-13T06:42:07  *** Alopex has quit IRC
 672016-12-13T06:43:12  *** Alopex has joined #bitcoin-core-dev
 682016-12-13T06:48:56  *** To7 has quit IRC
 692016-12-13T06:49:33  *** Ylbam has joined #bitcoin-core-dev
 702016-12-13T07:00:11  *** dermoth has quit IRC
 712016-12-13T07:03:03  *** dermoth has joined #bitcoin-core-dev
 722016-12-13T07:11:22  *** moli has quit IRC
 732016-12-13T07:12:00  *** moli has joined #bitcoin-core-dev
 742016-12-13T07:53:31  *** BashCo has quit IRC
 752016-12-13T07:54:11  *** BashCo has joined #bitcoin-core-dev
 762016-12-13T07:59:15  *** BashCo has quit IRC
 772016-12-13T08:17:33  *** BashCo has joined #bitcoin-core-dev
 782016-12-13T08:30:55  *** Giszmo has quit IRC
 792016-12-13T08:34:11  *** abpa has quit IRC
 802016-12-13T09:32:38  *** ryanofsky_ has quit IRC
 812016-12-13T09:32:57  *** morcos has quit IRC
 822016-12-13T09:32:58  *** sdaftuar has quit IRC
 832016-12-13T09:32:59  *** zxzzt has quit IRC
 842016-12-13T09:33:16  *** laurentmt has joined #bitcoin-core-dev
 852016-12-13T09:34:18  *** zxzzt has joined #bitcoin-core-dev
 862016-12-13T09:34:43  *** morcos has joined #bitcoin-core-dev
 872016-12-13T09:34:51  *** sdaftuar has joined #bitcoin-core-dev
 882016-12-13T09:34:51  *** sdaftuar has joined #bitcoin-core-dev
 892016-12-13T09:35:28  *** laurentmt has quit IRC
 902016-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
 912016-12-13T09:40:13  <rabidus_> :E
 922016-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
 932016-12-13T09:43:34  *** MarcoFalke has joined #bitcoin-core-dev
 942016-12-13T09:45:53  *** ryanofsky_ has joined #bitcoin-core-dev
 952016-12-13T09:50:01  <luke-jr> sigh
 962016-12-13T09:58:21  *** laurentmt has joined #bitcoin-core-dev
 972016-12-13T10:00:40  <Lauda> You should listen ti maxwell's advice regarding that one.
 982016-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
 992016-12-13T10:09:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/76fcd9d50341...e6ba5068f107
1002016-12-13T10:09:28  <bitcoin-git> bitcoin/master e49a252 Richard Kiss: Fix spelling.
1012016-12-13T10:09:29  <bitcoin-git> bitcoin/master e6ba506 MarcoFalke: Merge #9335: Fix typo in test/data/tx_valid.json...
1022016-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
1032016-12-13T10:18:07  *** laurentmt has quit IRC
1042016-12-13T10:27:19  *** AaronvanW has quit IRC
1052016-12-13T10:29:05  *** laurentmt has joined #bitcoin-core-dev
1062016-12-13T10:33:55  <MarcoFalke> I think #9302 and #9290 are reviewed to death, ready for merge
1072016-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
1082016-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
1092016-12-13T10:36:33  <MarcoFalke> > wumpus
1102016-12-13T10:36:36  <MarcoFalke> can people please notify me if there is a pull which is clearly ready for merging?
1112016-12-13T10:38:27  *** laurentmt has quit IRC
1122016-12-13T10:44:15  *** jtimon has joined #bitcoin-core-dev
1132016-12-13T10:48:37  *** MarcoFalke has left #bitcoin-core-dev
1142016-12-13T10:50:18  *** jtimon has quit IRC
1152016-12-13T11:03:49  *** AaronvanW has joined #bitcoin-core-dev
1162016-12-13T11:03:50  *** AaronvanW has quit IRC
1172016-12-13T11:03:50  *** AaronvanW has joined #bitcoin-core-dev
1182016-12-13T11:15:54  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e6ba5068f107...b6abdc77d39c
1192016-12-13T11:15:54  <bitcoin-git> bitcoin/master b3a7410 Pieter Wuille: Return txid even if ATMP fails for new transaction
1202016-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...
1212016-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
1222016-12-13T11:17:08  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b6abdc77d39c...cfd5e6b1dc32
1232016-12-13T11:17:09  <bitcoin-git> bitcoin/master 7b49f22 Pieter Wuille: Squashed 'src/secp256k1/' changes from 7a49cac..8225239...
1242016-12-13T11:17:10  <bitcoin-git> bitcoin/master 547a53d Pieter Wuille: Update libsecp256k1 to master
1252016-12-13T11:17:10  <bitcoin-git> bitcoin/master cfd5e6b Wladimir J. van der Laan: Merge #9334: Update to latest libsecp256k1...
1262016-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
1272016-12-13T11:21:39  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfd5e6b1dc32...5233aefa3f52
1282016-12-13T11:21:40  <bitcoin-git> bitcoin/master 8c1dbc5 Karl-Johan Alm: Refactor: Removed begin/end_ptr functions.
1292016-12-13T11:21:40  <bitcoin-git> bitcoin/master 5233aef Wladimir J. van der Laan: Merge #9305: Refactor: Removed begin/end_ptr functions....
1302016-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
1312016-12-13T11:22:50  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5233aefa3f52...26fe5c98ab6a
1322016-12-13T11:22:51  <bitcoin-git> bitcoin/master bae1eef Gregory Maxwell: Fix wallet/test/crypto_tests.cpp for OpenSSL 1.1 API....
1332016-12-13T11:22:51  <bitcoin-git> bitcoin/master b05b1af Gregory Maxwell: Fix qt/paymentrequestplus.cpp for OpenSSL 1.1 API....
1342016-12-13T11:22:52  <bitcoin-git> bitcoin/master 26fe5c9 Wladimir J. van der Laan: Merge #9326: Update for OpenSSL 1.1 API....
1352016-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
1362016-12-13T11:25:09  *** atroxes has quit IRC
1372016-12-13T11:33:41  *** MarcoFalke has joined #bitcoin-core-dev
1382016-12-13T11:34:30  *** atroxes has joined #bitcoin-core-dev
1392016-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
1402016-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
1412016-12-13T11:46:24  *** jtimon has joined #bitcoin-core-dev
1422016-12-13T11:50:37  *** MarcoFalke has left #bitcoin-core-dev
1432016-12-13T12:00:54  *** jtimon has quit IRC
1442016-12-13T12:07:37  *** laurentmt has joined #bitcoin-core-dev
1452016-12-13T12:08:08  *** laurentmt has quit IRC
1462016-12-13T12:24:28  *** jtimon has joined #bitcoin-core-dev
1472016-12-13T12:32:11  *** chris200_ has joined #bitcoin-core-dev
1482016-12-13T12:44:35  *** jtimon has quit IRC
1492016-12-13T12:58:05  *** jtimon has joined #bitcoin-core-dev
1502016-12-13T13:08:56  *** btcdrak has quit IRC
1512016-12-13T13:09:50  *** justanotheruser has joined #bitcoin-core-dev
1522016-12-13T13:10:50  *** jtimon has quit IRC
1532016-12-13T13:16:24  *** arubi has quit IRC
1542016-12-13T13:24:57  *** goregrind has quit IRC
1552016-12-13T13:28:14  *** goregrind has joined #bitcoin-core-dev
1562016-12-13T13:49:51  *** Atomicat has quit IRC
1572016-12-13T13:53:51  *** Atomicat has joined #bitcoin-core-dev
1582016-12-13T13:54:00  *** arubi has joined #bitcoin-core-dev
1592016-12-13T13:57:14  *** wasi has quit IRC
1602016-12-13T14:02:37  *** wasi has joined #bitcoin-core-dev
1612016-12-13T14:04:38  <jonasschnelli> luke-jr: the question is, if we really want to support commands like cmd(arg,,) resulting in `cmd arg "" ""`
1622016-12-13T14:04:47  <jonasschnelli> IMO the later is fine... but not sure about cmd(arg,,)
1632016-12-13T14:05:16  <jonasschnelli> Empty arguments in a bracket-like syntax looks strange to me.
1642016-12-13T14:05:28  *** Chris_Stewart_5 has quit IRC
1652016-12-13T14:07:02  *** protomar has joined #bitcoin-core-dev
1662016-12-13T14:07:23  <luke-jr> jonasschnelli: IMO either it should be supported, or an error ;)
1672016-12-13T14:07:58  <jonasschnelli> luke-jr: Yes. Agree. IMO it should thrown an error... I'll fix that.
1682016-12-13T14:12:58  *** laurentmt has joined #bitcoin-core-dev
1692016-12-13T14:19:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1702016-12-13T14:42:21  *** Guyver2 has joined #bitcoin-core-dev
1712016-12-13T14:44:15  *** Chris_Stewart_5 has quit IRC
1722016-12-13T14:44:27  *** Sosumi has joined #bitcoin-core-dev
1732016-12-13T14:48:56  *** To7 has joined #bitcoin-core-dev
1742016-12-13T14:50:56  *** jtimon has joined #bitcoin-core-dev
1752016-12-13T14:53:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1762016-12-13T14:56:13  <phantomcircuit> jonasschnelli, is this for nested calls?
1772016-12-13T15:23:33  *** JackH has joined #bitcoin-core-dev
1782016-12-13T15:24:33  *** Giszmo has joined #bitcoin-core-dev
1792016-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
1802016-12-13T15:59:02  *** abpa has joined #bitcoin-core-dev
1812016-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
1822016-12-13T16:30:16  <ryanofsky_> jtimon: maybe it needs an #include <stdint.h>
1832016-12-13T16:32:44  <jtimon> ryanofsky_: it has an #include <stdlib.h> but it may be just that, thanks, I'll try that
1842016-12-13T16:34:46  *** laurentmt has quit IRC
1852016-12-13T16:35:37  *** laurentmt has joined #bitcoin-core-dev
1862016-12-13T16:37:22  *** Ylbam has quit IRC
1872016-12-13T16:45:21  *** btcdrak has joined #bitcoin-core-dev
1882016-12-13T16:49:10  *** abpa has joined #bitcoin-core-dev
1892016-12-13T16:54:40  *** Ylbam has joined #bitcoin-core-dev
1902016-12-13T17:25:24  *** protomar has quit IRC
1912016-12-13T17:26:15  *** laurentmt has quit IRC
1922016-12-13T17:46:38  *** laurentmt has joined #bitcoin-core-dev
1932016-12-13T17:47:02  *** laurentmt has quit IRC
1942016-12-13T17:48:05  *** BashCo has quit IRC
1952016-12-13T18:07:40  *** BashCo has joined #bitcoin-core-dev
1962016-12-13T18:08:35  *** atroxes has quit IRC
1972016-12-13T18:09:50  *** atroxes has joined #bitcoin-core-dev
1982016-12-13T18:13:38  *** paveljanik has joined #bitcoin-core-dev
1992016-12-13T18:25:38  *** aalex_ has quit IRC
2002016-12-13T18:53:11  <gmaxwell> wumpus: thanks for the merges!
2012016-12-13T19:03:23  *** aalex has joined #bitcoin-core-dev
2022016-12-13T19:17:48  *** bsm117532 has quit IRC
2032016-12-13T19:24:01  *** timothy has quit IRC
2042016-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.
2052016-12-13T19:26:55  <sipa> morcos: i'm working on a per-txout chainstate... this simplifies so much
2062016-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
2072016-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
2082016-12-13T19:27:55  <sipa> morcos: doing it a very naive way, hoping that leveldb properly deduplicates the txids
2092016-12-13T19:28:15  <morcos> won't take long to figure that out.. ha
2102016-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
2112016-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)
2122016-12-13T19:30:02  *** bsm117532 has joined #bitcoin-core-dev
2132016-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
2142016-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
2152016-12-13T19:30:35  <gmaxwell> (it's not really needed here, loast a word)
2162016-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.
2172016-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...
2182016-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!)
2192016-12-13T19:41:15  *** jtimon has quit IRC
2202016-12-13T19:41:31  *** jtimon has joined #bitcoin-core-dev
2212016-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?
2222016-12-13T19:45:53  <sipa> morcos: i don't know about outputs... but for change, we shouldn't make anything between changeOutputWeight * effectiveRelayFee
2232016-12-13T19:45:59  <sipa> s/between/below/
2242016-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
2252016-12-13T19:48:12  <morcos> so minChange takes care of making a best-efforts basis to not produce anything uneconomical
2262016-12-13T19:48:47  <morcos> but it would makes sense to have some dustCreationTheshold = SafetyMargin * dustThreshold
2272016-12-13T19:48:53  <morcos> that applies to everything...
2282016-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
2292016-12-13T19:54:42  *** shesek has quit IRC
2302016-12-13T19:59:25  *** timothy has joined #bitcoin-core-dev
2312016-12-13T20:05:55  *** jtimon has quit IRC
2322016-12-13T20:06:03  *** jtimon has joined #bitcoin-core-dev
2332016-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?  :)
2342016-12-13T20:21:14  *** Chris_Stewart_5 has quit IRC
2352016-12-13T20:31:20  <jtimon> btw ryanofsky_ thanks was that
2362016-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 ?
2372016-12-13T20:36:34  <morcos> jtimon: ha.  neither!  thats why i was hoping to avoid a third.
2382016-12-13T20:36:55  <jtimon> oh, mhmm, I lack the context on why you need 2 already
2392016-12-13T20:37:01  <morcos> will explain in the PR
2402016-12-13T20:37:07  <gmaxwell> morcos: be sure to include private keys.
2412016-12-13T20:37:08  <jtimon> sure, no hurry
2422016-12-13T20:37:31  *** jtimon has quit IRC
2432016-12-13T20:37:40  *** jtimon has joined #bitcoin-core-dev
2442016-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)
2452016-12-13T20:38:07  <gmaxwell> I hope there is no reason to make the network more restrictive of dust in the future.
2462016-12-13T20:40:42  <paveljanik> gmaxwell, ;-) I expect it will be rbtced in 5, 4, 3, ... ;-)
2472016-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
2482016-12-13T20:45:38  *** Sosumi has quit IRC
2492016-12-13T20:55:38  *** timothy has quit IRC
2502016-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.
2512016-12-13T21:02:52  <jtimon> mhmm, I hadn't though about that, maybe a reason to modify #9279 ...
2522016-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
2532016-12-13T21:03:24  <jtimon> I was hoping to encapsulate the variable behind a policy class at some point...
2542016-12-13T21:06:16  <jtimon> I guess another option would be to have 2 functions/methods that call the same one internally
2552016-12-13T21:10:50  *** timothy has joined #bitcoin-core-dev
2562016-12-13T21:12:47  <morcos> jtimon: yeah i think that would be fine and an easy change:  GDT(txout) { return GDT(txout, ::minRelayTxFee); }
2572016-12-13T21:13:28  <jtimon> I mean, if we plan to encapsulate the value later that's 2 rounds of disruption instead of one
2582016-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
2592016-12-13T21:14:17  <jtimon> I mean, didn't mean to stop you
2602016-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
2612016-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
2622016-12-13T21:17:14  <jtimon> or that
2632016-12-13T21:17:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2642016-12-13T21:17:32  <jtimon> optionally taking another one if we maybe want to have more than 2 rates
2652016-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.
2662016-12-13T21:18:32  <gmaxwell> Otherwise it is impossible to change the limit without causing the creation of limit violating transactions.
2672016-12-13T21:19:02  <jtimon> I see
2682016-12-13T21:38:03  *** bsm117532 has quit IRC
2692016-12-13T21:38:29  *** bsm117532 has joined #bitcoin-core-dev
2702016-12-13T21:42:47  *** bsm117532 has quit IRC
2712016-12-13T21:43:15  *** bsm117532 has joined #bitcoin-core-dev
2722016-12-13T21:48:33  *** Guyver2 has quit IRC
2732016-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
2742016-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.
2752016-12-13T21:51:17  <morcos> but i admit i don't know how its used....
2762016-12-13T22:29:04  *** brg444 has joined #bitcoin-core-dev
2772016-12-13T22:47:21  *** arubi has quit IRC
2782016-12-13T23:30:43  *** JackH has quit IRC