1 2017-08-30 00:15:48	0|btcdrak|re Twitter. blocking does prevent blocked person from replying which is useful against impersonation and obvious accounts. agree it is unproductive to block high profile trolls tho.  anyway there are no blocks now. was a hangover from when we started and the account was being targetted last year.
 2 2017-08-30 00:17:14	0|gmaxwell|btcdrak: thanks, yea, it's really problematic when anything we post gets immediately knocked offtopic by trolling. (just like jeff did with morcos' reply about the compaint; veering straight into hardfork conspiracy theories)
 3 2017-08-30 00:18:01	0|gmaxwell|I think if they continue to do things like that we should just keep records of it and block them when its clearly gone on too far. And if they complain we can just post summaries of their abusive and unprofessional behavior.
 4 2017-08-30 00:19:22	0|btcdrak|we can keep screenshots of trolling that could eventually justify action, maybe. at least it would be empirical
 5 2017-08-30 00:19:34	0|gmaxwell|I think our project has already suffered to much from having our ability to communicate supressed by trolling; but I think we can behave above reproach without allowing too much abuse.
 6 2017-08-30 00:20:18	0|btcdrak|gmaxwell: agreed. it is a learning process.
 7 2017-08-30 00:20:41	0|btcdrak|I think we arent doing terribly, but always room to improve. :)
 8 2017-08-30 00:21:27	0|gmaxwell|The complaint about being blocked is basically depending on a false comparison.  Lets imagine we were unconditionally unable to block. Then we could count on every announcement we put up immediately being flooded with smearing, and we'd simply stop tweeting entirely.  Could anyone argue that a twitter account which never tweets is superior to one that has blocked people but get used. Effectively
 9 2017-08-30 00:21:34	0|gmaxwell|, not twetting is equivilent to blocking everyone. :)
