12016-03-16T00:04:38  *** molz has joined #bitcoin-core-dev
  22016-03-16T00:07:46  *** moli has quit IRC
  32016-03-16T00:10:50  *** mrkent has joined #bitcoin-core-dev
  42016-03-16T00:29:12  *** Don_John has joined #bitcoin-core-dev
  52016-03-16T00:33:56  *** Don_John_ has joined #bitcoin-core-dev
  62016-03-16T00:35:53  *** Don_John_ has quit IRC
  72016-03-16T00:36:03  *** Don_John has quit IRC
  82016-03-16T00:48:45  *** dogu has joined #bitcoin-core-dev
  92016-03-16T00:56:01  *** dogu has quit IRC
 102016-03-16T00:56:05  *** BashCo_ has joined #bitcoin-core-dev
 112016-03-16T00:58:25  *** BashCo has quit IRC
 122016-03-16T01:17:03  *** fredrin has quit IRC
 132016-03-16T01:20:05  *** fredrin has joined #bitcoin-core-dev
 142016-03-16T01:24:51  *** fredrin has quit IRC
 152016-03-16T01:32:58  *** fredrin has joined #bitcoin-core-dev
 162016-03-16T01:40:59  *** Ylbam has quit IRC
 172016-03-16T01:41:54  *** jtimon has quit IRC
 182016-03-16T01:45:16  *** fengling has joined #bitcoin-core-dev
 192016-03-16T01:53:27  *** ghtdak has quit IRC
 202016-03-16T02:22:45  *** justanot1eruser has joined #bitcoin-core-dev
 212016-03-16T02:23:02  *** justanotheruser has quit IRC
 222016-03-16T02:36:25  *** ghtdak has joined #bitcoin-core-dev
 232016-03-16T02:40:54  <GitHub1> [bitcoin] EthanHeilman opened pull request #7696: Fix de-serialization bug where AddrMan is left corrupted (master...bug) https://github.com/bitcoin/bitcoin/pull/7696
 242016-03-16T02:42:53  *** achow101 has quit IRC
 252016-03-16T02:45:56  *** fengling has quit IRC
 262016-03-16T02:46:52  *** fengling has joined #bitcoin-core-dev
 272016-03-16T02:49:53  *** achow101 has joined #bitcoin-core-dev
 282016-03-16T02:51:03  *** Chris_Stewart_5 has quit IRC
 292016-03-16T02:51:16  <achow101> will there be a full write up of the details of the segwit changes so that wallet developers can work on its implementation?
 302016-03-16T02:51:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 312016-03-16T02:51:33  <achow101> preferably before the release of the client with segwit?
 322016-03-16T03:08:41  *** mrkent has quit IRC
 332016-03-16T03:09:59  *** Bob777 has joined #bitcoin-core-dev
 342016-03-16T03:11:33  *** AaronvanW has quit IRC
 352016-03-16T03:23:55  *** AaronvanW has joined #bitcoin-core-dev
 362016-03-16T03:27:51  *** wallet42 has joined #bitcoin-core-dev
 372016-03-16T03:41:51  *** aknix has quit IRC
 382016-03-16T03:49:39  *** evoskuil has quit IRC
 392016-03-16T03:50:01  *** evoskuil has joined #bitcoin-core-dev
 402016-03-16T03:53:30  *** achow101 has quit IRC
 412016-03-16T03:59:02  *** Alopex has quit IRC
 422016-03-16T04:00:07  *** Alopex has joined #bitcoin-core-dev
 432016-03-16T04:03:43  *** pavel_ has joined #bitcoin-core-dev
 442016-03-16T04:06:15  *** paveljanik has quit IRC
 452016-03-16T04:06:21  *** Giszmo has quit IRC
 462016-03-16T04:14:14  *** Bob777 has quit IRC
 472016-03-16T04:35:14  *** shesek has quit IRC
 482016-03-16T04:36:58  *** shesek has joined #bitcoin-core-dev
 492016-03-16T04:42:01  *** Alopex has quit IRC
 502016-03-16T04:43:06  *** Alopex has joined #bitcoin-core-dev
 512016-03-16T04:52:25  *** Thireus has quit IRC
 522016-03-16T05:06:01  *** Alopex has quit IRC
 532016-03-16T05:07:06  *** Alopex has joined #bitcoin-core-dev
 542016-03-16T05:36:01  *** Alopex has quit IRC
 552016-03-16T05:37:07  *** Alopex has joined #bitcoin-core-dev
 562016-03-16T05:38:43  *** zooko has joined #bitcoin-core-dev
 572016-03-16T06:01:18  *** pavel_ has quit IRC
 582016-03-16T06:01:27  *** paveljanik has joined #bitcoin-core-dev
 592016-03-16T06:01:27  *** paveljanik has joined #bitcoin-core-dev
 602016-03-16T06:05:52  *** Chris_Stewart_5 has quit IRC
 612016-03-16T06:10:33  *** zooko has quit IRC
 622016-03-16T06:12:02  *** Alopex has quit IRC
 632016-03-16T06:12:25  *** Thireus has joined #bitcoin-core-dev
 642016-03-16T06:13:07  *** Alopex has joined #bitcoin-core-dev
 652016-03-16T06:27:09  *** BashCo has joined #bitcoin-core-dev
 662016-03-16T06:29:23  *** BashCo_ has quit IRC
 672016-03-16T07:40:27  *** gribble has quit IRC
 682016-03-16T07:44:00  *** Ylbam has joined #bitcoin-core-dev
 692016-03-16T07:47:10  *** PRab has quit IRC
 702016-03-16T07:50:23  *** gribble has joined #bitcoin-core-dev
 712016-03-16T07:50:41  *** Thireus has quit IRC
 722016-03-16T08:00:36  *** JackH has joined #bitcoin-core-dev
 732016-03-16T08:09:32  *** BashCo has quit IRC
 742016-03-16T08:10:07  *** BashCo has joined #bitcoin-core-dev
 752016-03-16T08:11:52  *** Thireus has joined #bitcoin-core-dev
 762016-03-16T08:14:52  *** BashCo has quit IRC
 772016-03-16T08:16:47  *** slackircbridge has quit IRC
 782016-03-16T08:17:21  *** slackircbridge has joined #bitcoin-core-dev
 792016-03-16T08:21:22  *** cjcj has quit IRC
 802016-03-16T08:22:19  *** Guyver2 has joined #bitcoin-core-dev
 812016-03-16T08:27:27  *** AaronvanW has quit IRC
 822016-03-16T08:30:19  *** BashCo has joined #bitcoin-core-dev
 832016-03-16T08:36:05  *** cjcj has joined #bitcoin-core-dev
 842016-03-16T08:36:09  *** Tasoshi has quit IRC
 852016-03-16T08:40:15  *** AaronvanW has joined #bitcoin-core-dev
 862016-03-16T09:31:46  *** cjcj has quit IRC
 872016-03-16T10:02:02  *** randy-waterhouse has quit IRC
 882016-03-16T10:21:45  *** laurentmt has joined #bitcoin-core-dev
 892016-03-16T10:23:37  *** laurentmt has quit IRC
 902016-03-16T10:39:23  *** AaronvanW has quit IRC
 912016-03-16T10:40:56  *** Guyver2 has quit IRC
 922016-03-16T10:48:46  *** AaronvanW has joined #bitcoin-core-dev
 932016-03-16T10:48:47  *** AaronvanW has quit IRC
 942016-03-16T10:48:47  *** AaronvanW has joined #bitcoin-core-dev
 952016-03-16T11:26:47  *** Guyver2 has joined #bitcoin-core-dev
 962016-03-16T11:28:49  *** jtimon has joined #bitcoin-core-dev
 972016-03-16T11:38:28  *** murch has joined #bitcoin-core-dev
 982016-03-16T12:51:48  *** hsmiths2 has quit IRC
 992016-03-16T12:52:17  *** hsmiths has joined #bitcoin-core-dev
