1 2015-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
  2 2015-11-25T00:05:21  <raedah> ah, looks like its in transactiondesc.cpp
  3 2015-11-25T00:20:51  *** arowser has quit IRC
  4 2015-11-25T00:21:15  *** arowser has joined #bitcoin-core-dev
  5 2015-11-25T00:54:29  *** Ylbam has quit IRC
  6 2015-11-25T00:57:40  *** blkdb has joined #bitcoin-core-dev
  7 2015-11-25T01:07:22  *** blkdb has quit IRC
  8 2015-11-25T01:07:31  *** blkdb has joined #bitcoin-core-dev
  9 2015-11-25T01:12:16  *** blkdb has quit IRC
 10 2015-11-25T01:12:32  *** phantomcircuit has quit IRC
 11 2015-11-25T01:12:39  *** phantomcircuit has joined #bitcoin-core-dev
 12 2015-11-25T01:12:46  *** blkdb has joined #bitcoin-core-dev
 13 2015-11-25T01:15:30  *** pmienk has quit IRC
 14 2015-11-25T01:16:42  *** pmienk has joined #bitcoin-core-dev
 15 2015-11-25T01:21:29  *** blkdb has quit IRC
 16 2015-11-25T01:25:43  *** cocoBTC has quit IRC
 17 2015-11-25T01:30:34  *** raedah has quit IRC
 18 2015-11-25T01:32:29  *** randy-waterhouse has joined #bitcoin-core-dev
 19 2015-11-25T01:52:55  *** pmienk has quit IRC
 20 2015-11-25T02:01:46  *** wumpus has quit IRC
 21 2015-11-25T02:03:40  *** wumpus has joined #bitcoin-core-dev
 22 2015-11-25T02:09:22  *** pmienk has joined #bitcoin-core-dev
 23 2015-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
 24 2015-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. :)
 25 2015-11-25T02:45:46  <phantomcircuit> gmaxwell, it also failed on INT64_MAX for some reason
 26 2015-11-25T02:46:31  <phantomcircuit> see my note on the outdated diff
 27 2015-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.
 28 2015-11-25T02:47:24  <phantomcircuit> oh you fixed that already
 29 2015-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)
 30 2015-11-25T02:52:20  *** belcher has quit IRC
 31 2015-11-25T02:52:38  *** dcousens has joined #bitcoin-core-dev
 32 2015-11-25T02:55:59  <gmaxwell> phantomcircuit: now the issue is that the blocktester (foolishly) depends on this.
 33 2015-11-25T03:00:49  *** tulip has joined #bitcoin-core-dev
 34 2015-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?
 35 2015-11-25T03:24:09  <gmaxwell> er. it's supposted to be like.. the dns seed identifer as a source.
 36 2015-11-25T03:25:47  *** blkdb has joined #bitcoin-core-dev
 37 2015-11-25T03:26:25  <cfields_> gmaxwell: right. that identifier requires another resolve, which i suppose could fail and result in a source of "".
 38 2015-11-25T03:26:43  <cfields_> (or am i reading it wrong?)
 39 2015-11-25T03:27:46  <gmaxwell> yea, it's brain damaged that it's resolving though, since thats going to return some random stuff.
 40 2015-11-25T03:28:04  <gmaxwell> We should be filling it in with a dummy value and a distinct dummy value per dnsseed.
 41 2015-11-25T03:28:17  <gmaxwell> I wonder if that resolution is a DNS leak when running on TOR?
 42 2015-11-25T03:29:06  <cfields_> i don't believe so, it should be stopped later down the path
 43 2015-11-25T03:30:24  <cfields_> er yikes.. maybe not
 44 2015-11-25T03:31:31  *** blkdb has quit IRC
 45 2015-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
 46 2015-11-25T03:35:27  *** blkdb has joined #bitcoin-core-dev
 47 2015-11-25T03:53:46  <phantomcircuit> gmaxwell, ./qa/pull-tester/rpc-tests.py passes all tests on 7093
 48 2015-11-25T04:00:19  <gmaxwell> phantomcircuit: yea, it's matt's blocktester thats failing. It's monitoring node status via p2p mempool calls.
 49 2015-11-25T04:04:09  <phantomcircuit> oh
 50 2015-11-25T04:04:21  <phantomcircuit> BlueMatt, ^
 51 2015-11-25T04:05:10  *** blur3d has joined #bitcoin-core-dev
 52 2015-11-25T04:06:53  <BlueMatt> gmaxwell: why are you not responding to queries if the node just asked for mempool now?
 53 2015-11-25T04:07:54  <BlueMatt> gmaxwell: that seems like an annoying hack :/
 54 2015-11-25T04:08:20  <gmaxwell> BlueMatt: It already answered.
 55 2015-11-25T04:08:30  <gmaxwell> it's not resending the same stuff it already sent.
 56 2015-11-25T04:10:03  <gmaxwell> BlueMatt: you've been whined at before about the pull tester using mempool... mempool behavior isn't consensus normative. :)
 57 2015-11-25T04:13:56  <BlueMatt> gmaxwell: yea, yea...
 58 2015-11-25T04:14:30  <BlueMatt> gmaxwell: the goal of it has changed slightly over time
 59 2015-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...
 60 2015-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)
 61 2015-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)
 62 2015-11-25T04:17:41  <BlueMatt> allow X-per-Y
 63 2015-11-25T04:17:44  <BlueMatt> then everything works :)
 64 2015-11-25T04:17:51  <BlueMatt> i think the tester only does like 3 or 4 total anyway
 65 2015-11-25T04:18:26  <gmaxwell> well I'm breaking the tester because I don't return duplicate results.
 66 2015-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.
 67 2015-11-25T04:19:32  <BlueMatt> yea, just multiply your quanitization interval by X and allow X requests each interval
 68 2015-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.
 69 2015-11-25T04:22:26  <BlueMatt> yea, my point was "meh"
 70 2015-11-25T04:22:54  <gmaxwell> then it remains a bandwidth exhaustion attack to keep calling mempool often.
 71 2015-11-25T04:23:19  <BlueMatt> not really
 72 2015-11-25T04:23:26  <BlueMatt> because you limit how often you can call it
 73 2015-11-25T04:23:45  <BlueMatt> to the same rate as your patch
 74 2015-11-25T04:25:19  *** mm_1 has quit IRC
 75 2015-11-25T04:26:09  *** arowser has quit IRC
 76 2015-11-25T04:26:34  *** arowser has joined #bitcoin-core-dev
 77 2015-11-25T04:27:02  *** mm_1 has joined #bitcoin-core-dev
 78 2015-11-25T04:28:15  <phantomcircuit> tulip, ha
 79 2015-11-25T04:28:25  <tulip> the blown up ping?
 80 2015-11-25T04:28:26  <phantomcircuit> i knew that someone would show up having seen that in production
 81 2015-11-25T04:28:36  <phantomcircuit> "production"
 82 2015-11-25T04:28:54  <phantomcircuit> there's lots of things using wall clock time that should be using monotonic time
 83 2015-11-25T04:29:07  <phantomcircuit> but i think for now it's better to explode than to silently do crazy things
 84 2015-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
 85 2015-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)
 86 2015-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!)
 87 2015-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.
 88 2015-11-25T04:34:02  <gmaxwell> cfields_:  perhaps? :P (I forget if we look at the source netgroup)
 89 2015-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.
 90 2015-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.
 91 2015-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.
 92 2015-11-25T04:40:11  *** PRab has joined #bitcoin-core-dev
 93 2015-11-25T04:40:55  <phantomcircuit> gmaxwell, agreed, but we would definitely want to review everywhere that GetTime* is used before changing their behavior
 94 2015-11-25T04:41:09  <phantomcircuit> but a simple find/replace to GetMonotonicTime
 95 2015-11-25T04:41:31  <phantomcircuit> or maybe just change GetTime to be monotonic and add GetWallclockTime
 96 2015-11-25T04:41:41  <phantomcircuit> which could keep the assert
 97 2015-11-25T04:43:01  <phantomcircuit> either way i think exploding all over the place is the best option for something doable right now today
 98 2015-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. :)
 99 2015-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.
