12015-11-25T00:03:16  <raedah> which file creates the info displayed in 'Show transaction details' ?  Looking at  src/qt/transactionrecord.cpp  and  src/qt/transactiontablemodel.cpp
  22015-11-25T00:05:21  <raedah> ah, looks like its in transactiondesc.cpp
  32015-11-25T00:20:51  *** arowser has quit IRC
  42015-11-25T00:21:15  *** arowser has joined #bitcoin-core-dev
  52015-11-25T00:54:29  *** Ylbam has quit IRC
  62015-11-25T00:57:40  *** blkdb has joined #bitcoin-core-dev
  72015-11-25T01:07:22  *** blkdb has quit IRC
  82015-11-25T01:07:31  *** blkdb has joined #bitcoin-core-dev
  92015-11-25T01:12:16  *** blkdb has quit IRC
 102015-11-25T01:12:32  *** phantomcircuit has quit IRC
 112015-11-25T01:12:39  *** phantomcircuit has joined #bitcoin-core-dev
 122015-11-25T01:12:46  *** blkdb has joined #bitcoin-core-dev
 132015-11-25T01:15:30  *** pmienk has quit IRC
 142015-11-25T01:16:42  *** pmienk has joined #bitcoin-core-dev
 152015-11-25T01:21:29  *** blkdb has quit IRC
 162015-11-25T01:25:43  *** cocoBTC has quit IRC
 172015-11-25T01:30:34  *** raedah has quit IRC
 182015-11-25T01:32:29  *** randy-waterhouse has joined #bitcoin-core-dev
 192015-11-25T01:52:55  *** pmienk has quit IRC
 202015-11-25T02:01:46  *** wumpus has quit IRC
 212015-11-25T02:03:40  *** wumpus has joined #bitcoin-core-dev
 222015-11-25T02:09:22  *** pmienk has joined #bitcoin-core-dev
 232015-11-25T02:41:51  <GitHub190> [bitcoin] pstratem opened pull request #7094: Assert now > 0 in GetTime GetTimeMillis GetTimeMicros (master...2015-11-24-assert-time) https://github.com/bitcoin/bitcoin/pull/7094
 242015-11-25T02:44:13  <gmaxwell> Guess my PR answered the question of if we still had tests that were expecting the mempool RPC to behave in certian ways. :)
 252015-11-25T02:45:46  <phantomcircuit> gmaxwell, it also failed on INT64_MAX for some reason
 262015-11-25T02:46:31  <phantomcircuit> see my note on the outdated diff
 272015-11-25T02:47:07  <gmaxwell> phantomcircuit: yea, I had a host that it did that on too. Which is weird because stdint.h is included in that file; but whatever; you were right: I should have done it consistently.
 282015-11-25T02:47:24  <phantomcircuit> oh you fixed that already
 292015-11-25T02:48:10  <phantomcircuit> i dont have any strong tie to either method but we've been using std::numeric_limits everywhere else (apparently for a reason, which i cant discern either)
 302015-11-25T02:52:20  *** belcher has quit IRC
 312015-11-25T02:52:38  *** dcousens has joined #bitcoin-core-dev
 322015-11-25T02:55:59  <gmaxwell> phantomcircuit: now the issue is that the blocktester (foolishly) depends on this.
 332015-11-25T03:00:49  *** tulip has joined #bitcoin-core-dev
 342015-11-25T03:20:33  <cfields_> anyone happen to know why dns seeds register a second dns query result as their source in addrman, rather than some dummy value?
 352015-11-25T03:24:09  <gmaxwell> er. it's supposted to be like.. the dns seed identifer as a source.
 362015-11-25T03:25:47  *** blkdb has joined #bitcoin-core-dev
 372015-11-25T03:26:25  <cfields_> gmaxwell: right. that identifier requires another resolve, which i suppose could fail and result in a source of "0.0.0.0".
 382015-11-25T03:26:43  <cfields_> (or am i reading it wrong?)
 392015-11-25T03:27:46  <gmaxwell> yea, it's brain damaged that it's resolving though, since thats going to return some random stuff.
 402015-11-25T03:28:04  <gmaxwell> We should be filling it in with a dummy value and a distinct dummy value per dnsseed.
 412015-11-25T03:28:17  <gmaxwell> I wonder if that resolution is a DNS leak when running on TOR?
 422015-11-25T03:29:06  <cfields_> i don't believe so, it should be stopped later down the path
 432015-11-25T03:30:24  <cfields_> er yikes.. maybe not
 442015-11-25T03:31:31  *** blkdb has quit IRC
 452015-11-25T03:33:28  <cfields_> gmaxwell: ok yea, that's ok. oneshots are used if a proxy is enabled, so that path isn't taken
 462015-11-25T03:35:27  *** blkdb has joined #bitcoin-core-dev
 472015-11-25T03:53:46  <phantomcircuit> gmaxwell, ./qa/pull-tester/rpc-tests.py passes all tests on 7093
 482015-11-25T04:00:19  <gmaxwell> phantomcircuit: yea, it's matt's blocktester thats failing. It's monitoring node status via p2p mempool calls.
 492015-11-25T04:04:09  <phantomcircuit> oh
 502015-11-25T04:04:21  <phantomcircuit> BlueMatt, ^
 512015-11-25T04:05:10  *** blur3d has joined #bitcoin-core-dev
 522015-11-25T04:06:53  <BlueMatt> gmaxwell: why are you not responding to queries if the node just asked for mempool now?
 532015-11-25T04:07:54  <BlueMatt> gmaxwell: that seems like an annoying hack :/
 542015-11-25T04:08:20  <gmaxwell> BlueMatt: It already answered.
 552015-11-25T04:08:30  <gmaxwell> it's not resending the same stuff it already sent.
 562015-11-25T04:10:03  <gmaxwell> BlueMatt: you've been whined at before about the pull tester using mempool... mempool behavior isn't consensus normative. :)
 572015-11-25T04:13:56  <BlueMatt> gmaxwell: yea, yea...
 582015-11-25T04:14:30  <BlueMatt> gmaxwell: the goal of it has changed slightly over time
 592015-11-25T04:14:40  <gmaxwell> in any case, I could add a hidden option to turn off this behavior, or bypass it for whitelisted peers or...
 602015-11-25T04:15:09  <gmaxwell> but I do think we need to limit how mempool P2P command works (Jeff suggested removing it entirely; but it's widely used by SPV wallets)
 612015-11-25T04:15:56  <gmaxwell> and I think my patch mostly solves the privacy and dos attacks without breaking SPV wallets (well, apparently mycelium redoes filterloads and mempools again, so I need some additional handling there)
 622015-11-25T04:17:41  <BlueMatt> allow X-per-Y
 632015-11-25T04:17:44  <BlueMatt> then everything works :)
 642015-11-25T04:17:51  <BlueMatt> i think the tester only does like 3 or 4 total anyway
 652015-11-25T04:18:26  <gmaxwell> well I'm breaking the tester because I don't return duplicate results.
 662015-11-25T04:19:14  <gmaxwell> The delay means that a spv wallet will need to mempool again 30 seconds after connecting in order to get _everything_, and it would be nice to only send it INVs for the things it missed.
 672015-11-25T04:19:32  <BlueMatt> yea, just multiply your quanitization interval by X and allow X requests each interval
 682015-11-25T04:22:13  <gmaxwell> I can allow more requests, but you're missing my point. It won't be able to stop returning old data then, so it'll send duplicates.
 692015-11-25T04:22:26  <BlueMatt> yea, my point was "meh"
 702015-11-25T04:22:54  <gmaxwell> then it remains a bandwidth exhaustion attack to keep calling mempool often.
 712015-11-25T04:23:19  <BlueMatt> not really
 722015-11-25T04:23:26  <BlueMatt> because you limit how often you can call it
 732015-11-25T04:23:45  <BlueMatt> to the same rate as your patch
 742015-11-25T04:25:19  *** mm_1 has quit IRC
 752015-11-25T04:26:09  *** arowser has quit IRC
 762015-11-25T04:26:34  *** arowser has joined #bitcoin-core-dev
 772015-11-25T04:27:02  *** mm_1 has joined #bitcoin-core-dev
 782015-11-25T04:28:15  <phantomcircuit> tulip, ha
 792015-11-25T04:28:25  <tulip> the blown up ping?
 802015-11-25T04:28:26  <phantomcircuit> i knew that someone would show up having seen that in production
 812015-11-25T04:28:36  <phantomcircuit> "production"
 822015-11-25T04:28:54  <phantomcircuit> there's lots of things using wall clock time that should be using monotonic time
 832015-11-25T04:29:07  <phantomcircuit> but i think for now it's better to explode than to silently do crazy things
 842015-11-25T04:31:30  <cfields_> gmaxwell: suggestions for a uuid for seeds rather than a second lookup? best i can come up with is designating a tiny chunk of the FC00::/7 range for groups. I'd say we should just feed addrman a deterministic hash for the source, but the address is serialized to disk
 852015-11-25T04:32:02  <gmaxwell> phantomcircuit: I have pointed out before that we should be using monotone time. I don't thinke we have any need for wallclock time, except logging (and even there, if logtimes are non-monotone it will break some log parsing tools for sure)
 862015-11-25T04:32:47  <gmaxwell> phantomcircuit: we already have code that does time ofsetting so it can just adjust the offset between the monotone clock and what we want it to be (in a way that preserves monotonicity!)
 872015-11-25T04:33:10  <gmaxwell> phantomcircuit: reworking time in bitcoin core is something I've wanted to do since 2011 but its so unimportant that I never will.
 882015-11-25T04:34:02  <gmaxwell> cfields_: 127.0.0.2 127.0.0.3  perhaps? :P (I forget if we look at the source netgroup)
 892015-11-25T04:34:35  <gmaxwell> even though it gets saved to disk, I don't think we care too much if its not fully consistent across versions. I suppose it's preferable if it is.
 902015-11-25T04:35:48  <gmaxwell> phantomcircuit: e.g. I think all Time() in core should be monotone, network time should be largely monotone but with the ability to step if its way out of wack.
 912015-11-25T04:37:00  <cfields_> gmaxwell: heh, i figured you'd smack me for not coming up with something more clever than a dummy range. if you're ok with that, i'll go ahead and do it that way and we can bikeshed about what actual range to use in the PR. 127.0.0.x sounds as good as any to me.
 922015-11-25T04:40:11  *** PRab has joined #bitcoin-core-dev
 932015-11-25T04:40:55  <phantomcircuit> gmaxwell, agreed, but we would definitely want to review everywhere that GetTime* is used before changing their behavior
 942015-11-25T04:41:09  <phantomcircuit> but a simple find/replace to GetMonotonicTime
 952015-11-25T04:41:31  <phantomcircuit> or maybe just change GetTime to be monotonic and add GetWallclockTime
 962015-11-25T04:41:41  <phantomcircuit> which could keep the assert
 972015-11-25T04:43:01  <phantomcircuit> either way i think exploding all over the place is the best option for something doable right now today
 982015-11-25T04:45:14  <gmaxwell> cfields_: the only downside I see w/ the dummy range is that if we reorder the list it'll behave suboptimally. But this is no great crime. :)
 992015-11-25T04:45:43  <gmaxwell> but as I said, if we're currently paying attention to source netgroups (I think we might in one table) them they should probably be in different netgroups.