10 2017-08-30 01:59:08	0|lejitz|Sorry for off-topic, but this seems important to this bunch https://www.reddit.com/r/Bitcoin/comments/6wvyab/bitmain_is_trying_to_patent_widely_used_efficient/
11 2017-08-30 02:05:45	0|kallewoof|ryanofsky: interesting. will definitely check that out.
12 2017-08-30 02:28:37	0|gmaxwell|https://bitcointalk.org/index.php?topic=2132893.0  I wonder if it's not crashing but hitting that gui off screen issue.
13 2017-08-30 05:49:36	0|bitcoin-git|[13bitcoin] 15maaku opened pull request #11196: Switch memory_cleanse implementation to BoringSSL's to ensure memory clearing even with -lto (06master...06fix-memory-clense) 02https://github.com/bitcoin/bitcoin/pull/11196
14 2017-08-30 12:35:27	0|morcos|instagibbs: I don't like you're new risky send addition to the corefeebot
15 2017-08-30 12:35:56	0|morcos|that is never something we would add to Bitcoin Core without a whole lot of complication to determine that that is a fee rate that would have legitimately been selected for the last block
16 2017-08-30 12:36:02	0|morcos|it could easily have been paid for out of band
17 2017-08-30 12:36:15	0|morcos|also accounting for packages correctly is not trivial, have you done that
18 2017-08-30 12:37:33	0|morcos|we shouldn't be using random ideas tweeted out to drive good practices in fee estimation.  it should be the other way around
19 2017-08-30 12:38:05	0|morcos|if it's a good idea that survives rigorous peer review we should implement it in a Bitcoin Core tool or bitcoind and then we can tweet out the result
20 2017-08-30 12:38:30	0|instagibbs|morcos, ok, how about "don't use this, just for my info"
21 2017-08-30 12:38:33	0|bitsegwit|risky send with (USE RBF HERE) dialog would be fine imo
22 2017-08-30 12:38:55	0|instagibbs|Or maybe I'll do another account that just is named DANGER and tweets that
23 2017-08-30 12:39:43	0|instagibbs|I'm not going to not tweet the info, but up for any disclaimer :)
24 2017-08-30 12:44:31	0|instagibbs|removed for now, will workshop it :)
25 2017-08-30 12:49:00	0|instagibbs|I do admit that the account name would cross some wires if it started tweeting out risky info, I appreciate the feedback
26 2017-08-30 13:06:24	0|morcos|instagibbs: yeah thanks, i'm fine with you tweeting whatever you want obviously, just not from Bitcoin Core Fee Bot.  Sounds official.
27 2017-08-30 13:06:53	0|morcos|and its not that i don't think that is a potentially useful piece of info, but i think it should be reviewed carefully before we do it as a project
28 2017-08-30 13:10:52	0|morcos|luke-jr: question about your node counter: http://luke.dashjr.org/programs/bitcoin/files/charts/software.html
29 2017-08-30 13:11:18	0|morcos|i assume that's lumping btc1 nodes into Bitcoin Core?  What do you think about dividing that up.
30 2017-08-30 13:11:45	0|morcos|I think its super useful to show that of people who bother to run full nodes, such a very small percentage are going to be on this supposed Nov fork
31 2017-08-30 13:15:15	0|instagibbs|morcos, what's the best way of getting package feerate for a particular tx? Looking at some summary statistics for block template could be nice
32 2017-08-30 13:16:07	0|morcos|instagibbs: it's complicated.  you have to basically run the whole mining algorithm over again to see what parts of its package were already included due to their own fee rate.
33 2017-08-30 13:16:20	0|morcos|and then look at the fee rate of the remaining package
34 2017-08-30 13:16:39	0|morcos|take a look at the mining code, and then you'll probably be sad
35 2017-08-30 13:17:46	0|morcos|I do think something along these lines is interesting though, i have had branches for some time now that track what the highest fee rate transactions in your mempool are that were eligble for inclusion and weren't..  which is the flip side of the coin you are looking at.
36 2017-08-30 13:18:02	0|morcos|both pieces of information are useful
37 2017-08-30 13:41:41	0|sdaftuar|morcos: instagibbs: i think we could easily add "last package feerate selected" to the set of things that CreateNewBlock spits out, eg to the debug log (or stash somewhere and return via rpc)
38 2017-08-30 13:42:54	0|sdaftuar|fyi an added bit of trickiness is at the end of a block, you might skip over higher feerate packages that don't fit, because the block is full, so it's not an easy value to reason about
39 2017-08-30 13:49:37	0|luke-jr|morcos: yes, I should probably divide them out somehow
40 2017-08-30 13:56:52	0|morcos|sdaftuar: yes, but that doesn't help the average full node that isn't running CNB
41 2017-08-30 13:57:34	0|sdaftuar|sure, but i thought it might be helpful to instagibbs' fee monitoring
42 2017-08-30 14:27:06	0|MarcoFalke|wumpus: Mind to add the list of pulls in 0.15.0 to the release notes. I'd like to look over that before final.
43 2017-08-30 15:00:40	0|bitcoin-git|13bitcoin/06master 1449eb091 15practicalswift: [tests] Avoid redundant assignments. Remove unused variables.
44 2017-08-30 15:00:40	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a90e6d2bffc4...d81dccf191a4
45 2017-08-30 15:00:41	0|bitcoin-git|13bitcoin/06master 14d81dccf 15MarcoFalke: Merge #10777: [tests] Avoid redundant assignments. Remove unused variables...
46 2017-08-30 15:01:14	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10777: [tests] Avoid redundant assignments. Remove unused variables (06master...06test-vars) 02https://github.com/bitcoin/bitcoin/pull/10777
47 2017-08-30 17:25:36	0|instagibbs|what was the current idea for supporting segwit addresses by default? Same derivation path, just adding all variants of output types?
48 2017-08-30 17:25:51	0|instagibbs|p2sh-p2wpkh + p2wpkh
49 2017-08-30 17:26:05	0|gmaxwell_|no please don't.
50 2017-08-30 17:26:31	0|gmaxwell_|then you're inviting people to randomly convert other people's keys to segwit addresses and it will sometimes work
51 2017-08-30 17:26:33	0|instagibbs|gmaxwell_, go on...
52 2017-08-30 17:26:54	0|instagibbs|bip49, minus the bip44 part?
53 2017-08-30 17:27:48	0|instagibbs|i think a number of wallets have converged on m/49'
54 2017-08-30 17:28:21	0|gmaxwell_|It should just be a different path, I don't think doing anything with 49 provides any value whatsoever, but it doesn't really matter which other path it is.
55 2017-08-30 17:28:56	0|instagibbs|Sounds good.
56 2017-08-30 17:30:40	0|gmaxwell|the problem I think arises in supporting multiple pools... it could be that we could be sw only except for imported keys.
57 2017-08-30 17:31:09	0|instagibbs|yes otherwise you'd have like 6 pools all said and done
58 2017-08-30 17:32:37	0|gmaxwell|we could still support turning an existing wallet into a segwit one, by generating a new master key and converting all keys to imported-like ones.
59 2017-08-30 17:33:33	0|gmaxwell|10:31:42 < solidfox> gmaxwell, I just noticed something in 15
60 2017-08-30 17:33:33	0|gmaxwell|10:31:58 < solidfox> gmaxwell, there is a %1 instead of "Bitcoin core"
61 2017-08-30 17:33:33	0|gmaxwell|10:32:24 < solidfox> on the tooltip for the open config file button
62 2017-08-30 18:19:09	0|jnewbery|wumpus (or other maintainer): can you add #10767 to the high-priority for review pile?
63 2017-08-30 18:19:19	0|bitcoin-git|[13bitcoin] 15esotericnonsense opened pull request #11198: [Qt] Fix display of package name on 'open config file' tooltip (060.15...06fix-config-tooltip) 02https://github.com/bitcoin/bitcoin/pull/11198
64 2017-08-30 18:27:26	0|esotericnonsense|if anyone is around - should I have based this on 0.15.0 or master? which is more helpful to those with push access?
65 2017-08-30 18:28:49	0|sdaftuar|esotericnonsense: default is to base things on master and tag them for backport
66 2017-08-30 18:29:16	0|sdaftuar|esotericnonsense: for things that don't cherry-pick cleanly, you can open a backport PR as well that is based on the older branch, but that's more the exception than the rule
67 2017-08-30 18:29:57	0|gmaxwell|esotericnonsense: always work against master unless you're just trying out a fix for an issue you haven't reproduced against master yet.
68 2017-08-30 18:33:03	0|gmaxwell|esotericnonsense: looking at backscroll, I see you were asking about BDB. Yes, you can use newer bdb but they can't (reliably) be run with older software, we're not aware of any improvements in BDB that would encourage using a newer version. And the newest versions have much more restrictive licensing. I think that our plan, to the extent we have one there, is to continue using the 4.8.x series
69 2017-08-30 18:33:06	0|esotericnonsense|right, so should I open another PR against master? just testing it now
70 2017-08-30 18:33:09	0|gmaxwell|until we abandon BDB for a proper custom wallet format.
71 2017-08-30 18:33:45	0|gmaxwell|esotericnonsense: yes, please do.
72 2017-08-30 18:34:01	0|esotericnonsense|will be up soon
73 2017-08-30 18:34:34	0|gmaxwell|esotericnonsense: in general, all changes must go in master first. this prevents mistakes where a fix goes in a release branch then shows up in the next major version.  It also gets the change more testing, since developers mostly work against master.
74 2017-08-30 18:34:53	0|gmaxwell|er then the issue shows up again in the next major version*.
75 2017-08-30 18:35:05	0|esotericnonsense|understood
76 2017-08-30 18:36:55	0|MarcoFalke|esotericnonsense: To prevent opening a fresh pull. You could try rebasing on c2704ec98a1b7b35b6a7c1b6b26a3f16d44e8880
77 2017-08-30 18:38:14	0|MarcoFalke|Make sure you are on the right branch and no uncommited changes! Then: git reset --hard c2704ec98a1b7b35b6a7c1b6b26a3f16d44e8880 && git cherry-pick 6c26e89 && git push origin $your_branch_name
78 2017-08-30 18:38:54	0|MarcoFalke|On GitHub there should be a dropdown to change from 0.15 branch to master branch
79 2017-08-30 18:44:38	0|esotericnonsense|MarcoFalke: i'd need to force push, no?
80 2017-08-30 18:47:31	0|MarcoFalke|jup, force  push
81 2017-08-30 18:47:40	0|esotericnonsense|done
82 2017-08-30 18:49:25	0|esotericnonsense|hang on, why rebase on c2704 and not d97fe2016cc7739929aac5c44de5037163b17ad0 ?
83 2017-08-30 18:49:38	0|esotericnonsense|https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsdialog.cpp
84 2017-08-30 18:52:01	0|MarcoFalke|d97fe2016cc7739929aac5c44de5037163b17ad0 works as well
85 2017-08-30 18:52:28	0|MarcoFalke|Those are commit from before 0.15 was branched of
86 2017-08-30 18:52:49	0|esotericnonsense|right that makes sense.
87 2017-08-30 18:53:14	0|MarcoFalke|Actually you could use any commit from master, as we usually backport by cherry-picks. But, yeah...
88 2017-08-30 19:47:58	0|bitcoin-git|[13bitcoin] 15danra opened pull request #11199: Sync module: Use std locking primitives instead of boost ones (06master...06refactor/sync-boost-to-std) 02https://github.com/bitcoin/bitcoin/pull/11199
89 2017-08-30 20:55:44	0|jimpo|My node is taking forever to get in sync (I'm working in a VM), but initChain state is consistency much faster with ~300K blocks in branch #1034.
90 2017-08-30 20:56:04	0|jimpo|Now that there's a DB migration that runs on boot, you should be able to test it without resyncing from scratch.
91 2017-08-30 20:57:44	0|sipa|jimpo: i'm confused
92 2017-08-30 20:58:14	0|sipa|what is initChain, what consistency, what is branch 1034?
93 2017-08-30 21:33:58	0|jimpo|sipa: Sorry, definitely posted that in the wrong channel