--- Day changed Wed Sep 21 2016
00:15 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:49 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Remote host closed the connection]
00:50 -!- ___tau___ [user@gateway/vpn/mullvad/x-dzppazocdlqtihnl] has quit [Quit: Konversation terminated!]
01:04 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
01:07 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
01:31 -!- ill [~ill@32.210.24.120] has quit [Ping timeout: 244 seconds]
01:38 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
01:39 < MarcoFalke> jonasschnelli: Would it be hard to use the theme for the text+background as luke-jr suggests?
01:39 < MarcoFalke> Anyway style nits can be fixed later, 8371 looks good now
01:40 < MarcoFalke> This is the most important gui change for 0.14. Better get it in sooner than later
01:40 < jonasschnelli> MarcoFalke: Yes. This could be done later...
01:40 < luke-jr> indeed
01:40 < jonasschnelli> Also. I'm not sure if theme based colors together with the icon and the progress bar will look nice
01:41 < jonasschnelli> I guess we also would need to ensure the singlecoloricon fits the theme...
01:41 < jonasschnelli> also the blackish overlay is something that looks good IMO
01:41 < jonasschnelli> gives a look that its something "important" to read..
01:41 < luke-jr> singlecoloricon is designed specifically to fit the theme :p
01:42 < 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
01:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev
01:42 < jonasschnelli> the inverted colors as an overlay make sense from an UX perspetive IMO.
01:43 < luke-jr> I'm not aware of a single app that inverts colours for modal dialogs.
01:48 < jonasschnelli> Luke-Jr: how should it look then?
01:50 < luke-jr> however modal dialogs normally look for the particular user's style
01:51 < jonasschnelli> But it's not a modal dialog... it's an overlay.
01:52 < luke-jr> good UX lies in behaving and looking as the user expects IMO
01:52 < luke-jr> jonasschnelli: what's the difference?
01:52 < jonasschnelli> Its in the same window
01:52 < jonasschnelli> It overlays the controls.
01:53 < jonasschnelli> Using a QDialog with modal flag would be wrong IMO
01:53 < luke-jr> preventing interaction with the controls is precisely what model dialogs are meant to be used for.
01:53 < 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
01:54 < jonasschnelli> Yes. But do you think a QDialog with modal flag would look appropriate?
01:54 < 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
01:54  * luke-jr ponders what similar things exist
01:54 < sipa> it also doesn't need preventing interaction with the entire application
01:55 < sipa> opening the debug window presumably should work fine
01:55 < luke-jr> sipa: good point
01:55 < jonasschnelli> Yes. It a partial-modal overlay. :)
01:56 < luke-jr> KMail shows an overlay while it loads a folder
01:56 < luke-jr> so it seems the overlay stuff is standard
01:56 < luke-jr> at least to some degree
01:56 < jonasschnelli> I think we could try to attach it more to the theme colors once its merged
01:56 < jonasschnelli> before we do cosmetic changes, we should address the problem that people download Core and start receiving funds that are then stuck.
01:57 < luke-jr> yes, I agree, this doesn't need to hold back merging
01:57 < sipa> use the text color as background and background color as text? :)
01:57 < sipa> yes agree, not a blocker
01:57 < jonasschnelli> Yes. Something like that
01:57 < wumpus> +1 on getting it merged
01:57 < sipa> ha, blocker... for a modal overlay
01:57 < jonasschnelli> heh!
01:57 < 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
01:57 < wumpus> hah
01:58 < wumpus> even an ugly black 'censored' box would be better than what there is now :p
01:58 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8371 needs another ACK (or a re-ack from MarcoFalke) before I merge it.
01:58 < luke-jr> lol
01:58 < MarcoFalke> ACK
01:58 < sipa> jonasschnelli: is the header count still wrong due to that signal reporting the best candidate rather than the best header?
01:58 < MarcoFalke> The github review sucks
01:58 < jonasschnelli> sipa: Should be right now... because...
01:59  * jonasschnelli is checking the code...
01:59 < sipa> we should discuss how to integrate the ack/nack/... things with github review
01:59 < sipa> what if you approve with a nack? :)
01:59 < MarcoFalke> Don't use github review
01:59 < jonasschnelli> clientModel->getHeaderTipTime()
01:59 < luke-jr> is BlueMatt annoyed at it still? :P
02:00 < jonasschnelli> sipa: https://github.com/bitcoin/bitcoin/pull/8371/files#diff-0db7dd184df07a48c307ccc182021a68R722
02:00 < sipa> MarcoFalke: why not?
02:00 < jonasschnelli> I take the time and height directly from pindexBestHeader
02:00 < wumpus> why does github review suck? Ithink combining multple comments into one review is pretty useful
02:00 < jonasschnelli> (each time the singal fires)
02:00 < MarcoFalke> It shows the changes as approved by me, even though new commits were pushed
02:00 < sipa> wumpus: agree
02:00 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
02:01 < sipa> MarcoFalke: it does tell you what changes the review was for, no?
02:01 < MarcoFalke> wumpus: But it does not hide the comments when they are solved
02:01 < jonasschnelli> MarcoFalke: but the "timeline" implies that you have reviewd on older state?
02:01 < jonasschnelli> thats indeed bad
02:01 < jonasschnelli> Do they go away if a commit gets added?
02:01 < MarcoFalke> Yes "timeline". But it is possible to push commits such that they appear in the past
02:01 < jonasschnelli> I really dislike the non-removing comments on the source-code...
02:01 < 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
02:02 < jonasschnelli> They stay also after a force push or commit that removes that code part
02:02 < wumpus> and you can still mention the commit in review comments if you want
02:02 < wumpus> jonasschnelli: that's slightly annoying, yes, otoh it makes the review history clearer
02:03 < wumpus> so people don't, say, suggest the opposite thing when something has been discussed already
02:03 < wumpus> hiding can be pretty annoying in that regard
02:03 < jonasschnelli> Yes. That indeed true..
02:03 < sipa> i hate it when review commemts automatically disappear
02:03 < sipa> i want to judge whether a comment still applies
02:03 < wumpus> yes
02:03 < jonasschnelli> I just fear very large pages with endless amount of comments/reviews
02:03 < wumpus> indeed, github's judgement is not very good there
02:03 < sipa> you can explicitly mark as resolved, no?
02:03 < jonasschnelli> But right... it makes stuff more obvious for new reviewers
02:04 < jonasschnelli> I guess no
02:04 < luke-jr> sipa: that'd be nice, but I've never seen it
02:04 < wumpus> it just looks if the line changes and then considered the comment invalid
02:04 < jonasschnelli> wumpus: I think for review-comments, they stay even if the lines gets removed afterwards
02:04 < sipa> and it used to differ based on whether it was a commit comment or pr comment
02:04 < 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.
02:05 < luke-jr> MarcoFalke: and then GitHub will change the behaviour under you :P
02:05 < sipa> MarcoFalke: just a rebase can make comments disappear
02:06 < MarcoFalke> Well, I use comments to indicate merge conflicts sometimes. I expect them to disappear after
02:06 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev
02:06 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Changing host]
02:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:07 < wumpus> MarcoFalke: you can still add 'single comments'
02:08 < wumpus> I'd expect them to still be treated the same as before on changes, unsure though
02:09 < wumpus> 'disappear' is not the right word, I think they never fully disappear, just get collapsed?
02:10 < wumpus> 'this comment is on a previous version of ...'
02:10 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
02:11 < MarcoFalke> Jup, single comments are the old fashioned comments 
02:11 < MarcoFalke> wumpus: Should I add the DEFAULT_DISABLEWALLET=false in this pull?
02:12 < wumpus> MarcoFalke: would be nice to do that in one go, yes
02:12 < 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.
02:12 < jonasschnelli> not sure how easy it is to get this merged in a whole
02:13 < luke-jr> perhaps I should split the refactors from multiwallet?
02:13 < jonasschnelli> Luke-Jr: The Qt wallet switch dropdown is also present when you only have a single wallet, right?
02:13 < wumpus> pretty difficult, better to do the refactoring needed step by step
02:13 < MarcoFalke> Agree
02:13 < jonasschnelli> wumpus: Yes. I though so...
02:13 < luke-jr> jonasschnelli: no, it's hidden with a single wallet
02:13 < luke-jr> wumpus: it is step by step, in commits :p
02:13 < MarcoFalke> jonasschnelli's pr is already "minimal". Though several hundred lines
02:14 < wumpus> if you want to know why, look what killed the first multi-wallet pull years ago, too much changed at once
02:14 < jonasschnelli> Mostly search and replace thought: https://github.com/bitcoin/bitcoin/pull/8764
02:14 < wumpus> yes jonasschnelli's PR is minimal
02:14 < wumpus> luke-jr's not so much
02:14 < jonasschnelli> I think we need to go in small step PRs
02:14 < luke-jr> ok, I'll open a new PR with just some refactoring
02:14 < MarcoFalke> Also, I like the approach of defaultWallet()
02:14 < luke-jr> unless you think I should do each refactor separately.. ._.
02:14 < 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
02:15 < 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
02:16 < wumpus> lol I had an adverse reaction on seeing the word 'boost' even though it's used in a completely different context
02:16 < luke-jr> XD
02:16 < jonasschnelli> hehe
02:16  * wumpus reads too much code
02:17 < jonasschnelli> Luke-Jr: What do you think about exposing the addWallet stuff to RPC?
02:17 < jonasschnelli> the -wallet= approach of adding wallets is kinda limited on runtime
02:17 < luke-jr> jonasschnelli: intentionally so
02:17 < wumpus> jonasschnelli: can be sone later
02:17 < luke-jr> for the "too much in one PR" reason
02:17 < jonasschnelli> Yes. Thats true
02:17 < wumpus> runtime wallet loading and unloading is super-spiffy,but harder to get right
02:17 < luke-jr> changing wallets at runtime makes this a lot more complex
02:18 < wumpus> yes,that
02:18 < jonasschnelli> Okay. I see. Agree on that.
02:18 < luke-jr> (especially closing)
02:18 < wumpus> same as with the wallet HD support, it's better to do small (but significant) steps at a time
02:18 < jonasschnelli> Luke-Jr: In my tests, the Qt drop-down stays there even with a single wallet
02:19 < luke-jr> jonasschnelli: hmm, that's a bug then
02:19 < luke-jr> IMO
02:20 < luke-jr> (at least in the current stage, I don't think normal users should be exposed to the feature)
02:20 < luke-jr> oh, the *debug* dropdown should stay with only one wallet though
02:20 < luke-jr> because it has a (none) option
02:21 < jonasschnelli> Okay. I'll test some more...
02:21 < luke-jr> actually tempting to make that the default, so users have yet one more step to compromise their wallet..
02:22 < 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
02:22 < MarcoFalke> jup
02:22 < luke-jr> wumpus: never tried, but I speculate you'd do something like the origin-pull remote trick
02:22 < MarcoFalke> I tried it
02:22 < wumpus> "Add more commits by pushing to the patch-4 branch on unsystemizer/bitcoin." ah
02:22 < wumpus> let's just try that
02:22 < MarcoFalke> git add remote unsys ...
02:23 < luke-jr> oh, it actually gives you access to his personal repo? :o
02:23 < MarcoFalke> git push unsys patch-4 -f
02:23 < MarcoFalke> luke-jr: Only this branch, IIRC
02:23 < wumpus> MarcoFalke: yes I was thining to difficult, I thought I had to push to some special pulls branch on bitcoin/bitcoin
02:23 < luke-jr> what happens if I open a PR for one of MarcoFalke's branches? <.<
02:24 < MarcoFalke> Hmm, good question
02:24 < luke-jr> MarcoFalke: got something to PR I can try it with?  :D
02:24 < MarcoFalke> One sec
02:25 < luke-jr> dad932c needs to be fixed, if you want something trivial
02:26 < wumpus> "git push -f git@github.com:unsystemizer/bitcoin.git HEAD:patch-4" seems to have worked
02:30 < wumpus> feels a bit like intruding to push to someone elses repository, but okay, it's very practical in this case
02:31 < MarcoFalke> luke-jr: https://github.com/bitcoin/bitcoin/compare/master...MarcoFalke:Mf1609-ContributeDoc?expand=1
02:31 < 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
02:32 < luke-jr> no checkbox in this case
02:32 < GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b4f53641a95d...84c9a048559d
02:32 < GitHub93> bitcoin/master 04d91f4 unsystemizer: Trivial: Fix ISO URL, capitalization...
02:32 < GitHub93> bitcoin/master 84c9a04 Wladimir J. van der Laan: Merge #8769: Trivial: Fix ISO URL, capitalization...
02:32 < luke-jr> hm, review won't let me set a review-type for the PR either. :P
02:32 < GitHub138> [bitcoin] laanwj closed pull request #8769: Trivial: Fix ISO URL, capitalization (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8769
02:34 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 244 seconds]
02:36 < MarcoFalke> wumpus, can you do "git push -f git@github.com:MarcoFalke/bitcoin.git HEAD:Mf1609-ContributeDoc"?
02:36 < wumpus> sure, does it matter what I overwrite it with?
02:37 < luke-jr> it should fail anyway
02:37 < MarcoFalke> no
02:37 < MarcoFalke> does not matter
02:37 < wumpus>  ! [remote rejected] HEAD -> Mf1609-ContributeDoc (permission denied)
02:37 < luke-jr> good, GitHub isn't totally incompetent. ☺
02:38 < wumpus> the access control code just became extremely complex though, wouldn't be surprised if someone still discovered a loophole
02:39 < wumpus> on some level this feature creeps me out
02:39 < MarcoFalke> Open a pull request to bitcoin:master in some other repo. Force push to bitcoin:master...
02:39 < sipa> likewise
02:39 < wumpus> git is meant to be authority-less
02:40 < luke-jr> it'd make slightly more sense if it had you push to the project's repo (the PR refs), but oh well
02:40 < 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
02:41 < luke-jr> tempting to try opening a PR against both Core and Classic, and see if one can influence the other..
02:41 < 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
02:42 < wumpus> luke-jr: hah
02:43 < wumpus> that's a clever idea, but let's not do it in this case, we don't want more allegations of attacking classic
02:44 < GitHub10> [bitcoin] luke-jr opened pull request #8772: [0.13] Backports (0.13...backports-0.13) https://github.com/bitcoin/bitcoin/pull/8772
02:48 < 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
02:51 < MarcoFalke> wumpus: Can I get permission to merge doc changes (comments, markdown, ...)?
02:53 < MarcoFalke> Otherwise I will just ping you when I feel soemthing trivial can be merged
02:53 < 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
02:57 < 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
02:58 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 265 seconds]
02:59 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev
03:01 < 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
03:01 < luke-jr> there we go, I think that's as far as I can go with split PRs until they get merged :p
03:06 -!- JackH [~laptop@host86-136-108-82.range86-136.btcentralplus.com] has joined #bitcoin-core-dev
03:25 < wumpus> MarcoFalke: sure
03:28 < GitHub94> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/84c9a048559d...886e8c9b7269
03:28 < GitHub94> bitcoin/master fab9107 MarcoFalke: init: Get rid of fDisableWallet
03:28 < GitHub94> bitcoin/master fa58edb MarcoFalke: [wallet] Introduce DEFAULT_DISABLE_WALLET
03:28 < GitHub94> bitcoin/master 886e8c9 Wladimir J. van der Laan: Merge #8768: init: Get rid of fDisableWallet...
03:28 < GitHub81> [bitcoin] laanwj closed pull request #8768: init: Get rid of fDisableWallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8768
03:29 < wumpus> MarcoFalke: certainly trivial things like https://github.com/bitcoin/bitcoin/pull/8773 you can just merge if they check out
03:31 < GitHub109> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/886e8c9b7269...52b5a8785de7
03:31 < GitHub109> bitcoin/master 6f933c6 Luke Dashjr: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
03:32 < GitHub109> bitcoin/master 52b5a87 MarcoFalke: Merge #8773: Trivial Bugfix: doc/gitian-building.md: Link to release-process needs to be updated...
03:32 < 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
03:33 < wumpus> re: wallet, I'd really like to get https://github.com/bitcoin/bitcoin/pull/7551 in
03:33 < wumpus> I think it's even more important than multiwallet
03:33 < wumpus> well it's pretty much orthagonal but okay
03:34 < 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
03:34 < sipa> wumpus: thabks for the reminder, eill review
03:35 < sipa> *will
03:35 < sipa> *thanks
03:35 < wumpus> thanks
03:38 < MarcoFalke> Sry, I think qt no longer compiles on master.
03:39 < sipa> uh-oh
03:39 < MarcoFalke> Forgot to #include wallet.h
03:39 < MarcoFalke> the "introduce DEFAULT_DISABLE_WALLET" is more involved
03:39 < MarcoFalke> in qt
03:39 < MarcoFalke> than search and replace
03:40 < MarcoFalke> might want to properly fix it, now that multiwallet is the goal
03:42 -!- laurentmt [~Thunderbi@80.215.210.116] has joined #bitcoin-core-dev
03:43 -!- laurentmt [~Thunderbi@80.215.210.116] has quit [Client Quit]
03:47 < wumpus> let's first get it to compile again
03:50 < sipa> *commits a #if 0 .. #endif around all .cpp files* - what did you do?! - it compiles again!
03:50 < wumpus> hehe
03:51 < 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
03:52 < wumpus> then do it the proper way some other time
03:52 < wumpus> re-do
03:53 < MarcoFalke> wumpus: Will create a pull
03:54 < wumpus> but if it involves multiwallet changes may be better to revert the current naive commit for now?
03:54 < MarcoFalke> should work without multiwallet changes
03:55 < MarcoFalke> Is this "Method names start with upper case" a style thing?
03:55 < wumpus> e.g. just fa58edb not the other commitin that pull
03:55 < wumpus> MarcoFalke: dunno, seems another satoshi-ism
03:55 < MarcoFalke> I think we have half of the names start upper case and the other half don't
03:55 < wumpus> qt code uses lowerCamelCase at least
03:55 < MarcoFalke> Never sure what to use in fresh code
03:55 < MarcoFalke> ok
03:56 < wumpus> nah if you sak me for something new and independent I'd suggest using lowerCamelCase, that's a more common C++ naming convention 
03:56 < wumpus> if you change existing code just go with the style of that code
03:56 < sipa> hmm, nearly all of the existing core code uses capitalized class and function names
03:57 < sipa> so i'd rather not introduce something else
03:57 < sipa> the developer notes used to mention this
03:57 < wumpus> I really have no strong opinion on it
03:57 < wumpus> I'm fine with either, but don't mix them in one class/unit
03:58 < 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
04:01 < 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()
04:03 < wumpus> capitalizing class names, on the other hand, makes sense to keep them apart
04:04 < sipa> all stl functions are lower_separated_by_underscore()
04:04 < wumpus> yes, that's a valid choice too
04:04 < wumpus> snake_case :)
04:04 < sipa> i perdonally find lowerCaseFollowedByUpper very strange, but it's all highly subjective
04:05 < wumpus> many projects use that for variables and member variables, that's reasonable sane
04:07 < 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
04:08 < 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 
04:09 < wumpus> having a separate naming convention for classes also avoids creating a class with the same name as a function
04:10 < wumpus> in any case I have no problems with stl-style either, except that it reminds me of boost :-)
04:11 < GitHub122> [bitcoin] MarcoFalke opened pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
04:13 < sipa> wumpus: i guess i'm biased because i learned c++ from bitcoin's codebase :)
04:13 < sipa> well, i knew c++ from university, but that was purely theory without ajy software development experience
04:14 < wumpus> yes, that can twist your mind :)
04:15 < wumpus> MarcoFalke: I'm confused by #8777, why do we have a wallet model if the wallet is disabled
04:15 < wumpus> did I really make it that way?
04:16 < MarcoFalke> My method is static
04:17 < wumpus> oh, okay, yes, that can work
04:17 < MarcoFalke> I think there is no walletModel in case of -disablewallet=1
04:18 < wumpus> static methods cover no instances, so can apply to all instances
04:18 < wumpus> yes
04:18 < wumpus> phew
04:19 < 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.
04:19 < sipa> wumpus: i did know C pretty well beforehand, maybe that helped :)
04:21 < 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, ...
04:22 < 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.
04:22 < MarcoFalke> So let's fetch some tea until travis clears the backlog
04:23 < 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 :)
04:24 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:27 < wumpus> sipa: hah!
04:28 < wumpus> MarcoFalke: we could cancel all the preceeding builds as they're going to fail anyway
04:30 < MarcoFalke> done. Should pick up the pull now
04:31 < MarcoFalke> reminds me that no entry in the travis matrix has qt builds enabled
04:31 < MarcoFalke> IIRC osx cross build does it (silently)
04:32 < wumpus> that was disabled for *somereason cfields probably knows*
04:32 < MarcoFalke> timeouts?
04:32 < wumpus> possibly timeout-related back when there were problems with caching after the travis trusty switch
04:32 < wumpus> yes
04:34 < 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
04:34 < wumpus> yea docker solves a problem we don't have, here
04:35 < MarcoFalke> Was on an unrelated note  ;)
04:35 -!- murch [~murch@p4FE383BA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
04:35 < MarcoFalke> (travis has no plans to switch to xenial soon)
04:36 < wumpus> testing native osx/win would be interesting, but I guess that runs into license issues
04:36 < MarcoFalke> Oh, travis has native osx?
04:36 < wumpus> and in the case of windows multi-stage issues: we want to build on trusty, then run the tests on an actualwindows machine
04:37 < 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
04:39 < MarcoFalke> (Right now we are bound to whatever ubuntu 14.04 provides us. Though, deterministic builds of the toolchain would help to untangle this)
04:39 < wumpus> switching to xenial would be a disaster right now, esp for windows build
04:40 < 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 :)
04:40 < MarcoFalke> No one detected this. We should have run tests on xenial at least for the release
04:40 < MarcoFalke> But then it is unfeasible to try every os and combination of toolchains
04:41 < wumpus> well this is a cross build issue that didn't get detected
04:41 < wumpus> we can't test every toolchain in existence
04:41 < wumpus> right
04:41 < wumpus> unfortunately, there are plenty of mingw toolchains that create absolutely broken windows code
04:41 < MarcoFalke> So cfields work sounds like the right step
04:41 < wumpus> we used to have that issue, and now it's back
04:42 < MarcoFalke> Looks like travis likes my pull.
04:43  * MarcoFalke off
04:43 < 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)
04:43 < wumpus> thanks ,going to merge it
04:44 < wumpus> cfields: ^^ re clang and windows, should we consider that?
04:45 < wumpus> would be worth an experiment at least I guess
04:45 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev
04:45 < GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/52b5a8785de7...fec6af744014
04:45 < GitHub146> bitcoin/master 6666ca6 MarcoFalke: [qt] WalletModel: Expose disablewallet
04:45 < GitHub146> bitcoin/master fec6af7 Wladimir J. van der Laan: Merge #8777: [qt] WalletModel: Expose disablewallet...
04:45 < GitHub97> [bitcoin] laanwj closed pull request #8777: [qt] WalletModel: Expose disablewallet (master...Mf1609-initDisableWallet) https://github.com/bitcoin/bitcoin/pull/8777
04:57 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5415:c093:e98:94c1] has quit [Quit: .]
05:00 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
05:00 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:c917:ff75:dc6c:bc99] has joined #bitcoin-core-dev
05:01 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 265 seconds]
05:06 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:c917:ff75:dc6c:bc99] has quit [Quit: .]
05:06 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev
05:14 < GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fec6af744014...cf5ebaa921a9
05:14 < GitHub170> bitcoin/master 7c069a7 Pavel Janík: Do not shadow global variable
05:14 < GitHub170> bitcoin/master cf5ebaa Wladimir J. van der Laan: Merge #8656: Trivial: Do not shadow global variable fileout...
05:14 < 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
05:16 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 265 seconds]
05:16 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 260 seconds]
05:21 -!- Alina-malina [~Alina-mal@37.157.216.188] has joined #bitcoin-core-dev
05:23 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev
05:24 -!- Alina-malina [~Alina-mal@37.157.216.188] has quit [Changing host]
05:24 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev
05:27 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:31 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
05:35 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 244 seconds]
05:44 < 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?
05:44 < sipa> wumpus: you're on http://coredev.tech/nextmeeting.html ?
05:45 < wumpus> oh I have the wrong link, okay
05:45 < wumpus> yep
05:50 < 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
05:50 < jonasschnelli> wumpus: Yes. Your listed... need to remove the *_tmp.html files!
05:51 < jonasschnelli> I updated the page right after you submitted your form. :)
05:52 < jonasschnelli> Ah. instagibbs just submitted the form as well...
05:52 < instagibbs> i saw it being discussed here
05:53  * jonasschnelli didn't know that wumpus is in the plubming business. .. :)
05:54 < jonasschnelli> *plumbing
05:55 -!- cryptapus_ is now known as cryptapus
06:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
06:06 < MarcoFalke> jonasschnelli: I think you forgot to merge the overlay pull this morning :)
06:07 < jonasschnelli> MarcoFalke: I was hoping someone did another review,.. but will merge in the next couple of hours.
06:08 < jonasschnelli> *someone will do
06:08 < BlueMatt> luke-jr: they seem to have partially fixed the email issues
06:08 < BlueMatt> github, that is
06:09 < BlueMatt> as of yesterday i was still getting duplicate emails from them, but at least they're properly threaded
06:10 < jonasschnelli> BlueMatt: while your here.. :), do you use the contrib/debian packaging dir for your bitcoin PPA?
06:11 < BlueMatt> i forked off of it a while ago, but anything something gets updated in contrib/debian i re-sync it
06:11 < BlueMatt> iirc the only real difference is package description (the new one is pretty terrible, iirc) and changelog
06:11 < BlueMatt> new as of like 3 versions ago, that is
06:12 < jonasschnelli> BlueMatt: I guess we should add zmq to the dependencies
06:12 < jonasschnelli> which probably should result compiling with zmq
06:12 < BlueMatt> oh, thats another difference - upnp is not built-in
06:13 < BlueMatt> because of the security issues a while back, and i never re-added it
06:13 < jonasschnelli> otherwise our "official" binary comes with zmq while the PPA does not
06:13 < BlueMatt> but no one has complained, so whatever
06:13 < BlueMatt> yea, could add zmq, though also security-swiss-cheese
06:13 < BlueMatt> but maybe i should....
06:14 < jonasschnelli> I would argue that if you like to use ZMQ, you should self-compile... but, yeah...
06:14 < BlueMatt> i mean ive never heard any complaints about that or upnp
06:15 < wumpus> zmq is only used for notification, and disabled by default
06:15 < BlueMatt> (not that that indicates much, people like to keep complaints to themselves, mostly)
06:15 < BlueMatt> wumpus: I'm aware, but so is upnp in bitcoind, and its still gross :p
06:16 < BlueMatt> though i did actually get like 2/3 emails about the 12.04 empty-package update, which i found impressive
06:16 < wumpus> yes, it's up to you as maintainer, please do explain that in the issue
06:16 < 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
06:16 < wumpus> people really shouldn't complain to us about the PPAs, though i guess the ppa doesn't have its own issue tracker
06:16 < wumpus> yes there's an issue, let em see
06:17 < sipa> BlueMatt: a few people in #bitcoin were confused by bitcoind disappearing
06:17 < jonasschnelli> we have contrib/debian though
06:17 < BlueMatt> oh, well if someone complained I can add it
06:17 < BlueMatt> sipa: yea, if i get emails then #bitcoin is generally guaranteed to complain
06:17 < BlueMatt> not much i could do, though :/
06:17 < sipa> BlueMatt: maybe a #!/bin/sh echo "The Bitcoin Core PPA no longer supports Ubuntu 12.04" would be better than just empty package?
06:18 < wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/issues/8759
06:18 < 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
06:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:18 < wumpus> BlueMatt: yes, I've seen that only once, the GUI tools do show it
06:19 < wumpus> it's meant for really critical notifications regarding a package, I guess this qualifies
06:19 < BlueMatt> indeed
06:21 < 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 
06:22  * BlueMatt ponders maildrop rule therefor
06:22 < wumpus> I started receiving so many github mails that that's the only ones I read at at the moment
06:23 < wumpus> (of course I tend to read the rest, but on github.com, not in my mailbox)
06:25 < 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
06:26 < wumpus> jonasschnelli: at least the manpages will be gone from there now
06:28 < BlueMatt> wumpus: yep, still eating breakfast, give me a few :p
06:29 < wumpus> BlueMatt: yes I don't mean to hurry :p
06:32 < wumpus> re: the new github review system, is it possible to un-approve a pull? 
06:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
06:40 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:54be:94ab:7e72:1328] has joined #bitcoin-core-dev
06:40 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]
06:41 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev
06:47 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:54be:94ab:7e72:1328] has quit [Read error: Connection reset by peer]
06:48 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:54be:94ab:7e72:1328] has joined #bitcoin-core-dev
06:53 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
06:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:05 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 240 seconds]
07:05 -!- DigiByteDev_ [~JT2@185.29.164.147] has joined #bitcoin-core-dev
07:22 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
07:23 < xinxi> Hi guys, are any documents on how to add a new type of address? 
07:23 -!- DigiByteDev_ [~JT2@185.29.164.147] has quit [Quit: DigiByteDev_]
07:24 < 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? 
07:28 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds]
07:31 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
07:40 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev
07:41 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
07:42 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev
07:42 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]
07:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
07:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:42 < instagibbs> murch: I'd be interested to see what effect, if any, witness discounting would have on effective paid fees per algorithm
07:44 < murch> instagibbs: Lemme have a look at the results
07:51 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Read error: Connection reset by peer]
07:52 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
07:54 < murch> instagibbs: Fees are almost exactly halved through the bench.
07:54 < murch> https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
07:55 < murch> instagibbs: I've uploaded the whole output table here ^
07:55 < sipa> murch: do any of the algorithms behave significantly better/worse (in terms of average number of transaction inputs) with and without segwit?
07:55 < sipa> or number of utxos held
07:59 < 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.
08:01 < 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.
08:03 < instagibbs> murch: are total fees in satoshis or?
08:04 < murch> instagibbs: Yes.
08:04 < murch> instagibbs: All bitcoin values are in satoshi.
08:07 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
08:11 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 255 seconds]
08:11 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
08:13 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
08:16 -!- skyraider [uid41097@gateway/web/irccloud.com/x-mnvfyopatqxolybv] has joined #bitcoin-core-dev
08:19 -!- d4de [~d4de@156.212.134.80] has joined #bitcoin-core-dev
08:19 < 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
08:19 < skyraider> https://www.irccloud.com/pastebin/rENd1qLg/tor%20disconnect%20callback%20incorrectly%20firing%20on%200.13.0
08:20 < d4de> I was surprised today by a bunch of tor client messages in our systems. Why not SOCKS5?
08:20 < sipa> skyraider: it's just trying to reach the tor control port to open a socket
08:20 < skyraider> (for additional context, this pull request supposedly fixes that message, but apparently not https://github.com/bitcoin/bitcoin/pull/7637)
08:20 < sipa> it's enabled by default, but doesn't do anything if you don't have tor running
08:21 < skyraider> sipa: ah, so it's harmless?
08:21 < sipa> yes
08:21 < skyraider> thanks
08:21 < sipa> that PR just prevents it from spamming your debug.log all the time
08:21 < sipa> now it just mentions it onc
08:21 < sipa> *once
08:22 < sipa> you can disable it by setting listenonion=0 in bitcoin.conf
08:22 < sipa> or running with -nolistenonion
08:25 < skyraider> hmm, i received several warnings... 6, it seems
08:28 < sipa> that's unexpected
08:28 < skyraider> listenonion=0 is effective, though. no warning after applying that config setting.
08:35 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev
08:46 -!- JackH [~laptop@host86-136-108-82.range86-136.btcentralplus.com] has quit [Ping timeout: 265 seconds]
09:08 < gmaxwell> murch: is your 'corewallet' with or without the extra input removal?
09:09 < murch> gmaxwell: Without pruning
09:09 < murch> i.e. extra input removal
09:09 < gmaxwell> okay
09:11 < 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.
09:13 < 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)
09:14 < 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?)
09:16 < 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?
09:16 < murch> BlueMatt: Yes, it's the coin selector from BitcoinJ.
09:16 < gmaxwell> BlueMatt: the paper says it uses "value * inputAge"
09:17 < BlueMatt> gmaxwell: it was written when using priority as selection wasnt insane :p
09:17 < BlueMatt> murch: is your "fee spent" thing just tx size * fee something, or does it actually analyze the code's fee selection behavior?
09:18 < 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?
09: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.
09:18 < murch> BlueMatt: It uses a flat fee of 10 satoshi per byte.
09:18 < BlueMatt> murch: ok, cool, yea, so it generates the smallest total tx bytes
09:20 < 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.
09:20 < murch> BlueMatt: Unfortunately, my scenario data does not contain actual time information.
09:21 < 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
09:21 < murch> BlueMatt: I have not checked just selecting "smallest bigger" yet. I just replicated what I found in the code.
09:23 < gmaxwell> BlueMatt: you mean making the final utxo set 126 times larger than bitcoin core isn't good?
09:23 < 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
09:23 < 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.
09:24 < 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
09:25 < BlueMatt> murch: did you emulate public FeeCalculation calculateFee(SendRequest req, Coin value, List<TransactionInput> originalInputs,
09:25 < BlueMatt>                                        boolean needAtLeastReferenceFee, List<TransactionOutput> candidates) throws InsufficientMoneyException {
09:25 < BlueMatt> ?
09:25 < BlueMatt> I mean because that is, essentially, the actual coin selection algorithm, not just CoinSelector
09:26 < murch> BlueMatt: Having a look, sorry it's been a few weeks
09:26 < BlueMatt> yea, np
09:27 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 250 seconds]
09:27 < BlueMatt> god this code is soooo old
09:27 < BlueMatt> wow, does no one maintain bitcoinj at all? how was this not replaced
09:30 < 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
09:30 < gmaxwell> murch: so is your codebase in a position to try more hypothetical algorithims? 
09:31 < murch> BlueMatt: I had missed "calculateFee", I had only discovered the CoinSelector.
09:32 < BlueMatt> murch: oh shit, that will probably significantly effect your simulation
09:32 < 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.
09:33 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev
09:33 < murch> BlueMatt: I should have written to the mailing list earlier. (._.)
09:33 < BlueMatt> murch: well either way you re-confirmed what we all knew: bitcoinj is unmaintained and its use should be significantly discouraged
09:34 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
09:35 < 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?
09:36 < 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.
09:36 < murch> Seems like I'm misrepresenting BitcoinJ here then.
09:36 < murch> perhaps also the other wallets.
09:37 < 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)
09:38 < BlueMatt> murch: is your simulator in java? that code is very standalone
09:38 < sipa> i don't understand why fee estimation matters
09:38 < murch> BlueMatt: Scala actually.
09:38 < BlueMatt> sipa: its not really fee estimation, its the thing that selects between coin selection options and change
09:38 < BlueMatt> ie whether to throw away change
09:38 < sipa> for a comparable simulation across clients you should assume a constant approximate feerate on the network
09:39 < BlueMatt> murch: so you can just drop that function in, mostly? I actually have no idea about scala tooling
09:39 < 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.
09:39 < BlueMatt> sipa: he does that
09:39 < sipa> and use the same fees in multiple tools
09:39 < sipa> murch: ah! you mean fee estimation of the transaction you are creating
09:39 < sipa> not feerate estimation on the network
09:40 < 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.)
09:41 < 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?
09:42 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection]
09:42 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 260 seconds]
09:42 < BlueMatt> murch: it takes the CoinSelector and will call it three times, and select between the options based on what the resulting change is
09:43 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
09:43 < murch> BlueMatt: o.0 I had the impression that the CoinSelector is deterministic?!
09:44 < 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"
09:46 < 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".
09:47 < sipa> murch: that seems desirable to me
09:47 < murch> BlueMatt: Ah, thanks. Now I get what you meant. I should probably be able to replicate that no problem.
09:47 < sipa> (the way you do it)
09:47 < sipa> otherwise there is the added variance of how wallets determine fees
09:48 < murch> sipa: Yeah, and it would have also blown the overhead for my simulation out of proportion. I'll add it to "Future Work". ;)
09:50 < 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. :)
09:55  * murch will be back after dinner
10:02 < gmaxwell> murch: 10sat/byte or per weight? (how does the segwit analysis change it?)
10:05 < gmaxwell> murch: so are you not modling the behavior where very small change out is converted into fee to avoid creating change?
10:13 < xinxi> gmaxwell: CT uses ECDH, which is not quantum resistant. Why not use a quantum resistant key exchange crypto algorithm? 
10:14 < instagibbs> xinxi: maybe #bitcoin-wizards ?
10:14 < xinxi> instagibbs: what's that for? 
10:15 < instagibbs> this channel is for near-term bitcoin core development, your question is about an implementation of elements sidechain and/or future quantum advances
10:15 < instagibbs> that channel is more suitable
10:15 < xinxi> instagibbs: OK.
10:15 < instagibbs> I can answer you there
10:18 < GitHub24> [bitcoin] MarcoFalke opened pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
10:28 < 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. 
11:14 -!- harrymm [~wayne@104.222.140.102] has quit [Ping timeout: 255 seconds]
11:22 -!- skyraider [uid41097@gateway/web/irccloud.com/x-mnvfyopatqxolybv] has quit [Quit: Connection closed for inactivity]
11:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:52 < GitHub54> [bitcoin] MarcoFalke opened pull request #8780: [rpc] Deprecate getinfo (master...Mf1609-getinfoDeprecate) https://github.com/bitcoin/bitcoin/pull/8780
11:54 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
11:55 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
12:00 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection]
12:02 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
12:02 < 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)
12:04 < 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.
12:07 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 260 seconds]
12:07 < gmaxwell> I suppose a sweep could instead work from the utxo set without loss.
12:13 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 268 seconds]
12:15 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]
12:26 -!- murch1 [~murch@p4FE3A480.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:27 -!- murch [~murch@p4FE383BA.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
12:34 -!- harrymm [~wayne@104.222.140.30] has joined #bitcoin-core-dev
12:45 -!- instagibbs [640f7203@gateway/web/freenode/ip.100.15.114.3] has quit [Ping timeout: 240 seconds]
12:46 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:5428:adc7:e421:30d2] has joined #bitcoin-core-dev
12:46 < GitHub125> [bitcoin] MarcoFalke opened pull request #8781: [contrib] delete qt_translations.py (master...Mf1609-deleteQtTrans) https://github.com/bitcoin/bitcoin/pull/8781
12:49 < MarcoFalke> I am looking for stuff but can only find outdated crap...
12:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
13:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
13:03 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
13:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
13:10 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
13:10 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 240 seconds]
13:20 -!- instagibbs [640f7203@gateway/web/freenode/ip.100.15.114.3] has joined #bitcoin-core-dev
13:26 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]
13:30 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-olpgdoalbnomffgb] has quit [Quit: Connection closed for inactivity]
13:44 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-jrvlnhxjwlefcfql] has quit [Remote host closed the connection]
13:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
14:07 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev
14:08 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:10 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
14:14 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 255 seconds]     
14:22 < BlueMatt> <instagibbs> pfrom->GetLocalServices() & NODE_WITNESS && (nCMPCTBLOCKVersion == 2)
14:22 < BlueMatt> <instagibbs> pfrom is referring to the remote node's flags, I hope
14:22 < BlueMatt> ...     
14:22 < BlueMatt> <BlueMatt> I think nLocalServices refers to YOUR services
14:22 < instagibbs> apparently not we learned, which confused the hell out of me
14:22 < BlueMatt> <BlueMatt> and you store it in every CNode object
14:22 < BlueMatt> is that true?
14:22 < BlueMatt> that seems...fun?
14:22 < instagibbs> nServices is the remote's services
14:22 < sipa> will check
14:22 < instagibbs> but both are stored on CNode
14:22 < BlueMatt> seems like an easy optimization for cfields to fix?
14:24 < instagibbs> well it could be a way to remember which services you promised without reconnecting?
14:24 < instagibbs> ie remembering what other node will have for nExpectedServices 
14:25 < 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..)
14:26 < 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
14:28 < 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?
14:28 < BlueMatt> (I'm not aware of any way it could change in the current code?)
14:28 < BlueMatt> eg pruning/bloom/etc cannot be turned on and off at runtime
14:28 < sipa> agree, it's always set at startup
14:28 < instagibbs> mind if i put a comment on that field to make that explicit? Maybe fewer tears in future
14:28 < BlueMatt> please do
14:28 < sipa> i'm making hypotheses here, cfields should probably comment
14:29 < BlueMatt> i dont think its new/changed in CConMan
14:29 < instagibbs> that was mine as well, but I'll wait for "official" call
14:30 < sipa> BlueMatt: before connman nLocalServices was a global
14:32 < instagibbs> I have a feeling reviewing cb pull will make a lot more sense now
14:47 < murch1> gmaxwell: 10 sat per byte, and for P2WPKH 10 byte per weight (if that's bytes + byte/4 for the witness part)
14:48 < 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.
14:49 < sipa> murch1: sounds right
14:51 < gmaxwell> murch1: does your model for core convert dust to fees?
14:56 < 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.
14:56 < gmaxwell> ::sigh::
14:57 < gmaxwell> murch1: okay, well your efforts then are moving things into a realm of academic novelty rather than anything pratical then.
14:57 < sipa> gmaxwell, murch1: i believe you are misunderstanding each other
14:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:58 < 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.
14:58 < sipa> how is the rule to convert dust to fees at all related to address reuse?
14:59 < gmaxwell> sipa: murch1 was responding to my earlier comment, not the most recent question about dust->fees..
14:59 < sipa> ah     
15:01 < sipa> gmaxwell: he is currently moddelling how actual wallets work... that seems very practically useful and not an academic novelty
15:02 < sipa> sure, if we're trying to find an optimal strategy, it may be worth taking reuse into account
15:02 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
15:04 < 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.
15:04 < sipa> i believe that's correct
15:05 < 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)
15:06 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 255 seconds]     
15:06 < gmaxwell> I'd be interested in knowing how the results change if it will send dust to fees more agressively. 
15:06 < sipa> yup     
15:06 < sipa> it's already pretty aggressive
15:06 < gmaxwell> e.g. try a direct match, send dust change to fees. Only try targeting 0.01 btc change if that fails. 
15:07 < 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?
15:07 < 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.
15:08 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev     
15:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15: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.
15:09 < 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. 
15:09 < 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………
15:10 < 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.
15:11 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
15:12 < 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 
15:13 < gmaxwell> yea, well I saw you were working off real data, so I had my hopes up. :P
15:13 < sipa> murch1: another idea may be to tie the minimum change to a percentage of the sent amount
15:13 < murch1> gmaxwell: The dataset is only positive and negative integers. Not even the order is actually really correct.
15:13 < murch1> because outgoing payments get recorded when requested and incoming only after confirmed.
15:14 < murch1> I have no clue when the transactions occurred or anything about addresses. :(
15:15 < gmaxwell> well, sensible wallets will not spend unconfirmed coins from third parties, so that ordering sounds basically correct.
15:15 < 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.
15:17 < luke-jr> what is the purpose of share/qt/protobuf.pri?
15:17 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds]     
15:18 < 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.
15:18 < 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.
15:18 < 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.
15:19 < sipa> murch1: but that does depend on the order of magnitude of the amounts you are dealing with
15:19 < murch1> true
15:19 < sipa> someone who regularly receives and sends small amounts may want a smaller setting for that
15:19 < murch1> I'm still working of the same MoneyPot dataset.
15:20 < 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.
15:20 < murch1> kanzure: Thanks
15:21 < 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?
15:22 < murch1> on Linux?
15:22 < murch1> You probably meant the message to gmaxwell before?
15:25 < 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.
15:25 < sipa> murch1: irssi
15:25 < murch1> gmaxwell: If the message was cut off before.
15:25 < 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. 
15:25 < sipa> used it exclusively for over 10 years now
15:25 < 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.
15:25 < 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.
15:26 < kanzure> ((well also the general benefit that everyone receives from good coin selection everywhere.))
15:31 -!- murch_ [~murch@p4FE3A480.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
15:33 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev     
15:34 < 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.
15:34 < murch_> sipa: did you see that about DoubleWallet?
15:35 -!- murch1 [~murch@p4FE3A480.dip0.t-ipconnect.de] has quit [Quit: Leaving.]     
15:35 -!- murch_ is now known as murch     
15:37 -!- sipa [~pw@2a02:348:86:3011::1] has quit [Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number]     
15:37 < luke-jr> ugh, we added unlicensed-or-GPL code to master (and soon 0.13..)
15:42 -!- sipa_ [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev     
15:44 < GitHub177> [bitcoin] MarcoFalke opened pull request #8783: [share] remove qt/protobuf.pri (master...Mf1609-deleteqtProto) https://github.com/bitcoin/bitcoin/pull/8783
15:48 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
15:48 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
15:49 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
15:52 -!- murch [~murch@p4FE3A480.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
15:56 < warren> luke-jr: where?
15:57 < luke-jr> warren: l_atomic.m4
15:57 < luke-jr> author is okay with licensing it under MIT-like terms, so workign on that
15:58 < warren> great
16:02 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
16:06 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
16:07 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 272 seconds]     
16:07 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
16:11 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
16:12 < GitHub136> [bitcoin] luke-jr opened pull request #8784: Copyright headers for build scripts (master...license_build) https://github.com/bitcoin/bitcoin/pull/8784
16:16 -!- rogerwilco [~rogerwilc@193-81-229-137.adsl.highway.telekom.at] has quit [Ping timeout: 250 seconds]     
16:17 -!- rogerwilco [~rogerwilc@195-230-63-194.adsl.highway.telekom.at] has joined #bitcoin-core-dev     
16:25 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
16:27 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
16:28 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
16:28 -!- LeMiner2 is now known as LeMiner     
16:29 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
16:41 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Quit: Leaving.]     
16:51 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
17:46 < GitHub154> [bitcoin] instagibbs opened pull request #8785: Comment on CNode::nLocalServices meaning (master...nlocalservisme) https://github.com/bitcoin/bitcoin/pull/8785
17:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hrhcrmzsqmtobfsq] has quit [Quit: Connection closed for inactivity]     
18:05 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 244 seconds]     
18:05 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit []     
18:06 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
18:14 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection]     
18:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
18:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
18:22 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
18:22 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-abfwlhknxypbpcsd] has joined #bitcoin-core-dev     
18:26 -!- xinxi [~xinxi@116.86.38.246] has quit [Client Quit]     
18:27 -!- shesek [~shesek@bzq-84-110-55-68.cablep.bezeqint.net] has quit [Ping timeout: 250 seconds]     
18:27 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
18:27 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 265 seconds]     
18:28 -!- xinxi [~xinxi@116.86.38.246] has quit [Client Quit]     
18:28 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
18:30 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
18:30 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
18:32 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev     
18:34 -!- shesek [~shesek@bzq-84-110-55-68.red.bezeqint.net] has joined #bitcoin-core-dev     
18:38 < wumpus> can we please stop doing the copyright pulls where half of github is highlightes
18:42 < wumpus> if you really think it is necessary to add everyone that ever fixed a typo in a build script before adding a header to each individual file, ask yourself whether this is really worth it, you're generalling ten gezillion notification mails
18:45 < achow101> by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant.
18:45 < gmaxwell> Why is that kind of thing being done by indivigual PRs rather than e.g. sending a mass email to all past contributors saying we're normalizing files in this and that way?
18:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
18:45 < gmaxwell> achow101: that is unlear though it could be made clear. 
18:46 < wumpus> I don't know, but this getting out of hand
18:46 < achow101> I though that was just kind of "in general" for all OSS projects
18:46 < wumpus> achow101: that is what I always thought too
18:46 < wumpus> there is a COPYING file in the rot of the repository
18:46 < wumpus> root*
18:47 < wumpus> if you don't put an explicit license in a file, that is what it is bound to
18:47 < wumpus> but apparantly this is turning into a frigging zoo now, what's next, ahving to ask permision for every source line?
18:47 < wumpus> what is this accomplishing?
18:48 < wumpus> and yes, asking per email would have been preferable. Asking once per contributor, too. If that is really necessary.
18:48 < wumpus> but we're not relicencing the project
18:48 < wumpus> it has ALWAYS been MIT
18:49 < wumpus> satoshi made it MIT
18:49 < wumpus> I've been contributing to open source for 20 years and I've never, once had a mail whether I gave permission to add a license header (license of the project) to the top of some file
18:50 < wumpus> I've been mailed a few times to approve of license changes, but that's a whole different and more serious thing
18:50 < wumpus> and that was for real contributions not changing the case of one letter in one file
18:55 < achow101> So what about adding this to the contributing.md: "By contributing to this repository, you agree to license your work under the MIT license and any subsequent licensing changes"
18:56 < wumpus> not the last part
18:57 < wumpus> only "By contributing to this repository, you agree to license your work under the MIT license"
18:57 < achow101> ok.     
18:58 < wumpus> future license changes are absolutely out of scope, I wouldn't agree to that - who decides? changing licenses is a serious issue. Adding the existing copyright header that has been the project's license since 2009 isn't.
18:59 < wumpus> I wouldn't be surprised with all this polling that people are starting to think we're changing licenses though ...
19:00 < GitHub82> [bitcoin] achow101 opened pull request #8786: Mandatory copyright agreement (master...copyright-contributing) https://github.com/bitcoin/bitcoin/pull/8786
19:02 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
19:13 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 265 seconds]     
19:29 < luke-jr> [01:45:21] <achow101> by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant. <-- not with the MIT license
19:30 < wumpus> yes we should make it explicitl
19:30 < wumpus> see https://github.com/bitcoin/bitcoin/pull/8786
19:30 < achow101> well my PR makes it explicit
19:30 < wumpus> yes     
19:32 < luke-jr> and hopefully people will stop submitting non-licensed code without getting permission first <.<
19:32 < wumpus> such as?
19:32 < luke-jr> wumpus: l_atomic.m4 until today
19:33 < wumpus> let's revert it then?
19:33 < luke-jr> came from a GPL-licensed project, with no license on the build stuff
19:33 < luke-jr> nah     
19:33 < luke-jr> already got an ACK from the author for MIT terms
19:34 < luke-jr> just something to keep in mind when stuff gets contributed by someone other than the original author
19:36 < wumpus> maybe we should add that to #8786, that if you submit something from another source it is important to mention that source as well as the license it is under
19:36 < luke-jr> +1     
19:39 < wumpus> hey, github review comments don't show as comments in the pull list
19:39 < luke-jr> O.o     
19:39 < wumpus> I've approved https://github.com/bitcoin/bitcoin/pull/8783 but it still shows as 0
19:40 < wumpus> unless I have an unrelated web caching issue, that happens
19:40 < kanzure> ouch is "approved" github's terminology? ok.
19:40 < achow101> How about "Any code contributed where you are not the original author must contain its license header"
19:40 < wumpus> yes makes sense achow101
19:40 < achow101> wumpus: I see your approval on 8783
19:41 < wumpus> kanzure: indeed, I wouldn't have used that word myself
19:41 < achow101> I think it's your browser
19:41 < kanzure> wumpus: that's going to cause confusion. oh well.
19:41 < luke-jr> can we get Travis to check for a copyright line on new files maybe?
19:42 < wumpus> achow101: yes I see it too in the topic itself, but do you see it in the overview list?
19:42 < wumpus> there's this comment icon and then a count, there's no count for #8783 here. Ohwell.
19:43 < achow101> oh that. No I don't see that
19:44 < wumpus> luke-jr: that's certainly possible
19:45 < wumpus> just paste the script from https://github.com/bitcoin/bitcoin/pull/8674 somewhere into the test process in travis.yml
19:45 < wumpus> +report
19:46 < wumpus> it's a pretty good suggestion, could even parse debian/copyright for the copyright metadata on binary files
19:46 < wumpus> I don't have time for those things though :)
19:50 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection]     
20:09 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-fxhzqwzfnzjxmgla] has joined #bitcoin-core-dev     
20:19 < GitHub131> [bitcoin] AmirAbrams opened pull request #8787: [Doc] Add missing autogen to example builds (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8787
20:23 < wumpus> how does this new 'project' functionality work? can I add a project, say 'Ubuntu 16.04 windows cross-build' and group issues under that?
20:27 < achow101> wumpus: watch https://www.youtube.com/watch?v=C6MGKHkNtxU
20:28 < roasbeef> it's basically like trello embedded within github 
20:29 < achow101> also read https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/
20:29 < wumpus> but can I use it for that? the problem is that I have to manually keep track of groups of issues right now, but they don't warrant a new label
20:33 < achow101> AFAICT, yes, you can use it for grouping related issues and PR's
20:33 < achow101> although it seems that actually doing it might be a bit of a pain with the drag and drop interface
20:35 < achow101> Stuff can be in multiple projects, and within projects are additional sub groupings (called columns)
20:39 < wumpus> thanks, looks somewhat like hwat I'm looking for then, I'll read on about it
20:47 -!- randy-waterhouse [~kiwigb@150.242.131.38] has joined #bitcoin-core-dev     
20:48 -!- randy-waterhouse [~kiwigb@150.242.131.38] has quit [Changing host]     
20:48 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev     
20:48 -!- YOU-JI [~youyouyou@y195091.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-core-dev     
20:48 -!- YOU-JI [~youyouyou@y195091.dynamic.ppp.asahi-net.or.jp] has quit [Client Quit]     
20:49 -!- YOU-JI [~youyouyou@y195091.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-core-dev     
20:50  * luke-jr wonders if projects are accessible to non-committers
20:50 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
20:51 < achow101> luke-jr: can you access the projects here: https://github.com/achow101/ProtectedBranchTest/projects ?
20:52 < luke-jr> I can see them, but it seems I cannot submit an issue to a specific project
20:54 -!- YOU-JI [~youyouyou@y195091.dynamic.ppp.asahi-net.or.jp] has quit [Client Quit]     
20:54 < achow101> right, I think it's more for internal organization for the committers
20:54 < achow101> just like how you can't do labels or milestones if you aren't part of the group
20:58 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 240 seconds]     
21:00 < sipa_> wumpus: you're up early
21:01 < sipa_> i briefly feared i was in the wrong timezone
21:05 < wumpus> achow101: seems to work fairly well https://github.com/bitcoin/bitcoin/projects/1
21:05 < wumpus> sipa_: hah yes couldn't sleep
21:06 < achow101> :D     
21:16 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
21:21 -!- sipa_ [~pw@2a02:348:86:3011::1] has quit [Quit: leaving]     
21:23 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev     
21:23 < sipa> wumpus: those projects look useful
21:23 < wumpus> indeed!
21:24 < sipa> especially if we'd actually maintain them, it could simplify things like writinf release notes as well
21:25 < sipa> "PRs #1234, #2345, #3456, #4567 and #5678 together replaced the outdated PoW system"
21:26 < wumpus> yes, that could be an advantage as well
21:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:55 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
21:59 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 264 seconds]     
22:01 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
22:04 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
22:04 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit]     
22:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:07 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
22:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:11 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 248 seconds]     
22:15 < wumpus> cfields: I've created a project for your P2P refactor, please add if I missed anything: https://github.com/bitcoin/bitcoin/projects/4
22:23 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 276 seconds]     
22:28 -!- Guest75206 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev     
22:28 -!- Guest75206 [~socrates1@li175-104.members.linode.com] has quit [Changing host]     
22:28 -!- Guest75206 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev     
22:28 -!- Guest75206 is now known as amiller     
22:40 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
22:41 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
22:44 < GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf5ebaa921a9...ca69ef4880d1
22:44 < GitHub21> bitcoin/master faf87af MarcoFalke: [contrib] delete qt_translations.py...
22:44 < GitHub21> bitcoin/master ca69ef4 Wladimir J. van der Laan: Merge #8781: [contrib] delete qt_translations.py...
22:44 < GitHub172> [bitcoin] laanwj closed pull request #8781: [contrib] delete qt_translations.py (master...Mf1609-deleteQtTrans) https://github.com/bitcoin/bitcoin/pull/8781
22:45 < GitHub146> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca69ef4880d1...64dc6457454a
22:45 < GitHub146> bitcoin/master fa13c5c MarcoFalke: [share] remove qt/protobuf.pri...
22:45 < GitHub146> bitcoin/master 64dc645 Wladimir J. van der Laan: Merge #8783: [share] remove qt/protobuf.pri...
22:45 < GitHub166> [bitcoin] laanwj closed pull request #8783: [share] remove qt/protobuf.pri (master...Mf1609-deleteqtProto) https://github.com/bitcoin/bitcoin/pull/8783
22:48 < GitHub28> [bitcoin] laanwj closed pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
22:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rcquzofiedjmsgct] has joined #bitcoin-core-dev     
22:55 < GitHub16> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/64dc6457454a...3166dff48f35
22:55 < GitHub16> bitcoin/master 6b6cbdd fanquake: [depends] expat 2.2.0
22:55 < GitHub16> bitcoin/master 9616ac8 fanquake: [depends] ccache 3.3.1
22:55 < GitHub16> bitcoin/master 86d410d fanquake: [depends] fontconfig 2.12.1
22:55 < GitHub4> [bitcoin] laanwj closed pull request #8423: [depends] expat 2.2.0, ccache 3.3.1, fontconfig 2.12.1 (master...expat-ccache-jul) https://github.com/bitcoin/bitcoin/pull/8423
22:56 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
22:56 < GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3166dff48f35...7008e28136b5
22:56 < GitHub101> bitcoin/master fa81d09 MarcoFalke: [contrib] Delete spendfrom
22:56 < GitHub101> bitcoin/master 7008e28 Wladimir J. van der Laan: Merge #8779: [contrib] Delete spendfrom...
22:57 < GitHub19> [bitcoin] laanwj closed pull request #8779: [contrib] Delete spendfrom (master...Mf1609-deleteAllTheThings) https://github.com/bitcoin/bitcoin/pull/8779
23:01 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 250 seconds]     
23:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:12 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
23:19 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
23:22 -!- DigiByteDev [~JT2@185.29.164.8] has joined #bitcoin-core-dev     
23:24 -!- xinxi [~xinxi@116.86.38.246] has quit [Quit: Leaving...]     
23:24 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
23:28 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 264 seconds]     
23:42 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]     
23:44 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection]     
23:45 < cfields> wumpus: ooh, neat
23:45 < jonasschnelli> cfields: do you see a/the reason why this fails on gcc but not on clang? https://github.com/bitcoin/bitcoin/pull/8745/files#diff-480477e89f9b6ddafb30c4383dcdd705R407
23:45 < jonasschnelli> Seems to cause linking errors...
23:45 < wumpus> yes. I like this feature
23:46 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
23:46 < jonasschnelli> Linking errors are here: https://travis-ci.org/bitcoin/bitcoin/jobs/160477991#L1567
23:46 < cfields> wumpus: I'll have a look in the morning. I've been distracted this week from the net stuff by the win32 toolchain crap. Got some neat stuff coming up as a result, though
23:47 < btcdrak> I quite like the projects tab, much easier to see a project progress potentially over more than one release
23:47 -!- xinxi_ [~xinxi@116.86.38.246] has joined #bitcoin-core-dev     
23:47 < cfields> jonasschnelli: heh, I just fixed the same thing for "bench" a few days ago, I need to PR it
23:47 < cfields> jonasschnelli: sec for link
23:47 < jonasschnelli> cfields: thanks!
23:48 < cfields> jonasschnelli: fyi, link-order doesn't matter for apple's linker, but it does for gnu ld/gold
23:48 < jonasschnelli> Yeah. I thought so and tried different orders,.. used the same the bitcoid does... 
23:48 < jonasschnelli> *then
23:48 < cfields> jonasschnelli: https://github.com/theuni/bitcoin/commit/a3786f1aeebf6455acec50926c3b27ea5c060f02
23:49 < jonasschnelli> cfields: Thanks.. Let me try something..
23:49 < cfields> jonasschnelli: should be pretty much copy/paste for you
23:49 < jonasschnelli> okay.
23:49 < jonasschnelli> btcdrak: A nice! We have projects now.
23:49 < btcdrak> international standards for copyright is "belongs to author" by default unless employed by a company, then it belongs to the employer by default, unless there is a prior agreement. Licensing is not implicit however. You do need to be careful about code copied from other projects that have incompatible licenses. Since we use MIT that's generally not a problem
23:49 < btcdrak> since MIT is generally quite permissive and compatible with just about anything.
23:50 < cfields> jonasschnelli: note that if something is disabled (zmq for example), it'll just be blank, so skipped. No need to try to if/endif around them anymore
23:50 < btcdrak> But in any case, users should be told the terms of submitting patches is that they license their work as MIT or if there is another license attached, they state that, and it is up to us to accept or refuse the patch (for example if the license was incompatible with our distribution).
23:50 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds]     
23:50 < btcdrak> Contributing should have a line about this.
23:50 < jonasschnelli> cfields: okay
23:51 < wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/8786
23:52 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds]     
23:53 < cfields> jonasschnelli: sigh, sorry. I took a quick look at the failure and assumed it was the same problem. Obviously looking more closely, it's something different.
23:54 < jonasschnelli> cfields: ah.. okay. But the amount of missing symbols should also point out that the linking order is wrong.. not?
23:55 < cfields> jonasschnelli: yes, either busted link order or circular dependency
23:55 -!- murch [~murch@p4FE3B008.dip0.t-ipconnect.de] has joined #bitcoin-core-dev