1002015-11-25T04:46:35  <cfields_> gmaxwell: not sure what you mean about reordering?
1012015-11-25T04:46:39  <gmaxwell> phantomcircuit: well it's more complex. monotone time is not calibrated to any particular starting point. So that means any place we print one of our stored times we may need to process it.
1022015-11-25T04:47:32  <tulip> phantomcircuit: I don't think I would have noticed except that the script the output was being piped to didn't like graphing a ping with 300,000 years of network latency.
1032015-11-25T04:47:34  <cfields_> gmaxwell: oh, you mean re-querying with existing addrman data?
1042015-11-25T04:47:40  <gmaxwell> cfields_: e.g. if the list is seed1, seed2, seed3  and we change to seed2, seed4, seed1, seed3  in a new release then addresses will go into different groups, perhaps giving one seed or another more share of your addrman than it should. But who cares.
1052015-11-25T04:48:20  <cfields_> gmaxwell: roger, and agreed.
1062015-11-25T04:49:01  <cfields_> gmaxwell: for background, i'm poking at this in order to make dns async. as-is, it's all tangled up if one resolve has to wait on another.
1072015-11-25T04:49:16  <cfields_> so there's more motivation than just "that looks weird"
1082015-11-25T04:49:30  <gmaxwell> phantomcircuit: but I think we should return numbers in network time, and then just have a function that converts any absolute time we display to network time.
1092015-11-25T04:49:39  <gmaxwell> cfields_: fantastic.
1102015-11-25T04:50:24  <gmaxwell> (and I think our log messages should log both network time and local time; /me wants for wumpus to shoot him)
1112015-11-25T04:50:25  <phantomcircuit> gmaxwell, static int64_t first_time; int64_t now = monotonic_time - first_time + 1;
1122015-11-25T04:50:25  <phantomcircuit> ?
1132015-11-25T04:50:43  <phantomcircuit> basically always start at 1
1142015-11-25T04:51:02  <gmaxwell> phantomcircuit: actually on most systems the monotone clocks starts at 0 at boot.
1152015-11-25T04:51:07  <phantomcircuit> oh
1162015-11-25T04:51:11  <phantomcircuit> then *shrug*
1172015-11-25T04:51:36  <cfields_> gmaxwell: you'll be happy to know also, the async networking coalesces 4 threads to 1. Not sure how many of those unused threads i get to spend myself, though :)
1182015-11-25T04:52:10  * gmaxwell looks at x86 virtual address space usage
1192015-11-25T04:52:12  <gmaxwell> :(
1202015-11-25T04:52:14  <gmaxwell> -3
1212015-11-25T04:52:16  <gmaxwell> :)
1222015-11-25T04:53:10  <gmaxwell> phantomcircuit: it's no big deal, we already handle network time being some arbritary offset from local time; so instead it would just be network time is an arbritary offset from monotone time, and that offset is initilized with localtime at start.
1232015-11-25T04:53:10  * cfields_ calls shotgun on at least one freed up thread for async block handling of some kind
1242015-11-25T04:53:50  <gmaxwell> phantomcircuit: most calculation internally would use monotone time, but display would convert to network time. (and obviously the network time needing things would use network time).
1252015-11-25T04:56:01  <phantomcircuit> gmaxwell, oh you mean the adjusted network time thingie?
1262015-11-25T04:56:30  <gmaxwell> yup yup.
1272015-11-25T04:59:17  <phantomcircuit> hmm yeah that makes sense
1282015-11-25T04:59:31  <phantomcircuit> and then finangle that such that it's monotonic unless something crazy happens
1292015-11-25T05:00:55  <gmaxwell> well the network time should be monotone except for steps, and we should probably log steps.
1302015-11-25T05:01:37  <gmaxwell> but it doesn't need to be, and most of our use of time is differential, and its more important that it be monotone than it have any particular timebase.
1312015-11-25T05:11:10  <CodeShark> we have such poor temporal resolution anyhow - ultimately consensus is about well-ordering of events
1322015-11-25T05:14:11  <gmaxwell> CodeShark: internally we have high resolution and do varrious things where time going backwards can cause breakage. See tulip's example with the 300 thousand year pingtime.
1332015-11-25T05:16:26  <CodeShark> was that part of an earlier discussion here? (scrolling back)
1342015-11-25T05:16:48  <tulip> yes, and #7094
1352015-11-25T05:19:01  <CodeShark> why were signed ints used for timestamps in the first place?
1362015-11-25T05:19:03  <CodeShark> :)
1372015-11-25T05:19:38  <CodeShark> what's the 300 thousand year pingtime?
1382015-11-25T05:20:39  <tulip> https://github.com/bitcoin/bitcoin/pull/7094#issuecomment-159487966
1392015-11-25T05:20:47  <phantomcircuit> CodeShark, his clock went backwards or something insane
1402015-11-25T05:20:52  <phantomcircuit> oh no i know
1412015-11-25T05:20:59  <gmaxwell> CodeShark: because they mostly get used for time differences, which are naturally signed. Not using signed values are part of what creates issues like the 300 years pingtime (instead of negative pingtimes)
1422015-11-25T05:21:04  <phantomcircuit> his clock started at 1970-1-1 and jumped to the current time
1432015-11-25T05:21:07  <phantomcircuit> or something like that
1442015-11-25T05:21:44  <gmaxwell> phantomcircuit: More likely it just went backwards a microsecond, and then the -1 was converted to unsigned at some point before it hit the screen.
1452015-11-25T05:21:51  <CodeShark> hah
1462015-11-25T05:22:03  <phantomcircuit> so many comical possibilities!
1472015-11-25T05:22:06  <phantomcircuit> :)
1482015-11-25T05:22:20  <phantomcircuit> gmaxwell, are there systems where the monotonic clock will wrap?
1492015-11-25T05:22:28  <gmaxwell> because people have the expectation that time does not flow backwards and write software accordingly.
1502015-11-25T05:22:33  <phantomcircuit> i'd like to think the kernel detects that and helps you out but...
1512015-11-25T05:23:00  <gmaxwell> phantomcircuit: the monotone clock returned by the OS should be cleaned of any vulgar hardware weirdness.
1522015-11-25T05:23:06  <gmaxwell> If it doesn't, we're allowed to fail. :)
1532015-11-25T05:23:20  <phantomcircuit> fail catastrophically? "your clock is broken"
1542015-11-25T05:23:24  <phantomcircuit> heh
1552015-11-25T05:23:25  <gmaxwell> (it's pretty easy to unwrap a monotone clock!)
1562015-11-25T05:23:59  <phantomcircuit> gmaxwell, as long as you're polling more frequently than the wrap interval yes
1572015-11-25T05:23:59  <gmaxwell> (so long as you know its period and poll it at least twice per cycle )
1582015-11-25T05:24:50  <tulip> phantomcircuit: 9223372036854 seconds is 9223372036854000000 microseconds, which is pretty close to 2**64. I think the clock just skipped back further than the ping time.
1592015-11-25T05:25:34  <phantomcircuit> yup
1602015-11-25T05:25:50  <gmaxwell> independant of this monotone time stuff, we should probably figure out where that stat goes unsigned and make it signed.
1612015-11-25T05:26:04  <gmaxwell> or discard negative values before they get that far. :)
1622015-11-25T05:27:32  <phantomcircuit> gmaxwell, ok now i can see the need for negative values
1632015-11-25T05:27:34  <phantomcircuit> :P
1642015-11-25T05:29:40  <CodeShark> why do we care about the other node's clock when doing a ping?
1652015-11-25T05:31:03  <tulip> it's the network time thing.
1662015-11-25T05:32:05  <tulip> -debug (-debug=net in master) will dump out the deltas of your peers timestamps. spoiler is, they're usually pretty awful.
1672015-11-25T05:39:22  *** blur3d has quit IRC
1682015-11-25T05:53:33  <gmaxwell> CodeShark: we don't know _anything_ about the other nodes clock when doing a ping.
1692015-11-25T05:53:44  <gmaxwell> CodeShark: it's not the other nodes clock at all.
1702015-11-25T05:54:07  <gmaxwell> GetTime() is not monotone. It can go back.  Time_ping_returned-Time_ping_sent can be negative.
1712015-11-25T05:55:09  <CodeShark> time_t now = time(NULL); - how can that go back unless the user's system clock gets changed?
1722015-11-25T05:55:31  <tulip> NTP will change the system clock backwards if it needs to.
1732015-11-25T05:55:38  <CodeShark> oh, ok
1742015-11-25T05:56:53  <CodeShark> if you only need to measure time intervals, isn't there a better option than time(NULL) that is unaffected by system clock changes?
1752015-11-25T05:57:09  <gmaxwell> yes, you ask the system for a monotone clock.
1762015-11-25T05:58:36  <CodeShark> is that part of the time.h library?
1772015-11-25T05:59:06  <CodeShark> I guess there's the timer stuff
1782015-11-25T05:59:16  <gmaxwell> tulip: NTP tries pretty hard to not move the clock backwards, but it will do so if its too far behind... and this can happen like.. constantly, if the path delay asymmetry of the NTP servers you're using changes. (e.g. due to servers going up/down or internet rerouting).
1792015-11-25T06:01:27  <tulip> phantomcircuit: RE doing things that rely on the accuracy of peer clocks, here's the offsets from a crawl of about 1000 random IPv4 peers. the data doesn't account for latency so +-300ms is probably within the noise when the nodes are far away. http://pastebin.com/raw.php?i=3zmQDyK0
1802015-11-25T06:03:07  <CodeShark> to force monotonicity, could we do something like static int prev = 0;  int GetTime() { time_t now = time(NULL); if (now > prev) { prev = now; } return prev; }
1812015-11-25T06:05:29  <gmaxwell> sweet now GetTime() needs to take a lock. :P
1822015-11-25T06:05:50  <CodeShark> yeah, it's not thread-safe...but we'll pretend we didn't notice ;)
1832015-11-25T06:06:22  <CodeShark> how often does it get called, though?
1842015-11-25T06:06:25  <gmaxwell> no, not cool. There is no such thing as a safe data race. It's undefined behavior and can cause spooky memory corruption at a distance. :)
1852015-11-25T06:06:43  <gmaxwell> CodeShark: all over the place, used for benchmarking stuf, yadda yadda (esp the microseconds version)
1862015-11-25T06:07:32  <CodeShark> so then this brings up another issue - even if the system clock is perfectly accurate, things may execute out-of-order
1872015-11-25T06:10:12  <CodeShark> I mean, the monotonicity ceases to be meaningful in a concurrent setting
1882015-11-25T06:10:55  <CodeShark> in general we cannot say which of two calls on two separate threads occurred first without using a lock
1892015-11-25T06:11:24  <gmaxwell> sure but that isn't the case for many things. We do really know that a ping response came after the request. They're seralized by the IO.
1902015-11-25T06:11:53  <CodeShark> right
1912015-11-25T06:12:22  <CodeShark> in that particular use case, though, a lock doesn't seem like the bottleneck
1922015-11-25T06:13:28  <CodeShark> in any case, we can just zero all negative diffs and basically achieve the same goal :)
1932015-11-25T06:13:44  <tulip> that would ruin the "minping" statistic
1942015-11-25T06:13:50  <cfields_> gmaxwell: speaking of which, I've been considering creating a bip for an explicitly-allowed out-of-order ping/pong. For ex, if the ping nonce is 0xffff, allow that to mean "this is not meant to be a fence, it's an actual latency measurement"
1952015-11-25T06:14:40  <cfields_> gmaxwell: as threading improves, we should have a way of specifying that a ping isn't meant to be a fence. Thoughts?
1962015-11-25T06:15:07  <cfields_> er, everyone^^. No clue why that was directed at gmaxwell :p
1972015-11-25T06:16:46  <cfields_> only one unordered ping would be allowed in-flight at any given time, so dropping the nonce doesn't cost anything
1982015-11-25T06:17:19  <gmaxwell> The purpose of the nonce isn't so much for ordering, its to prevent faking a fast response.
1992015-11-25T06:18:04  <gmaxwell> I dunno if an unordered ping is actually useful, for every case where I'd like to use pings, I'd like it to go higher if the peer is busy. But if there is a use, I don't have a problem-- but it shouldn't lose the nonce. :)
2002015-11-25T06:18:59  <gmaxwell> tulip: yea, thats why I said discard above.
2012015-11-25T06:21:03  <cfields_> gmaxwell: well busy can be fleeting.. so it's not a great metric for discerning peering. "Busy" is also kinda an implementation detail. With better threading, a close-by busy peer may be more helpful than a further away idle one.
2022015-11-25T06:21:26  <cfields_> re nonce: point taken
2032015-11-25T06:23:09  <gmaxwell> cfields_: close by is best measured by the minimum.
2042015-11-25T06:23:32  <gmaxwell> (or minimum with periodic forgetting if you're concerned about it changing.)
2052015-11-25T06:27:16  <cfields_> gmaxwell: makes sense i guess. assuming you've stuck around long enough for a good minimum :)
2062015-11-25T06:47:34  <phantomcircuit> gmaxwell, atomics horray
2072015-11-25T06:47:39  <phantomcircuit> compare_and_swap
2082015-11-25T07:16:17  <Luke-Jr> gmaxwell: bool races are unsafe?
2092015-11-25T07:23:23  <phantomcircuit> Luke-Jr, yes
2102015-11-25T07:23:31  <phantomcircuit> Luke-Jr, dont tell ckpool
2112015-11-25T07:23:35  <phantomcircuit> it's funnier this way
2122015-11-25T07:23:48  <Luke-Jr> what could possibly go wrong in a bool race? :/
2132015-11-25T07:24:17  <phantomcircuit> Luke-Jr, overwrite a random byte of memory with garbage?
2142015-11-25T07:24:40  <Luke-Jr> that'd be a pointer race?
2152015-11-25T07:25:06  <phantomcircuit> Luke-Jr, clever compilers doing clever optimizations have the same effect potentially
2162015-11-25T07:25:22  <Luke-Jr> real-world optimizations?
2172015-11-25T07:26:17  <Luke-Jr> hm, I suppose the compiler could move a condition check outside a busy loop because it knows the value won't change inside it..
2182015-11-25T07:26:34  <Luke-Jr> well, except if for the volatile keyword..
2192015-11-25T07:30:53  <gmaxwell> Luke-Jr:  any race is unsafe. The compile can do things like "oh, later I will overwrite this variable, that means I have exclusive access to it, I can store temporary thing to it for now."
2202015-11-25T07:35:40  <Luke-Jr> hmm, I wouldn't think that is allowed if it's volatile
2212015-11-25T07:38:19  <gmaxwell> Volitile should prevent that; though volitile is frequently misimplemented.
2222015-11-25T07:40:35  *** randy-waterhouse has quit IRC
2232015-11-25T07:41:32  *** randy-waterhouse has joined #bitcoin-core-dev
2242015-11-25T07:47:00  <wumpus> gmaxwell: log messages should log at least current monotonic time, local time, network time, bulletin of atomic scientists' number of minutes to midnight, and the absolute time since the big bang in Planck time units
2252015-11-25T07:47:24  *** Ylbam has joined #bitcoin-core-dev
2262015-11-25T07:48:48  <gmaxwell> oh your stabbing is just right.
2272015-11-25T07:48:51  <gmaxwell> :)
2282015-11-25T07:54:50  <wumpus> gmaxwell: can we have your input on these tests? https://github.com/bitcoin/bitcoin/issues/7086  Looks like one hidden place where openssl is still used, as an oversight, as openssl hasn't been part of consensus in that particular way for ages
2292015-11-25T07:58:46  <wumpus> and now the code is running into trouble with newer OpenSSLs
2302015-11-25T08:05:46  <GitHub144> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b19fe277dd62...26af1ac7cbce
2312015-11-25T08:05:47  <GitHub144> bitcoin/master ae98388 Jonas Schnelli: [Qt] add startup option to reset Qt settings
2322015-11-25T08:05:47  <GitHub144> bitcoin/master f71bfef Jonas Schnelli: add UI help for -resetguisettings
2332015-11-25T08:05:48  <GitHub144> bitcoin/master 26af1ac Jonas Schnelli: Merge pull request #7006...
2342015-11-25T08:05:53  *** Thireus has quit IRC
2352015-11-25T08:05:56  <GitHub116> [bitcoin] jonasschnelli closed pull request #7006: [Qt] add startup option to reset Qt settings (master...2015/11/qt_resetsettings) https://github.com/bitcoin/bitcoin/pull/7006
2362015-11-25T08:08:42  *** randy-waterhouse has quit IRC
2372015-11-25T08:10:13  <jonasschnelli> hmm.... testing coinjoin and QT. Question:
2382015-11-25T08:11:15  <jonasschnelli> I have two 50BTC inputs, one from node0, one from node1. I create a transaction with those inputs with two outputs (49.9 to node0, 49.9 to node1). What would be expected as output for listtransactions and over the GUI?
2392015-11-25T08:11:52  <jonasschnelli> I expect only the relevant in/outs should be listed/calculated for the net?
2402015-11-25T08:13:14  <gmaxwell> It displays the coins that weren't yours as negative fee.
2412015-11-25T08:13:29  <gmaxwell> Which is ... internally consistent though a little confusing when you're not expecting it.
2422015-11-25T08:15:14  <wumpus> ah yes the negative fees when you don't own all inputs, that's not just a qt issue
2432015-11-25T08:16:15  <jonasschnelli> Yes. Listtransactions tell me now:  "fee": 49.98000000
2442015-11-25T08:17:14  <gmaxwell> It's logical in a sense, but hah. can be a real heart stopper.
2452015-11-25T08:17:24  <jonasschnelli> haha... right.
2462015-11-25T08:17:34  <wumpus> hehe indeed
2472015-11-25T08:17:38  <gmaxwell> FWIW, if I had champaign or really drank, I would have poped a cork at that issue being opened.
2482015-11-25T08:18:09  <gmaxwell> This is the first real proof of coinjoin being in widespread use by actual users: the reported a known 'bug'!
2492015-11-25T08:18:41  <jonasschnelli> Indeed. At it was reported by two users (independent) within 1.5 month...
2502015-11-25T08:18:46  <wumpus> it is good to see people actually using coinjoin, absolutely!
2512015-11-25T08:19:30  <gmaxwell> (bug just in quotes because I'm not actually sure what our behavior should be. Without access to the inputs in the wallet, it's hard to handle sanely!)
2522015-11-25T08:19:46  <gmaxwell> (reporting it all as fee might actually be the best we can do with the data available)
2532015-11-25T08:20:24  <wumpus> can we 'see' that something fishy is happening and flag the transaction as 'probably coinjoin',?
2542015-11-25T08:20:34  <wumpus> that'd at least help with the UI aspect a bit
2552015-11-25T08:20:36  *** dcousens has quit IRC
2562015-11-25T08:21:07  <gmaxwell> yes, well if there are inputs from outside the wallet we can just flag it as "used outside funds"
2572015-11-25T08:21:31  <gmaxwell> Or "used outside funds (coinjoin? lighthouse?)"
2582015-11-25T08:21:33  <wumpus> e.g. "you may be seeing exorbitant fees on this transaction because it involves foreign inputs"
2592015-11-25T08:21:38  <wumpus> right
2602015-11-25T08:22:04  <gmaxwell> well they're the opposite of exorbitant. :P
2612015-11-25T08:22:28  <wumpus> negative exorbitant :p
2622015-11-25T08:22:54  <gmaxwell> "exuberant fees"
2632015-11-25T08:22:56  <wumpus> people may not see the sign correctly, but agreed
2642015-11-25T08:23:00  <wumpus> LOL!
2652015-11-25T08:23:12  <gmaxwell> yea, it freaked me out the first time.
2662015-11-25T08:23:34  <gmaxwell> well actually not the first but the first time I did a CJ with an ordinary amount of coin.
2672015-11-25T08:25:28  <gmaxwell> I wasn't likely to mistake this for a too high fee error:
2682015-11-25T08:25:30  <gmaxwell>     "fee": 50000.31337000,
2692015-11-25T08:25:38  <gmaxwell> (this is not output from a testnet wallet)
2702015-11-25T08:25:40  <wumpus> whoa
2712015-11-25T08:27:09  <gmaxwell> but later a 10BTC one startled me I think.
2722015-11-25T08:27:34  <wumpus> was that the 'link yourself rich' or something transaction from bitcoin talk?
2732015-11-25T08:27:49  <wumpus> e.g. the first coinjoin experiment
2742015-11-25T08:28:02  *** paveljanik has quit IRC
2752015-11-25T08:29:36  <gmaxwell> https://bitcointalk.org/index.php?topic=139581.0
2762015-11-25T08:30:05  <gmaxwell> It works, FWIW, lots of wallet tracker things think that address is all kinds of stuff.
2772015-11-25T08:30:28  <gmaxwell> well half-works, they were supposted to notice all the linked up stuff and realize that what they were doing was dumb.
2782015-11-25T08:30:55  <wumpus> it's promising for the future at least when it is more used, they probably won't adjust dumb behavior for one transaction :)
2792015-11-25T08:32:14  <gmaxwell> well I made lots of coinjoins with that address, with lots of other people who went on to do coinjoins, and also joined with keys and got them imported varrious places.
2802015-11-25T08:32:58  *** raedah has joined #bitcoin-core-dev
2812015-11-25T08:33:18  <gmaxwell> otoh I now have to avoid anyone donating to it, because I probably can't spend any coins sent there in a lot of places. :(
2822015-11-25T08:35:06  <wumpus> is it 'contaminated'?
2832015-11-25T08:36:32  <gmaxwell> https://www.walletexplorer.com/wallet/0093bdcd5f898d99?from_address=1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB  and from what I've heard the commercial anti-fungibility tools are even dumber (more agressive about what they include)
2842015-11-25T08:37:53  <gmaxwell> in any case, it seems to think that 'wallet' has 266 addresses, and I believe only two of them are mine.
2852015-11-25T08:38:32  <gmaxwell> actually checking, three of them, how'd that one get linked. :-/
2862015-11-25T08:42:02  <CodeShark> expecting dumb people to notice that what they're doing is dumb is a risky success strategy - and avoiding donations is a good kind of problem to have :)
2872015-11-25T08:42:19  <tulip> has anybody tested -blocksonly with dynamic fees?
2882015-11-25T08:42:46  <tulip> I sort of expected the dynamic fee RPC calls to return -1, but they don't. they're returning values.
2892015-11-25T08:42:56  <gmaxwell> tulip: I  have, results in the -1 all the time (unless you have prexisting save predictioned), in which case they just fade out.
2902015-11-25T08:43:13  <gmaxwell> the results surprised me too, but they go away if you delete the saved stats file.
2912015-11-25T08:43:41  <tulip> ah good call.
2922015-11-25T08:44:10  <tulip> maybe they should just be hard wired to -1 with blocksonly?
2932015-11-25T08:47:36  <gmaxwell> tulip: so blocksonly isn't necessarily all blocks only; as you can have whitelisted peers you accept txn from. I was also contemplating a rpc command to one shot perform a top mempool fetch from a single peer; but I dunno if we'd take that upstream.
2942015-11-25T08:47:52  <gmaxwell> but perhaps it should be hardwired -1 when the mempool is totally empty?
2952015-11-25T08:48:18  <tulip> right, ok.
2962015-11-25T08:49:05  <gmaxwell> the goal with the saved state is to give useful resutlts as soon as you start.
2972015-11-25T08:49:28  <tulip> I'd completely forgot it exists, that's all.
2982015-11-25T09:00:34  *** paveljanik has joined #bitcoin-core-dev
2992015-11-25T09:00:43  *** paveljanik has quit IRC
3002015-11-25T09:02:26  <GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26af1ac7cbce...348b281f8a67
3012015-11-25T09:02:27  <GitHub102> bitcoin/master 392d3c5 Cory Fields: build: Set osx permissions in the dmg to make Gatekeeper happy
3022015-11-25T09:02:27  <GitHub102> bitcoin/master 348b281 Wladimir J. van der Laan: Merge pull request #7092...
3032015-11-25T09:02:32  <GitHub54> [bitcoin] laanwj closed pull request #7092: build: Set osx permissions in the dmg to make Gatekeeper happy (master...osx-perm-fix) https://github.com/bitcoin/bitcoin/pull/7092
3042015-11-25T09:07:07  <wumpus> jonasschnelli: good call on closing #7089 - indeed, bitcoin's core github is not the place to request changes to consensus behavior
3052015-11-25T09:07:45  <jonasschnelli> wumpus: Yes. It was a bit harsh but I think we need to keep discussions out of the github context.
3062015-11-25T09:08:01  <gmaxwell> hm. I didn't even see #7089 but yes.
3072015-11-25T09:08:27  <gmaxwell> Kind of irritating that they keep going back to probably the worst proposal for that ever done. (e.g. needlessly a hardfork)
3082015-11-25T09:09:20  <jonasschnelli> But i agree with him. It causes big pain for HWW devs to trustworthy validate fees (=input amounts).
3092015-11-25T09:09:28  <gmaxwell> Oh absolutely.
3102015-11-25T09:10:25  <gmaxwell> CHECKSIG in elements alpha tries one fix, though a different one would be better. I expect there will be a decent soft fork new checksig operator proposed within sig months.
3112015-11-25T09:10:45  <jonasschnelli> Not sure what is best practice there. But I think retrieving over SPV/BF the inputs and validate these together with the transaction is the only feasible way.
3122015-11-25T09:12:08  <gmaxwell> jonasschnelli: Currently, sure. But if we add a new checksig operator it can avoid having to check the inputs at all.
3132015-11-25T09:12:15  <wumpus> providing the dependent transactions together with the transaction seems like the only feasible way, certainly if the HW wants to verify that the inputs are really the ones given
3142015-11-25T09:12:56  <gmaxwell> Checksig already signs the txin scriptpubkey but what it really should sign is the whole utxo. If it did, then when signing you need only provide the utxos and not the whole parent transactions. If you lie the signature will be invalid.
3152015-11-25T09:13:29  <gmaxwell> But this can't be done as a sighash flag to checksig. Well it can but it would be insane and irresponsbile to hardfork the network for that.
3162015-11-25T09:13:32  <wumpus> indeed it signs the scriptpubkey, and that doesn't help verifying the amount
3172015-11-25T09:14:02  <wumpus> sure, a hardfork for that is stupid
3182015-11-25T09:19:09  <tulip> it looks like there's mining software on the main network which is rolling the sequence number. not disastrous or particularly interesting at the moment, but it might be notable if anybody is altering the behaviour of sequence numbers with a consensus rule like in BIP112.
3192015-11-25T09:19:51  <gmaxwell> lol oh boy. fortunately BIP constrains the transaction version number.
3202015-11-25T09:19:56  <gmaxwell> er that BIP.
3212015-11-25T09:20:02  <gmaxwell> tulip: thanks for noticing that. :(
3222015-11-25T09:27:26  <tulip> might be problematic if miners using this software just flip forward the version number though.
3232015-11-25T09:28:00  *** davec has quit IRC
3242015-11-25T09:28:41  *** davec has joined #bitcoin-core-dev
3252015-11-25T09:31:43  <wumpus> flipping forward the version number like people click 'OK' on software's terms and conditions
3262015-11-25T09:39:08  <jonasschnelli> hmm... testing wallet.py over the GUI makes the test fail.
3272015-11-25T09:39:17  <jonasschnelli> It looks like that self.nodes[2].settxfee(Decimal('0.001')) has no effect
3282015-11-25T09:39:35  <jonasschnelli> Assertion failed: 89.99977400 != 89.99900000
3292015-11-25T09:40:49  <jonasschnelli> how can the GUI "disturb" self.nodes[2].settxfee(Decimal('0.001')) and make the RPC servers sendtoaddress make pay different fees
3302015-11-25T09:42:04  <sipa> that seems weird...
3312015-11-25T09:43:35  <jonasschnelli> maybe this is related to the fPayAtLeastCustomFee
3322015-11-25T09:44:06  <wumpus> the GUI at least used to hook into fee decisions
3332015-11-25T09:44:29  * wumpus checks ui_interface
3342015-11-25T09:45:00  <gmaxwell> jonasschnelli: I suppose this is why it's important to test for impossible outcomes!
3352015-11-25T09:45:53  <wumpus> ok, seems no longer the case
3362015-11-25T09:46:14  <wumpus> neither ui_interface or the signals on CWallet itself have anything to do with determining fees
3372015-11-25T09:47:27  <wumpus> maybe a race condition as the UI gives some background load
3382015-11-25T09:47:59  <jonasschnelli> hmm... CreateTransaction repots a payTxFee=22600 after calling settxfee(Decimal('0.001')).
3392015-11-25T09:52:54  <wumpus> maybe coin control interfering? or some settings from QSettings?
3402015-11-25T09:52:59  *** arowser has quit IRC
3412015-11-25T09:53:16  *** jcorgan has quit IRC
3422015-11-25T09:53:27  *** arowser has joined #bitcoin-core-dev
3432015-11-25T09:53:54  *** neha has quit IRC
3442015-11-25T09:53:56  <wumpus> ideally the GUI should have an 'ignore QSettings' option for tests
3452015-11-25T09:54:00  *** jcorgan has joined #bitcoin-core-dev
3462015-11-25T09:54:00  *** jcorgan has joined #bitcoin-core-dev
3472015-11-25T09:54:02  *** neha has joined #bitcoin-core-dev
3482015-11-25T09:54:34  *** Madars has quit IRC
3492015-11-25T09:56:42  *** Madars has joined #bitcoin-core-dev
3502015-11-25T10:29:25  *** BashCo has joined #bitcoin-core-dev
3512015-11-25T10:31:54  *** andytoshi has quit IRC
3522015-11-25T10:32:18  <GitHub53> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/348b281f8a67...2b2ddc558e1c
3532015-11-25T10:32:19  <GitHub53> bitcoin/master 5ad5463 MarcoFalke: Squashed 'src/secp256k1/' changes from 2bfb82b..6c527ec...
3542015-11-25T10:32:19  <GitHub53> bitcoin/master fa63e49 MarcoFalke: Merge commit '5ad54630935d1f340666de7bc9ffef9b8a1df296' into HEAD
3552015-11-25T10:32:20  <GitHub53> bitcoin/master 2b2ddc5 Wladimir J. van der Laan: Merge pull request #7088...
3562015-11-25T10:32:25  <jonasschnelli> found the problematic UI interaction that interferes the RPC server.
3572015-11-25T10:32:28  <GitHub130> [bitcoin] laanwj closed pull request #7088: [trivial] pull secp256k1 subtree (master...MarcoFalke-2015-syncSecp256k1) https://github.com/bitcoin/bitcoin/pull/7088
3582015-11-25T10:32:34  <jonasschnelli> void SendCoinsDialog::updateGlobalFeeVariables()  ---> fSendFreeTransactions = ui->checkBoxFreeTx->isChecked()
3592015-11-25T10:32:41  <jonasschnelli> Gets called when the GUI starts
3602015-11-25T10:33:09  <jonasschnelli> sorry... not fSendFreeTransactions , i meant instead: fPayAtLeastCustomFee = ui->radioCustomAtLeast->isChecked();
3612015-11-25T10:33:15  <wumpus> good catch
3622015-11-25T10:33:24  <wumpus> phew, at least not a race condition!
3632015-11-25T10:41:20  *** andytoshi has joined #bitcoin-core-dev
3642015-11-25T11:16:48  <wumpus> though ideally the UI wouldn't be updating global variables like that, just pass everything it needs into the transaction creation/commit
3652015-11-25T11:22:26  *** Thireus has joined #bitcoin-core-dev
3662015-11-25T11:31:59  *** andytoshi has quit IRC
3672015-11-25T11:36:09  <jonasschnelli> wumpus: I though the same. The UI should not connect globals vars with radio-buttons, etc.
3682015-11-25T11:36:27  <wumpus> managed to avoid that with coin control, but apparently some did sneak in
3692015-11-25T11:37:16  <wumpus> (e.g. coincontrol config is global, but only to the GUI, it is explicitly passed to the core, so doesn't/shouldn't interfere with RPC usage)
3702015-11-25T11:38:54  <jonasschnelli> but i don't get this. "settxfee" is supposed to by by fee per KB?! Also it help says so. But it's actually absolute?!
3712015-11-25T11:39:19  <wumpus> it's per kB afaik
3722015-11-25T11:39:44  <jonasschnelli> If it would be, that assert would not be true: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/wallet.py#L111
3732015-11-25T11:40:28  <jonasschnelli> I just created a transaction on regtest after calling "settxfee 0.001" ... gettransaction tells me: "fee": -0.00100000
3742015-11-25T11:41:13  <jonasschnelli> hexlen 384 = 192 bytes = a expected fee of 0.000192
3752015-11-25T11:41:26  <wumpus> it assumes rounding?
3762015-11-25T11:42:05  <sipa>     if (fPayAtLeastCustomFee && nFeeNeeded > 0 && nFeeNeeded < payTxFee.GetFeePerK())
3772015-11-25T11:42:07  <sipa>         nFeeNeeded = payTxFee.GetFeePerK();
3782015-11-25T11:42:08  <jonasschnelli> no. settxfee to 0.01 resuls in a transaction with fee "fee": -0.01000000
3792015-11-25T11:42:11  <sipa> ^ that looks complete broken
3802015-11-25T11:42:29  <sipa> payTxFee is treated as a minimum, absolute, fee for a transaction
3812015-11-25T11:42:48  <jonasschnelli> right... this needs fixing.
3822015-11-25T11:43:16  <sipa> what is this "payatleastcustomfee" ?
3832015-11-25T11:43:43  <sipa> the comment says "user selected total at least"
3842015-11-25T11:43:48  <sipa> so this is clearly intentional
3852015-11-25T11:44:28  <jonasschnelli> Right. But fPayAtLeastCustomFee = true by default.
3862015-11-25T11:44:34  <jonasschnelli> Which makes by default every fee absolute?
3872015-11-25T11:44:43  <jonasschnelli> and the only way to change fPayAtLeastCustomFee is over the GUI?
3882015-11-25T11:44:51  <sipa> ... yup
3892015-11-25T11:44:54  <jonasschnelli> hah
3902015-11-25T11:45:01  *** MarcoFalke has joined #bitcoin-core-dev
3912015-11-25T11:45:10  <jonasschnelli> i think we should review https://github.com/bitcoin/bitcoin/pull/6708
3922015-11-25T11:45:17  <sipa> from within the coin control dialog
3932015-11-25T11:45:32  <sipa> so it makes sense that from without coincontrol you're able to set the absolute fee
3942015-11-25T11:46:18  <sipa> but it should 1) use a separate variable (not paytxfee, but for example overridetotalfee) 2) it should be passed down through the coin control preferences, not through a global
3952015-11-25T11:46:37  <jonasschnelli> Right. It should not be a global variable and should not touch outside GUI behavior. It's actually also available without CoinControl.
3962015-11-25T11:47:06  <sipa> well it being set to true by default is broken
3972015-11-25T11:47:20  <sipa> and it can only be unset through the coincontrol gui
3982015-11-25T11:47:51  <jonasschnelli> okay. will work on a fix.
3992015-11-25T11:47:57  <jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK(); // <--- is a dirty hack!
4002015-11-25T11:48:58  <jonasschnelli> but i see, that an absolute fee can help (during RPC tests and maybe some other usecases).
4012015-11-25T11:49:16  <jonasschnelli> What about adding an option to set absolute fees over "settxfee"?
4022015-11-25T11:49:29  <sipa> makes no sense
4032015-11-25T11:49:33  <sipa> without coin control
4042015-11-25T11:49:49  <jonasschnelli> It only makes sense for regression tests.
4052015-11-25T11:50:00  <sipa> and if you're doing selection manually (via createrawtransaction), there is no need for it
4062015-11-25T11:50:02  <jonasschnelli> to deterministic calculate fees
4072015-11-25T11:50:22  <sipa> well if it's exposed by RPC it is necessarily global
4082015-11-25T11:50:26  <sipa> (for RPC)
4092015-11-25T11:50:50  <sipa> let's first fix the use case, then the rest?
4102015-11-25T11:51:01  <jonasschnelli> If we drop absolute fees (which would be the right step), rpc tests need this update: https://github.com/bitcoin/bitcoin/pull/6708/files#diff-51c9989cea15f3cac744183b78cb0688
4112015-11-25T11:53:02  *** andytoshi has joined #bitcoin-core-dev
4122015-11-25T11:54:22  <sipa> jonasschnelli: i'm writing a fix
4132015-11-25T11:54:35  <jonasschnelli> sipa: okay.. nice.
4142015-11-25T11:54:47  <jonasschnelli> I'll fix the UI stuff.
4152015-11-25T11:55:09  <jonasschnelli> Need to drop the absolut fee option for "non-coincontrol" transactions
4162015-11-25T11:56:22  * jonasschnelli needs to go back to the thing he was actually working on, "CoinJoin transactions display"
4172015-11-25T11:59:29  <sipa> oh, there is a nCustomFeeRadio set from the send dialog
4182015-11-25T11:59:36  <MarcoFalke> jonasschnelli, are you working on the https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 thing?
4192015-11-25T11:59:39  <sipa> sorry, this will need gui hackery
4202015-11-25T11:59:48  <MarcoFalke> Didn't catch that, so we are not duplicating effort
4212015-11-25T12:00:26  <jonasschnelli> MarcoFalke: I think sipa has just started to work on some things there. I'll wait until he has something.
4222015-11-25T12:00:33  <jonasschnelli> Then i'd like to address the UI stuff
4232015-11-25T12:00:54  <sipa> jonasschnelli: so my suggestion would be to remove the "pay at least total" function from the regular send dialog, and move it to the coin control one
4242015-11-25T12:01:15  <MarcoFalke> sipa, to fix https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 ?
4252015-11-25T12:01:18  <sipa> then the setting can just be passed via the coincontrol settings object, which is trivial
4262015-11-25T12:01:46  <sipa> MarcoFalke: no, to fix the fact that the "set at least total" function works via a global and changes all fees
4272015-11-25T12:02:25  <sipa> why was this introduced?
4282015-11-25T12:02:35  <jonasschnelli> sipa: right. It should be in the CC dialog.
4292015-11-25T12:02:57  <jonasschnelli> <sipa>	why was this introduced? / you mean the "pay at least total"? Probably together with Cozzes CC stuff?
4302015-11-25T12:03:14  <MarcoFalke> Yes it's by cozz
4312015-11-25T12:03:55  <sipa> so nobody ever noticed that this makes bitcoin core's transaction pay around 4x too much fee by default?
4322015-11-25T12:04:15  <jonasschnelli> sipa: hah. I assume "no"!.. scary!
4332015-11-25T12:04:28  <sipa> oh, i assume paytxfee was 0 by default, so it didn't have any effect
4342015-11-25T12:04:33  * jonasschnelli thinks Cozz was payed by the miners... :)
4352015-11-25T12:04:49  <jonasschnelli> sipa: right. This is a point.
4362015-11-25T12:05:07  <sipa> jonasschnelli: see my betterabsolute branch
4372015-11-25T12:05:16  <sipa> jonasschnelli: sorry, i thought i could do more, but there rest is gui code
4382015-11-25T12:05:20  <MarcoFalke> I haven't checked previous code but it may be to mimick how earlier version have done that.
4392015-11-25T12:05:34  <MarcoFalke> Was this "let's use round numbers for fees" a thing back then?
4402015-11-25T12:05:44  <sipa> right, i think until some time in the past, we always paid per kilobyte started
4412015-11-25T12:05:44  <jonasschnelli> sipa: np. I'm happy to take over.
4422015-11-25T12:05:50  <sipa> not per byte
4432015-11-25T12:05:51  <sipa> jonasschnelli: thanks!
4442015-11-25T12:18:58  <MarcoFalke> sipa, should I rebase onto betterabsolute?
4452015-11-25T12:19:46  <MarcoFalke> or wait until the gui is fixed
4462015-11-25T12:20:07  <sipa> MarcoFalke: up to jonasschnelli
4472015-11-25T12:20:54  <jonasschnelli> MarcoFalke: let me finish it, i'll also cherry-pick your wallet.py changes,... maybe afterwards there are still things that could be optimized.
4482015-11-25T12:22:13  <GitHub91> [bitcoin] laanwj opened pull request #7095: Replace scriptnum_test's normative ScriptNum implementation (master...2015_11_remove_openssl_consensus_checks) https://github.com/bitcoin/bitcoin/pull/7095
4492015-11-25T12:26:54  *** guest234234 has joined #bitcoin-core-dev
4502015-11-25T12:29:20  <MarcoFalke> wumpus, is https://github.com/bitcoin/bitcoin/pull/527/files#diff-e2b7ef544fda33841c06f443b2cab6b3 still relevant for gitian?
4512015-11-25T12:29:48  <wumpus> MarcoFalke: no
4522015-11-25T12:30:42  <wumpus> it never was; gitian-downloader was meant to be a downloader for bitcoin that checks the gitian signatures, but AFAIK it was never completed or used
4532015-11-25T12:31:02  <MarcoFalke> But the folder is used to store the pgp keys?
4542015-11-25T12:31:18  <wumpus> yes, just a convention
4552015-11-25T12:32:02  <wumpus> the download-configs are pointless
4562015-11-25T12:34:19  <wumpus> I think they've been kept around in case anyone was ever going to resurrect the tool, but that never happened, I guess they're out of date enough to be removed now
4572015-11-25T12:34:42  <MarcoFalke> Just doing this with my next trvial pull
4582015-11-25T13:05:11  <MarcoFalke> Oh, that's why travis is only running with 3/5 speed.
4592015-11-25T13:05:13  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92025728
4602015-11-25T13:05:18  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684
4612015-11-25T13:22:12  <GitHub180> [bitcoin] jonasschnelli opened pull request #7096: [Wallet] fix settxfee and improve minimum absolute fee GUI options (master...2015/11/feefix) https://github.com/bitcoin/bitcoin/pull/7096
4622015-11-25T13:25:18  *** BashCo has quit IRC
4632015-11-25T13:25:50  *** BashCo has joined #bitcoin-core-dev
4642015-11-25T13:26:51  *** tulip has quit IRC
4652015-11-25T13:31:03  <GitHub147> [bitcoin] jonasschnelli closed pull request #6708: [wallet] Default fPayAtLeastCustomFee to false (master...MarcoFalke-2015-walletFixPayTxFee) https://github.com/bitcoin/bitcoin/pull/6708
4662015-11-25T13:32:33  *** MarcoFalke has quit IRC
4672015-11-25T13:36:36  *** jgarzik has quit IRC
4682015-11-25T13:53:26  *** BashCo has quit IRC
4692015-11-25T13:53:50  *** BashCo has joined #bitcoin-core-dev
4702015-11-25T13:55:05  *** BashCo has quit IRC
4712015-11-25T13:55:42  *** BashCo has joined #bitcoin-core-dev
4722015-11-25T13:57:10  *** BashCo has quit IRC
4732015-11-25T13:57:38  *** BashCo has joined #bitcoin-core-dev
4742015-11-25T14:02:50  *** guest234234 has quit IRC
4752015-11-25T14:03:36  *** jgarzik has joined #bitcoin-core-dev
4762015-11-25T14:03:36  *** jgarzik has joined #bitcoin-core-dev
4772015-11-25T14:07:00  *** BashCo has quit IRC
4782015-11-25T14:07:28  *** BashCo has joined #bitcoin-core-dev
4792015-11-25T14:09:10  *** BashCo has quit IRC
4802015-11-25T14:09:46  *** BashCo has joined #bitcoin-core-dev
4812015-11-25T14:14:50  *** Guyver2 has joined #bitcoin-core-dev
4822015-11-25T14:24:40  *** BashCo_ has joined #bitcoin-core-dev
4832015-11-25T14:25:21  *** BashCo has quit IRC
4842015-11-25T14:25:24  *** MarcoFalke has joined #bitcoin-core-dev
4852015-11-25T14:32:12  *** BashCo_ has quit IRC
4862015-11-25T14:32:43  *** BashCo has joined #bitcoin-core-dev
4872015-11-25T14:34:38  *** BashCo has quit IRC
4882015-11-25T14:34:58  *** BashCo has joined #bitcoin-core-dev
4892015-11-25T14:37:56  *** BashCo has quit IRC
4902015-11-25T14:38:07  *** BashCo has joined #bitcoin-core-dev
4912015-11-25T15:16:13  *** BashCo has joined #bitcoin-core-dev
4922015-11-25T15:23:51  *** ParadoxSpiral has joined #bitcoin-core-dev
4932015-11-25T15:39:17  *** MarcoFalke has quit IRC
4942015-11-25T16:11:59  *** zookolaptop has quit IRC
4952015-11-25T16:44:03  *** jl2012 has quit IRC
4962015-11-25T16:44:12  *** jl2012 has joined #bitcoin-core-dev
4972015-11-25T17:38:54  *** Thireus has quit IRC
4982015-11-25T17:39:21  *** cocoBTC has joined #bitcoin-core-dev
4992015-11-25T17:45:55  *** ParadoxSpiral_ has joined #bitcoin-core-dev
5002015-11-25T17:49:21  *** ParadoxSpiral has quit IRC
5012015-11-25T17:55:43  *** BashCo has quit IRC
5022015-11-25T18:11:13  *** cocoBTC has joined #bitcoin-core-dev
5032015-11-25T18:13:17  *** BashCo has joined #bitcoin-core-dev
5042015-11-25T18:26:26  *** Ylbam has quit IRC
5052015-11-25T18:26:45  *** Ylbam has joined #bitcoin-core-dev
5062015-11-25T19:37:37  *** jtimon has quit IRC
5072015-11-25T19:48:57  <cfields_> sipa: thoughts on https://github.com/theuni/bitcoin/commit/792b0f5da618ea51ecd7b21db633faa6743c1e68 ?
5082015-11-25T19:50:08  <cfields_> not sure what the reasoning was for the double lookup, does it serve a purpose that a static dummy source wouldn't?
5092015-11-25T20:52:04  *** belcher has joined #bitcoin-core-dev
5102015-11-25T21:03:55  <cfields_> ok, i must be going crazy... using a vanilla node with no externally bound address, ipv4/ipv6 aren't set as reachable by default. So when addr's come in, they're not added to addrman since they fail IsReachable(). Result is that addrman only ever contains dns seeds
5112015-11-25T21:04:03  <cfields_> ...that can't be right.
5122015-11-25T21:08:36  <gmaxwell> oh that bug. damn
5132015-11-25T21:09:16  <gmaxwell> I think phantomcircuit (?) found that a couple months ago, someone did, and I forgot about it. So it may well be true.
5142015-11-25T21:09:16  <cfields_> gmaxwell: so that's actually the case? whoa.
5152015-11-25T21:09:22  *** Guyver2 has quit IRC
5162015-11-25T21:09:23  <cfields_> just verified with an addrman dump
5172015-11-25T21:11:07  <cfields_> gmaxwell: surely it's reasonable to set a net to reachable once a connection has been established on it?
5182015-11-25T21:12:14  <gmaxwell> I think we should be setting IPv4 reachable if we have any IPv4 bindings at least.
5192015-11-25T21:12:36  <gmaxwell> and tor reachable if we have a onion proxy configured.
5202015-11-25T21:13:01  <cfields_> i believe the latter is already done
5212015-11-25T21:25:30  *** JackH has quit IRC
5222015-11-25T21:33:32  *** Thireus has joined #bitcoin-core-dev
5232015-11-25T21:46:54  *** raskolnnikov has quit IRC
5242015-11-25T21:57:42  *** randy-waterhouse has joined #bitcoin-core-dev
5252015-11-25T22:06:59  <gmaxwell> wumpus: I switched to a somewhat different approach in that mempool limit patch. I now have it set setInventoryKnown (I think it should have always done this), and not return anything in setInventoryKnown.  It also only considers the top 8192 entries in the mempool.
5262015-11-25T22:19:40  *** ParadoxSpiral_ has quit IRC
5272015-11-25T22:28:13  *** midnightmagic has quit IRC
5282015-11-25T22:28:45  *** tulip has joined #bitcoin-core-dev
5292015-11-25T22:34:06  *** midnightmagic has joined #bitcoin-core-dev
5302015-11-25T22:40:02  *** belcher has quit IRC
5312015-11-25T22:40:20  *** belcher has joined #bitcoin-core-dev
5322015-11-25T22:43:23  *** jgarzik has quit IRC
5332015-11-25T22:52:34  *** cocoBTC has quit IRC
5342015-11-25T22:57:10  *** Guest66004 has joined #bitcoin-core-dev
5352015-11-25T23:10:29  <GitHub82> [bitcoin] gmaxwell opened pull request #7099: Add whitelistforcerelay setting and default to off. (master...control_relay_force) https://github.com/bitcoin/bitcoin/pull/7099
5362015-11-25T23:18:12  *** Guest66004 has quit IRC
5372015-11-25T23:18:12  *** Guest66004 has joined #bitcoin-core-dev
5382015-11-25T23:18:20  *** Guest66004 is now known as jgarzik_
5392015-11-25T23:24:14  *** asoltys has joined #bitcoin-core-dev
5402015-11-25T23:26:08  *** randy-waterhouse has quit IRC
5412015-11-25T23:39:13  *** randy-waterhouse has joined #bitcoin-core-dev
5422015-11-25T23:59:54  *** jtimon has joined #bitcoin-core-dev