1002016-03-16T13:15:56  *** B4ckJ4ck007 has joined #bitcoin-core-dev
1012016-03-16T13:22:26  *** B4ckJ4ck007 has left #bitcoin-core-dev
1022016-03-16T13:23:31  *** B4ckJ4ck007 has joined #bitcoin-core-dev
1032016-03-16T13:23:43  *** B4ckJ4ck007 has left #bitcoin-core-dev
1042016-03-16T13:24:29  *** B4ckJ4ck007 has joined #bitcoin-core-dev
1052016-03-16T13:26:14  *** B4ckJ4ck007 has quit IRC
1062016-03-16T13:26:37  *** B4ckJ4ck007 has joined #bitcoin-core-dev
1072016-03-16T13:44:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1082016-03-16T13:56:23  *** laurentmt has joined #bitcoin-core-dev
1092016-03-16T13:56:57  *** laurentmt has quit IRC
1102016-03-16T14:27:26  <GitHub25> [bitcoin] sdaftuar opened pull request #7697: Tests: make prioritise_transaction.py more robust (master...fix-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/7697
1112016-03-16T14:28:04  *** zooko has joined #bitcoin-core-dev
1122016-03-16T14:43:00  *** Guyver2_ has joined #bitcoin-core-dev
1132016-03-16T14:45:32  *** Guyver2 has quit IRC
1142016-03-16T14:45:34  *** Guyver2_ is now known as Guyver2
1152016-03-16T14:53:42  *** xiangfu has quit IRC
1162016-03-16T14:59:26  *** xiangfu has joined #bitcoin-core-dev
1172016-03-16T15:06:09  <Chris_Stewart_5> Hi guys, I know this isn't the correct channel, but I figured some one in this channel might be able to answer my question - i've already tried #bitcoin-dev
1182016-03-16T15:06:28  <Chris_Stewart_5> I'm looking at this test case from script_valid.json that is suppose to pass in core
1192016-03-16T15:06:30  <Chris_Stewart_5> ["0x4a 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "0 CHECKSIG NOT", "", "Overly long signature is correctly encoded"]
1202016-03-16T15:06:53  <Chris_Stewart_5> however the signature 0x00...000 isn't a valid DER signature - so why is this test case suppose to pass?
1212016-03-16T15:08:13  <Chris_Stewart_5> interestingly enough, that same test case is also included in script_invalid.json as well
1222016-03-16T15:09:15  <sipa> that test doesn't specify DERSIG as validation flag
1232016-03-16T15:09:43  <Chris_Stewart_5> sipa: So this is a historical test case pre BIP-66?
1242016-03-16T15:09:44  <sipa> or STRICTENC or LOW_S
1252016-03-16T15:09:45  <wumpus> intersting
1262016-03-16T15:09:56  <wumpus> I think he got confused by ["Increase test coverage for DERSIG"]
1272016-03-16T15:10:02  <sipa> Chris_Stewart_5: in a way...
1282016-03-16T15:10:11  <wumpus> after which none of the test cases supply the DERSIG flag :-)
1292016-03-16T15:10:12  <sipa> Chris_Stewart_5: the consensus rules are still well defined for historical cases
1302016-03-16T15:10:38  <wumpus> (some do, later on, but not under that heading)
1312016-03-16T15:10:54  <sipa> wumpus: compare that section to the corresponding section in script_invalid; the tests verify the difference in validity by setting/unsetting that flag
1322016-03-16T15:11:16  <wumpus> sipa: I believe you that it's correct, it just looks funny
1332016-03-16T15:11:24  <sipa> that's the typical way these tests are constructed: find the minimal set of flag difference that cause validity to change, and put one side in valid and one side in invalid
1342016-03-16T15:11:32  <sipa> probably deserves a comment!
1352016-03-16T15:11:37  <wumpus> right
1362016-03-16T15:15:33  <Chris_Stewart_5> thanks guys, If I am understanding this correctly, we would have to deploy another soft fork to make this signature valid again for bitcoin core nodes? Are the flags in the test case used ONLY for these test cases or is there similar flags used in bitcoin core's interpreter?
1372016-03-16T15:15:33  *** davec has quit IRC
1382016-03-16T15:15:59  *** davec has joined #bitcoin-core-dev
1392016-03-16T15:16:11  <sipa> Chris_Stewart_5: it would require a hard fork to make them valid again
1402016-03-16T15:16:45  <sipa> Chris_Stewart_5: that specific test tests the script evaluation engine, which does not know anything about consensus rules or transactions or blocks even
1412016-03-16T15:16:57  <sipa> so it specifies the flags for evaluation with each test
1422016-03-16T15:17:24  <sipa> other, higher-level tests exist that actually check whether the consensus logic evaluates things correctly
1432016-03-16T15:17:42  <Chris_Stewart_5> sipa: Is that right though? Obviously OP_CHECKSIG has to know about txs because they are needed for hashing to compare against the sigs?
1442016-03-16T15:17:58  <Chris_Stewart_5> or OP_CHECKMULTISIG
1452016-03-16T15:18:28  <sipa> Chris_Stewart_5: nope, it's abstracted through BaseSignatureChecker
1462016-03-16T15:18:53  <sipa> and then there is an implementation for that for CTransaction, but it can be used to verify signatures on other things than transactions
1472016-03-16T15:19:06  <Chris_Stewart_5> interesting, I"ve been trying to model something similar in Scala, i'll have to take a closer look
1482016-03-16T15:19:37  <Chris_Stewart_5> I think i was just running into this problem of who knows about what (does the interpreter needs to know about txs etc..)
1492016-03-16T15:20:26  <sipa> there were some plans of introducing a new message signing feature based on this, so that you can do multisigs on a message, for example
1502016-03-16T15:23:12  *** Giszmo has joined #bitcoin-core-dev
1512016-03-16T15:27:57  *** MarcoFalke has joined #bitcoin-core-dev
1522016-03-16T15:31:21  *** zooko has quit IRC
1532016-03-16T16:00:39  *** MarcoFalke has quit IRC
1542016-03-16T16:14:01  *** B4ckJ4ck007 has quit IRC
1552016-03-16T16:19:20  *** jtimon has quit IRC
1562016-03-16T16:23:27  *** BashCo has quit IRC
1572016-03-16T16:24:04  *** BashCo has joined #bitcoin-core-dev
1582016-03-16T16:25:59  *** jtimon has joined #bitcoin-core-dev
1592016-03-16T16:29:06  *** BashCo has quit IRC
1602016-03-16T16:32:29  <GitHub191> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/a6a860796a44...3d0dfdbf9f26
1612016-03-16T16:32:30  <GitHub191> bitcoin/master fa3a81a MarcoFalke: [tests] Extend util_ParseMoney test case
1622016-03-16T16:32:30  <GitHub191> bitcoin/master fad7dc8 MarcoFalke: [qa] wallet: speed up tests
1632016-03-16T16:32:31  <GitHub191> bitcoin/master fa8cd46 MarcoFalke: [qa] Move create_tx() to util.py
1642016-03-16T16:32:39  <GitHub140> [bitcoin] laanwj closed pull request #7684: [qa] Extend tests (master...Mf1603-qaCleanup1) https://github.com/bitcoin/bitcoin/pull/7684
1652016-03-16T16:48:23  *** BashCo has joined #bitcoin-core-dev
1662016-03-16T17:07:14  *** laurentmt has joined #bitcoin-core-dev
1672016-03-16T17:13:14  *** Thireus has quit IRC
1682016-03-16T17:20:25  *** Chris_Stewart_5 has quit IRC
1692016-03-16T17:22:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1702016-03-16T17:34:43  *** Thireus has joined #bitcoin-core-dev
1712016-03-16T17:38:45  *** mrkent has joined #bitcoin-core-dev
1722016-03-16T17:46:08  <btcdrak> has anyone complained to Github about the sort order of commits on PRs?
1732016-03-16T17:47:36  <sipa> btcdrak: they're sorted by date
1742016-03-16T17:47:39  <sipa> https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/
1752016-03-16T17:59:13  *** MarcoFalke has joined #bitcoin-core-dev
1762016-03-16T18:02:30  <MarcoFalke> wumpus around?
1772016-03-16T18:06:45  *** molz has quit IRC
1782016-03-16T18:07:07  *** molz has joined #bitcoin-core-dev
1792016-03-16T18:13:55  *** wallet421 has joined #bitcoin-core-dev
1802016-03-16T18:14:30  <btcdrak> hunt the wumpus https://www.youtube.com/watch?v=xGVOw8gXl6Y
1812016-03-16T18:16:03  *** wallet42 has quit IRC
1822016-03-16T18:24:12  <paveljanik> btcdrak, red ferrari started and wnt away. Ah, this was ad ;-))
1832016-03-16T18:55:40  *** MarcoFalke has quit IRC
1842016-03-16T18:56:28  *** murch has left #bitcoin-core-dev
1852016-03-16T19:05:08  <GitHub116> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d0dfdbf9f26...622fe6c32f41
1862016-03-16T19:05:08  <GitHub116> bitcoin/master ec14339 Suhas Daftuar: Tests: make prioritise_transaction.py more robust
1872016-03-16T19:05:09  <GitHub116> bitcoin/master 622fe6c Wladimir J. van der Laan: Merge #7697: Tests: make prioritise_transaction.py more robust...
1882016-03-16T19:05:17  <GitHub103> [bitcoin] laanwj closed pull request #7697: Tests: make prioritise_transaction.py more robust (master...fix-prioritise-transaction) https://github.com/bitcoin/bitcoin/pull/7697
1892016-03-16T19:06:30  <CodeShark> btcdrak: the original text version in BASIC: https://youtu.be/9BsliGry-OA
1902016-03-16T19:12:24  *** MarcoFalke has joined #bitcoin-core-dev
1912016-03-16T19:21:05  <wumpus> MarcoFalke: yes (but not for long)
1922016-03-16T19:21:15  <MarcoFalke> wumpus, I was wondering what you think about the patches toGetFee()
1932016-03-16T19:21:38  <wumpus> haven't really looked at that yet
1942016-03-16T19:21:52  <wumpus> most of the fee logic honestly confuses me
1952016-03-16T19:22:09  <MarcoFalke> Jup the current logic even has a bug
1962016-03-16T19:22:27  <MarcoFalke> GetFee() is not monotonic in the size
1972016-03-16T19:22:37  <MarcoFalke> Would be trivial to fix
1982016-03-16T19:22:43  <wumpus> I''m not surprised - I think we should first document what we want, then try to achieve that in the code
1992016-03-16T19:23:15  <MarcoFalke> So I'd prefer to keep the integer logic (truncate)
2002016-03-16T19:23:18  <wumpus> currently it's impossible to say if behavior is desirable or not
2012016-03-16T19:23:27  <MarcoFalke> morcos and jtimon suggested to make it always ceil
2022016-03-16T19:23:46  <wumpus> well at the very least please don't use doubles for monetary values
2032016-03-16T19:24:09  <wumpus> I don't have an opinion on ceil versus floor, that'd at most make a satoshi difference I guess?
2042016-03-16T19:24:19  <MarcoFalke> sure
2052016-03-16T19:24:40  <MarcoFalke> but ceil at least needs a double for the time of calculation
2062016-03-16T19:24:41  <wumpus> so go with whatever results in the simplest code
2072016-03-16T19:25:14  <wumpus> you don't ever *need* doubles
2082016-03-16T19:25:20  <jtimon> I think avoiding the optional param as suggested by morcos certainly simplifies things
2092016-03-16T19:25:24  <morcos> MarcoFalke: Why do we NEED to change something?
2102016-03-16T19:25:46  <MarcoFalke> we need at least make getFee() monotonic
2112016-03-16T19:25:56  <morcos> ehh
2122016-03-16T19:25:59  <wumpus> morcos: yes, that's what first needs to be decided
2132016-03-16T19:26:17  *** mol11111 has joined #bitcoin-core-dev
2142016-03-16T19:26:38  <morcos> MarcoFalke: btw, i'm totally fine with just truncating all the time too, but you were against truncating to 0
2152016-03-16T19:26:45  <morcos> what i dont' want is more complexity
2162016-03-16T19:26:49  <wumpus> if we don't need to change something that'd be preferable, so we can catch up to document the current behavior
2172016-03-16T19:26:51  <jtimon> to be honest I'm still not sure what this is all about, even after reading the 2 PRs
2182016-03-16T19:27:18  <MarcoFalke> ok, I will submit a minimal code change patch this evening
2192016-03-16T19:27:22  <wumpus> if we could describe things in human understandable terms that'd help devs too
2202016-03-16T19:27:29  *** mol11111 is now known as moli
2212016-03-16T19:27:37  <wumpus> as said, I've been maintaining this code for years and the fee code freaks me out
2222016-03-16T19:28:16  <jtimon> what about always truncating but instead of ever returning 0, just return 1 satoshi?
2232016-03-16T19:28:19  <wumpus> at least if there's a large change in behavior we should document it in the release notes next time :)
2242016-03-16T19:28:33  *** molz has quit IRC
2252016-03-16T19:28:34  <MarcoFalke> jtimon, that's what I am going to do
2262016-03-16T19:28:39  <morcos> wumpus: i know you say you don't like doubles, but the mining code and the fee estimation code which are the things that use fee rates, both use them as doubles
2272016-03-16T19:28:41  <MarcoFalke> will result in least code and diff
2282016-03-16T19:28:49  <wumpus> morcos: that's awful
2292016-03-16T19:29:33  <jtimon> MarcoFalke: oh, nice, what's the problem with returning 0 in the first place anywa?
2302016-03-16T19:30:07  <MarcoFalke> we still use it in the wallet to "detect" what the user selected
2312016-03-16T19:30:22  <MarcoFalke> paytxfee or confirmtarget
2322016-03-16T19:30:33  <jtimon> and now the user can't select 0 fee?
2332016-03-16T19:30:35  <wumpus> doubles don't have exactly the same behavior on all platforms, which make it dangerous to use them for monetary values, we've had some strange reports of behavior while using doubles in the RPC layer
2342016-03-16T19:30:51  <morcos> wumpus: i mean i said that kind of for effect, its not really awful the way its used, and i'm fine keeping CFeeRate to not use doubles, but its worth keeping in mind that we're losing precision by converting it to some weird integer
2352016-03-16T19:30:53  <wumpus> now we've got rid of them there
2362016-03-16T19:31:19  <jtimon> just use int satoshis everywhere
2372016-03-16T19:31:34  <morcos> but its satoshis per size
2382016-03-16T19:31:39  <wumpus> morcos: if you lose precision with integer arithmetic at least in a predictable, deterministic, platform independent way :)
2392016-03-16T19:32:00  <wumpus> but it should be possible not to lost precision, if you use the right amount of fixed point precision
2402016-03-16T19:32:15  <MarcoFalke> Using doubles for bitcoin should be fine right now, as a double can hold all possible values with exact precision IIRC.
2412016-03-16T19:32:25  <MarcoFalke> But we should avoid it for consistency
2422016-03-16T19:32:28  <morcos> wumpus: well for instance in the mining (actually mempool sorting) code its calculation using integers but they are converted to doubles to ignore overflow risk
2432016-03-16T19:32:29  <wumpus> 'should be fine' but please don't
2442016-03-16T19:33:02  <wumpus> they said the same about using doubles in RPC, and there's been some strange rounding errors
2452016-03-16T19:33:03  <MarcoFalke> Jup, people will look at the code and think this is best practise
2462016-03-16T19:33:15  <morcos> anywya, we're not talking about using doubles for an amount, i think everyone would 100% agree, that no bitcoin amount should ever be represented as a double  (bitcoins.satoshis)
2472016-03-16T19:33:25  <jtimon> I guess CFeeRate's ```/ 1000``` simplifies some parts of the code, but I still dislike the whole concept (and much more that this code is included in current libconsensus)
2482016-03-16T19:33:38  <sdaftuar> CFeeRate is in libconsensus?
2492016-03-16T19:34:24  <MarcoFalke> jtimon, you mean IsDust()?
2502016-03-16T19:34:43  <wumpus> I'd really prefer to stick to the point that doubles and floating point arithmetic dosn't belong in financial software
2512016-03-16T19:34:57  <jtimon> yes, from the beginning, I've been trying to move it out ever since without luck, but if someone else wants to rewrite any of my attempts I'm more than happy to review
2522016-03-16T19:36:22  <wumpus> I'm sure it is not used by any actual consensus code and could be moved out of libconsensus in due time
2532016-03-16T19:36:58  <jtimon> MarcoFalke: IsDust and dustThereshold too, that's the reason why it cannot simply be moved out (amount.h would remain without .cpp or all its code can be simply moved back to primitives/transaction.h but then policy/feerate.o needs to depend on the whole consensus/transaction.o instead of only amount.h)
2542016-03-16T19:37:21  <jtimon> wumpus: it can be moved out of consensus at any time
2552016-03-16T19:37:27  <wumpus> jtimon: right
2562016-03-16T19:38:09  <jtimon> for the first version that was small enough to just leave it for later, but we're leaving it for later ever since
2572016-03-16T19:38:38  <jtimon> s/we're/we've been
2582016-03-16T19:39:56  <wumpus> anyhow, re; fee, I think we should first have a plan what we really want, what is the current behavior, what is the intended behavior, before we just start changing code again and surpise users
2592016-03-16T19:40:08  <morcos> wumpus: to summarize what i think the CFeeRate current problem is , we definited it as satoshis/kB which doesn't have enough precision as an integer to not be a bit annoying (both close to 0 and too many ties in mempool sorting).  not super annoying, but it was a bit of a silly definition
2602016-03-16T19:41:46  <wumpus> morcos: yes I fully agree the current implementation of CFeeRate is somewhat silly
2612016-03-16T19:42:06  <jtimon> I guess the advantage of using KB instead of just bytes it's to contemplate fees below 1 satoshi per byte, which I have no idea if currently makes sense
2622016-03-16T19:42:44  <morcos> yes, jtimon from a human communication format satoshis/B makes more sense, but for precision, you really want satoshis/MB
2632016-03-16T19:43:02  <jtimon> so any more generic replacement to contemplate lower fees would do it, I think
2642016-03-16T19:43:14  <wumpus> well the internal representation doesn't have to depend on human communication format at all
2652016-03-16T19:43:21  <wumpus> it cen be presented in whatever way makes sense to the user
2662016-03-16T19:43:37  <morcos> well CFeeRate is almost only for human communication format
2672016-03-16T19:43:52  <morcos> most things internally store fees and size separately
2682016-03-16T19:43:57  <morcos> and do the calculations as necessary
2692016-03-16T19:44:08  <jtimon> alright, so we need more precission and 1000 happens to be too small of a divider some times. what about an optional bytes param that defaults to 1000 ?
2702016-03-16T19:44:12  <wumpus> human communication depends on the formatting function only
2712016-03-16T19:44:13  <morcos> or like the estimation code use doubles b/c they're doing all kinds of crazy exponential decays and stuff
2722016-03-16T19:44:58  <wumpus> jtimon: you mean make it a rational?
2732016-03-16T19:45:26  <jtimon> I think that would open the door to some more simplifications for cases where you multiply by 1000 and divide by tx_size right after dividing by 1000 in the exnapsulated stuff
2742016-03-16T19:45:30  <wumpus> well it's better than a double :)
2752016-03-16T19:46:26  <jtimon> no, wait I've probably said something stupid, let me think more while looking at code
2762016-03-16T19:46:59  <morcos> well, its not causing me any issues right now, so i prefer no changes to anything that isn't an obvious improvement
2772016-03-16T19:47:08  <wumpus> morcos: absolutely
2782016-03-16T19:47:24  <wumpus> that's my whole point about the fee logic, really
2792016-03-16T19:49:31  <wumpus> first consider what is the current case, and what we want, so we can define what is an improvement
2802016-03-16T19:50:36  <morcos> the problem MarcoFalke is trying to solve (or at least part of it) isnt' a problem with CFeeRate, but with a shortcut in how we detect whether the user has selected to paytxfee
2812016-03-16T19:51:14  <morcos> it would make more sense to find out whether the paytxfee option has been set, and not whether it = 0 or rounds to 0 in terms of decidign whether to use dynamic fee estimation
2822016-03-16T19:51:26  <morcos> thats would be the ideal fix, but that would be a change of behavior potentially for users
2832016-03-16T19:51:51  <wumpus> I've been kind of caught by surprise by the fPayAtLeastCustomFee stuff, for example
2842016-03-16T19:52:51  <morcos> right now you can't select paytxfee=0  , that just seems silly, you should be able to set whatever fee you want, and if you select a fee, you don't use fee estimation, even if your fee rounds/truncates/ceilings/doubles/or trampolines to 0
2852016-03-16T19:53:01  <wumpus> https://github.com/bitcoin/bitcoin/issues/7633#issuecomment-195254622   I'd really like to avoid this another time
2862016-03-16T19:53:45  <wumpus> "how we detect whether the user has selected to paytxfee" let's just follow the straightforward route and add a boolean then
2872016-03-16T19:53:58  <wumpus> second guessing the user sucks
2882016-03-16T19:55:24  <wumpus> sure - we can change the API, it's not prohobitive to change the behavior at all, just be sure to mention it in the release notes :)
2892016-03-16T19:56:20  <MarcoFalke> I should have done the release notes as part of the pull probably. Still, no one yelled at me all the time before 0.12 was released. Even though my original pull was from September.
2902016-03-16T19:56:30  <wumpus> and we shoudl really write a document what the various fee options do, how they interact, what is the result in practice
2912016-03-16T19:56:45  <wumpus> it's soo flexible that no one understands really :)
2922016-03-16T19:57:41  <wumpus> I'm not blaming you at all MarcoFalke, it's a strange coincidence of circumstances
2932016-03-16T19:57:44  <MarcoFalke> you suggested to add a .md in /doc? I'd rather not do this taking considering that you need a pull every time someone wants to edit the file.
2942016-03-16T19:57:55  <wumpus> I don't care where
2952016-03-16T19:58:21  <MarcoFalke> bitcoin wiki it?
2962016-03-16T19:58:26  <MarcoFalke> or the website?
2972016-03-16T19:58:37  <MarcoFalke> Do we have infrastructure on the website for documentation yet?
2982016-03-16T19:58:40  <wumpus> fine with me, I usually put stuff in gists but that's hard to find I suppose
2992016-03-16T19:58:48  <wumpus> well on the website you need a pull for every change too
3002016-03-16T19:59:34  <MarcoFalke> but bitcoin/bitcoin commits are read by somewhat more people than the website commits
3012016-03-16T19:59:42  <wumpus> wikis have the problem that there's no change control at all
3022016-03-16T19:59:49  <wumpus> that's why we moved the BIPs to git
3032016-03-16T20:00:36  <wumpus> anyhow this isn't imporant, if you write it you get to decide where to put it
3042016-03-16T20:02:36  <wumpus> bitcoin.org has extensive infrastructure for documentation, don't think bitcoincore.org has
3052016-03-16T20:03:31  <morcos> what do you think about changing the names of those options.  i mean i know thats annoying.  but calling them paytxfeerate instead of paytxfee would make a whole lot more sense
3062016-03-16T20:04:16  <morcos> i don't know if its easy enough to do that in a compatible way, i guess we'd have to consolidate where the arguments are looked at
3072016-03-16T20:04:39  <wumpus> why not just document them better instead of change the name :)
3082016-03-16T20:05:14  <morcos> yeah i guess there are a ton of them
3092016-03-16T20:05:52  <wumpus> I mean for a clean slate, in retrospect, it would be awesome to name them differently, and as in any program there are plenty of awkwarly named options... but yes there's a strong backward compatibiltiy versus sensibility for new users compromise
3102016-03-16T20:06:06  <GitHub37> [bitcoin] MarcoFalke closed pull request #7660: [amount] Extend GetFee() by optional flag ceil (master...Mf1603-amountCeil) https://github.com/bitcoin/bitcoin/pull/7660
3112016-03-16T20:06:16  <GitHub110> [bitcoin] MarcoFalke closed pull request #7661:  [wallet] Round up to the next satoshi on odd fee rates  (master...Mf1603-walletCeil) https://github.com/bitcoin/bitcoin/pull/7661
3122016-03-16T20:07:11  <wumpus> and it's possible to argue that the name of the options themselves is just arbitrary, it's just a name, as long as it's not completely deceptive what matters is how they're documented
3132016-03-16T20:07:46  <MarcoFalke> Would be great to have different option names map to the same option to be used as synonyms... Which brings us back to the rewrite of the arg parser...
3142016-03-16T20:08:14  <wumpus> well we do have some options that just throw an error if you provide them, and mention that they're either removed or have a new name
3152016-03-16T20:08:42  <wumpus> but there's got to be a good motivation to do that, it shouldn't look like just sending the user on a wild goose chase :)
3162016-03-16T20:08:48  <MarcoFalke> paytxfee is still widely used. Would be nasty to require everyone change their conf
3172016-03-16T20:09:09  <morcos> wumpus: btw, i made your change to 7187, should i go ahead and squash all the commits, not sure if you thought review was done
3182016-03-16T20:09:34  <MarcoFalke> wumpus any update on "wumpus: Would it be possible for us to arrange open source licenses of the Jetbrains IDEs for C++ and Python? They offer free licenses to projects like this"
3192016-03-16T20:09:50  <wumpus> e.g. there's an issue to rename '-rescan' becuase many people use it out of confusion... well, yes, but you can't really keep the new name secret to clueless users :)
3202016-03-16T20:10:21  <wumpus> morcos: I think review was good for that, we should merge it
3212016-03-16T20:10:40  <wumpus> MarcoFalke: yea will do that, haven't got around to it
3222016-03-16T20:10:56  <wumpus> morcos: (and squash, yes)
3232016-03-16T20:13:14  <MarcoFalke> morcos (and others) Make sure to have the commit id somewhere in the GitHub discussion before you squash. Otherwise it's less transparent and harder to re-review if the reviewer hasn't pulled your repo yet.
3242016-03-16T20:13:25  <wumpus> morcos: I think changing the semantics in potentially dangerous way would be a good reason to rename them, and error when the old name is used
3252016-03-16T20:13:49  <morcos> wumpus: like maxsigcachesize  :)
3262016-03-16T20:16:34  <morcos> ok done
3272016-03-16T20:16:37  <wumpus> morcos: ehh that changed from entries to MiB didn't it
3282016-03-16T20:16:57  <wumpus> morcos: yes, luckily it's an option no one knows about :)
3292016-03-16T20:17:01  <morcos> yeah, i mean the damage is probably not that large, just an unlimited sigcache
3302016-03-16T20:17:24  <wumpus> but yes it'd have made sense to change the name
3312016-03-16T20:19:30  *** MarcoFalke has quit IRC
3322016-03-16T20:20:28  <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/622fe6c32f41...14d6324a248d
3332016-03-16T20:20:28  <GitHub33> bitcoin/master 982670c Alex Morcos: Add LockPoints...
3342016-03-16T20:20:29  <GitHub33> bitcoin/master 14d6324 Wladimir J. van der Laan: Merge #7187: Keep reorgs fast for SequenceLocks checks...
3352016-03-16T20:20:33  <GitHub162> [bitcoin] laanwj closed pull request #7187: Keep reorgs fast for SequenceLocks checks (master...fastReorgBIP68) https://github.com/bitcoin/bitcoin/pull/7187
3362016-03-16T20:32:53  <btcdrak> The mempool behaviours for BIP68/112 have been backported by cherry-pick to 0.11 and 0.12 in PRs #7543, #7695 and #7693. Can I ask a few eyes you verify they are correct.
3372016-03-16T20:38:37  *** achow101 has joined #bitcoin-core-dev
3382016-03-16T20:44:31  *** laurentmt has quit IRC
3392016-03-16T21:23:54  *** Don_John has joined #bitcoin-core-dev
3402016-03-16T21:47:51  *** Guyver2 has quit IRC
3412016-03-16T22:01:47  *** randy-waterhouse has joined #bitcoin-core-dev
3422016-03-16T22:30:35  *** BashCo_ has joined #bitcoin-core-dev
3432016-03-16T22:33:02  *** BashCo has quit IRC
3442016-03-16T22:43:20  *** Thireus has quit IRC
3452016-03-16T22:43:38  *** Thireus has joined #bitcoin-core-dev
3462016-03-16T22:58:21  *** PRab has joined #bitcoin-core-dev
3472016-03-16T23:00:02  *** Thireus has quit IRC
3482016-03-16T23:01:04  *** Chris_Stewart_5 has quit IRC
3492016-03-16T23:11:09  *** MarcoFalke has joined #bitcoin-core-dev
3502016-03-16T23:17:55  *** wallet421 has quit IRC
3512016-03-16T23:34:28  *** wallet42 has joined #bitcoin-core-dev
3522016-03-16T23:46:57  *** belcher has joined #bitcoin-core-dev
3532016-03-16T23:47:14  *** MarcoFalke has quit IRC
3542016-03-16T23:55:27  *** laurentmt has joined #bitcoin-core-dev