12016-09-21T00:33:16  *** Chris_Stewart_5 has quit IRC
  22016-09-21T00:35:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  32016-09-21T00:43:52  *** moli has joined #bitcoin-core-dev
  42016-09-21T00:46:03  *** mol has quit IRC
  52016-09-21T00:46:27  *** brg444 has joined #bitcoin-core-dev
  62016-09-21T00:46:55  *** Ylbam has quit IRC
  72016-09-21T01:04:15  *** analpaper has joined #bitcoin-core-dev
  82016-09-21T01:22:17  *** Chris_Stewart_5 has quit IRC
  92016-09-21T01:39:59  *** PaulCapestany has joined #bitcoin-core-dev
 102016-09-21T01:40:26  *** dcousens has joined #bitcoin-core-dev
 112016-09-21T01:57:26  *** btcdrak has quit IRC
 122016-09-21T01:59:36  <phantomcircuit> is there some reason im not aware of that the wallet functions aren't acquiring the lock themselves?
 132016-09-21T01:59:46  <phantomcircuit> instead of relying on the caller to have acquired the lock?
 142016-09-21T02:11:36  *** brg444 has quit IRC
 152016-09-21T02:13:31  *** jchrome has joined #bitcoin-core-dev
 162016-09-21T02:29:08  *** jchrome has quit IRC
 172016-09-21T02:30:14  *** jchrome has joined #bitcoin-core-dev
 182016-09-21T02:39:23  <phantomcircuit> luke-jr: ^
 192016-09-21T02:40:00  <phantomcircuit> it *should* be safe for me to simpyl add LOCK(cs_wallet); calls to all methods which assume a lock? (which is basically all of them)
 202016-09-21T02:41:35  <luke-jr> phantomcircuit: my guess would be so they could be used recursively
 212016-09-21T02:53:24  *** go1111111 has quit IRC
 222016-09-21T02:56:07  *** Alopex has quit IRC
 232016-09-21T02:57:12  *** Alopex has joined #bitcoin-core-dev
 242016-09-21T03:01:35  *** Atomic_zEU0b has joined #bitcoin-core-dev
 252016-09-21T03:02:04  *** Atomic_zEU0b has left #bitcoin-core-dev
 262016-09-21T03:02:35  <Atomic_zEU0b> hey
 272016-09-21T03:08:53  *** jchrome has left #bitcoin-core-dev
 282016-09-21T03:15:31  *** dcousens has quit IRC
 292016-09-21T03:18:22  *** Alopex has quit IRC
 302016-09-21T03:19:27  *** Alopex has joined #bitcoin-core-dev
 312016-09-21T03:19:38  <phantomcircuit> gmaxwell: the LOCK construct is recursive right?
 322016-09-21T03:33:06  <luke-jr> pretty sure it isn't. or at least can't be relied on to be.
 332016-09-21T03:42:09  *** dcousens has joined #bitcoin-core-dev
 342016-09-21T03:53:21  *** jchrome has joined #bitcoin-core-dev
 352016-09-21T04:00:03  *** dermoth has quit IRC
 362016-09-21T04:00:37  *** dermoth has joined #bitcoin-core-dev
 372016-09-21T04:08:02  *** sdaftuar has quit IRC
 382016-09-21T04:18:15  *** sdaftuar has joined #bitcoin-core-dev
 392016-09-21T04:58:01  *** Alopex has quit IRC
 402016-09-21T04:58:01  *** davec has quit IRC
 412016-09-21T04:58:20  *** davec has joined #bitcoin-core-dev
 422016-09-21T04:59:06  *** Alopex has joined #bitcoin-core-dev
 432016-09-21T05:06:14  *** justan0theruser has joined #bitcoin-core-dev
 442016-09-21T05:06:23  *** justanotheruser has quit IRC
 452016-09-21T05:11:21  *** kyletorpey has quit IRC
 462016-09-21T05:12:32  *** kyletorpey has joined #bitcoin-core-dev
 472016-09-21T05:20:44  *** analpaper has quit IRC
 482016-09-21T05:27:46  *** kadoban has quit IRC
 492016-09-21T05:38:20  <wumpus> phantomcircuit: yes, the default mutex used in bitcoin core is a recursive one
 502016-09-21T05:39:05  <wumpus> we'd rather have it otherwise, there are a few solid software engineering reasons to avoid recursive mutexes, but that's part of our inheritance and it's terribly difficult to change (and be sure of the result)
 512016-09-21T05:39:36  <wumpus> note that new code in general tries to use normal, single-use mutexes
 522016-09-21T05:40:57  *** mn3monic has joined #bitcoin-core-dev
 532016-09-21T05:56:10  *** paveljanik has joined #bitcoin-core-dev
 542016-09-21T05:56:10  *** paveljanik has joined #bitcoin-core-dev
 552016-09-21T06:08:48  <luke-jr> wumpus: pretty sure I hit a deadlock from locking the same mutex twice in a thread, fwiw
 562016-09-21T06:09:25  <wumpus> that is very possible, but not with the main, wallet locks and such as they are recursive mutexes
 572016-09-21T06:09:31  *** Ylbam has joined #bitcoin-core-dev
 582016-09-21T06:10:18  <wumpus> you can try locking them 100 times in a loop in the same thread, they just keep track of a counter, so as long as you unlock the same number of times you will be fine
 592016-09-21T06:11:25  <luke-jr> wumpus: I guess I should just close https://github.com/bitcoin/bitcoin/pull/8687 and simply remove the call in a new PR?
 602016-09-21T06:11:56  <wumpus> let's close it in favor of #8765
 612016-09-21T06:12:28  <luke-jr> oh, missed that
 622016-09-21T06:12:37  <wumpus> he had missed your pull too
 632016-09-21T06:12:45  <GitHub113> [bitcoin] laanwj closed pull request #8687: Bugfix: RPC/Wallet: removeprunedfunds should flush the wallet db (master...bugfix_removeprunedfunds) https://github.com/bitcoin/bitcoin/pull/8687
 642016-09-21T06:15:13  *** btcdrak has joined #bitcoin-core-dev
 652016-09-21T06:16:02  <GitHub23> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1c24d5f63720...b4f53641a95d
 662016-09-21T06:16:02  <GitHub23> bitcoin/master c6f5ca8 Jonas Schnelli: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds
 672016-09-21T06:16:03  <GitHub23> bitcoin/master b4f5364 Wladimir J. van der Laan: Merge #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds...
 682016-09-21T06:16:12  <GitHub106> [bitcoin] laanwj closed pull request #8765: [Wallet] remove "unused" ThreadFlushWalletDB from removeprunedfunds (master...2016/09/flush_wallet_dump) https://github.com/bitcoin/bitcoin/pull/8765
 692016-09-21T06:16:15  *** dcousens has quit IRC
 702016-09-21T06:27:16  *** MarcoFalke has joined #bitcoin-core-dev
 712016-09-21T06:38:01  *** Alopex has quit IRC
 722016-09-21T06:39:07  *** Alopex has joined #bitcoin-core-dev
 732016-09-21T06:55:35  *** rubensayshi has joined #bitcoin-core-dev
 742016-09-21T07:15:15  *** paveljanik has quit IRC
 752016-09-21T07:49:25  *** tucenaber has quit IRC
 762016-09-21T07:50:28  *** ___tau___ has quit IRC
 772016-09-21T08:04:50  *** molz has joined #bitcoin-core-dev
 782016-09-21T08:07:36  *** moli has quit IRC
 792016-09-21T08:31:42  *** ill has quit IRC
 802016-09-21T08:38:13  *** mrkent has quit IRC
 812016-09-21T08:39:33  <MarcoFalke> jonasschnelli: Would it be hard to use the theme for the text+background as luke-jr suggests?
 822016-09-21T08:39:43  <MarcoFalke> Anyway style nits can be fixed later, 8371 looks good now
 832016-09-21T08:40:27  <MarcoFalke> This is the most important gui change for 0.14. Better get it in sooner than later
 842016-09-21T08:40:32  <jonasschnelli> MarcoFalke: Yes. This could be done later...
 852016-09-21T08:40:45  <luke-jr> indeed
 862016-09-21T08:40:58  <jonasschnelli> Also. I'm not sure if theme based colors together with the icon and the progress bar will look nice
 872016-09-21T08:41:12  <jonasschnelli> I guess we also would need to ensure the singlecoloricon fits the theme...
 882016-09-21T08:41:22  <jonasschnelli> also the blackish overlay is something that looks good IMO
 892016-09-21T08:41:39  <jonasschnelli> gives a look that its something "important" to read..
 902016-09-21T08:41:56  <luke-jr> singlecoloricon is designed specifically to fit the theme :p
 912016-09-21T08:42:11  <jonasschnelli> if we just use the theme colors, it might be white with black text and not really distinctable between the rest of the UI elements
 922016-09-21T08:42:24  *** DigiByteDev has joined #bitcoin-core-dev
 932016-09-21T08:42:38  <jonasschnelli> the inverted colors as an overlay make sense from an UX perspetive IMO.
 942016-09-21T08:43:40  <luke-jr> I'm not aware of a single app that inverts colours for modal dialogs.
 952016-09-21T08:48:16  <jonasschnelli> Luke-Jr: how should it look then?
 962016-09-21T08:50:38  <luke-jr> however modal dialogs normally look for the particular user's style
 972016-09-21T08:51:56  <jonasschnelli> But it's not a modal dialog... it's an overlay.
 982016-09-21T08:52:10  <luke-jr> good UX lies in behaving and looking as the user expects IMO
 992016-09-21T08:52:17  <luke-jr> jonasschnelli: what's the difference?
