12018-07-30T00:04:44 *** jhfrontz has joined #bitcoin-core-dev
22018-07-30T00:19:10 *** nodweber has joined #bitcoin-core-dev
32018-07-30T00:27:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
42018-07-30T00:31:00 *** davec has quit IRC
52018-07-30T00:36:43 *** Chris_Stewart_5 has quit IRC
62018-07-30T00:50:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
72018-07-30T00:53:46 *** brighton36 has quit IRC
82018-07-30T00:54:40 *** fanquake has joined #bitcoin-core-dev
92018-07-30T01:00:07 <fanquake> I've closed 0.16.2 and opened a new 0.16.x milestone for some new 0.16 backports.
102018-07-30T01:00:50 <fanquake> Also locked the conversation on https://github.com/bitcoin/bitcoin/commit/d2186b3db61a9d4dc2d4a6211573790d9e34bf58#comments, as that's probably carried on long enough.
112018-07-30T01:08:03 <gmaxwell> man, should have locked that right away.
122018-07-30T01:09:02 <gmaxwell> Someday I will invent the devices that allows one to stab someone in the face over the internet, but today is not that day.
132018-07-30T01:13:01 <sipa> killall -SIGECUTE
142018-07-30T01:16:09 *** promag has quit IRC
152018-07-30T01:18:57 *** Lauda has quit IRC
162018-07-30T01:19:35 *** nodweber has quit IRC
172018-07-30T01:24:44 *** murrayn has joined #bitcoin-core-dev
182018-07-30T01:24:52 *** Lauda has joined #bitcoin-core-dev
192018-07-30T01:36:21 *** nodweber has joined #bitcoin-core-dev
202018-07-30T01:40:57 *** nodweber has quit IRC
212018-07-30T01:55:31 *** masonicboom has joined #bitcoin-core-dev
222018-07-30T01:57:16 *** nodweber has joined #bitcoin-core-dev
232018-07-30T01:57:31 *** masonicboom has quit IRC
242018-07-30T02:00:10 *** meshcollider_ has joined #bitcoin-core-dev
252018-07-30T02:01:58 *** nodweber has quit IRC
262018-07-30T02:04:49 *** Chris_Stewart_5 has quit IRC
272018-07-30T02:18:10 *** nodweber has joined #bitcoin-core-dev
282018-07-30T02:22:54 *** nodweber has quit IRC
292018-07-30T02:27:33 *** jhfrontz has quit IRC
302018-07-30T02:39:04 *** nodweber has joined #bitcoin-core-dev
312018-07-30T02:43:49 *** nodweber has quit IRC
322018-07-30T02:50:01 *** masonicboom has joined #bitcoin-core-dev
332018-07-30T02:54:31 *** masonicboom has quit IRC
342018-07-30T02:55:18 *** luke-jr has quit IRC
352018-07-30T02:55:31 *** luke-jr has joined #bitcoin-core-dev
362018-07-30T02:59:59 *** nodweber has joined #bitcoin-core-dev
372018-07-30T03:03:02 *** d9b4bef9 has quit IRC
382018-07-30T03:04:07 *** d9b4bef9 has joined #bitcoin-core-dev
392018-07-30T03:04:33 *** nodweber has quit IRC
402018-07-30T03:05:02 *** d9b4bef9 has quit IRC
412018-07-30T03:06:07 *** d9b4bef9 has joined #bitcoin-core-dev
422018-07-30T03:20:55 *** nodweber has joined #bitcoin-core-dev
432018-07-30T03:25:54 *** nodweber has quit IRC
442018-07-30T03:41:46 *** nodweber has joined #bitcoin-core-dev
452018-07-30T03:46:19 *** nodweber has quit IRC
462018-07-30T04:02:40 *** nodweber has joined #bitcoin-core-dev
472018-07-30T04:07:29 *** nodweber has quit IRC
482018-07-30T04:12:45 <kallewoof> luke-jr: Regarding comment on #13756 -- you say "This doesn't actually fully solve #10065, since transactions received with a dirty address are still shown in the GUI / RPC". Are you referring to the case where someone sends funds to destination X, and then later send funds again to destination X before I spend from X? Why is that a problem? X is not dirty unless I spend from it once, in which case the second send WILL be
492018-07-30T04:12:45 <kallewoof> marked dirty.
502018-07-30T04:12:46 <gribble> https://github.com/bitcoin/bitcoin/issues/10065 | Support not reusing addresses · Issue #10065 · bitcoin/bitcoin · GitHub
512018-07-30T04:12:47 <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: -avoidreuse feature for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
522018-07-30T04:14:44 <kallewoof> Oh wait, you're talking specifically about the GUI/RPC. Yes, I guess this only applies to the coin select algo...
532018-07-30T04:15:36 <sipa> kallewoof: i guess luke-jr wants it to not even treat a second receive at the same address as a valid incoming payment
542018-07-30T04:15:38 <kallewoof> It feels to me like this needs to be split up into multiple PR's to be manageable in size. I wonder what the MVP is for an acceptable merge for people -- a lot of talk is focused on GUI stuff, which I felt would come later.
552018-07-30T04:16:33 <kallewoof> sipa: Yeah. I mean, it won't be, if you use the built in send mechanism since both CLI and QT use the coin selection methods which will exclude these.
562018-07-30T04:17:04 <sipa> kallewoof: i assume he means for listtransactions/getbalance/...
572018-07-30T04:17:16 <kallewoof> Right.
582018-07-30T04:17:22 <sipa> (i have very little opinion about the matter)
592018-07-30T04:18:36 <kallewoof> Maybe I should just make multiple PR's that stack on top of each other. I do intend to address the RPC side of things at least, and perhaps take a stab at QT, but I tend to fail whenever I touch that code.
602018-07-30T04:19:56 *** meshcollider_ has quit IRC
612018-07-30T04:23:31 *** nodweber has joined #bitcoin-core-dev
622018-07-30T04:28:29 *** nodweber has quit IRC
632018-07-30T04:30:41 *** jb55 has joined #bitcoin-core-dev
642018-07-30T04:32:56 *** mdrollette has quit IRC
652018-07-30T04:34:46 *** mdrollette has joined #bitcoin-core-dev
662018-07-30T04:38:37 *** masonicboom has joined #bitcoin-core-dev
672018-07-30T04:43:10 *** masonicboom has quit IRC
682018-07-30T04:44:24 *** nodweber has joined #bitcoin-core-dev
692018-07-30T04:48:15 <luke-jr> kallewoof: yes, multiple steps seems like a good approach
702018-07-30T04:49:00 *** ken2812221 has joined #bitcoin-core-dev
712018-07-30T04:49:19 *** nodweber has quit IRC
722018-07-30T04:55:01 <luke-jr> kallewoof: and "reused" *does* convey it's to be avoided, at least as an internal term (which IMO is all this should be)
732018-07-30T04:56:10 <kallewoof> You mean we should use a different term for the actual user interface? Doesn't that make things unnecessarily confusing?
742018-07-30T04:58:38 <luke-jr> kallewoof: the UI should just show reused transactions as eternally unconfirmed until spent ;)
752018-07-30T04:58:53 <luke-jr> notated somewhere that they won't confirm normally
762018-07-30T04:59:21 <luke-jr> (and perhaps coin selection should actively try to spend them..)
772018-07-30T05:00:45 <kallewoof> Wait, coin selection should try to spend them? I thought the whole idea was that coin selection should never spend them.
782018-07-30T05:01:13 <kallewoof> And eternally unconfirmed sounds like it will result in â questions from people
792018-07-30T05:05:22 *** nodweber has joined #bitcoin-core-dev
802018-07-30T05:10:19 *** nodweber has quit IRC
812018-07-30T05:14:04 *** rodarmor_ is now known as rodarmor
822018-07-30T05:18:25 <gmaxwell> luke-jr: I think showing them as unconfirmed is going to far, especially instantly.
832018-07-30T05:18:43 <gmaxwell> better to first show some warnings on them, this will cause people to complain and change behavior.
842018-07-30T05:20:04 <gmaxwell> kallewoof: there are some cases where they would be okay to spend, e.g. if we can spend them by themselves with no other inputs (esp with no change).
852018-07-30T05:20:34 <gmaxwell> This is with the idea that the main thing we're trying to do is prevent the snowball effect where most of your wallet is linked togeather.
862018-07-30T05:25:09 <kallewoof> Yeah, I was thinking about that before. It seems like you care about privacy differently in different situations. E.g. donations to a charity from a dirty address sounds like a great idea.
872018-07-30T05:26:15 *** nodweber has joined #bitcoin-core-dev
882018-07-30T05:26:48 <kallewoof> Generally, it feels like a 'categorization mechanism' (accounts done right) would be quite useful. Spend A coins together as appropriate. Mix A and B only if funds are lacking, and put resulting change in category B, not A. Etc etc.
892018-07-30T05:30:52 *** nodweber has quit IRC
902018-07-30T05:45:20 <luke-jr> kallewoof: if we never spend them, then they shouldn't be shown at all, or should be shown as conflicted or similar
912018-07-30T05:45:40 <luke-jr> kallewoof: by spending them, we remove the security risk
922018-07-30T05:46:36 <luke-jr> (which is much less than the privacy risk, so perhaps not the prevailing motivation on ideal behaviour here)
932018-07-30T05:47:10 *** nodweber has joined #bitcoin-core-dev
942018-07-30T05:47:30 <kallewoof> I assume this is almost always slightly-above-dust amounts, so the most common scenario will be to simply not touch it, no?
952018-07-30T05:48:02 <kallewoof> It feels odd to proactively try to spend it.
962018-07-30T05:48:03 <luke-jr> dust spam could just be ignored; the cases I'm thinking of are when the sender sends twice
972018-07-30T05:52:02 *** nodweber has quit IRC
982018-07-30T05:54:53 <kallewoof> I'm sort of optimizing for the case where someone is actively trying to track you by purposefully spamming you with tiny outputs so they can see where your coins are going. That seems quite different from what you're talking about..
992018-07-30T05:56:49 <kallewoof> And sounds like the proper reaction is different too. Should the case 'reused, tiny' be treated differently from the case 'reused, non-tiny'? How do you define 'non-tiny'? (Dust threshold * X I guess)..
1002018-07-30T06:04:35 *** windsok has quit IRC
1012018-07-30T06:08:02 *** nodweber has joined #bitcoin-core-dev
1022018-07-30T06:12:45 *** nodweber has quit IRC
1032018-07-30T06:28:59 *** nodweber has joined #bitcoin-core-dev
1042018-07-30T06:33:34 *** nodweber has quit IRC
1052018-07-30T06:43:41 *** atroxes has quit IRC
1062018-07-30T06:49:09 <kallewoof> I am currently adding 'allow_dirty' bools to various methods. Maybe it would make more sense to have a three-option state instead (mixed, clean, dirty), where mixed=ignore dirty state, clean=only dirty=false, dirty=only dirty=true.
1072018-07-30T06:49:53 *** nodweber has joined #bitcoin-core-dev
1082018-07-30T06:50:37 *** harrymm has joined #bitcoin-core-dev
1092018-07-30T06:52:03 *** atroxes has joined #bitcoin-core-dev
1102018-07-30T06:54:24 *** nodweber has quit IRC
1112018-07-30T06:56:01 *** d9b4bef9 has quit IRC
1122018-07-30T06:57:07 *** d9b4bef9 has joined #bitcoin-core-dev
1132018-07-30T06:59:09 *** d9b4bef9 has joined #bitcoin-core-dev
1142018-07-30T06:59:52 *** no_input_found has joined #bitcoin-core-dev
1152018-07-30T07:10:51 *** nodweber has joined #bitcoin-core-dev
1162018-07-30T07:11:31 *** fanquake has quit IRC
1172018-07-30T07:15:05 *** nodweber has quit IRC
1182018-07-30T07:20:37 *** elkalamar has quit IRC
1192018-07-30T07:21:14 *** elkalamar has joined #bitcoin-core-dev
1202018-07-30T07:23:11 *** elkalamar has joined #bitcoin-core-dev
1212018-07-30T07:25:04 *** go1111111 has quit IRC
1222018-07-30T07:28:57 *** bitbee has quit IRC
1232018-07-30T07:29:51 *** bitbee has joined #bitcoin-core-dev
1242018-07-30T07:30:59 *** promag has joined #bitcoin-core-dev
1252018-07-30T07:31:44 *** nodweber has joined #bitcoin-core-dev
1262018-07-30T07:36:40 *** nodweber has quit IRC
1272018-07-30T07:36:49 *** Sentineo has quit IRC
1282018-07-30T07:37:09 *** Sentineo has joined #bitcoin-core-dev
1292018-07-30T07:40:11 *** Guest43893 has joined #bitcoin-core-dev
1302018-07-30T07:40:47 *** go1111111 has joined #bitcoin-core-dev
1312018-07-30T07:41:21 *** elkalamar has quit IRC
1322018-07-30T07:44:58 *** promag has quit IRC
1332018-07-30T07:52:38 *** nodweber has joined #bitcoin-core-dev
1342018-07-30T07:57:31 *** nodweber has quit IRC
1352018-07-30T08:11:06 <Fuzzbawls> Question: (please ping me directly with answer) Given the recent acquisition of GitHub by Microsoft, is a relocation of the bitcoin source code to an alternative platform (like GitLab) being considered at all? If so, has anyone been actively working towards porting the `.travis.yml` file over to an alternative CI provider? I've had mixed results with such a port; some features can be duplicated/represented, and some cannot (like the $TRAVIS_COMMIT
1362018-07-30T08:11:06 <Fuzzbawls> _RANGE and the $TRAVIS_EVENT_TYPE environment variables, for example)
1372018-07-30T08:11:36 *** setpill has joined #bitcoin-core-dev
1382018-07-30T08:13:31 *** nodweber has joined #bitcoin-core-dev
1392018-07-30T08:16:37 *** timothy has joined #bitcoin-core-dev
1402018-07-30T08:17:57 *** nodweber has quit IRC
1412018-07-30T08:23:53 *** Guest43893 has quit IRC
1422018-07-30T08:32:15 *** nodweber has joined #bitcoin-core-dev
1432018-07-30T08:34:42 *** p3tr has joined #bitcoin-core-dev
1442018-07-30T08:34:56 <kallewoof> I have opened #13801 as an alternative, which replaces the dirty flag with a dest_filter=mixed/clean/dirty. More fine grained control, but slightly bigger diff. Will close one or the other based on feedback.
1452018-07-30T08:34:58 <gribble> https://github.com/bitcoin/bitcoin/issues/13801 | wallet: -avoidreuse with destination filters by kallewoof · Pull Request #13801 · bitcoin/bitcoin · GitHub
1462018-07-30T08:37:22 *** promag has joined #bitcoin-core-dev
1472018-07-30T08:57:57 *** SopaXorzTaker has joined #bitcoin-core-dev
1482018-07-30T09:32:08 *** face has quit IRC
1492018-07-30T09:43:27 *** AaronvanW has joined #bitcoin-core-dev
1502018-07-30T09:44:14 *** face has joined #bitcoin-core-dev
1512018-07-30T09:49:40 *** AaronvanW has quit IRC
1522018-07-30T09:50:16 *** AaronvanW has joined #bitcoin-core-dev
1532018-07-30T09:51:59 *** face has quit IRC
1542018-07-30T10:04:51 *** setpill has quit IRC
1552018-07-30T10:06:56 *** setpill has joined #bitcoin-core-dev
1562018-07-30T10:18:17 *** rex4539 has quit IRC
1572018-07-30T10:19:05 *** rex4539 has joined #bitcoin-core-dev
1582018-07-30T10:35:18 *** setpill has quit IRC
1592018-07-30T10:37:24 *** setpill has joined #bitcoin-core-dev
1602018-07-30T10:48:56 *** zivl has quit IRC
1612018-07-30T10:54:30 *** promag has quit IRC
1622018-07-30T10:55:02 *** promag has joined #bitcoin-core-dev
1632018-07-30T10:59:32 *** promag has quit IRC
1642018-07-30T11:01:11 *** face has joined #bitcoin-core-dev
1652018-07-30T11:03:57 *** Empact has quit IRC
1662018-07-30T11:04:50 *** setpill has quit IRC
1672018-07-30T11:05:11 *** setpill has joined #bitcoin-core-dev
1682018-07-30T11:06:44 *** rex4539 has joined #bitcoin-core-dev
1692018-07-30T11:12:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1702018-07-30T11:18:19 <wumpus> I really don't like all these PRs that just brush the code a bit
1712018-07-30T11:19:27 <wumpus> all the diff noise makes it harder to keep track of what is changing, and if it's not a clear win in, say, avoiding a class of bugs, I don't think it's generally worth it
1722018-07-30T11:19:45 <wumpus> it also creates endless motivations to create new PRs
1732018-07-30T11:19:46 <wumpus> please stop it
1742018-07-30T11:19:56 *** setpill has quit IRC
1752018-07-30T11:21:37 *** setpill has joined #bitcoin-core-dev
1762018-07-30T11:30:47 *** zivl has joined #bitcoin-core-dev
1772018-07-30T11:41:02 *** d9b4bef9 has quit IRC
1782018-07-30T11:42:08 *** d9b4bef9 has joined #bitcoin-core-dev
1792018-07-30T11:44:37 *** masonicboom has joined #bitcoin-core-dev
1802018-07-30T11:49:02 *** masonicboom has quit IRC
1812018-07-30T11:53:27 *** face has quit IRC
1822018-07-30T11:56:11 *** Chris_Stewart_5 has quit IRC
1832018-07-30T12:06:45 *** fanquake has joined #bitcoin-core-dev
1842018-07-30T12:07:10 <fanquake> wumpus I think I agree.
1852018-07-30T12:07:51 <fanquake> There are quite a PRs with feedback/questions being left outstanding while new PRs are continually being opened (by the same author etc).
1862018-07-30T12:08:20 <wumpus> fanquake: thanks; I mean it's obviously not black and white, some changes make more sense than others, but sometimes it looks like they're just being dished out for the sake of making changes
1872018-07-30T12:10:03 <wumpus> say, #13770
1882018-07-30T12:10:05 <gribble> https://github.com/bitcoin/bitcoin/issues/13770 | Use explicit captures in lambda expressions by practicalswift · Pull Request #13770 · bitcoin/bitcoin · GitHub
1892018-07-30T12:10:24 <wumpus> I mean I'm sure there's arguments for it, but shouldn't that first be discussed, then maybe added tothe code style for *new code*
1902018-07-30T12:10:58 <wumpus> not just roll over the entire code, out of the blue, and change something that we weren't even aware about before
1912018-07-30T12:11:29 <fanquake> Yea. This one was sort of similar #13795.
1922018-07-30T12:11:30 <gribble> https://github.com/bitcoin/bitcoin/issues/13795 | build: Add missing [[noreturn]] to handleRunawayException(...). Enable -Wsuggest-attribute=noreturn if available. by practicalswift · Pull Request #13795 · bitcoin/bitcoin · GitHub
1932018-07-30T12:11:40 <wumpus> yes
1942018-07-30T12:11:47 <fanquake> No feature/build flag I hadn't really seen before. One build failures, and it gets closed with no more discussion?
1952018-07-30T12:11:52 <fanquake> *A feature..
1962018-07-30T12:12:50 <fanquake> Surely at least some followup or an explanation of what didn't work would be handy, even just for a future PR which might try doing the same thing.
1972018-07-30T12:17:26 <wumpus> the problem is that everyone is overworked, let's avoid creating unnecessary work out of the blue
1982018-07-30T12:17:48 <wumpus> that's basically my entire criticism
1992018-07-30T12:19:44 <fanquake> Yep, that's a fair call.
2002018-07-30T12:20:03 <fanquake> It's kinda felt like the repo has been "slowing down", over the past month or two
2012018-07-30T12:20:21 <fanquake> If not a longer period than that
2022018-07-30T12:20:42 <wumpus> I'm not sure that is true
2032018-07-30T12:24:46 <fanquake> Maybe it's just the fact that there is a lot of different work going on that makes it harder to gauge progress
2042018-07-30T12:26:16 <wumpus> sorry: https://github.com/bitcoin/bitcoin/pull/13770#issuecomment-408845832
2052018-07-30T12:28:38 <fanquake> The point of applying to new code is good. We've seen continual cases of follow up changes/fixing things up "just after" they were merged.
2062018-07-30T12:29:41 <wumpus> right!
2072018-07-30T12:39:12 *** masonicboom has joined #bitcoin-core-dev
2082018-07-30T12:43:47 *** masonicboom has quit IRC
2092018-07-30T12:47:19 <kallewoof> I agree gaining consensus for code style update (via PR and (concept) ACK's w/ merge) should be required before making changes unless the change is an obvious improvement that everyone needs. However, I also believe that we should automate EVERYTHING that can be automated, even if it is only slightly beneficial.
2102018-07-30T12:48:12 <kallewoof> Automating PR review seems like an obvious win.
2112018-07-30T12:54:59 <wumpus> at least I'm not arguing against automated PR review
2122018-07-30T12:55:50 <wumpus> I think checking for things that actually makes sense is good
2132018-07-30T12:57:49 <luke-jr> kallewoof: PR review cannot be automated..
2142018-07-30T12:58:15 <wumpus> but not adding vague concerns all the time that haven't actually resulted in bugs nor are likely to result in such, we're trying to build functional code here, the concern is not perfect style according to some person's preferences
2152018-07-30T12:58:17 <fanquake> kallewoof I agree re automation. At least in the case of the Draht bot, as it has started improving/gotten a bit less noisy, I've begun to enjoy the merge conflict notifications, as well as nearly automated? gitian builds.
2162018-07-30T12:59:09 <fanquake> However posting a comment to say that 15 PRs all conflict with each other is probably getting towards the less valuable end, heh.
2172018-07-30T12:59:55 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2182018-07-30T13:03:37 <wumpus> luke-jr: I think he means the linters, so the basic trivial stuff
2192018-07-30T13:03:47 <wumpus> if only real code review could be automated!
2202018-07-30T13:03:50 <kallewoof> wumpus: I admit I haven't seen the PR in detail, I was mostly talking about past experience :)
2212018-07-30T13:04:44 <kallewoof> and yes, I am talking about the review that you can automate, not all review.
2222018-07-30T13:05:25 <wumpus> kallewoof: I think MarcoFalke's approach is better than practicalswifts in this regard; DrahtBot has a PR that updates various known things before the 0.17 branch, practicalswift on the other hand creates PR after PR after PR changing things all over the code base
2232018-07-30T13:06:09 *** Chris_Stewart_5 has quit IRC
2242018-07-30T13:07:17 <wumpus> I think agreeing to make some such changes (certainly if they're alrady part of the coding guidelines) before a release is okay, at least it's a rare thing
2252018-07-30T13:08:47 <fanquake> Something like #13802 might be just that sort of thing, but I've added there that it should really be added the the build system if possible. Otherwise could lead to endless followup.
2262018-07-30T13:08:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13802 | Dont use zero as null pointer constant by practicalswift · Pull Request #13802 · bitcoin/bitcoin · GitHub
2272018-07-30T13:09:06 <fanquake> i.e sweeping change just before a release
2282018-07-30T13:09:14 <wumpus> my concern is with sweeping changes that come out of the blue
2292018-07-30T13:09:44 <wumpus> suddenly there's this completely new thing you should care about and we should update the entire cod efor!
2302018-07-30T13:10:26 <wumpus> please, let's work on issues that affect users
2312018-07-30T13:13:53 *** face has joined #bitcoin-core-dev
2322018-07-30T13:19:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2332018-07-30T13:27:49 <kallewoof> Ideally, if a PR will plug a potential issue later down the road, it should be encouraged, but it can be hard to judge. I think a way to solve this is to put the weight on the PR creator -- find compelling and easy to follow reasons for why the PR is necessary, or we all agree to concept NACK saying we don't see the reason. Maybe even add that to the contributor guidelines.
2342018-07-30T13:28:34 <wumpus> yes, if there is a good rationale, we have a way to introduce that (through the coding guidelines), I agree
2352018-07-30T13:29:31 <wumpus> that's exactly what I said in my post, too
2362018-07-30T13:29:39 <kallewoof> *nod*
2372018-07-30T13:33:33 *** masonicboom has joined #bitcoin-core-dev
2382018-07-30T13:33:38 *** jhfrontz has joined #bitcoin-core-dev
2392018-07-30T13:37:45 *** masonicboom has quit IRC
2402018-07-30T13:39:33 *** satwo has joined #bitcoin-core-dev
2412018-07-30T13:40:28 *** fanquake has quit IRC
2422018-07-30T13:56:18 *** grubles has quit IRC
2432018-07-30T13:58:31 <kallewoof> wumpus: Does #13803 convey the right message?
2442018-07-30T13:58:33 <gribble> https://github.com/bitcoin/bitcoin/issues/13803 | doc: add note to developer docs about warranted PRs by kallewoof · Pull Request #13803 · bitcoin/bitcoin · GitHub
2452018-07-30T14:02:11 <wumpus> kallewoof: I think so! wouldn't a better place be CONTRIBUTING.md though?
2462018-07-30T14:03:26 <kallewoof> I was unsure about that. I have no strong feelings about it, personally, so can move it.
2472018-07-30T14:04:56 <kallewoof> Actually, it fits better in contributing, I think. Moving it.
2482018-07-30T14:05:13 <wumpus> that's where people automatically get linked afaik
2492018-07-30T14:07:32 <kallewoof> Moved
2502018-07-30T14:17:22 *** grubles has joined #bitcoin-core-dev
2512018-07-30T14:17:42 *** fanquake has joined #bitcoin-core-dev
2522018-07-30T14:19:54 <fanquake> ken2812221 Are you following any of the upstream Windows/leveldb work? I've seen a few different PRs that also seem to be working on the unicode problems that you are.
2532018-07-30T14:21:02 <fanquake> i.e https://github.com/google/leveldb/pull/526
2542018-07-30T14:21:26 <fanquake> However progress on them seems to be stagnating.
2552018-07-30T14:22:22 <ken2812221> fanquake: No, I haven't seen those yet.
2562018-07-30T14:23:56 <ken2812221> google might not want to port leveldb to Windows.
2572018-07-30T14:25:09 <ken2812221> I just do the minimum changes base on current env_win.cc
2582018-07-30T14:26:33 <fanquake> np. Just mentioned as it was worth a look incase you could cherry-pick anything useful.
2592018-07-30T14:28:11 <ken2812221> Thanks, will take a look.
2602018-07-30T14:29:00 <fanquake> wumpus You can probably merge 13803 straight in. 13554 also ready.
2612018-07-30T14:30:41 <wumpus> thanks!
2622018-07-30T14:32:56 *** harding has quit IRC
2632018-07-30T14:33:27 *** masonicboom has joined #bitcoin-core-dev
2642018-07-30T14:33:46 *** harding has joined #bitcoin-core-dev
2652018-07-30T14:34:03 *** promag has joined #bitcoin-core-dev
2662018-07-30T14:35:34 <fanquake> Also 13797, backporting to 0.16
2672018-07-30T14:37:45 *** masonicboom has quit IRC
2682018-07-30T14:42:15 *** promag has quit IRC
2692018-07-30T14:44:51 <kallewoof> wumpus: mind if I fix commit message s/developer/contributor/ on 13803? don't wanna touch if you intend to merge it now.
2702018-07-30T14:47:20 <kallewoof> Actually promag nit is valid so gonna fix that too. Apologies.
2712018-07-30T14:47:44 <wumpus> kallewoof: for sure!
2722018-07-30T14:48:10 <wumpus> kallewoof: this should be open for a while for discussion probably nayway
2732018-07-30T14:48:32 <kallewoof> Yes, good point.
2742018-07-30T14:50:34 <kallewoof> Although practicalswift did already ACK it. Not sure if anyone else is affected (apart from myself, of course.. I mean, this obviously means #12879 is not gonna see the light of day, ever).
2752018-07-30T14:50:36 <gribble> https://github.com/bitcoin/bitcoin/issues/12879 | [scripted-diff] No extern function declarations by kallewoof · Pull Request #12879 · bitcoin/bitcoin · GitHub
2762018-07-30T14:50:41 <satwo> Is there a more detailed guide (than what is currently found in CONTRIBUTING.md) that explains, step-by-step, the proper testing of a PR? I would assume at minimum: compile and run the patch set, make sure the intended behavior is present, make sure no unintended behaviors have been introduced (is there a systematic way to approach this?), and run (all, or just relevant?) unit tests.
2772018-07-30T14:52:19 <kallewoof> satwo: Not to my knowledge. In fact, I wrote an entire framework (https://www.npmjs.com/package/bctest and https://www.npmjs.com/package/bitcointest) before I finally found out there was a pythong testing framework already :P
2782018-07-30T14:55:07 <fanquake> "compile and run the patch set" Quite often this needs to be done across multiple OS's, as occasionally a something will break a *BSD build, or Windows etc
2792018-07-30T14:55:35 <fanquake> Running all the tests suites (--extended), running any linters etc.
2802018-07-30T14:56:01 <fanquake> However what your testing/checking is always dependant on the actual change.
2812018-07-30T14:57:27 <fanquake> There was at one point a bitcoin test cases/writeups repo, but I don't think it ever got much traction
2822018-07-30T14:58:48 <wumpus> it depends on the change; if it is aspecific, say a refactoring, then running the test framework (both unit and functional) should be enough
2832018-07-30T14:59:03 <wumpus> if it is specific, for example you're adding an API call, then you need to add a functional test for that call
2842018-07-30T14:59:30 <wumpus> for more complex internal functionality you'd want to add unit tests
2852018-07-30T15:01:10 *** Victorsueca has quit IRC
2862018-07-30T15:02:00 <satwo> kallewoof: ha! That must have been quite the learning experience, if nothing else :)
2872018-07-30T15:02:20 *** Victorsueca has joined #bitcoin-core-dev
2882018-07-30T15:02:58 <satwo> fanquake: That was something I was wondering about: how does one know when a change should be tested on different platforms, and when testing on any single platform is sufficient?
2892018-07-30T15:03:05 <kallewoof> Yeah I enjoyed it. :) LImited use but still
2902018-07-30T15:03:25 *** michaelsdunn1 has joined #bitcoin-core-dev
2912018-07-30T15:03:43 <gmaxwell> ISTM that the project has sped up in the last year in terms of changes, but I don't think that the number of interesting new features, performance improvements, or bug fixes have increased at the same rate which sometimes just makes it seem like more work to keep up but less interesting.
2922018-07-30T15:03:44 <wumpus> satwo: in any case if you are working on something, just ask, and people here can probably answer what you need
2932018-07-30T15:04:04 <gmaxwell> satwo: In terms of "systematic way" -- the systematic part should be largely implemented by the automated tests.
2942018-07-30T15:04:57 <gmaxwell> So for testing a PR: run the automated tests, test your own use cases, and test whatever you can come up with specific to the PR that isn't automated.
2952018-07-30T15:06:05 <satwo> wumpus: thanks! I definitely need to familiarize myself with functional vs unit tests in bitcoin. I'll continue to come here to ask my noobish questions.
2962018-07-30T15:06:21 <jonasschnelli> MarcoFalke: there are two merge commits in #13804
2972018-07-30T15:06:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13804 | Stacked Transaction Pool Layer by MarcoFalke · Pull Request #13804 · bitcoin/bitcoin · GitHubAsset 1Asset 1
2982018-07-30T15:07:23 <kallewoof> satwo: functional = start up one or several nodes and try stuff out by calling them via RPC. unit = actually call C++ methods directly and check if they behave right
2992018-07-30T15:07:25 <fanquake> satwo: Here's one example of a PR that "silently" broke builds on FreeBSD 10 9598.
3002018-07-30T15:10:00 <fanquake> There gui can also get somewhat limited testing, especially on Windows. Although, that stems more from so few of the developers, at least working on Core, using Windows.
3012018-07-30T15:13:21 <fanquake> However that might seem to be changing if you take into account recent PRs.
3022018-07-30T15:16:57 *** ExtraCrispy has joined #bitcoin-core-dev
3032018-07-30T15:17:04 <wumpus> breaking FreeBSD is a good way to make me angry :)
3042018-07-30T15:17:08 <satwo> gmaxwell: thanks for the clarification! Very helpful.
3052018-07-30T15:18:12 <wumpus> but that doesn't happen that often, usually with build system changes, those I test on *BSD first before merging
3062018-07-30T15:19:32 <satwo> kallewoof: Thanks for the clarification! Pretty straightforward yet I'd never considered the difference until today.
3072018-07-30T15:22:37 <satwo> fanquake: thanks for the PR reference, very interesting. I do have Windows running on Parallels so I could certainly help out on that front.
3082018-07-30T15:25:10 *** fanquake has quit IRC
3092018-07-30T15:29:39 *** booyah has quit IRC
3102018-07-30T15:29:54 *** Victorsueca has quit IRC
3112018-07-30T15:30:17 *** booyah has joined #bitcoin-core-dev
3122018-07-30T15:30:38 *** Victorsueca has joined #bitcoin-core-dev
3132018-07-30T16:01:54 *** booyah has quit IRC
3142018-07-30T16:02:22 *** marcinja has joined #bitcoin-core-dev
3152018-07-30T16:04:12 *** Dizzle has joined #bitcoin-core-dev
3162018-07-30T16:06:06 *** booyah has joined #bitcoin-core-dev
3172018-07-30T16:22:30 *** masonicboom has joined #bitcoin-core-dev
3182018-07-30T16:26:52 *** masonicboom has quit IRC
3192018-07-30T16:29:46 *** contrapumpkin has joined #bitcoin-core-dev
3202018-07-30T16:30:55 *** setpill has quit IRC
3212018-07-30T16:31:39 *** booyah has quit IRC
3222018-07-30T16:32:05 *** copumpkin has quit IRC
3232018-07-30T16:36:11 <jamesob> did we recently bump the required version of protobuf?
3242018-07-30T16:38:16 <wumpus> jamesob: I don't think so, and I'd be really surprised
3252018-07-30T16:38:37 <wumpus> the only use of protobuf is the payment request code in bitcoin-qt and that hasn't seen serious changes since... forever
3262018-07-30T16:39:17 <jamesob> I just started getting some related-looking compile failures: https://gist.github.com/jamesob/70fda4b96499f7b86c938370ffe92b49
3272018-07-30T16:40:35 *** Dizzle has quit IRC
3282018-07-30T16:41:10 <wumpus> that looks like you need to make clean (or even clear your tree) and rebuild -- this is most likely caused by the protobuf version on your system changing through package managers or such
3292018-07-30T16:41:34 <jamesob> thanks, I'll give that a shot
3302018-07-30T16:41:49 <wumpus> (pb.h isn't part of the repository but generated)
3312018-07-30T16:43:18 *** gribble has quit IRC
3322018-07-30T16:52:30 *** owowo has quit IRC
3332018-07-30T16:54:24 *** booyah has joined #bitcoin-core-dev
3342018-07-30T16:56:46 *** gribble has joined #bitcoin-core-dev
3352018-07-30T17:00:06 *** owowo has joined #bitcoin-core-dev
3362018-07-30T17:18:39 *** masonicboom has joined #bitcoin-core-dev
3372018-07-30T17:44:09 *** SopaXorzTaker has quit IRC
3382018-07-30T17:48:22 *** masonicboom has quit IRC
3392018-07-30T17:59:47 *** masonicboom has joined #bitcoin-core-dev
3402018-07-30T18:01:50 *** nodweber has quit IRC
3412018-07-30T18:17:47 *** nodweber has joined #bitcoin-core-dev
3422018-07-30T18:18:30 *** jhfrontz has quit IRC
3432018-07-30T18:22:29 *** nodweber has quit IRC
3442018-07-30T18:23:07 *** jhfrontz has joined #bitcoin-core-dev
3452018-07-30T18:24:09 *** rabidus has quit IRC
3462018-07-30T18:26:25 *** promag has joined #bitcoin-core-dev
3472018-07-30T18:29:38 *** promag has quit IRC
3482018-07-30T18:33:23 *** quitobro has joined #bitcoin-core-dev
3492018-07-30T18:33:53 <quitobro> hey guys i have a question about best practice for managing watch-only addresses
3502018-07-30T18:34:20 <quitobro> specifically, which RPC commands are best to use in order to *get transactions tied to an input address*
3512018-07-30T18:35:01 <quitobro> i was expecting `getreceivedbyaddress` to take an address param and return a list of UTXOs or tx's
3522018-07-30T18:35:19 *** jhfrontz has quit IRC
3532018-07-30T18:35:46 *** jhfrontz has joined #bitcoin-core-dev
3542018-07-30T18:36:02 <quitobro> furthermore, when i was exploring the `*byaccount` RPC commands it seems like many of them are deprecated - is the 'account' concept being deprecated or just select commands like `getreceivedbyaccount`?
3552018-07-30T18:38:06 *** jhfrontz has quit IRC
3562018-07-30T18:38:25 <sipa> quitobro: the accounts concept is deprecated
3572018-07-30T18:38:40 *** nodweber has joined #bitcoin-core-dev
3582018-07-30T18:39:08 <sipa> quitobro: if you import a watch only address, the usual RPCs like getreceivedbyaddress will work
3592018-07-30T18:39:12 <sipa> but you first need to import them
3602018-07-30T18:39:51 <sipa> quitobro: labels will replace accounts; so you'll still be able to give a label to an address and see transactions to a label etc
3612018-07-30T18:40:01 <sipa> but there won't be a "label balance" like there is an account balance
3622018-07-30T18:40:12 <sipa> they're just a way to tag addresses for receives
3632018-07-30T18:40:48 <quitobro> sipa: ok thanks. yea, `getreceivedbyaddress` is nice but i want something which returns the transaction history at address, not just the balance...
3642018-07-30T18:41:38 *** jhfrontz has joined #bitcoin-core-dev
3652018-07-30T18:41:40 <sipa> quitobro: listreceivedbyaddress
3662018-07-30T18:41:54 <quitobro> i suppose i can go thru `listtransactions` and filter by address?
3672018-07-30T18:43:18 *** nodweber has quit IRC
3682018-07-30T18:43:38 <quitobro> ah, ok, and then filter thru the list of tx summaries grabbing only the ones i care about, or something like that. thank you sipa!
3692018-07-30T18:43:47 <quitobro> this is what i needed :)
3702018-07-30T18:44:18 *** jhfrontz has quit IRC
3712018-07-30T18:46:20 *** jhfrontz has joined #bitcoin-core-dev
3722018-07-30T18:55:01 *** promag has joined #bitcoin-core-dev
3732018-07-30T18:56:14 *** quitobro has quit IRC
3742018-07-30T18:59:33 *** nodweber has joined #bitcoin-core-dev
3752018-07-30T19:00:55 <jamesob> wumpus: turns out I had a mismatch between my protoc version (newer) and libprotobuf-dev
3762018-07-30T19:01:56 <wumpus> jamesob: whoops
3772018-07-30T19:03:49 *** tripleslash has quit IRC
3782018-07-30T19:04:02 *** nodweber has quit IRC
3792018-07-30T19:05:55 *** quitobro has joined #bitcoin-core-dev
3802018-07-30T19:06:30 *** promag has quit IRC
3812018-07-30T19:06:42 <quitobro> sipa: one more question - when calling `importaddress` with `rescan=true`, will that operation be blocking other reads/writes to the local blockchain database?
3822018-07-30T19:07:25 <sipa> quitobro: it will block pretty much everything
3832018-07-30T19:08:36 *** michaelsdunn1 has quit IRC
3842018-07-30T19:10:45 <quitobro> sipa: okay sounds like we may need to schedule our rescans very carefully then
3852018-07-30T19:10:58 *** promag has joined #bitcoin-core-dev
3862018-07-30T19:11:25 <sipa> quitobro: you should import addresses before they're being used :)
3872018-07-30T19:11:26 <quitobro> how long do rescans take usually? relative to say initial sync time?
3882018-07-30T19:13:04 <sipa> a significant fraction
3892018-07-30T19:14:09 <gmaxwell> quitobro: Can you talk about your usecase? why are you performing rescans at all?
3902018-07-30T19:14:24 <quitobro> hm okay... for our application we don't manage users' keys, but want to provide essentially a blockchain explorer... is there a way to get tx & balance details for an arbitrary valid address, without importing as watch-only?
3912018-07-30T19:15:01 <quitobro> we looked at using a 3rd party service but we don't want those blockchain queries to potentially reveal customers' addresses
3922018-07-30T19:15:13 <quitobro> and would prefer to run our own nodes and fulfill those requests
3932018-07-30T19:15:47 <quitobro> we sell a cryptocurrency trading platform as a software service
3942018-07-30T19:16:03 <quitobro> so there is a large blockchain explorer-esque component as part of e.g. trade settlement
3952018-07-30T19:16:41 <gmaxwell> Importing as watching before issing the addresses is the canonical, supported way. Your next best alternative is to write your own indexer. The issue is that the resource costs of indexing all transactions in history will continue to rapidly grow... so most people who setup that way will eventually need to switch to using a centeralized service due to the resource costs.
3962018-07-30T19:17:17 <gmaxwell> There hasn't been much interest in maintaining that kind of index in bitcoind because of the above.
3972018-07-30T19:18:20 <quitobro> gmaxwell: in other words everyone's index needs/requirements vary so there isn't a good way to implement arbitrary indexes in bitcoind?
3982018-07-30T19:18:36 <quitobro> or rather indexes for arbitrary watch-only addresses
3992018-07-30T19:20:30 *** nodweber has joined #bitcoin-core-dev
4002018-07-30T19:20:36 <gmaxwell> We may have a feature in 0.18 that makes rescan much faster (e.g. a minute maybe, instead of hours), but likely still too slow for your application.
4012018-07-30T19:22:36 <quitobro> gmaxwell: cool what is that feature? sounds quite nite
4022018-07-30T19:22:36 <gmaxwell> quitobro: diversity of needs is one issue, but scalablity is another. At least in the community people aren't generally excited on working on technology that will only be usable on large dedicated servers, if not now, then in a couple years. If someone showed up and wanted to add optional indexing, and was willing to jump through the right hoops to isolate it, I think the contribution would be
4032018-07-30T19:22:36 <gmaxwell> welcome.
4042018-07-30T19:22:38 <quitobro> nice*
4052018-07-30T19:23:25 <gmaxwell> quitobro: use of BIP-158 filters locally. Basically for every block we'd save a small fingerprint of the addresses involved in the block.
4062018-07-30T19:23:35 <gmaxwell> Then scanning only has to check those, and not the whole blockchain.
4072018-07-30T19:23:55 <gmaxwell> it's still a linear scan, rather than an index, but of a lot less data.
4082018-07-30T19:24:40 <gmaxwell> There is a pull req implementing the filters, but not the wallet rescan using it, yet.
4092018-07-30T19:24:57 *** nodweber has quit IRC
4102018-07-30T19:25:11 <gmaxwell> It's too late to make 0.17 right now, but I think it's somewhat likely for 0.18.
4112018-07-30T19:25:18 <quitobro> gmaxwell: i see, ok maybe if we continue down this path (as opposed to running a super beefy, indexed dedicated server) we will be able to make a contribution
4122018-07-30T19:25:32 <gmaxwell> If nothing else, being willing to show up and test it would help.
4132018-07-30T19:26:03 <quitobro> definitely; should we just keep our eyes on bitcoin-dev-mailing-list?
4142018-07-30T19:26:28 <gmaxwell> In general, when there are features that are mostly interesting for commerical players, we'd still welcome them, but industry needs to step up and do more of that work... there is just too much to do. :)
4152018-07-30T19:26:35 <gmaxwell> quitobro: you might want to also keep an eye on https://github.com/bitcoin/bitcoin/pull/12254
4162018-07-30T19:27:20 <gmaxwell> After it's merged presumably there will be more PRs to actually make use of it.
4172018-07-30T19:29:37 *** promag has quit IRC
4182018-07-30T19:37:18 <midnightmagic> I actually thought working on the weird higher-end functionality was the best thing I used to do professionally. (as limited as that was)
4192018-07-30T19:38:05 *** nodweber has joined #bitcoin-core-dev
4202018-07-30T19:39:59 *** promag has joined #bitcoin-core-dev
4212018-07-30T19:42:25 *** promag has quit IRC
4222018-07-30T19:45:13 *** intcat has quit IRC
4232018-07-30T19:45:13 *** arubi has quit IRC
4242018-07-30T19:47:33 *** arubi has joined #bitcoin-core-dev
4252018-07-30T19:48:46 *** intcat has joined #bitcoin-core-dev
4262018-07-30T19:52:30 *** quitobro has quit IRC
4272018-07-30T19:53:03 *** tripleslash has joined #bitcoin-core-dev
4282018-07-30T19:59:09 <MarcoFalke> Just a PSA for member of the GitHub-labels group:
4292018-07-30T19:59:27 <MarcoFalke> You can tag with "Needs gitian build" and DrahtBot will create a built in the next day or so
4302018-07-30T20:00:38 *** nodweber has quit IRC
4312018-07-30T20:05:15 *** elkalamar has joined #bitcoin-core-dev
4322018-07-30T20:06:05 *** promag has joined #bitcoin-core-dev
4332018-07-30T20:17:39 *** nodweber has joined #bitcoin-core-dev
4342018-07-30T20:24:32 *** sturles has quit IRC
4352018-07-30T20:33:32 *** promag has quit IRC
4362018-07-30T20:45:12 *** sturles has joined #bitcoin-core-dev
4372018-07-30T20:47:02 *** d9b4bef9 has quit IRC
4382018-07-30T20:48:18 *** d9b4bef9 has joined #bitcoin-core-dev
4392018-07-30T21:12:14 *** booyah has quit IRC
4402018-07-30T21:21:35 *** nodweber has quit IRC
4412018-07-30T21:32:10 *** Chris_Stewart_5 has quit IRC
4422018-07-30T21:59:57 *** arubi has quit IRC
4432018-07-30T22:00:22 *** arubi has joined #bitcoin-core-dev
4442018-07-30T22:00:40 *** promag has joined #bitcoin-core-dev
4452018-07-30T22:01:20 <promag> provoostenator: let me know if you can try #13791 in windows? ty!
4462018-07-30T22:01:21 <gribble> https://github.com/bitcoin/bitcoin/issues/13791 | gui: Reject dialogs if key escape is pressed by promag · Pull Request #13791 · bitcoin/bitcoin · GitHubAsset 1Asset 1
4472018-07-30T22:04:37 *** timothy has quit IRC
4482018-07-30T22:19:36 *** michaelsdunn1 has joined #bitcoin-core-dev
4492018-07-30T22:20:06 *** michaelsdunn1 has joined #bitcoin-core-dev
4502018-07-30T22:25:18 *** luke-jr has quit IRC
4512018-07-30T22:25:26 *** luke-jr has joined #bitcoin-core-dev
4522018-07-30T22:28:04 *** Victorsueca has quit IRC
4532018-07-30T22:29:19 *** Victorsueca has joined #bitcoin-core-dev
4542018-07-30T22:29:21 *** masonicboom has quit IRC
4552018-07-30T22:35:21 *** michaelsdunn1 has quit IRC
4562018-07-30T22:39:00 *** masonicboom has joined #bitcoin-core-dev
4572018-07-30T23:04:38 *** Krellan has joined #bitcoin-core-dev
4582018-07-30T23:14:09 *** Krellan has quit IRC
4592018-07-30T23:22:21 <ken2812221> promag: It works fine on Windows.
4602018-07-30T23:22:46 <promag> ty ken2812221
4612018-07-30T23:22:57 <promag> just saw your reply there
4622018-07-30T23:22:58 *** Krellan has joined #bitcoin-core-dev
4632018-07-30T23:23:28 <promag> ken2812221: if you change value in the options dialog, press esc, and reopen, is the value reset?
4642018-07-30T23:24:45 <ken2812221> promag: Yes, it does not store the setting if I press esc.
4652018-07-30T23:25:39 *** masonicboom has quit IRC
4662018-07-30T23:26:10 *** vicenteH has joined #bitcoin-core-dev
4672018-07-30T23:26:34 <promag> ken2812221: ok cool
4682018-07-30T23:28:54 *** Emcy has quit IRC
4692018-07-30T23:40:02 *** Emcy has joined #bitcoin-core-dev
4702018-07-30T23:49:12 *** michaelsdunn1 has joined #bitcoin-core-dev
4712018-07-30T23:59:12 *** promag has quit IRC