100 2015-11-25T04:46:35  <cfields_> gmaxwell: not sure what you mean about reordering?
101 2015-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.
102 2015-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.
103 2015-11-25T04:47:34  <cfields_> gmaxwell: oh, you mean re-querying with existing addrman data?
104 2015-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.
105 2015-11-25T04:48:20  <cfields_> gmaxwell: roger, and agreed.
106 2015-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.
107 2015-11-25T04:49:16  <cfields_> so there's more motivation than just "that looks weird"
108 2015-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.
109 2015-11-25T04:49:39  <gmaxwell> cfields_: fantastic.
110 2015-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)
111 2015-11-25T04:50:25  <phantomcircuit> gmaxwell, static int64_t first_time; int64_t now = monotonic_time - first_time + 1;
112 2015-11-25T04:50:25  <phantomcircuit> ?
113 2015-11-25T04:50:43  <phantomcircuit> basically always start at 1
114 2015-11-25T04:51:02  <gmaxwell> phantomcircuit: actually on most systems the monotone clocks starts at 0 at boot.
115 2015-11-25T04:51:07  <phantomcircuit> oh
116 2015-11-25T04:51:11  <phantomcircuit> then *shrug*
117 2015-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 :)
118 2015-11-25T04:52:10  * gmaxwell looks at x86 virtual address space usage
119 2015-11-25T04:52:12  <gmaxwell> :(
120 2015-11-25T04:52:14  <gmaxwell> -3
121 2015-11-25T04:52:16  <gmaxwell> :)
122 2015-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.
123 2015-11-25T04:53:10  * cfields_ calls shotgun on at least one freed up thread for async block handling of some kind
124 2015-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).
125 2015-11-25T04:56:01  <phantomcircuit> gmaxwell, oh you mean the adjusted network time thingie?
126 2015-11-25T04:56:30  <gmaxwell> yup yup.
127 2015-11-25T04:59:17  <phantomcircuit> hmm yeah that makes sense
128 2015-11-25T04:59:31  <phantomcircuit> and then finangle that such that it's monotonic unless something crazy happens
129 2015-11-25T05:00:55  <gmaxwell> well the network time should be monotone except for steps, and we should probably log steps.
130 2015-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.
131 2015-11-25T05:11:10  <CodeShark> we have such poor temporal resolution anyhow - ultimately consensus is about well-ordering of events
132 2015-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.
133 2015-11-25T05:16:26  <CodeShark> was that part of an earlier discussion here? (scrolling back)
134 2015-11-25T05:16:48  <tulip> yes, and #7094
135 2015-11-25T05:19:01  <CodeShark> why were signed ints used for timestamps in the first place?
136 2015-11-25T05:19:03  <CodeShark> :)
137 2015-11-25T05:19:38  <CodeShark> what's the 300 thousand year pingtime?
138 2015-11-25T05:20:39  <tulip> https://github.com/bitcoin/bitcoin/pull/7094#issuecomment-159487966
139 2015-11-25T05:20:47  <phantomcircuit> CodeShark, his clock went backwards or something insane
140 2015-11-25T05:20:52  <phantomcircuit> oh no i know
141 2015-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)
142 2015-11-25T05:21:04  <phantomcircuit> his clock started at 1970-1-1 and jumped to the current time
143 2015-11-25T05:21:07  <phantomcircuit> or something like that
144 2015-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.
145 2015-11-25T05:21:51  <CodeShark> hah
146 2015-11-25T05:22:03  <phantomcircuit> so many comical possibilities!
147 2015-11-25T05:22:06  <phantomcircuit> :)
148 2015-11-25T05:22:20  <phantomcircuit> gmaxwell, are there systems where the monotonic clock will wrap?
149 2015-11-25T05:22:28  <gmaxwell> because people have the expectation that time does not flow backwards and write software accordingly.
150 2015-11-25T05:22:33  <phantomcircuit> i'd like to think the kernel detects that and helps you out but...
151 2015-11-25T05:23:00  <gmaxwell> phantomcircuit: the monotone clock returned by the OS should be cleaned of any vulgar hardware weirdness.
152 2015-11-25T05:23:06  <gmaxwell> If it doesn't, we're allowed to fail. :)
153 2015-11-25T05:23:20  <phantomcircuit> fail catastrophically? "your clock is broken"
154 2015-11-25T05:23:24  <phantomcircuit> heh
155 2015-11-25T05:23:25  <gmaxwell> (it's pretty easy to unwrap a monotone clock!)
156 2015-11-25T05:23:59  <phantomcircuit> gmaxwell, as long as you're polling more frequently than the wrap interval yes
157 2015-11-25T05:23:59  <gmaxwell> (so long as you know its period and poll it at least twice per cycle )
158 2015-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.
159 2015-11-25T05:25:34  <phantomcircuit> yup
160 2015-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.
161 2015-11-25T05:26:04  <gmaxwell> or discard negative values before they get that far. :)
162 2015-11-25T05:27:32  <phantomcircuit> gmaxwell, ok now i can see the need for negative values
163 2015-11-25T05:27:34  <phantomcircuit> :P
164 2015-11-25T05:29:40  <CodeShark> why do we care about the other node's clock when doing a ping?
165 2015-11-25T05:31:03  <tulip> it's the network time thing.
166 2015-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.
167 2015-11-25T05:39:22  *** blur3d has quit IRC
168 2015-11-25T05:53:33  <gmaxwell> CodeShark: we don't know _anything_ about the other nodes clock when doing a ping.
169 2015-11-25T05:53:44  <gmaxwell> CodeShark: it's not the other nodes clock at all.
170 2015-11-25T05:54:07  <gmaxwell> GetTime() is not monotone. It can go back.  Time_ping_returned-Time_ping_sent can be negative.
171 2015-11-25T05:55:09  <CodeShark> time_t now = time(NULL); - how can that go back unless the user's system clock gets changed?
172 2015-11-25T05:55:31  <tulip> NTP will change the system clock backwards if it needs to.
173 2015-11-25T05:55:38  <CodeShark> oh, ok
174 2015-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?
175 2015-11-25T05:57:09  <gmaxwell> yes, you ask the system for a monotone clock.
176 2015-11-25T05:58:36  <CodeShark> is that part of the time.h library?
177 2015-11-25T05:59:06  <CodeShark> I guess there's the timer stuff
178 2015-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).
179 2015-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
180 2015-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; }
181 2015-11-25T06:05:29  <gmaxwell> sweet now GetTime() needs to take a lock. :P
182 2015-11-25T06:05:50  <CodeShark> yeah, it's not thread-safe...but we'll pretend we didn't notice ;)
183 2015-11-25T06:06:22  <CodeShark> how often does it get called, though?
184 2015-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. :)
185 2015-11-25T06:06:43  <gmaxwell> CodeShark: all over the place, used for benchmarking stuf, yadda yadda (esp the microseconds version)
186 2015-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
187 2015-11-25T06:10:12  <CodeShark> I mean, the monotonicity ceases to be meaningful in a concurrent setting
188 2015-11-25T06:10:55  <CodeShark> in general we cannot say which of two calls on two separate threads occurred first without using a lock
189 2015-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.
190 2015-11-25T06:11:53  <CodeShark> right
191 2015-11-25T06:12:22  <CodeShark> in that particular use case, though, a lock doesn't seem like the bottleneck
192 2015-11-25T06:13:28  <CodeShark> in any case, we can just zero all negative diffs and basically achieve the same goal :)
193 2015-11-25T06:13:44  <tulip> that would ruin the "minping" statistic
194 2015-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"
195 2015-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?
196 2015-11-25T06:15:07  <cfields_> er, everyone^^. No clue why that was directed at gmaxwell :p
197 2015-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
198 2015-11-25T06:17:19  <gmaxwell> The purpose of the nonce isn't so much for ordering, its to prevent faking a fast response.
199 2015-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. :)
200 2015-11-25T06:18:59  <gmaxwell> tulip: yea, thats why I said discard above.
201 2015-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.
202 2015-11-25T06:21:26  <cfields_> re nonce: point taken
203 2015-11-25T06:23:09  <gmaxwell> cfields_: close by is best measured by the minimum.
204 2015-11-25T06:23:32  <gmaxwell> (or minimum with periodic forgetting if you're concerned about it changing.)
205 2015-11-25T06:27:16  <cfields_> gmaxwell: makes sense i guess. assuming you've stuck around long enough for a good minimum :)
206 2015-11-25T06:47:34  <phantomcircuit> gmaxwell, atomics horray
207 2015-11-25T06:47:39  <phantomcircuit> compare_and_swap
208 2015-11-25T07:16:17  <Luke-Jr> gmaxwell: bool races are unsafe?
209 2015-11-25T07:23:23  <phantomcircuit> Luke-Jr, yes
210 2015-11-25T07:23:31  <phantomcircuit> Luke-Jr, dont tell ckpool
211 2015-11-25T07:23:35  <phantomcircuit> it's funnier this way
212 2015-11-25T07:23:48  <Luke-Jr> what could possibly go wrong in a bool race? :/
213 2015-11-25T07:24:17  <phantomcircuit> Luke-Jr, overwrite a random byte of memory with garbage?
214 2015-11-25T07:24:40  <Luke-Jr> that'd be a pointer race?
215 2015-11-25T07:25:06  <phantomcircuit> Luke-Jr, clever compilers doing clever optimizations have the same effect potentially
216 2015-11-25T07:25:22  <Luke-Jr> real-world optimizations?
217 2015-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..
218 2015-11-25T07:26:34  <Luke-Jr> well, except if for the volatile keyword..
219 2015-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."
220 2015-11-25T07:35:40  <Luke-Jr> hmm, I wouldn't think that is allowed if it's volatile
221 2015-11-25T07:38:19  <gmaxwell> Volitile should prevent that; though volitile is frequently misimplemented.
222 2015-11-25T07:40:35  *** randy-waterhouse has quit IRC
223 2015-11-25T07:41:32  *** randy-waterhouse has joined #bitcoin-core-dev
224 2015-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
225 2015-11-25T07:47:24  *** Ylbam has joined #bitcoin-core-dev
226 2015-11-25T07:48:48  <gmaxwell> oh your stabbing is just right.
227 2015-11-25T07:48:51  <gmaxwell> :)
228 2015-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
229 2015-11-25T07:58:46  <wumpus> and now the code is running into trouble with newer OpenSSLs
230 2015-11-25T08:05:46  <GitHub144> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b19fe277dd62...26af1ac7cbce
231 2015-11-25T08:05:47  <GitHub144> bitcoin/master ae98388 Jonas Schnelli: [Qt] add startup option to reset Qt settings
232 2015-11-25T08:05:47  <GitHub144> bitcoin/master f71bfef Jonas Schnelli: add UI help for -resetguisettings
233 2015-11-25T08:05:48  <GitHub144> bitcoin/master 26af1ac Jonas Schnelli: Merge pull request #7006...
234 2015-11-25T08:05:53  *** Thireus has quit IRC
235 2015-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
236 2015-11-25T08:08:42  *** randy-waterhouse has quit IRC
237 2015-11-25T08:10:13  <jonasschnelli> hmm.... testing coinjoin and QT. Question:
238 2015-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?
239 2015-11-25T08:11:52  <jonasschnelli> I expect only the relevant in/outs should be listed/calculated for the net?
240 2015-11-25T08:13:14  <gmaxwell> It displays the coins that weren't yours as negative fee.
241 2015-11-25T08:13:29  <gmaxwell> Which is ... internally consistent though a little confusing when you're not expecting it.
242 2015-11-25T08:15:14  <wumpus> ah yes the negative fees when you don't own all inputs, that's not just a qt issue
243 2015-11-25T08:16:15  <jonasschnelli> Yes. Listtransactions tell me now:  "fee": 49.98000000
244 2015-11-25T08:17:14  <gmaxwell> It's logical in a sense, but hah. can be a real heart stopper.
245 2015-11-25T08:17:24  <jonasschnelli> haha... right.
246 2015-11-25T08:17:34  <wumpus> hehe indeed
247 2015-11-25T08:17:38  <gmaxwell> FWIW, if I had champaign or really drank, I would have poped a cork at that issue being opened.
248 2015-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'!
249 2015-11-25T08:18:41  <jonasschnelli> Indeed. At it was reported by two users (independent) within 1.5 month...
250 2015-11-25T08:18:46  <wumpus> it is good to see people actually using coinjoin, absolutely!
251 2015-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!)
252 2015-11-25T08:19:46  <gmaxwell> (reporting it all as fee might actually be the best we can do with the data available)
253 2015-11-25T08:20:24  <wumpus> can we 'see' that something fishy is happening and flag the transaction as 'probably coinjoin',?
254 2015-11-25T08:20:34  <wumpus> that'd at least help with the UI aspect a bit
255 2015-11-25T08:20:36  *** dcousens has quit IRC
256 2015-11-25T08:21:07  <gmaxwell> yes, well if there are inputs from outside the wallet we can just flag it as "used outside funds"
257 2015-11-25T08:21:31  <gmaxwell> Or "used outside funds (coinjoin? lighthouse?)"
258 2015-11-25T08:21:33  <wumpus> e.g. "you may be seeing exorbitant fees on this transaction because it involves foreign inputs"
259 2015-11-25T08:21:38  <wumpus> right
260 2015-11-25T08:22:04  <gmaxwell> well they're the opposite of exorbitant. :P
261 2015-11-25T08:22:28  <wumpus> negative exorbitant :p
262 2015-11-25T08:22:54  <gmaxwell> "exuberant fees"
263 2015-11-25T08:22:56  <wumpus> people may not see the sign correctly, but agreed
264 2015-11-25T08:23:00  <wumpus> LOL!
265 2015-11-25T08:23:12  <gmaxwell> yea, it freaked me out the first time.
266 2015-11-25T08:23:34  <gmaxwell> well actually not the first but the first time I did a CJ with an ordinary amount of coin.
267 2015-11-25T08:25:28  <gmaxwell> I wasn't likely to mistake this for a too high fee error:
268 2015-11-25T08:25:30  <gmaxwell>     "fee": 50000.31337000,
269 2015-11-25T08:25:38  <gmaxwell> (this is not output from a testnet wallet)
270 2015-11-25T08:25:40  <wumpus> whoa
271 2015-11-25T08:27:09  <gmaxwell> but later a 10BTC one startled me I think.
272 2015-11-25T08:27:34  <wumpus> was that the 'link yourself rich' or something transaction from bitcoin talk?
273 2015-11-25T08:27:49  <wumpus> e.g. the first coinjoin experiment
274 2015-11-25T08:28:02  *** paveljanik has quit IRC
275 2015-11-25T08:29:36  <gmaxwell> https://bitcointalk.org/index.php?topic=139581.0
276 2015-11-25T08:30:05  <gmaxwell> It works, FWIW, lots of wallet tracker things think that address is all kinds of stuff.
277 2015-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.
278 2015-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 :)
279 2015-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.
280 2015-11-25T08:32:58  *** raedah has joined #bitcoin-core-dev
281 2015-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. :(
282 2015-11-25T08:35:06  <wumpus> is it 'contaminated'?
283 2015-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)
284 2015-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.
285 2015-11-25T08:38:32  <gmaxwell> actually checking, three of them, how'd that one get linked. :-/
286 2015-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 :)
287 2015-11-25T08:42:19  <tulip> has anybody tested -blocksonly with dynamic fees?
288 2015-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.
289 2015-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.
290 2015-11-25T08:43:13  <gmaxwell> the results surprised me too, but they go away if you delete the saved stats file.
291 2015-11-25T08:43:41  <tulip> ah good call.
292 2015-11-25T08:44:10  <tulip> maybe they should just be hard wired to -1 with blocksonly?
293 2015-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.
294 2015-11-25T08:47:52  <gmaxwell> but perhaps it should be hardwired -1 when the mempool is totally empty?
295 2015-11-25T08:48:18  <tulip> right, ok.
296 2015-11-25T08:49:05  <gmaxwell> the goal with the saved state is to give useful resutlts as soon as you start.
297 2015-11-25T08:49:28  <tulip> I'd completely forgot it exists, that's all.
298 2015-11-25T09:00:34  *** paveljanik has joined #bitcoin-core-dev
299 2015-11-25T09:00:43  *** paveljanik has quit IRC
300 2015-11-25T09:02:26  <GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26af1ac7cbce...348b281f8a67
301 2015-11-25T09:02:27  <GitHub102> bitcoin/master 392d3c5 Cory Fields: build: Set osx permissions in the dmg to make Gatekeeper happy
302 2015-11-25T09:02:27  <GitHub102> bitcoin/master 348b281 Wladimir J. van der Laan: Merge pull request #7092...
303 2015-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
304 2015-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
305 2015-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.
306 2015-11-25T09:08:01  <gmaxwell> hm. I didn't even see #7089 but yes.
307 2015-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)
308 2015-11-25T09:09:20  <jonasschnelli> But i agree with him. It causes big pain for HWW devs to trustworthy validate fees (=input amounts).
309 2015-11-25T09:09:28  <gmaxwell> Oh absolutely.
310 2015-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.
311 2015-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.
312 2015-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.
313 2015-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
314 2015-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.
315 2015-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.
316 2015-11-25T09:13:32  <wumpus> indeed it signs the scriptpubkey, and that doesn't help verifying the amount
317 2015-11-25T09:14:02  <wumpus> sure, a hardfork for that is stupid
318 2015-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.
319 2015-11-25T09:19:51  <gmaxwell> lol oh boy. fortunately BIP constrains the transaction version number.
320 2015-11-25T09:19:56  <gmaxwell> er that BIP.
321 2015-11-25T09:20:02  <gmaxwell> tulip: thanks for noticing that. :(
322 2015-11-25T09:27:26  <tulip> might be problematic if miners using this software just flip forward the version number though.
323 2015-11-25T09:28:00  *** davec has quit IRC
324 2015-11-25T09:28:41  *** davec has joined #bitcoin-core-dev
325 2015-11-25T09:31:43  <wumpus> flipping forward the version number like people click 'OK' on software's terms and conditions
326 2015-11-25T09:39:08  <jonasschnelli> hmm... testing wallet.py over the GUI makes the test fail.
327 2015-11-25T09:39:17  <jonasschnelli> It looks like that self.nodes[2].settxfee(Decimal('0.001')) has no effect
328 2015-11-25T09:39:35  <jonasschnelli> Assertion failed: 89.99977400 != 89.99900000
329 2015-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
330 2015-11-25T09:42:04  <sipa> that seems weird...
331 2015-11-25T09:43:35  <jonasschnelli> maybe this is related to the fPayAtLeastCustomFee
332 2015-11-25T09:44:06  <wumpus> the GUI at least used to hook into fee decisions
333 2015-11-25T09:44:29  * wumpus checks ui_interface
334 2015-11-25T09:45:00  <gmaxwell> jonasschnelli: I suppose this is why it's important to test for impossible outcomes!
335 2015-11-25T09:45:53  <wumpus> ok, seems no longer the case
336 2015-11-25T09:46:14  <wumpus> neither ui_interface or the signals on CWallet itself have anything to do with determining fees
337 2015-11-25T09:47:27  <wumpus> maybe a race condition as the UI gives some background load
338 2015-11-25T09:47:59  <jonasschnelli> hmm... CreateTransaction repots a payTxFee=22600 after calling settxfee(Decimal('0.001')).
339 2015-11-25T09:52:54  <wumpus> maybe coin control interfering? or some settings from QSettings?
340 2015-11-25T09:52:59  *** arowser has quit IRC
341 2015-11-25T09:53:16  *** jcorgan has quit IRC
342 2015-11-25T09:53:27  *** arowser has joined #bitcoin-core-dev
343 2015-11-25T09:53:54  *** neha has quit IRC
344 2015-11-25T09:53:56  <wumpus> ideally the GUI should have an 'ignore QSettings' option for tests
345 2015-11-25T09:54:00  *** jcorgan has joined #bitcoin-core-dev
346 2015-11-25T09:54:00  *** jcorgan has joined #bitcoin-core-dev
347 2015-11-25T09:54:02  *** neha has joined #bitcoin-core-dev
348 2015-11-25T09:54:34  *** Madars has quit IRC
349 2015-11-25T09:56:42  *** Madars has joined #bitcoin-core-dev
350 2015-11-25T10:29:25  *** BashCo has joined #bitcoin-core-dev
351 2015-11-25T10:31:54  *** andytoshi has quit IRC
352 2015-11-25T10:32:18  <GitHub53> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/348b281f8a67...2b2ddc558e1c
353 2015-11-25T10:32:19  <GitHub53> bitcoin/master 5ad5463 MarcoFalke: Squashed 'src/secp256k1/' changes from 2bfb82b..6c527ec...
354 2015-11-25T10:32:19  <GitHub53> bitcoin/master fa63e49 MarcoFalke: Merge commit '5ad54630935d1f340666de7bc9ffef9b8a1df296' into HEAD
355 2015-11-25T10:32:20  <GitHub53> bitcoin/master 2b2ddc5 Wladimir J. van der Laan: Merge pull request #7088...
356 2015-11-25T10:32:25  <jonasschnelli> found the problematic UI interaction that interferes the RPC server.
357 2015-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
358 2015-11-25T10:32:34  <jonasschnelli> void SendCoinsDialog::updateGlobalFeeVariables()  ---> fSendFreeTransactions = ui->checkBoxFreeTx->isChecked()
359 2015-11-25T10:32:41  <jonasschnelli> Gets called when the GUI starts
360 2015-11-25T10:33:09  <jonasschnelli> sorry... not fSendFreeTransactions , i meant instead: fPayAtLeastCustomFee = ui->radioCustomAtLeast->isChecked();
361 2015-11-25T10:33:15  <wumpus> good catch
362 2015-11-25T10:33:24  <wumpus> phew, at least not a race condition!
363 2015-11-25T10:41:20  *** andytoshi has joined #bitcoin-core-dev
364 2015-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
365 2015-11-25T11:22:26  *** Thireus has joined #bitcoin-core-dev
366 2015-11-25T11:31:59  *** andytoshi has quit IRC
367 2015-11-25T11:36:09  <jonasschnelli> wumpus: I though the same. The UI should not connect globals vars with radio-buttons, etc.
368 2015-11-25T11:36:27  <wumpus> managed to avoid that with coin control, but apparently some did sneak in
369 2015-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)
370 2015-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?!
371 2015-11-25T11:39:19  <wumpus> it's per kB afaik
372 2015-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
373 2015-11-25T11:40:28  <jonasschnelli> I just created a transaction on regtest after calling "settxfee 0.001" ... gettransaction tells me: "fee": -0.00100000
374 2015-11-25T11:41:13  <jonasschnelli> hexlen 384 = 192 bytes = a expected fee of 0.000192
375 2015-11-25T11:41:26  <wumpus> it assumes rounding?
376 2015-11-25T11:42:05  <sipa>     if (fPayAtLeastCustomFee && nFeeNeeded > 0 && nFeeNeeded < payTxFee.GetFeePerK())
377 2015-11-25T11:42:07  <sipa>         nFeeNeeded = payTxFee.GetFeePerK();
378 2015-11-25T11:42:08  <jonasschnelli> no. settxfee to 0.01 resuls in a transaction with fee "fee": -0.01000000
379 2015-11-25T11:42:11  <sipa> ^ that looks complete broken
380 2015-11-25T11:42:29  <sipa> payTxFee is treated as a minimum, absolute, fee for a transaction
381 2015-11-25T11:42:48  <jonasschnelli> right... this needs fixing.
382 2015-11-25T11:43:16  <sipa> what is this "payatleastcustomfee" ?
383 2015-11-25T11:43:43  <sipa> the comment says "user selected total at least"
384 2015-11-25T11:43:48  <sipa> so this is clearly intentional
385 2015-11-25T11:44:28  <jonasschnelli> Right. But fPayAtLeastCustomFee = true by default.
386 2015-11-25T11:44:34  <jonasschnelli> Which makes by default every fee absolute?
387 2015-11-25T11:44:43  <jonasschnelli> and the only way to change fPayAtLeastCustomFee is over the GUI?
388 2015-11-25T11:44:51  <sipa> ... yup
389 2015-11-25T11:44:54  <jonasschnelli> hah
390 2015-11-25T11:45:01  *** MarcoFalke has joined #bitcoin-core-dev
391 2015-11-25T11:45:10  <jonasschnelli> i think we should review https://github.com/bitcoin/bitcoin/pull/6708
392 2015-11-25T11:45:17  <sipa> from within the coin control dialog
393 2015-11-25T11:45:32  <sipa> so it makes sense that from without coincontrol you're able to set the absolute fee
394 2015-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
395 2015-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.
396 2015-11-25T11:47:06  <sipa> well it being set to true by default is broken
397 2015-11-25T11:47:20  <sipa> and it can only be unset through the coincontrol gui
398 2015-11-25T11:47:51  <jonasschnelli> okay. will work on a fix.
399 2015-11-25T11:47:57  <jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK(); // <--- is a dirty hack!
400 2015-11-25T11:48:58  <jonasschnelli> but i see, that an absolute fee can help (during RPC tests and maybe some other usecases).
401 2015-11-25T11:49:16  <jonasschnelli> What about adding an option to set absolute fees over "settxfee"?
402 2015-11-25T11:49:29  <sipa> makes no sense
403 2015-11-25T11:49:33  <sipa> without coin control
404 2015-11-25T11:49:49  <jonasschnelli> It only makes sense for regression tests.
405 2015-11-25T11:50:00  <sipa> and if you're doing selection manually (via createrawtransaction), there is no need for it
406 2015-11-25T11:50:02  <jonasschnelli> to deterministic calculate fees
407 2015-11-25T11:50:22  <sipa> well if it's exposed by RPC it is necessarily global
408 2015-11-25T11:50:26  <sipa> (for RPC)
409 2015-11-25T11:50:50  <sipa> let's first fix the use case, then the rest?
410 2015-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
411 2015-11-25T11:53:02  *** andytoshi has joined #bitcoin-core-dev
412 2015-11-25T11:54:22  <sipa> jonasschnelli: i'm writing a fix
413 2015-11-25T11:54:35  <jonasschnelli> sipa: okay.. nice.
414 2015-11-25T11:54:47  <jonasschnelli> I'll fix the UI stuff.
415 2015-11-25T11:55:09  <jonasschnelli> Need to drop the absolut fee option for "non-coincontrol" transactions
416 2015-11-25T11:56:22  * jonasschnelli needs to go back to the thing he was actually working on, "CoinJoin transactions display"
417 2015-11-25T11:59:29  <sipa> oh, there is a nCustomFeeRadio set from the send dialog
418 2015-11-25T11:59:36  <MarcoFalke> jonasschnelli, are you working on the https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 thing?
419 2015-11-25T11:59:39  <sipa> sorry, this will need gui hackery
420 2015-11-25T11:59:48  <MarcoFalke> Didn't catch that, so we are not duplicating effort
421 2015-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.
422 2015-11-25T12:00:33  <jonasschnelli> Then i'd like to address the UI stuff
423 2015-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
424 2015-11-25T12:01:15  <MarcoFalke> sipa, to fix https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 ?
425 2015-11-25T12:01:18  <sipa> then the setting can just be passed via the coincontrol settings object, which is trivial
426 2015-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
427 2015-11-25T12:02:25  <sipa> why was this introduced?
428 2015-11-25T12:02:35  <jonasschnelli> sipa: right. It should be in the CC dialog.
429 2015-11-25T12:02:57  <jonasschnelli> <sipa>	why was this introduced? / you mean the "pay at least total"? Probably together with Cozzes CC stuff?
430 2015-11-25T12:03:14  <MarcoFalke> Yes it's by cozz
431 2015-11-25T12:03:55  <sipa> so nobody ever noticed that this makes bitcoin core's transaction pay around 4x too much fee by default?
432 2015-11-25T12:04:15  <jonasschnelli> sipa: hah. I assume "no"!.. scary!
433 2015-11-25T12:04:28  <sipa> oh, i assume paytxfee was 0 by default, so it didn't have any effect
434 2015-11-25T12:04:33  * jonasschnelli thinks Cozz was payed by the miners... :)
435 2015-11-25T12:04:49  <jonasschnelli> sipa: right. This is a point.
436 2015-11-25T12:05:07  <sipa> jonasschnelli: see my betterabsolute branch
437 2015-11-25T12:05:16  <sipa> jonasschnelli: sorry, i thought i could do more, but there rest is gui code
438 2015-11-25T12:05:20  <MarcoFalke> I haven't checked previous code but it may be to mimick how earlier version have done that.
439 2015-11-25T12:05:34  <MarcoFalke> Was this "let's use round numbers for fees" a thing back then?
440 2015-11-25T12:05:44  <sipa> right, i think until some time in the past, we always paid per kilobyte started
441 2015-11-25T12:05:44  <jonasschnelli> sipa: np. I'm happy to take over.
442 2015-11-25T12:05:50  <sipa> not per byte
443 2015-11-25T12:05:51  <sipa> jonasschnelli: thanks!
444 2015-11-25T12:18:58  <MarcoFalke> sipa, should I rebase onto betterabsolute?
445 2015-11-25T12:19:46  <MarcoFalke> or wait until the gui is fixed
446 2015-11-25T12:20:07  <sipa> MarcoFalke: up to jonasschnelli
447 2015-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.
448 2015-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
449 2015-11-25T12:26:54  *** guest234234 has joined #bitcoin-core-dev
450 2015-11-25T12:29:20  <MarcoFalke> wumpus, is https://github.com/bitcoin/bitcoin/pull/527/files#diff-e2b7ef544fda33841c06f443b2cab6b3 still relevant for gitian?
451 2015-11-25T12:29:48  <wumpus> MarcoFalke: no
452 2015-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
453 2015-11-25T12:31:02  <MarcoFalke> But the folder is used to store the pgp keys?
454 2015-11-25T12:31:18  <wumpus> yes, just a convention
455 2015-11-25T12:32:02  <wumpus> the download-configs are pointless
456 2015-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
457 2015-11-25T12:34:42  <MarcoFalke> Just doing this with my next trvial pull
458 2015-11-25T13:05:11  <MarcoFalke> Oh, that's why travis is only running with 3/5 speed.
459 2015-11-25T13:05:13  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92025728
460 2015-11-25T13:05:18  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684
461 2015-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
462 2015-11-25T13:25:18  *** BashCo has quit IRC
463 2015-11-25T13:25:50  *** BashCo has joined #bitcoin-core-dev
464 2015-11-25T13:26:51  *** tulip has quit IRC
465 2015-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
466 2015-11-25T13:32:33  *** MarcoFalke has quit IRC
467 2015-11-25T13:36:36  *** jgarzik has quit IRC
468 2015-11-25T13:53:26  *** BashCo has quit IRC
469 2015-11-25T13:53:50  *** BashCo has joined #bitcoin-core-dev
470 2015-11-25T13:55:05  *** BashCo has quit IRC
471 2015-11-25T13:55:42  *** BashCo has joined #bitcoin-core-dev
472 2015-11-25T13:57:10  *** BashCo has quit IRC
473 2015-11-25T13:57:38  *** BashCo has joined #bitcoin-core-dev
474 2015-11-25T14:02:50  *** guest234234 has quit IRC
475 2015-11-25T14:03:36  *** jgarzik has joined #bitcoin-core-dev
476 2015-11-25T14:03:36  *** jgarzik has joined #bitcoin-core-dev
477 2015-11-25T14:07:00  *** BashCo has quit IRC
478 2015-11-25T14:07:28  *** BashCo has joined #bitcoin-core-dev
479 2015-11-25T14:09:10  *** BashCo has quit IRC
480 2015-11-25T14:09:46  *** BashCo has joined #bitcoin-core-dev
481 2015-11-25T14:14:50  *** Guyver2 has joined #bitcoin-core-dev
482 2015-11-25T14:24:40  *** BashCo_ has joined #bitcoin-core-dev
483 2015-11-25T14:25:21  *** BashCo has quit IRC
484 2015-11-25T14:25:24  *** MarcoFalke has joined #bitcoin-core-dev
485 2015-11-25T14:32:12  *** BashCo_ has quit IRC
486 2015-11-25T14:32:43  *** BashCo has joined #bitcoin-core-dev
487 2015-11-25T14:34:38  *** BashCo has quit IRC
488 2015-11-25T14:34:58  *** BashCo has joined #bitcoin-core-dev
489 2015-11-25T14:37:56  *** BashCo has quit IRC
490 2015-11-25T14:38:07  *** BashCo has joined #bitcoin-core-dev
491 2015-11-25T15:16:13  *** BashCo has joined #bitcoin-core-dev
492 2015-11-25T15:23:51  *** ParadoxSpiral has joined #bitcoin-core-dev
493 2015-11-25T15:39:17  *** MarcoFalke has quit IRC
494 2015-11-25T16:11:59  *** zookolaptop has quit IRC
495 2015-11-25T16:44:03  *** jl2012 has quit IRC
496 2015-11-25T16:44:12  *** jl2012 has joined #bitcoin-core-dev
497 2015-11-25T17:38:54  *** Thireus has quit IRC
498 2015-11-25T17:39:21  *** cocoBTC has joined #bitcoin-core-dev
499 2015-11-25T17:45:55  *** ParadoxSpiral_ has joined #bitcoin-core-dev
500 2015-11-25T17:49:21  *** ParadoxSpiral has quit IRC
501 2015-11-25T17:55:43  *** BashCo has quit IRC
502 2015-11-25T18:11:13  *** cocoBTC has joined #bitcoin-core-dev
503 2015-11-25T18:13:17  *** BashCo has joined #bitcoin-core-dev
504 2015-11-25T18:26:26  *** Ylbam has quit IRC
505 2015-11-25T18:26:45  *** Ylbam has joined #bitcoin-core-dev
506 2015-11-25T19:37:37  *** jtimon has quit IRC
507 2015-11-25T19:48:57  <cfields_> sipa: thoughts on https://github.com/theuni/bitcoin/commit/792b0f5da618ea51ecd7b21db633faa6743c1e68 ?
508 2015-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?
509 2015-11-25T20:52:04  *** belcher has joined #bitcoin-core-dev
510 2015-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
511 2015-11-25T21:04:03  <cfields_> ...that can't be right.
512 2015-11-25T21:08:36  <gmaxwell> oh that bug. damn
513 2015-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.
514 2015-11-25T21:09:16  <cfields_> gmaxwell: so that's actually the case? whoa.
515 2015-11-25T21:09:22  *** Guyver2 has quit IRC
516 2015-11-25T21:09:23  <cfields_> just verified with an addrman dump
517 2015-11-25T21:11:07  <cfields_> gmaxwell: surely it's reasonable to set a net to reachable once a connection has been established on it?
518 2015-11-25T21:12:14  <gmaxwell> I think we should be setting IPv4 reachable if we have any IPv4 bindings at least.
519 2015-11-25T21:12:36  <gmaxwell> and tor reachable if we have a onion proxy configured.
520 2015-11-25T21:13:01  <cfields_> i believe the latter is already done
521 2015-11-25T21:25:30  *** JackH has quit IRC
522 2015-11-25T21:33:32  *** Thireus has joined #bitcoin-core-dev
523 2015-11-25T21:46:54  *** raskolnnikov has quit IRC
524 2015-11-25T21:57:42  *** randy-waterhouse has joined #bitcoin-core-dev
525 2015-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.
526 2015-11-25T22:19:40  *** ParadoxSpiral_ has quit IRC
527 2015-11-25T22:28:13  *** midnightmagic has quit IRC
528 2015-11-25T22:28:45  *** tulip has joined #bitcoin-core-dev
529 2015-11-25T22:34:06  *** midnightmagic has joined #bitcoin-core-dev
530 2015-11-25T22:40:02  *** belcher has quit IRC
531 2015-11-25T22:40:20  *** belcher has joined #bitcoin-core-dev
532 2015-11-25T22:43:23  *** jgarzik has quit IRC
533 2015-11-25T22:52:34  *** cocoBTC has quit IRC
534 2015-11-25T22:57:10  *** Guest66004 has joined #bitcoin-core-dev
535 2015-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
536 2015-11-25T23:18:12  *** Guest66004 has quit IRC
537 2015-11-25T23:18:12  *** Guest66004 has joined #bitcoin-core-dev
538 2015-11-25T23:18:20  *** Guest66004 is now known as jgarzik_
539 2015-11-25T23:24:14  *** asoltys has joined #bitcoin-core-dev
540 2015-11-25T23:26:08  *** randy-waterhouse has quit IRC
541 2015-11-25T23:39:13  *** randy-waterhouse has joined #bitcoin-core-dev
542 2015-11-25T23:59:54  *** jtimon has joined #bitcoin-core-dev