1002016-09-21T08:52:33  <jonasschnelli> Its in the same window
1012016-09-21T08:52:52  <jonasschnelli> It overlays the controls.
1022016-09-21T08:53:12  <jonasschnelli> Using a QDialog with modal flag would be wrong IMO
1032016-09-21T08:53:50  <luke-jr> preventing interaction with the controls is precisely what model dialogs are meant to be used for.
1042016-09-21T08:53:54  <jonasschnelli> We could try to use the theme color for the black, hiding-part and a theme color for the overlay-info-layer and the text
1052016-09-21T08:54:13  <jonasschnelli> Yes. But do you think a QDialog with modal flag would look appropriate?
1062016-09-21T08:54:14  <luke-jr> the key distinction I see in this case, is that the dialog needs to go away on its own when the process completes
1072016-09-21T08:54:39  * luke-jr ponders what similar things exist
1082016-09-21T08:54:52  <sipa> it also doesn't need preventing interaction with the entire application
1092016-09-21T08:55:03  <sipa> opening the debug window presumably should work fine
1102016-09-21T08:55:05  <luke-jr> sipa: good point
1112016-09-21T08:55:58  <jonasschnelli> Yes. It a partial-modal overlay. :)
1122016-09-21T08:56:05  <luke-jr> KMail shows an overlay while it loads a folder
1132016-09-21T08:56:13  <luke-jr> so it seems the overlay stuff is standard
1142016-09-21T08:56:18  <luke-jr> at least to some degree
1152016-09-21T08:56:38  <jonasschnelli> I think we could try to attach it more to the theme colors once its merged
1162016-09-21T08:56:58  <jonasschnelli> before we do cosmetic changes, we should address the problem that people download Core and start receiving funds that are then stuck.
1172016-09-21T08:57:01  <luke-jr> yes, I agree, this doesn't need to hold back merging
1182016-09-21T08:57:04  <sipa> use the text color as background and background color as text? :)
1192016-09-21T08:57:11  <sipa> yes agree, not a blocker
1202016-09-21T08:57:13  <jonasschnelli> Yes. Something like that
1212016-09-21T08:57:14  <wumpus> +1 on getting it merged
1222016-09-21T08:57:24  <sipa> ha, blocker... for a modal overlay
1232016-09-21T08:57:31  <jonasschnelli> heh!
1242016-09-21T08:57:39  <wumpus> this is here to solve a serious problem that ends up with a lot of sob stories in my mail, not just to look pretty
1252016-09-21T08:57:41  <wumpus> hah
1262016-09-21T08:58:12  <wumpus> even an ugly black 'censored' box would be better than what there is now :p
1272016-09-21T08:58:21  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8371 needs another ACK (or a re-ack from MarcoFalke) before I merge it.
1282016-09-21T08:58:21  <luke-jr> lol
1292016-09-21T08:58:29  <MarcoFalke> ACK
1302016-09-21T08:58:38  <sipa> jonasschnelli: is the header count still wrong due to that signal reporting the best candidate rather than the best header?
1312016-09-21T08:58:43  <MarcoFalke> The github review sucks
1322016-09-21T08:58:53  <jonasschnelli> sipa: Should be right now... because...
1332016-09-21T08:59:12  * jonasschnelli is checking the code...
1342016-09-21T08:59:17  <sipa> we should discuss how to integrate the ack/nack/... things with github review
1352016-09-21T08:59:29  <sipa> what if you approve with a nack? :)
1362016-09-21T08:59:33  <MarcoFalke> Don't use github review
1372016-09-21T08:59:33  <jonasschnelli> clientModel->getHeaderTipTime()
1382016-09-21T08:59:38  <luke-jr> is BlueMatt annoyed at it still? :P
1392016-09-21T09:00:01  <jonasschnelli> sipa: https://github.com/bitcoin/bitcoin/pull/8371/files#diff-0db7dd184df07a48c307ccc182021a68R722
1402016-09-21T09:00:20  <sipa> MarcoFalke: why not?
1412016-09-21T09:00:25  <jonasschnelli> I take the time and height directly from pindexBestHeader
1422016-09-21T09:00:34  <wumpus> why does github review suck? Ithink combining multple comments into one review is pretty useful
1432016-09-21T09:00:36  <jonasschnelli> (each time the singal fires)
1442016-09-21T09:00:39  <MarcoFalke> It shows the changes as approved by me, even though new commits were pushed
1452016-09-21T09:00:44  <sipa> wumpus: agree
1462016-09-21T09:00:44  *** AaronvanW has quit IRC
1472016-09-21T09:01:01  <sipa> MarcoFalke: it does tell you what changes the review was for, no?
1482016-09-21T09:01:07  <MarcoFalke> wumpus: But it does not hide the comments when they are solved
1492016-09-21T09:01:12  <jonasschnelli> MarcoFalke: but the "timeline" implies that you have reviewd on older state?
1502016-09-21T09:01:15  <jonasschnelli> thats indeed bad
1512016-09-21T09:01:24  <jonasschnelli> Do they go away if a commit gets added?
1522016-09-21T09:01:48  <MarcoFalke> Yes "timeline". But it is possible to push commits such that they appear in the past
1532016-09-21T09:01:50  <jonasschnelli> I really dislike the non-removing comments on the source-code...
1542016-09-21T09:01:55  <wumpus> MarcoFalke: that's the same with an ACK, really, the reason for speicfying the commit it was against is to be able to check what exactly you reviewed later, not to de-approve on changes
1552016-09-21T09:02:06  <jonasschnelli> They stay also after a force push or commit that removes that code part
1562016-09-21T09:02:12  <wumpus> and you can still mention the commit in review comments if you want
1572016-09-21T09:02:47  <wumpus> jonasschnelli: that's slightly annoying, yes, otoh it makes the review history clearer
1582016-09-21T09:03:03  <wumpus> so people don't, say, suggest the opposite thing when something has been discussed already
1592016-09-21T09:03:09  <wumpus> hiding can be pretty annoying in that regard
1602016-09-21T09:03:17  <jonasschnelli> Yes. That indeed true..
1612016-09-21T09:03:17  <sipa> i hate it when review commemts automatically disappear
1622016-09-21T09:03:32  <sipa> i want to judge whether a comment still applies
1632016-09-21T09:03:37  <wumpus> yes
1642016-09-21T09:03:42  <jonasschnelli> I just fear very large pages with endless amount of comments/reviews
1652016-09-21T09:03:51  <wumpus> indeed, github's judgement is not very good there
1662016-09-21T09:03:55  <sipa> you can explicitly mark as resolved, no?
1672016-09-21T09:03:56  <jonasschnelli> But right... it makes stuff more obvious for new reviewers
1682016-09-21T09:04:02  <jonasschnelli> I guess no
1692016-09-21T09:04:07  <luke-jr> sipa: that'd be nice, but I've never seen it
1702016-09-21T09:04:11  <wumpus> it just looks if the line changes and then considered the comment invalid
1712016-09-21T09:04:35  <jonasschnelli> wumpus: I think for review-comments, they stay even if the lines gets removed afterwards
1722016-09-21T09:04:41  <sipa> and it used to differ based on whether it was a commit comment or pr comment
1732016-09-21T09:04:55  <MarcoFalke> So use the review thing when you want the comments to stay. And use the old comment thing when the feedback should vanish after being addressed.
1742016-09-21T09:05:12  <luke-jr> MarcoFalke: and then GitHub will change the behaviour under you :P
1752016-09-21T09:05:19  <sipa> MarcoFalke: just a rebase can make comments disappear
1762016-09-21T09:06:14  <MarcoFalke> Well, I use comments to indicate merge conflicts sometimes. I expect them to disappear after
1772016-09-21T09:06:48  *** AaronvanW has joined #bitcoin-core-dev
1782016-09-21T09:07:44  <wumpus> MarcoFalke: you can still add 'single comments'
1792016-09-21T09:08:10  <wumpus> I'd expect them to still be treated the same as before on changes, unsure though
1802016-09-21T09:09:55  <wumpus> 'disappear' is not the right word, I think they never fully disappear, just get collapsed?
1812016-09-21T09:10:21  <wumpus> 'this comment is on a previous version of ...'
1822016-09-21T09:10:34  *** justan0theruser has quit IRC
1832016-09-21T09:11:24  <MarcoFalke> Jup, single comments are the old fashioned comments
1842016-09-21T09:11:43  <MarcoFalke> wumpus: Should I add the DEFAULT_DISABLEWALLET=false in this pull?
1852016-09-21T09:12:07  <wumpus> MarcoFalke: would be nice to do that in one go, yes
1862016-09-21T09:12:27  <jonasschnelli> Luke-Jr: I agree that it would be better to first merge https://github.com/bitcoin/bitcoin/pull/8694 and then improving multiwallet stuff.
1872016-09-21T09:12:53  <jonasschnelli> not sure how easy it is to get this merged in a whole
1882016-09-21T09:13:13  <luke-jr> perhaps I should split the refactors from multiwallet?
1892016-09-21T09:13:14  <jonasschnelli> Luke-Jr: The Qt wallet switch dropdown is also present when you only have a single wallet, right?
1902016-09-21T09:13:15  <wumpus> pretty difficult, better to do the refactoring needed step by step
1912016-09-21T09:13:26  <MarcoFalke> Agree
1922016-09-21T09:13:27  <jonasschnelli> wumpus: Yes. I though so...
1932016-09-21T09:13:28  <luke-jr> jonasschnelli: no, it's hidden with a single wallet
1942016-09-21T09:13:42  <luke-jr> wumpus: it is step by step, in commits :p
1952016-09-21T09:13:52  <MarcoFalke> jonasschnelli's pr is already "minimal". Though several hundred lines
1962016-09-21T09:14:03  <wumpus> if you want to know why, look what killed the first multi-wallet pull years ago, too much changed at once
1972016-09-21T09:14:05  <jonasschnelli> Mostly search and replace thought: https://github.com/bitcoin/bitcoin/pull/8764
1982016-09-21T09:14:07  <wumpus> yes jonasschnelli's PR is minimal
1992016-09-21T09:14:13  <wumpus> luke-jr's not so much
2002016-09-21T09:14:17  <jonasschnelli> I think we need to go in small step PRs
2012016-09-21T09:14:38  <luke-jr> ok, I'll open a new PR with just some refactoring
2022016-09-21T09:14:51  <MarcoFalke> Also, I like the approach of defaultWallet()
2032016-09-21T09:14:51  <luke-jr> unless you think I should do each refactor separately.. ._.
2042016-09-21T09:14:53  <wumpus> I mean there's obviously a compromise here, try to change the world in one PR and no one has the energy to review it, change too little and it's death by a thousand cuts as people don't see the story anymore
2052016-09-21T09:15:16  <jonasschnelli> Luke-Jr: Yes. And sorry for "shooting" in the same direction with https://github.com/bitcoin/bitcoin/pull/8764 I like your mutliwallet PR and really like to boost getting this in
2062016-09-21T09:16:05  <wumpus> lol I had an adverse reaction on seeing the word 'boost' even though it's used in a completely different context
2072016-09-21T09:16:11  <luke-jr> XD
2082016-09-21T09:16:13  <jonasschnelli> hehe
2092016-09-21T09:16:18  * wumpus reads too much code
2102016-09-21T09:17:12  <jonasschnelli> Luke-Jr: What do you think about exposing the addWallet stuff to RPC?
2112016-09-21T09:17:24  <jonasschnelli> the -wallet= approach of adding wallets is kinda limited on runtime
2122016-09-21T09:17:32  <luke-jr> jonasschnelli: intentionally so
2132016-09-21T09:17:38  <wumpus> jonasschnelli: can be sone later
2142016-09-21T09:17:43  <luke-jr> for the "too much in one PR" reason
2152016-09-21T09:17:49  <jonasschnelli> Yes. Thats true
2162016-09-21T09:17:57  <wumpus> runtime wallet loading and unloading is super-spiffy,but harder to get right
2172016-09-21T09:17:59  <luke-jr> changing wallets at runtime makes this a lot more complex
2182016-09-21T09:18:04  <wumpus> yes,that
2192016-09-21T09:18:13  <jonasschnelli> Okay. I see. Agree on that.
2202016-09-21T09:18:46  <luke-jr> (especially closing)
2212016-09-21T09:18:48  <wumpus> same as with the wallet HD support, it's better to do small (but significant) steps at a time
2222016-09-21T09:18:54  <jonasschnelli> Luke-Jr: In my tests, the Qt drop-down stays there even with a single wallet
2232016-09-21T09:19:46  <luke-jr> jonasschnelli: hmm, that's a bug then
2242016-09-21T09:19:56  <luke-jr> IMO
2252016-09-21T09:20:15  <luke-jr> (at least in the current stage, I don't think normal users should be exposed to the feature)
2262016-09-21T09:20:39  <luke-jr> oh, the *debug* dropdown should stay with only one wallet though
2272016-09-21T09:20:43  <luke-jr> because it has a (none) option
2282016-09-21T09:21:27  <jonasschnelli> Okay. I'll test some more...
2292016-09-21T09:21:34  <luke-jr> actually tempting to make that the default, so users have yet one more step to compromise their wallet..
2302016-09-21T09:22:13  <wumpus> how does this pushing-to-others-branches work? say I want to remove the double space in #8769 without that user openeing yet anouther pull request because he can't squash
2312016-09-21T09:22:38  <MarcoFalke> jup
2322016-09-21T09:22:40  <luke-jr> wumpus: never tried, but I speculate you'd do something like the origin-pull remote trick
2332016-09-21T09:22:40  <MarcoFalke> I tried it
2342016-09-21T09:22:44  <wumpus> "Add more commits by pushing to the patch-4 branch on unsystemizer/bitcoin." ah
2352016-09-21T09:22:48  <wumpus> let's just try that
2362016-09-21T09:22:56  <MarcoFalke> git add remote unsys ...
2372016-09-21T09:23:03  <luke-jr> oh, it actually gives you access to his personal repo? :o
2382016-09-21T09:23:03  <MarcoFalke> git push unsys patch-4 -f
2392016-09-21T09:23:13  <MarcoFalke> luke-jr: Only this branch, IIRC
2402016-09-21T09:23:29  <wumpus> MarcoFalke: yes I was thining to difficult, I thought I had to push to some special pulls branch on bitcoin/bitcoin
2412016-09-21T09:23:31  <luke-jr> what happens if I open a PR for one of MarcoFalke's branches? <.<
2422016-09-21T09:24:01  <MarcoFalke> Hmm, good question
2432016-09-21T09:24:17  <luke-jr> MarcoFalke: got something to PR I can try it with?  :D
2442016-09-21T09:24:32  <MarcoFalke> One sec
2452016-09-21T09:25:03  <luke-jr> dad932c needs to be fixed, if you want something trivial
2462016-09-21T09:26:52  <wumpus> "git push -f git@github.com:unsystemizer/bitcoin.git HEAD:patch-4" seems to have worked
2472016-09-21T09:30:47  <wumpus> feels a bit like intruding to push to someone elses repository, but okay, it's very practical in this case
2482016-09-21T09:31:01  <MarcoFalke> luke-jr: https://github.com/bitcoin/bitcoin/compare/master...MarcoFalke:Mf1609-ContributeDoc?expand=1
2492016-09-21T09:31:58  <GitHub92> [bitcoin] luke-jr opened pull request #8771: CONTRIBUTING: Mention not to open several pulls (master...Mf1609-ContributeDoc) https://github.com/bitcoin/bitcoin/pull/8771
2502016-09-21T09:32:06  <luke-jr> no checkbox in this case
2512016-09-21T09:32:49  <GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b4f53641a95d...84c9a048559d
2522016-09-21T09:32:50  <GitHub93> bitcoin/master 04d91f4 unsystemizer: Trivial: Fix ISO URL, capitalization...
2532016-09-21T09:32:50  <GitHub93> bitcoin/master 84c9a04 Wladimir J. van der Laan: Merge #8769: Trivial: Fix ISO URL, capitalization...
2542016-09-21T09:32:51  <luke-jr> hm, review won't let me set a review-type for the PR either. :P
2552016-09-21T09:32:59  <GitHub138> [bitcoin] laanwj closed pull request #8769: Trivial: Fix ISO URL, capitalization (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8769
2562016-09-21T09:34:03  *** jchrome has quit IRC
2572016-09-21T09:36:33  <MarcoFalke> wumpus, can you do "git push -f git@github.com:MarcoFalke/bitcoin.git HEAD:Mf1609-ContributeDoc"?
2582016-09-21T09:36:58  <wumpus> sure, does it matter what I overwrite it with?
2592016-09-21T09:37:06  <luke-jr> it should fail anyway
2602016-09-21T09:37:07  <MarcoFalke> no
2612016-09-21T09:37:18  <MarcoFalke> does not matter
2622016-09-21T09:37:19  <wumpus>  ! [remote rejected] HEAD -> Mf1609-ContributeDoc (permission denied)
2632016-09-21T09:37:52  <luke-jr> good, GitHub isn't totally incompetent. ☺
2642016-09-21T09:38:43  <wumpus> the access control code just became extremely complex though, wouldn't be surprised if someone still discovered a loophole
2652016-09-21T09:39:41  <wumpus> on some level this feature creeps me out
2662016-09-21T09:39:49  <MarcoFalke> Open a pull request to bitcoin:master in some other repo. Force push to bitcoin:master...
2672016-09-21T09:39:52  <sipa> likewise
2682016-09-21T09:39:59  <wumpus> git is meant to be authority-less
2692016-09-21T09:40:06  <luke-jr> it'd make slightly more sense if it had you push to the project's repo (the PR refs), but oh well
2702016-09-21T09:40:53  <wumpus> and it's not like it allows doing anything new, it was already possible to change a branch before merging it, by doing it locally
2712016-09-21T09:41:01  <luke-jr> tempting to try opening a PR against both Core and Classic, and see if one can influence the other..
2722016-09-21T09:41:34  <wumpus> luke-jr: yes. It'd make more sense if it was copy-on-write, and the branch changed to a local branch if a repo owner wants to override it
2732016-09-21T09:42:37  <wumpus> luke-jr: hah
2742016-09-21T09:43:07  <wumpus> that's a clever idea, but let's not do it in this case, we don't want more allegations of attacking classic
2752016-09-21T09:44:35  <GitHub10> [bitcoin] luke-jr opened pull request #8772: [0.13] Backports (0.13...backports-0.13) https://github.com/bitcoin/bitcoin/pull/8772
2762016-09-21T09:48:51  <GitHub137> [bitcoin] luke-jr opened pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (master...bugfix_link_20160921) https://github.com/bitcoin/bitcoin/pull/8773
2772016-09-21T09:51:15  <MarcoFalke> wumpus: Can I get permission to merge doc changes (comments, markdown, ...)?
2782016-09-21T09:53:42  <MarcoFalke> Otherwise I will just ping you when I feel soemthing trivial can be merged
2792016-09-21T09:53:49  <GitHub124> [bitcoin] luke-jr opened pull request #8774: Qt refactors to better abstract wallet access (master...multiwallet_prefactor_qt) https://github.com/bitcoin/bitcoin/pull/8774
2802016-09-21T09:57:07  <GitHub30> [bitcoin] luke-jr opened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
2812016-09-21T09:58:20  *** Yogh has quit IRC
2822016-09-21T09:59:06  *** Yogh has joined #bitcoin-core-dev
2832016-09-21T10:01:19  <GitHub181> [bitcoin] luke-jr opened pull request #8776: Wallet refactoring leading up to multiwallet (master...multiwallet_prefactor_wallet) https://github.com/bitcoin/bitcoin/pull/8776
2842016-09-21T10:01:52  <luke-jr> there we go, I think that's as far as I can go with split PRs until they get merged :p
2852016-09-21T10:06:54  *** JackH has joined #bitcoin-core-dev
2862016-09-21T10:25:04  <wumpus> MarcoFalke: sure
2872016-09-21T10:28:14  <GitHub94> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/84c9a048559d...886e8c9b7269
2882016-09-21T10:28:15  <GitHub94> bitcoin/master fab9107 MarcoFalke: init: Get rid of fDisableWallet
2892016-09-21T10:28:15  <GitHub94> bitcoin/master fa58edb MarcoFalke: [wallet] Introduce DEFAULT_DISABLE_WALLET
2902016-09-21T10:28:16  <GitHub94> bitcoin/master 886e8c9 Wladimir J. van der Laan: Merge #8768: init: Get rid of fDisableWallet...
2912016-09-21T10:28:29  <GitHub81> [bitcoin] laanwj closed pull request #8768: init: Get rid of fDisableWallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8768
2922016-09-21T10:29:56  <wumpus> MarcoFalke: certainly trivial things like https://github.com/bitcoin/bitcoin/pull/8773 you can just merge if they check out
2932016-09-21T10:31:59  <GitHub109> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/886e8c9b7269...52b5a8785de7
2942016-09-21T10:31:59  <GitHub109> bitcoin/master 6f933c6 Luke Dashjr: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
2952016-09-21T10:32:00  <GitHub109> bitcoin/master 52b5a87 MarcoFalke: Merge #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
2962016-09-21T10:32:09  <GitHub143> [bitcoin] MarcoFalke closed pull request #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated (master...bugfix_link_20160921) https://github.com/bitcoin/bitcoin/pull/8773
2972016-09-21T10:33:02  <wumpus> re: wallet, I'd really like to get https://github.com/bitcoin/bitcoin/pull/7551 in
2982016-09-21T10:33:15  <wumpus> I think it's even more important than multiwallet
2992016-09-21T10:33:56  <wumpus> well it's pretty much orthagonal but okay
3002016-09-21T10:34:50  <wumpus> as we can't get around allowing users to import things into the wallet, finally  having a consistent, one-stop call to import things into the wallet would help
3012016-09-21T10:34:56  <sipa> wumpus: thabks for the reminder, eill review
3022016-09-21T10:35:02  <sipa> *will
3032016-09-21T10:35:05  <sipa> *thanks
3042016-09-21T10:35:06  <wumpus> thanks
3052016-09-21T10:38:44  <MarcoFalke> Sry, I think qt no longer compiles on master.
3062016-09-21T10:39:03  <sipa> uh-oh
3072016-09-21T10:39:09  <MarcoFalke> Forgot to #include wallet.h
3082016-09-21T10:39:44  <MarcoFalke> the "introduce DEFAULT_DISABLE_WALLET" is more involved
3092016-09-21T10:39:47  <MarcoFalke> in qt
3102016-09-21T10:39:52  <MarcoFalke> than search and replace
3112016-09-21T10:40:17  <MarcoFalke> might want to properly fix it, now that multiwallet is the goal
3122016-09-21T10:42:54  *** laurentmt has joined #bitcoin-core-dev
3132016-09-21T10:43:08  *** laurentmt has quit IRC
3142016-09-21T10:47:54  <wumpus> let's first get it to compile again
3152016-09-21T10:50:07  <sipa> *commits a #if 0 .. #endif around all .cpp files* - what did you do?! - it compiles again!
3162016-09-21T10:50:27  <wumpus> hehe
3172016-09-21T10:51:05  <wumpus> it's just that 'properly fix it' sounds like something that takes significant time, and I'm held up by this, maybe we should just revert that commit for now? @MarcoFalke
3182016-09-21T10:52:00  <wumpus> then do it the proper way some other time
3192016-09-21T10:52:12  <wumpus> re-do
3202016-09-21T10:53:55  <MarcoFalke> wumpus: Will create a pull
3212016-09-21T10:54:20  <wumpus> but if it involves multiwallet changes may be better to revert the current naive commit for now?
3222016-09-21T10:54:55  <MarcoFalke> should work without multiwallet changes
3232016-09-21T10:55:01  <MarcoFalke> Is this "Method names start with upper case" a style thing?
3242016-09-21T10:55:04  <wumpus> e.g. just fa58edb not the other commitin that pull
3252016-09-21T10:55:18  <wumpus> MarcoFalke: dunno, seems another satoshi-ism
3262016-09-21T10:55:34  <MarcoFalke> I think we have half of the names start upper case and the other half don't
3272016-09-21T10:55:42  <wumpus> qt code uses lowerCamelCase at least
3282016-09-21T10:55:44  <MarcoFalke> Never sure what to use in fresh code
3292016-09-21T10:55:55  <MarcoFalke> ok
3302016-09-21T10:56:26  <wumpus> nah if you sak me for something new and independent I'd suggest using lowerCamelCase, that's a more common C++ naming convention
3312016-09-21T10:56:36  <wumpus> if you change existing code just go with the style of that code
3322016-09-21T10:56:57  <sipa> hmm, nearly all of the existing core code uses capitalized class and function names
3332016-09-21T10:57:06  <sipa> so i'd rather not introduce something else
3342016-09-21T10:57:36  <sipa> the developer notes used to mention this
3352016-09-21T10:57:41  <wumpus> I really have no strong opinion on it
3362016-09-21T10:57:56  <wumpus> I'm fine with either, but don't mix them in one class/unit
3372016-09-21T10:58:39  <wumpus> especially with code I may use for other projects (such as the locked memory manager) I really prefer not to use this weird method capitalization style
3382016-09-21T11:01:38  <wumpus> even c++11 has some assumptions about method and function names starting with lower-case, e.g. range-base for loops expect begin/end() not Begin/End()
3392016-09-21T11:03:03  <wumpus> capitalizing class names, on the other hand, makes sense to keep them apart
3402016-09-21T11:04:11  <sipa> all stl functions are lower_separated_by_underscore()
3412016-09-21T11:04:30  <wumpus> yes, that's a valid choice too
3422016-09-21T11:04:36  <wumpus> snake_case :)
3432016-09-21T11:04:58  <sipa> i perdonally find lowerCaseFollowedByUpper very strange, but it's all highly subjective
3442016-09-21T11:05:04  <wumpus> many projects use that for variables and member variables, that's reasonable sane
3452016-09-21T11:07:21  <wumpus> for method names too, but using it for everything including class names well it's consistent but makes it hard to tell things apart
3462016-09-21T11:08:02  <wumpus> unless you have an editor such as Qt Creator which highlights class names differently from methods differently from class variables, but I don't have that luxury since I switched to vim
3472016-09-21T11:09:07  <wumpus> having a separate naming convention for classes also avoids creating a class with the same name as a function
3482016-09-21T11:10:42  <wumpus> in any case I have no problems with stl-style either, except that it reminds me of boost :-)
3492016-09-21T11:11:48  <GitHub122> [bitcoin] MarcoFalke opened pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
3502016-09-21T11:13:12  <sipa> wumpus: i guess i'm biased because i learned c++ from bitcoin's codebase :)
3512016-09-21T11:13:35  <sipa> well, i knew c++ from university, but that was purely theory without ajy software development experience
3522016-09-21T11:14:42  <wumpus> yes, that can twist your mind :)
3532016-09-21T11:15:35  <wumpus> MarcoFalke: I'm confused by #8777, why do we have a wallet model if the wallet is disabled
3542016-09-21T11:15:50  <wumpus> did I really make it that way?
3552016-09-21T11:16:13  <MarcoFalke> My method is static
3562016-09-21T11:17:21  <wumpus> oh, okay, yes, that can work
3572016-09-21T11:17:50  <MarcoFalke> I think there is no walletModel in case of -disablewallet=1
3582016-09-21T11:18:01  <wumpus> static methods cover no instances, so can apply to all instances
3592016-09-21T11:18:05  <wumpus> yes
3602016-09-21T11:18:07  <wumpus> phew
3612016-09-21T11:19:33  <wumpus> sipa: I think you learned c++ very well considering what you learned it from. Then again, I learned c++ from the MSVC6 manual and MS MFC stuff, so my initial influence is ever so malformed too.
3622016-09-21T11:19:58  <sipa> wumpus: i did know C pretty well beforehand, maybe that helped :)
3632016-09-21T11:21:10  <sipa> also, satoshi's c++ had a weird style, but it also did many things well, i think - hardly any manual memory management, no overuse of class hierarchies, some templating but only where it really avoids a ton of code, ...
3642016-09-21T11:22:17  <wumpus> yes that's true, it has its positive sides. It's just that he was bad at isolating aspects from each other, and code organization.
3652016-09-21T11:22:18  <MarcoFalke> So let's fetch some tea until travis clears the backlog
3662016-09-21T11:23:34  <sipa> wumpus: /me still recalls the call to mark a key as used from inside the script validation code, wallet being in main.cpp, and direct calls into the wx code from inside block validation :)
3672016-09-21T11:24:54  *** cryptapus has joined #bitcoin-core-dev
3682016-09-21T11:27:47  <wumpus> sipa: hah!
3692016-09-21T11:28:29  <wumpus> MarcoFalke: we could cancel all the preceeding builds as they're going to fail anyway
3702016-09-21T11:30:29  <MarcoFalke> done. Should pick up the pull now
3712016-09-21T11:31:33  <MarcoFalke> reminds me that no entry in the travis matrix has qt builds enabled
3722016-09-21T11:31:57  <MarcoFalke> IIRC osx cross build does it (silently)
3732016-09-21T11:32:02  <wumpus> that was disabled for *somereason cfields probably knows*
3742016-09-21T11:32:14  <MarcoFalke> timeouts?
3752016-09-21T11:32:30  <wumpus> possibly timeout-related back when there were problems with caching after the travis trusty switch
3762016-09-21T11:32:40  <wumpus> yes
3772016-09-21T11:34:14  <MarcoFalke> Also, I thought about switching to docker within travis, but then the travis script is already complicated and it won't get better/easier, as there are no dockerfiles for native osx and native win
3782016-09-21T11:34:56  <wumpus> yea docker solves a problem we don't have, here
3792016-09-21T11:35:15  <MarcoFalke> Was on an unrelated note  ;)
3802016-09-21T11:35:31  *** murch has joined #bitcoin-core-dev
3812016-09-21T11:35:59  <MarcoFalke> (travis has no plans to switch to xenial soon)
3822016-09-21T11:36:06  <wumpus> testing native osx/win would be interesting, but I guess that runs into license issues
3832016-09-21T11:36:26  <MarcoFalke> Oh, travis has native osx?
3842016-09-21T11:36:49  <wumpus> and in the case of windows multi-stage issues: we want to build on trusty, then run the tests on an actualwindows machine
3852016-09-21T11:37:46  <wumpus> though WINE is really convenient here and I have never seen any issues where wine didn't detect a problem that real windows would. WINE seems to be *stricter* in API correctness
3862016-09-21T11:39:07  <MarcoFalke> (Right now we are bound to whatever ubuntu 14.04 provides us. Though, deterministic builds of the toolchain would help to untangle this)
3872016-09-21T11:39:35  <wumpus> switching to xenial would be a disaster right now, esp for windows build
3882016-09-21T11:40:28  <wumpus> I should likely put https://github.com/bitcoin/bitcoin/pull/8249 on ice; having less effective ASLR is great compared to the alternative of crashing with stack protectors :)
3892016-09-21T11:40:30  <MarcoFalke> No one detected this. We should have run tests on xenial at least for the release
3902016-09-21T11:40:50  <MarcoFalke> But then it is unfeasible to try every os and combination of toolchains
3912016-09-21T11:41:06  <wumpus> well this is a cross build issue that didn't get detected
3922016-09-21T11:41:11  <wumpus> we can't test every toolchain in existence
3932016-09-21T11:41:22  <wumpus> right
3942016-09-21T11:41:45  <wumpus> unfortunately, there are plenty of mingw toolchains that create absolutely broken windows code
3952016-09-21T11:41:45  <MarcoFalke> So cfields work sounds like the right step
3962016-09-21T11:41:56  <wumpus> we used to have that issue, and now it's back
3972016-09-21T11:42:57  <MarcoFalke> Looks like travis likes my pull.
3982016-09-21T11:43:12  * MarcoFalke off
3992016-09-21T11:43:24  <wumpus> I wonder if switching to clang would help there. From what I've heard from some infosec related people the clang windows support is getting pretty good, and MSFT is even contributing to it. And Mozilla uses it to build Rust binaries (unsure if they use it for building firfox for windows)
4002016-09-21T11:43:27  <wumpus> thanks ,going to merge it
4012016-09-21T11:44:34  <wumpus> cfields: ^^ re clang and windows, should we consider that?
4022016-09-21T11:45:07  <wumpus> would be worth an experiment at least I guess
4032016-09-21T11:45:21  *** jchrome has joined #bitcoin-core-dev
4042016-09-21T11:45:44  <GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/52b5a8785de7...fec6af744014
4052016-09-21T11:45:44  <GitHub146> bitcoin/master 6666ca6 MarcoFalke: [qt] WalletModel: Expose disablewallet
4062016-09-21T11:45:45  <GitHub146> bitcoin/master fec6af7 Wladimir J. van der Laan: Merge #8777: [qt] WalletModel: Expose disablewallet...
4072016-09-21T11:45:58  <GitHub97> [bitcoin] laanwj closed pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
4082016-09-21T11:57:38  *** PaulCapestany has quit IRC
4092016-09-21T12:00:24  *** rubensayshi has quit IRC
4102016-09-21T12:00:34  *** PaulCapestany has joined #bitcoin-core-dev
4112016-09-21T12:01:06  *** jchrome has quit IRC
4122016-09-21T12:06:09  *** PaulCapestany has quit IRC
4132016-09-21T12:06:54  *** jchrome has joined #bitcoin-core-dev
4142016-09-21T12:14:05  <GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fec6af744014...cf5ebaa921a9
4152016-09-21T12:14:06  <GitHub170> bitcoin/master 7c069a7 Pavel Janík: Do not shadow global variable
4162016-09-21T12:14:06  <GitHub170> bitcoin/master cf5ebaa Wladimir J. van der Laan: Merge #8656: Trivial: Do not shadow global variable fileout...
4172016-09-21T12:14:15  <GitHub191> [bitcoin] laanwj closed pull request #8656: Trivial: Do not shadow global variable fileout (master...20160902_Wshadow_fileout) https://github.com/bitcoin/bitcoin/pull/8656
4182016-09-21T12:16:33  *** Alina-malina has quit IRC
4192016-09-21T12:16:55  *** jchrome has quit IRC
4202016-09-21T12:21:18  *** Alina-malina has joined #bitcoin-core-dev
4212016-09-21T12:23:11  *** jchrome has joined #bitcoin-core-dev
4222016-09-21T12:24:56  *** Alina-malina has quit IRC
4232016-09-21T12:24:56  *** Alina-malina has joined #bitcoin-core-dev
4242016-09-21T12:27:02  *** cryptapus_ has joined #bitcoin-core-dev
4252016-09-21T12:29:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4262016-09-21T12:31:16  *** cryptapus has quit IRC
4272016-09-21T12:35:24  *** jchrome has quit IRC
4282016-09-21T12:44:04  <wumpus> jonasschnelli: btw I registered for http://coredev.tech/nextmeeting_tmp.html some time ago but my name is not appearing yet, did something go wrong?
4292016-09-21T12:44:50  <sipa> wumpus: you're on http://coredev.tech/nextmeeting.html ?
4302016-09-21T12:45:04  <wumpus> oh I have the wrong link, okay
4312016-09-21T12:45:16  <wumpus> yep
4322016-09-21T12:50:20  <GitHub78> [bitcoin] MarcoFalke closed pull request #8536: [qa] Adjust poll interval for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536
4332016-09-21T12:50:57  <jonasschnelli> wumpus: Yes. Your listed... need to remove the *_tmp.html files!
4342016-09-21T12:51:12  <jonasschnelli> I updated the page right after you submitted your form. :)
4352016-09-21T12:52:06  <jonasschnelli> Ah. instagibbs just submitted the form as well...
4362016-09-21T12:52:47  <instagibbs> i saw it being discussed here
4372016-09-21T12:53:44  * jonasschnelli didn't know that wumpus is in the plubming business. .. :)
4382016-09-21T12:54:35  <jonasschnelli> *plumbing
4392016-09-21T12:55:04  *** cryptapus_ is now known as cryptapus
4402016-09-21T13:05:01  *** Chris_Stewart_5 has quit IRC
4412016-09-21T13:06:26  <MarcoFalke> jonasschnelli: I think you forgot to merge the overlay pull this morning :)
4422016-09-21T13:07:50  <jonasschnelli> MarcoFalke: I was hoping someone did another review,.. but will merge in the next couple of hours.
4432016-09-21T13:08:02  <jonasschnelli> *someone will do
4442016-09-21T13:08:43  <BlueMatt> luke-jr: they seem to have partially fixed the email issues
4452016-09-21T13:08:45  <BlueMatt> github, that is
4462016-09-21T13:09:02  <BlueMatt> as of yesterday i was still getting duplicate emails from them, but at least they're properly threaded
4472016-09-21T13:10:42  <jonasschnelli> BlueMatt: while your here.. :), do you use the contrib/debian packaging dir for your bitcoin PPA?
4482016-09-21T13:11:10  <BlueMatt> i forked off of it a while ago, but anything something gets updated in contrib/debian i re-sync it
4492016-09-21T13:11:29  <BlueMatt> iirc the only real difference is package description (the new one is pretty terrible, iirc) and changelog
4502016-09-21T13:11:44  <BlueMatt> new as of like 3 versions ago, that is
4512016-09-21T13:12:28  <jonasschnelli> BlueMatt: I guess we should add zmq to the dependencies
4522016-09-21T13:12:46  <jonasschnelli> which probably should result compiling with zmq
4532016-09-21T13:12:56  <BlueMatt> oh, thats another difference - upnp is not built-in
4542016-09-21T13:13:06  <BlueMatt> because of the security issues a while back, and i never re-added it
4552016-09-21T13:13:06  <jonasschnelli> otherwise our "official" binary comes with zmq while the PPA does not
4562016-09-21T13:13:11  <BlueMatt> but no one has complained, so whatever
4572016-09-21T13:13:25  <BlueMatt> yea, could add zmq, though also security-swiss-cheese
4582016-09-21T13:13:33  <BlueMatt> but maybe i should....
4592016-09-21T13:14:00  <jonasschnelli> I would argue that if you like to use ZMQ, you should self-compile... but, yeah...
4602016-09-21T13:14:42  <BlueMatt> i mean ive never heard any complaints about that or upnp
4612016-09-21T13:15:02  <wumpus> zmq is only used for notification, and disabled by default
4622016-09-21T13:15:09  <BlueMatt> (not that that indicates much, people like to keep complaints to themselves, mostly)
4632016-09-21T13:15:28  <BlueMatt> wumpus: I'm aware, but so is upnp in bitcoind, and its still gross :p
4642016-09-21T13:16:02  <BlueMatt> though i did actually get like 2/3 emails about the 12.04 empty-package update, which i found impressive
4652016-09-21T13:16:08  <wumpus> yes, it's up to you as maintainer, please do explain that in the issue
4662016-09-21T13:16:47  <BlueMatt> hmm? was an issue opened for this? sorry, I havent checked github emails in a day, I'll get caught up on github when I'm done with breakfast
4672016-09-21T13:16:48  <wumpus> people really shouldn't complain to us about the PPAs, though i guess the ppa doesn't have its own issue tracker
4682016-09-21T13:16:56  <wumpus> yes there's an issue, let em see
4692016-09-21T13:17:12  <sipa> BlueMatt: a few people in #bitcoin were confused by bitcoind disappearing
4702016-09-21T13:17:13  <jonasschnelli> we have contrib/debian though
4712016-09-21T13:17:34  <BlueMatt> oh, well if someone complained I can add it
4722016-09-21T13:17:45  <BlueMatt> sipa: yea, if i get emails then #bitcoin is generally guaranteed to complain
4732016-09-21T13:17:49  <BlueMatt> not much i could do, though :/
4742016-09-21T13:17:58  <sipa> BlueMatt: maybe a #!/bin/sh echo "The Bitcoin Core PPA no longer supports Ubuntu 12.04" would be better than just empty package?
4752016-09-21T13:18:29  <wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/issues/8759
4762016-09-21T13:18:32  <BlueMatt> i was later informed that you can make the updater pop up the package changelog during the update process so people have to read it, though i assume the gui tools might hide it
4772016-09-21T13:18:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4782016-09-21T13:18:55  <wumpus> BlueMatt: yes, I've seen that only once, the GUI tools do show it
4792016-09-21T13:19:20  <wumpus> it's meant for really critical notifications regarding a package, I guess this qualifies
4802016-09-21T13:19:37  <BlueMatt> indeed
4812016-09-21T13:21:32  <wumpus> btw re: github mails I found out that it's possible to filter mails where you're personally notified from the rest of the bulk by filtering for "to:mention@noreply.github.com", may be useful
4822016-09-21T13:22:15  * BlueMatt ponders maildrop rule therefor
4832016-09-21T13:22:21  <wumpus> I started receiving so many github mails that that's the only ones I read at at the moment
4842016-09-21T13:23:22  <wumpus> (of course I tend to read the rest, but on github.com, not in my mailbox)
4852016-09-21T13:25:16  <wumpus> in any case please comment on #8759. I don't mind personally whether you want to support zmq or not, but the decision should be documented
4862016-09-21T13:26:21  <wumpus> jonasschnelli: at least the manpages will be gone from there now
4872016-09-21T13:28:36  <BlueMatt> wumpus: yep, still eating breakfast, give me a few :p
4882016-09-21T13:29:03  <wumpus> BlueMatt: yes I don't mean to hurry :p
4892016-09-21T13:32:57  <wumpus> re: the new github review system, is it possible to un-approve a pull?
4902016-09-21T13:34:06  *** Chris_Stewart_5 has quit IRC
4912016-09-21T13:40:35  *** PaulCapestany has joined #bitcoin-core-dev
4922016-09-21T13:40:48  *** DigiByteDev has quit IRC
4932016-09-21T13:41:35  *** DigiByteDev has joined #bitcoin-core-dev
4942016-09-21T13:47:06  *** PaulCapestany has quit IRC
4952016-09-21T13:48:56  *** PaulCapestany has joined #bitcoin-core-dev
4962016-09-21T13:53:39  *** aalex has joined #bitcoin-core-dev
4972016-09-21T13:53:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4982016-09-21T14:05:05  *** DigiByteDev has quit IRC
4992016-09-21T14:05:15  *** DigiByteDev_ has joined #bitcoin-core-dev
5002016-09-21T14:22:12  *** xinxi has joined #bitcoin-core-dev
5012016-09-21T14:23:05  <xinxi> Hi guys, are any documents on how to add a new type of address?
5022016-09-21T14:23:51  *** DigiByteDev_ has quit IRC
5032016-09-21T14:24:29  <xinxi> For example, if I want to use public key directly as the address using of using hash160, what should I do given that we don't care about quantum resistance?
5042016-09-21T14:28:59  *** xinxi has quit IRC
5052016-09-21T14:31:45  *** xinxi has joined #bitcoin-core-dev
5062016-09-21T14:40:30  *** veleiro has joined #bitcoin-core-dev
5072016-09-21T14:41:52  *** cryptapus has quit IRC
5082016-09-21T14:42:07  *** paveljanik has joined #bitcoin-core-dev
5092016-09-21T14:42:07  *** paveljanik has joined #bitcoin-core-dev
5102016-09-21T14:42:19  *** cryptapus has joined #bitcoin-core-dev
5112016-09-21T14:42:43  <instagibbs> murch: I'd be interested to see what effect, if any, witness discounting would have on effective paid fees per algorithm
5122016-09-21T14:44:11  <murch> instagibbs: Lemme have a look at the results
5132016-09-21T14:51:38  *** bsm117532 has quit IRC
5142016-09-21T14:52:11  *** bsm117532 has joined #bitcoin-core-dev
5152016-09-21T14:54:07  <murch> instagibbs: Fees are almost exactly halved through the bench.
5162016-09-21T14:54:25  <murch> https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
5172016-09-21T14:55:02  <murch> instagibbs: I've uploaded the whole output table here ^
5182016-09-21T14:55:40  <sipa> murch: do any of the algorithms behave significantly better/worse (in terms of average number of transaction inputs) with and without segwit?
5192016-09-21T14:55:54  <sipa> or number of utxos held
5202016-09-21T14:59:56  <murch> sipa: Good question. Actually, Core seems to have a significantly increased average UtxoPool size. With P2WPKH it's 70% bigger (×1.7). Only Core significantly changes though.
5212016-09-21T15:01:39  <murch> Input set size has also a much bigger deviation for Core under P2WPKH. I'm weirded out by that though. I'll have to check whether that is reproducable.
5222016-09-21T15:03:57  <instagibbs> murch: are total fees in satoshis or?
5232016-09-21T15:04:05  <murch> instagibbs: Yes.
5242016-09-21T15:04:59  <murch> instagibbs: All bitcoin values are in satoshi.
5252016-09-21T15:07:12  *** Giszmo has quit IRC
5262016-09-21T15:11:34  *** aalex has quit IRC
5272016-09-21T15:11:52  *** Giszmo has joined #bitcoin-core-dev
5282016-09-21T15:13:26  *** aalex has joined #bitcoin-core-dev
5292016-09-21T15:16:32  *** skyraider has joined #bitcoin-core-dev
5302016-09-21T15:19:08  *** d4de has joined #bitcoin-core-dev
5312016-09-21T15:19:38  <skyraider> hi, i'm getting some odd bitcoind errors on startup - the tor disconnect callback seems to be firing, but i have nothing about tor in my config file
5322016-09-21T15:19:57  <skyraider> https://www.irccloud.com/pastebin/rENd1qLg/tor%20disconnect%20callback%20incorrectly%20firing%20on%200.13.0
5332016-09-21T15:20:12  <d4de> I was surprised today by a bunch of tor client messages in our systems. Why not SOCKS5?
5342016-09-21T15:20:39  <sipa> skyraider: it's just trying to reach the tor control port to open a socket
5352016-09-21T15:20:49  <skyraider> (for additional context, this pull request supposedly fixes that message, but apparently not https://github.com/bitcoin/bitcoin/pull/7637)
5362016-09-21T15:20:52  <sipa> it's enabled by default, but doesn't do anything if you don't have tor running
5372016-09-21T15:21:02  <skyraider> sipa: ah, so it's harmless?
5382016-09-21T15:21:17  <sipa> yes
5392016-09-21T15:21:21  <skyraider> thanks
5402016-09-21T15:21:31  <sipa> that PR just prevents it from spamming your debug.log all the time
5412016-09-21T15:21:36  <sipa> now it just mentions it onc
5422016-09-21T15:21:38  <sipa> *once
5432016-09-21T15:22:47  <sipa> you can disable it by setting listenonion=0 in bitcoin.conf
5442016-09-21T15:22:53  <sipa> or running with -nolistenonion
5452016-09-21T15:25:41  <skyraider> hmm, i received several warnings... 6, it seems
5462016-09-21T15:28:32  <sipa> that's unexpected
5472016-09-21T15:28:47  <skyraider> listenonion=0 is effective, though. no warning after applying that config setting.
5482016-09-21T15:35:33  *** Sosumi has joined #bitcoin-core-dev
5492016-09-21T15:46:48  *** JackH has quit IRC
5502016-09-21T16:08:58  <gmaxwell> murch: is your 'corewallet' with or without the extra input removal?
5512016-09-21T16:09:16  <murch> gmaxwell: Without pruning
5522016-09-21T16:09:23  <murch> i.e. extra input removal
5532016-09-21T16:09:39  <gmaxwell> okay
5542016-09-21T16:11:51  <murch> gmaxwell: That's actually the only difference between BreadWallet and Mycelium: Both do FIFO and Mycelium additionally minimizes the input set by removing extra inputs. As you see, it has a huge impact on the mean Utxo set size.
5552016-09-21T16:13:35  <murch> gmaxwell: You might also find this table with more evaluation criteria interesting: https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml (same as posted above)
5562016-09-21T16:14:07  <gmaxwell> how do the wallets doing fifo handle it if they get dustspammed? (someone pays them more tiny inputs than they can fit in a single txn?)
5572016-09-21T16:16:23  <BlueMatt> murch: in your analysis, I'm assuming AndroidWallet is just the old bitcoinj code I wrote many years ago and not something AndroidWallet specific?
5582016-09-21T16:16:44  <murch> BlueMatt: Yes, it's the coin selector from BitcoinJ.
5592016-09-21T16:16:57  <gmaxwell> BlueMatt: the paper says it uses "value * inputAge"
5602016-09-21T16:17:10  <BlueMatt> gmaxwell: it was written when using priority as selection wasnt insane :p
5612016-09-21T16:17:22  <BlueMatt> murch: is your "fee spent" thing just tx size * fee something, or does it actually analyze the code's fee selection behavior?
5622016-09-21T16:18:12  <BlueMatt> murch: have you tested the bitcoinj thing with a coinselector which does something smarter (like picking smallest-bigger-than-desired) even if its dead-simple?
5632016-09-21T16:18:18  <murch> gmaxwell: In their selector I didn't see any special checks for small inputs, they may have checks in their utxo pool management though. I didn't check that.
5642016-09-21T16:18:36  <murch> BlueMatt: It uses a flat fee of 10 satoshi per byte.
5652016-09-21T16:18:53  <BlueMatt> murch: ok, cool, yea, so it generates the smallest total tx bytes
5662016-09-21T16:20:03  <murch> BlueMatt: I added block height to the UTXO in order to give the BitcoinJ coin selector a better chance (instead of just selecting the largest always). My time model is very simple though and just jumps Gaussian time steps between transactions.
5672016-09-21T16:20:30  <murch> BlueMatt: Unfortunately, my scenario data does not contain actual time information.
5682016-09-21T16:21:14  <BlueMatt> murch: i mean the bitcoinj thing is now braindead as fuck...it made sense way back when it was written but the fact that it hasnt been updated since is surpsiing to me, because thats insane
5692016-09-21T16:21:51  <murch> BlueMatt: I have not checked just selecting "smallest bigger" yet. I just replicated what I found in the code.
5702016-09-21T16:23:07  <gmaxwell> BlueMatt: you mean making the final utxo set 126 times larger than bitcoin core isn't good?
5712016-09-21T16:23:44  <BlueMatt> murch: wait, did you take the like overcomplicated thing in the wallet that tries to figure out if change is reasonable, or just do the priority-based selection
5722016-09-21T16:23:45  <murch> BlueMatt: Perhaps there is a misunderstanding here: I have just replicated the coin selection behavior. I have also replicated fee estimation to the point that some wallets will always assume a change output and pay for it. I have not replicated how fee levels are estimated for each wallet.
5732016-09-21T16:24:20  <BlueMatt> gmaxwell: i mean now its essentially just randomly selecting shit...like ignore that its making the utxo set larger its just like selecting things almost randomly because it hasnt been updated to realize that priority hasnt been a thing for a year or two now
5742016-09-21T16:25:03  <BlueMatt> murch: did you emulate public FeeCalculation calculateFee(SendRequest req, Coin value, List<TransactionInput> originalInputs,
5752016-09-21T16:25:03  <BlueMatt>                                        boolean needAtLeastReferenceFee, List<TransactionOutput> candidates) throws InsufficientMoneyException {
5762016-09-21T16:25:04  <BlueMatt> ?
5772016-09-21T16:25:25  <BlueMatt> I mean because that is, essentially, the actual coin selection algorithm, not just CoinSelector
5782016-09-21T16:26:42  <murch> BlueMatt: Having a look, sorry it's been a few weeks
5792016-09-21T16:26:47  <BlueMatt> yea, np
5802016-09-21T16:27:14  *** xinxi has quit IRC
5812016-09-21T16:27:34  <BlueMatt> god this code is soooo old
5822016-09-21T16:27:42  <BlueMatt> wow, does no one maintain bitcoinj at all? how was this not replaced
5832016-09-21T16:30:02  <instagibbs> murch: i think you should try to control for estimated fees as much as possible. Hard to disentagle fees vs utxos with current data
5842016-09-21T16:30:19  <gmaxwell> murch: so is your codebase in a position to try more hypothetical algorithims?
5852016-09-21T16:31:32  <murch> BlueMatt: I had missed "calculateFee", I had only discovered the CoinSelector.
5862016-09-21T16:32:13  <BlueMatt> murch: oh shit, that will probably significantly effect your simulation
5872016-09-21T16:32:34  <murch> gmaxwell: I was planning to provide it around Scaling Bitcoin. There was a few more things I wanted to do before publishing it. Trying other strategies is a case of inheritance and overriding a single function though.
5882016-09-21T16:33:17  *** jchrome has joined #bitcoin-core-dev
5892016-09-21T16:33:28  <murch> BlueMatt: I should have written to the mailing list earlier. (._.)
5902016-09-21T16:33:52  <BlueMatt> murch: well either way you re-confirmed what we all knew: bitcoinj is unmaintained and its use should be significantly discouraged
5912016-09-21T16:34:44  *** xinxi has joined #bitcoin-core-dev
5922016-09-21T16:35:04  <murch> BlueMatt: Is it as complex as it looks. Could you walk me through how it influences Coin Selection from the top of your head, if it isn't too complicated?
5932016-09-21T16:36:11  <murch> instagibbs: I was actually just looking at Coin Selection strategies and had in the beginning completely avoided fee estimation. I added fees after I realized how deeply ingrained fee estimation was in Core's coin selection.
5942016-09-21T16:36:41  <murch> Seems like I'm misrepresenting BitcoinJ here then.
5952016-09-21T16:36:58  <murch> perhaps also the other wallets.
5962016-09-21T16:37:51  <BlueMatt> murch: hmmm, i cant say i recall exactly what the behavior there is...its also very much based on what bitcoin core did at the time (and its non-fee anti-spam measures)
5972016-09-21T16:38:01  <BlueMatt> murch: is your simulator in java? that code is very standalone
5982016-09-21T16:38:15  <sipa> i don't understand why fee estimation matters
5992016-09-21T16:38:16  <murch> BlueMatt: Scala actually.
6002016-09-21T16:38:37  <BlueMatt> sipa: its not really fee estimation, its the thing that selects between coin selection options and change
6012016-09-21T16:38:41  <BlueMatt> ie whether to throw away change
6022016-09-21T16:38:58  <sipa> for a comparable simulation across clients you should assume a constant approximate feerate on the network
6032016-09-21T16:39:01  <BlueMatt> murch: so you can just drop that function in, mostly? I actually have no idea about scala tooling
6042016-09-21T16:39:09  <murch> sipa: E.g. Bitcoin Core uses an initial guess of the fee to restrict solutions in the selection pass through. It will only update the fee guess after the selection attempt if it didn't produce a satisfying result.
6052016-09-21T16:39:10  <BlueMatt> sipa: he does that
6062016-09-21T16:39:15  <sipa> and use the same fees in multiple tools
6072016-09-21T16:39:36  <sipa> murch: ah! you mean fee estimation of the transaction you are creating
6082016-09-21T16:39:42  <sipa> not feerate estimation on the network
6092016-09-21T16:40:48  <murch> sipa: I did assume a constant fee rate of 10 satoshi per byte. There are some minor differences how wallets apply it though. (E.g. some always pay for a change output.)
6102016-09-21T16:41:49  <murch> BlueMatt: Scala can call any Java class. But I'm a bit confused at this point: Does the calculateFee code just check whether to drop the change or create it, or does it change the actual selection?
6112016-09-21T16:42:08  *** xinxi has quit IRC
6122016-09-21T16:42:20  *** jchrome has quit IRC
6132016-09-21T16:42:29  <BlueMatt> murch: it takes the CoinSelector and will call it three times, and select between the options based on what the resulting change is
6142016-09-21T16:43:01  *** xinxi has joined #bitcoin-core-dev
6152016-09-21T16:43:13  <murch> BlueMatt: o.0 I had the impression that the CoinSelector is deterministic?!
6162016-09-21T16:44:59  <BlueMatt> i dont recall 100% how it works, iirc its something like "first call with the amount you need, then, if you got a change value which you were gonna throw away, call it again with enough additional to not throw away the change, and then there is a third case that does X"
6172016-09-21T16:46:19  <murch> sipa: I should probably stress that my simulation does not cover fee levels. I've just applied a common fee estimation to all wallets that prescibes 10 satoshi per byte. The figures for the fees in my results are therefore essentially an abstraction of "inputs spent", "outputs created" and "changes created".
6182016-09-21T16:47:08  <sipa> murch: that seems desirable to me
6192016-09-21T16:47:09  <murch> BlueMatt: Ah, thanks. Now I get what you meant. I should probably be able to replicate that no problem.
6202016-09-21T16:47:15  <sipa> (the way you do it)
6212016-09-21T16:47:38  <sipa> otherwise there is the added variance of how wallets determine fees
6222016-09-21T16:48:38  <murch> sipa: Yeah, and it would have also blown the overhead for my simulation out of proportion. I'll add it to "Future Work". ;)
6232016-09-21T16:50:44  <murch> gmaxwell: Did you have something in particular in mind to try? We (sipa, you, instagibbs, me) did discuss this a few months ago already though. And I've also read your Bitcoin Wiki page on Coin Selection. :)
6242016-09-21T16:55:50  * murch will be back after dinner
6252016-09-21T17:02:11  <gmaxwell> murch: 10sat/byte or per weight? (how does the segwit analysis change it?)
6262016-09-21T17:05:04  <gmaxwell> murch: so are you not modling the behavior where very small change out is converted into fee to avoid creating change?
6272016-09-21T17:13:39  <xinxi> gmaxwell: CT uses ECDH, which is not quantum resistant. Why not use a quantum resistant key exchange crypto algorithm?
6282016-09-21T17:14:19  <instagibbs> xinxi: maybe #bitcoin-wizards ?
6292016-09-21T17:14:54  <xinxi> instagibbs: what's that for?
6302016-09-21T17:15:27  <instagibbs> this channel is for near-term bitcoin core development, your question is about an implementation of elements sidechain and/or future quantum advances
6312016-09-21T17:15:35  <instagibbs> that channel is more suitable
6322016-09-21T17:15:44  <xinxi> instagibbs: OK.
6332016-09-21T17:15:56  <instagibbs> I can answer you there
6342016-09-21T17:18:57  <GitHub24> [bitcoin] MarcoFalke opened pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
6352016-09-21T17:28:02  <gmaxwell> murch: as far as changes, there are a number of simple strategies I'd try.  E.g. try to form a zero change transaction, converting up to X to extra fees,  failing that, add a change output, and spend all coins paid to a selected address when any are spent.  If change >2x the payment, create two change outputs, randomly selecting splitting the change in half or making one equal to the payment.
6362016-09-21T18:14:43  *** harrymm has quit IRC
6372016-09-21T18:22:52  *** skyraider has quit IRC
6382016-09-21T18:48:35  *** Guyver2 has joined #bitcoin-core-dev
6392016-09-21T18:52:29  <GitHub54> [bitcoin] MarcoFalke opened pull request #8780: [rpc] Deprecate getinfo (master...Mf1609-getinfoDeprecate) https://github.com/bitcoin/bitcoin/pull/8780
6402016-09-21T18:54:14  *** davec has quit IRC
6412016-09-21T18:55:06  *** davec has joined #bitcoin-core-dev
6422016-09-21T19:00:24  *** xinxi has quit IRC
6432016-09-21T19:02:03  *** xinxi has joined #bitcoin-core-dev
6442016-09-21T19:02:05  <gmaxwell> MarcoFalke: please include more explination in your commit messages (/pull requs); e.g. the getinfo deprecate should give the short reason for it (replaced by rpc x/y/z)
6452016-09-21T19:04:38  <gmaxwell> jonasschnelli: on the sweep thing (#8763); I agree the functionality would be useful. But I'm somewhat torn-- we really should be avoiding introducing pruning incompatible functionality, and right now recan is so slow as to be more or less useless.
6462016-09-21T19:07:00  *** xinxi has quit IRC
6472016-09-21T19:07:04  <gmaxwell> I suppose a sweep could instead work from the utxo set without loss.
6482016-09-21T19:13:19  *** [Author] has quit IRC
6492016-09-21T19:15:36  *** jtimon has quit IRC
6502016-09-21T19:26:30  *** murch1 has joined #bitcoin-core-dev
6512016-09-21T19:27:30  *** murch has quit IRC
6522016-09-21T19:34:40  *** harrymm has joined #bitcoin-core-dev
6532016-09-21T19:45:42  *** instagibbs has quit IRC
6542016-09-21T19:46:01  *** cdecker has joined #bitcoin-core-dev
6552016-09-21T19:46:47  <GitHub125> [bitcoin] MarcoFalke opened pull request #8781: [contrib] delete qt_translations.py (master...Mf1609-deleteQtTrans) https://github.com/bitcoin/bitcoin/pull/8781
6562016-09-21T19:49:01  <MarcoFalke> I am looking for stuff but can only find outdated crap...
6572016-09-21T19:54:59  *** Guyver2 has quit IRC
6582016-09-21T20:02:18  *** Chris_Stewart_5 has quit IRC
6592016-09-21T20:03:20  *** xinxi has joined #bitcoin-core-dev
6602016-09-21T20:04:41  *** cryptapus has quit IRC
6612016-09-21T20:10:31  *** jnewbery has joined #bitcoin-core-dev
6622016-09-21T20:10:33  *** xinxi has quit IRC
6632016-09-21T20:20:06  *** instagibbs has joined #bitcoin-core-dev
6642016-09-21T20:26:45  *** jnewbery has quit IRC
6652016-09-21T20:30:47  *** jl2012 has quit IRC
6662016-09-21T20:44:44  *** crudel has quit IRC
6672016-09-21T20:57:41  *** laurentmt has joined #bitcoin-core-dev
6682016-09-21T21:07:46  *** xinxi has joined #bitcoin-core-dev
6692016-09-21T21:08:31  *** jnewbery has joined #bitcoin-core-dev
6702016-09-21T21:10:02  *** laurentmt has quit IRC
6712016-09-21T21:14:16  *** xinxi has quit IRC
6722016-09-21T21:22:08  <BlueMatt> <instagibbs> pfrom->GetLocalServices() & NODE_WITNESS && (nCMPCTBLOCKVersion == 2)
6732016-09-21T21:22:09  <BlueMatt> <instagibbs> pfrom is referring to the remote node's flags, I hope
6742016-09-21T21:22:11  <BlueMatt> ...
6752016-09-21T21:22:19  <BlueMatt> <BlueMatt> I think nLocalServices refers to YOUR services
6762016-09-21T21:22:22  <instagibbs> apparently not we learned, which confused the hell out of me
6772016-09-21T21:22:26  <BlueMatt> <BlueMatt> and you store it in every CNode object
6782016-09-21T21:22:28  <BlueMatt> is that true?
6792016-09-21T21:22:31  <BlueMatt> that seems...fun?
6802016-09-21T21:22:45  <instagibbs> nServices is the remote's services
6812016-09-21T21:22:57  <sipa> will check
6822016-09-21T21:22:59  <instagibbs> but both are stored on CNode
6832016-09-21T21:22:59  <BlueMatt> seems like an easy optimization for cfields to fix?
6842016-09-21T21:24:13  <instagibbs> well it could be a way to remember which services you promised without reconnecting?
6852016-09-21T21:24:40  <instagibbs> ie remembering what other node will have for nExpectedServices
6862016-09-21T21:25:55  <luke-jr> irssi exploit: https://irssi.org/security/irssi_sa_2016.txt (seems like a repeat of CVE-2003-1020, so may wish to consider whether there might be more unfound exploits..)
6872016-09-21T21:26:32  <sipa> BlueMatt: i believe it was done because nLocalServices can change - by copying it into the CNode we have an immutable value that never changes, and also tells us what local services we announced to that peer
6882016-09-21T21:28:02  <BlueMatt> ahh, i guess it doesnt change now, but we might decide to change the way we handle things in the future and then it could change?
6892016-09-21T21:28:10  <BlueMatt> (I'm not aware of any way it could change in the current code?)
6902016-09-21T21:28:21  <BlueMatt> eg pruning/bloom/etc cannot be turned on and off at runtime
6912016-09-21T21:28:27  <sipa> agree, it's always set at startup
6922016-09-21T21:28:28  <instagibbs> mind if i put a comment on that field to make that explicit? Maybe fewer tears in future
6932016-09-21T21:28:42  <BlueMatt> please do
6942016-09-21T21:28:52  <sipa> i'm making hypotheses here, cfields should probably comment
6952016-09-21T21:29:04  <BlueMatt> i dont think its new/changed in CConMan
6962016-09-21T21:29:07  <instagibbs> that was mine as well, but I'll wait for "official" call
6972016-09-21T21:30:06  <sipa> BlueMatt: before connman nLocalServices was a global
6982016-09-21T21:32:30  <instagibbs> I have a feeling reviewing cb pull will make a lot more sense now
6992016-09-21T21:47:43  <murch1> gmaxwell: 10 sat per byte, and for P2WPKH 10 byte per weight (if that's bytes + byte/4 for the witness part)
7002016-09-21T21:48:39  <murch1> gmaxwell: I have a MIN_CHANGE parameter, which for some wallets is the limit for conversion to fee and for other wallets (such as Core) added to the target before selection.
7012016-09-21T21:49:47  <sipa> murch1: sounds right
7022016-09-21T21:51:14  <gmaxwell> murch1: does your model for core convert dust to fees?
7032016-09-21T21:56:06  <murch1> gmaxwell: Concerning the strategy, what is X? What would X be? The fee cost of the change output? My simulation doesn't model "addresses", so I can't model issues concerning address reuse. Address reuse is already heavily discouraged and I've decided to omit that. Change splitting is clear.
7042016-09-21T21:56:47  <gmaxwell> ::sigh::
7052016-09-21T21:57:05  <gmaxwell> murch1: okay, well your efforts then are moving things into a realm of academic novelty rather than anything pratical then.
7062016-09-21T21:57:24  <sipa> gmaxwell, murch1: i believe you are misunderstanding each other
7072016-09-21T21:58:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7082016-09-21T21:58:18  <gmaxwell> because address reuse is _very_ common on the network, and agressively consuming inputs is probably a good strategy-- but it's potentially devistating to privacy, but not if it's limited to same-address ... in which case it's probably helpful for privacy.
7092016-09-21T21:58:53  <sipa> how is the rule to convert dust to fees at all related to address reuse?
7102016-09-21T21:59:27  <gmaxwell> sipa: murch1 was responding to my earlier comment, not the most recent question about dust->fees..
7112016-09-21T21:59:33  <sipa> ah
7122016-09-21T22:01:38  <sipa> gmaxwell: he is currently moddelling how actual wallets work... that seems very practically useful and not an academic novelty
7132016-09-21T22:02:13  <sipa> sure, if we're trying to find an optimal strategy, it may be worth taking reuse into account
7142016-09-21T22:02:23  *** jtimon has joined #bitcoin-core-dev
7152016-09-21T22:04:34  <murch1> gmaxwell: dust to fees: Yes it does, but only if it cannot create a direct match or a change of at least 0.01 BTC. In my simulation the smallest change Core created was 0.01 BTC.
7162016-09-21T22:04:58  <sipa> i believe that's correct
7172016-09-21T22:05:52  <sipa> (though we may want to reduce that value - there has been talk about making it based on the dust rule, derived from the mempool feerate or estimated feerate, but the current code is still 0.01 BTC i think)
7182016-09-21T22:06:01  *** Yogh has quit IRC
7192016-09-21T22:06:08  <gmaxwell> I'd be interested in knowing how the results change if it will send dust to fees more agressively.
7202016-09-21T22:06:17  <sipa> yup
7212016-09-21T22:06:39  <sipa> it's already pretty aggressive
7222016-09-21T22:06:46  <gmaxwell> e.g. try a direct match, send dust change to fees. Only try targeting 0.01 btc change if that fails.
7232016-09-21T22:07:33  <murch1> gmaxwell: Here is a question. For a very long time I thought that spending several outputs from the same address required only one signature. I recently saw an answer on Bitcoin.SE that said that spending transactions from the same address still uses a full signature each. Is the only concern privacy then?
7242016-09-21T22:07:42  <gmaxwell> Sorry for sounding harsh above, it's demoralizing though to hear that you've done all this modling work and it can't model the behavior I suggested on the input pruning PR.
7252016-09-21T22:08:15  *** Yogh has joined #bitcoin-core-dev
7262016-09-21T22:09:04  *** justanotheruser has joined #bitcoin-core-dev
7272016-09-21T22:09:09  <murch1> sipa: It seems to me that the MIN_CHANGE of 0.01 BTC is the one thing that keeps the UTXO pool of Core wallets so small.
7282016-09-21T22:09:26  <gmaxwell> murch1: making larger change may result in more optimial selection, without regard to privacy.  But agressively doing that in general would be very bad for privacy.
7292016-09-21T22:09:44  <murch1> I'm not sure it would make sense to make it smaller. I recently ran a series of tests with the RandomWallet with different levels of MIN_CHANGE. ……… Searching………
7302016-09-21T22:10:58  <gmaxwell> If it always spends all the coins paid to a paritcular address, that would not have that downside-- and would even be good for privacy, since they wouldn't get pulled into other transactions where they're cosslinked.
7312016-09-21T22:11:16  *** xinxi has joined #bitcoin-core-dev
7322016-09-21T22:12:33  <murch1> gmaxwell: I model almost the complete transaction process, e.g. UTXO are unique, have value and confirmation height. Adding an Address is not that much work. The issue is with modelling address reuse behavior. I'm already making generous assumptions about transaction sizes by working off of only one real-world scenario data set, I'm also guessing at intervals between transactions. Pulling Address behavior from thin air seemed another
7332016-09-21T22:13:02  <gmaxwell> yea, well I saw you were working off real data, so I had my hopes up. :P
7342016-09-21T22:13:16  <sipa> murch1: another idea may be to tie the minimum change to a percentage of the sent amount
7352016-09-21T22:13:33  <murch1> gmaxwell: The dataset is only positive and negative integers. Not even the order is actually really correct.
7362016-09-21T22:13:58  <murch1> because outgoing payments get recorded when requested and incoming only after confirmed.
7372016-09-21T22:14:13  <murch1> I have no clue when the transactions occurred or anything about addresses. :(
7382016-09-21T22:15:25  <gmaxwell> well, sensible wallets will not spend unconfirmed coins from third parties, so that ordering sounds basically correct.
7392016-09-21T22:15:44  <kanzure> murch1: i think you are experiencing message cutoff. there are various ways to force your irc client to split your text into multiple messages.
7402016-09-21T22:17:15  <luke-jr> what is the purpose of share/qt/protobuf.pri?
7412016-09-21T22:17:54  *** xinxi has quit IRC
7422016-09-21T22:18:16  <kanzure> gmaxwell: when i have looked at coin selection (for some reason i reimplemented the stochastic approximation approach?), my thinking was "gee it would be hard to express complex preference profiles for how i would like a good coin selection method to do my bidding for me". there are a bunch of different knobs to tweak- probably it will end up being wallet developers that pick some "sane choices" instead of exposing this to users.. dunno.
7432016-09-21T22:18:32  <gmaxwell> other possible data sources would be taking 'wallets' extracted from the blockchain via taint analysis cross linking. E.g. pick a random transaction, add all addresses that its inputs were paid too. Then find all transactions that spend coins paid to those addresses, add all their inputs, and repeat until no more is added.
7442016-09-21T22:18:53  <murch1> sipa: Concerning Size of the MIN_CHANGE: I've run 10 iteratios of RandomWallet with MIN_CHANGE 10 sats, 100 sats, 1000 sats,…,1BTC.  There is a tiny bit of a dip on 1mBTC, the first palpable drop in average UTXO pool size is at 0.01BTC, it really goes down on 0.1 BTC.
7452016-09-21T22:19:31  <sipa> murch1: but that does depend on the order of magnitude of the amounts you are dealing with
7462016-09-21T22:19:43  <murch1> true
7472016-09-21T22:19:49  <sipa> someone who regularly receives and sends small amounts may want a smaller setting for that
7482016-09-21T22:19:55  <murch1> I'm still working of the same MoneyPot dataset.
7492016-09-21T22:20:06  <gmaxwell> kanzure: I am doubtful users can usefully chose on this... but there are choices on the efficient frontier. E.g. I cannot think of _any_ downside to adding all inputs paying to an address you're spending (up to some maximum). I think it's strictly superior to not doing so.
7502016-09-21T22:20:16  <murch1> kanzure: Thanks
7512016-09-21T22:21:57  <murch1> completely off-topic, but Pidgin sucks for IRC • I used to have a decent client when I still used Linux, but I've only started using IRC for Bitcoin again recently. Any recommendation for a decent IRC client?
7522016-09-21T22:22:10  <murch1> on Linux?
7532016-09-21T22:22:34  <murch1> You probably meant the message to gmaxwell before?
7542016-09-21T22:25:11  <murch1> sipa: That's basically what "DoubleWallet" does. It sets MIN_CHANGE to the sent amount (i.e. the percentage is 100%). It has consistently a much larger UTXO pool than Core on the P2PKH sim.
7552016-09-21T22:25:32  <sipa> murch1: irssi
7562016-09-21T22:25:38  <murch1> gmaxwell: If the message was cut off before.
7572016-09-21T22:25:49  <murch1> gmaxwell: I model almost the complete transaction process, e.g. UTXO are unique, have value and confirmation height. Adding an Address is not that much work. The issue is with modelling address reuse behavior.
7582016-09-21T22:25:49  <sipa> used it exclusively for over 10 years now
7592016-09-21T22:25:54  <murch1> gmaxwell: I'm already making generous assumptions about transaction sizes by working off of only one real-world scenario data set, I'm also guessing at intervals between transactions. Pulling Address behavior from thin air seemed another huge endeavor.
7602016-09-21T22:26:00  <kanzure> gmaxwell: i think change creation can be informed by known long-term behavior of your wallet-- perhaps you know you're going to be making payments in a very specific way, even long-term pre-planned payments. OTOH, it's probably the folks that /don't/ have this foresight who would benefit the most from better privacy in coin selection.
7612016-09-21T22:27:00  <kanzure> ((well also the general benefit that everyone receives from good coin selection everywhere.))
7622016-09-21T22:31:47  *** murch_ has joined #bitcoin-core-dev
7632016-09-21T22:33:03  *** [Author] has joined #bitcoin-core-dev
7642016-09-21T22:34:05  <murch_> sipa: Tried that, but it took me forever to figure out how to get anywhere. I'll try again maybe, when I have a few days to just play around with it. Got something else now, I think.
7652016-09-21T22:34:15  <murch_> sipa: did you see that about DoubleWallet?
7662016-09-21T22:35:21  *** murch1 has quit IRC
7672016-09-21T22:35:28  *** murch_ is now known as murch
7682016-09-21T22:37:00  *** sipa has quit IRC
7692016-09-21T22:37:17  <luke-jr> ugh, we added unlicensed-or-GPL code to master (and soon 0.13..)
7702016-09-21T22:42:07  *** sipa_ has joined #bitcoin-core-dev
7712016-09-21T22:44:57  <GitHub177> [bitcoin] MarcoFalke opened pull request #8783: [share] remove qt/protobuf.pri (master...Mf1609-deleteqtProto) https://github.com/bitcoin/bitcoin/pull/8783
7722016-09-21T22:48:37  *** MarcoFalke has quit IRC
7732016-09-21T22:48:52  *** moli has joined #bitcoin-core-dev
7742016-09-21T22:49:15  *** molz has quit IRC
7752016-09-21T22:52:14  *** murch has quit IRC
7762016-09-21T22:56:56  <warren> luke-jr: where?
7772016-09-21T22:57:12  <luke-jr> warren: l_atomic.m4
7782016-09-21T22:57:24  <luke-jr> author is okay with licensing it under MIT-like terms, so workign on that
7792016-09-21T22:58:00  <warren> great
7802016-09-21T23:02:04  *** xinxi has joined #bitcoin-core-dev
7812016-09-21T23:06:45  *** LeMiner has quit IRC
7822016-09-21T23:07:07  *** xinxi has quit IRC
7832016-09-21T23:07:54  *** LeMiner has joined #bitcoin-core-dev
7842016-09-21T23:11:37  *** jnewbery has quit IRC
7852016-09-21T23:12:25  <GitHub136> [bitcoin] luke-jr opened pull request #8784: Copyright headers for build scripts (master...license_build) https://github.com/bitcoin/bitcoin/pull/8784
7862016-09-21T23:16:44  *** rogerwilco has quit IRC
7872016-09-21T23:17:14  *** rogerwilco has joined #bitcoin-core-dev
7882016-09-21T23:25:46  *** LeMiner2 has joined #bitcoin-core-dev
7892016-09-21T23:27:16  *** jnewbery has joined #bitcoin-core-dev
7902016-09-21T23:28:20  *** LeMiner has quit IRC
7912016-09-21T23:28:20  *** LeMiner2 is now known as LeMiner
7922016-09-21T23:29:18  *** To7 has quit IRC
7932016-09-21T23:41:21  *** veleiro has quit IRC
7942016-09-21T23:51:46  *** xinxi has joined #bitcoin-core-dev