< 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.
< 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)
< 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.
< btcdrak>
we can keep screenshots of trolling that could eventually justify action, maybe. at least it would be empirical
< 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.
< btcdrak>
gmaxwell: agreed. it is a learning process.
< btcdrak>
I think we arent doing terribly, but always room to improve. :)
< 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
< gmaxwell>
, not twetting is equivilent to blocking everyone. :)
< bitcoin-git>
[bitcoin] maaku opened pull request #11196: Switch memory_cleanse implementation to BoringSSL's to ensure memory clearing even with -lto (master...fix-memory-clense) https://github.com/bitcoin/bitcoin/pull/11196
< morcos>
instagibbs: I don't like you're new risky send addition to the corefeebot
< 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
< morcos>
it could easily have been paid for out of band
< morcos>
also accounting for packages correctly is not trivial, have you done that
< morcos>
we shouldn't be using random ideas tweeted out to drive good practices in fee estimation. it should be the other way around
< 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
< instagibbs>
morcos, ok, how about "don't use this, just for my info"
< bitsegwit>
risky send with (USE RBF HERE) dialog would be fine imo
< instagibbs>
Or maybe I'll do another account that just is named DANGER and tweets that
< instagibbs>
I'm not going to not tweet the info, but up for any disclaimer :)
< instagibbs>
removed for now, will workshop it :)
< instagibbs>
I do admit that the account name would cross some wires if it started tweeting out risky info, I appreciate the feedback
< morcos>
instagibbs: yeah thanks, i'm fine with you tweeting whatever you want obviously, just not from Bitcoin Core Fee Bot. Sounds official.
< 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
< morcos>
i assume that's lumping btc1 nodes into Bitcoin Core? What do you think about dividing that up.
< 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
< 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
< 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.
< morcos>
and then look at the fee rate of the remaining package
< morcos>
take a look at the mining code, and then you'll probably be sad
< 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.
< morcos>
both pieces of information are useful
< 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)
< 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
< luke-jr>
morcos: yes, I should probably divide them out somehow
< morcos>
sdaftuar: yes, but that doesn't help the average full node that isn't running CNB
< sdaftuar>
sure, but i thought it might be helpful to instagibbs' fee monitoring
< 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.
< instagibbs>
what was the current idea for supporting segwit addresses by default? Same derivation path, just adding all variants of output types?
< instagibbs>
p2sh-p2wpkh + p2wpkh
< gmaxwell_>
no please don't.
< gmaxwell_>
then you're inviting people to randomly convert other people's keys to segwit addresses and it will sometimes work
< instagibbs>
gmaxwell_, go on...
< instagibbs>
bip49, minus the bip44 part?
< instagibbs>
i think a number of wallets have converged on m/49'
< 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.
< instagibbs>
Sounds good.
< gmaxwell>
the problem I think arises in supporting multiple pools... it could be that we could be sw only except for imported keys.
< instagibbs>
yes otherwise you'd have like 6 pools all said and done
< 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.
< gmaxwell>
10:31:42 < solidfox> gmaxwell, I just noticed something in 15
< gmaxwell>
10:31:58 < solidfox> gmaxwell, there is a %1 instead of "Bitcoin core"
< gmaxwell>
10:32:24 < solidfox> on the tooltip for the open config file button
< jnewbery>
wumpus (or other maintainer): can you add #10767 to the high-priority for review pile?
< bitcoin-git>
[bitcoin] esotericnonsense opened pull request #11198: [Qt] Fix display of package name on 'open config file' tooltip (0.15...fix-config-tooltip) https://github.com/bitcoin/bitcoin/pull/11198
< 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?
< sdaftuar>
esotericnonsense: default is to base things on master and tag them for backport
< 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
< gmaxwell>
esotericnonsense: always work against master unless you're just trying out a fix for an issue you haven't reproduced against master yet.
< 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
< esotericnonsense>
right, so should I open another PR against master? just testing it now
< gmaxwell>
until we abandon BDB for a proper custom wallet format.
< gmaxwell>
esotericnonsense: yes, please do.
< esotericnonsense>
will be up soon
< 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.
< gmaxwell>
er then the issue shows up again in the next major version*.
< esotericnonsense>
understood
< MarcoFalke>
esotericnonsense: To prevent opening a fresh pull. You could try rebasing on c2704ec98a1b7b35b6a7c1b6b26a3f16d44e8880
< 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
< MarcoFalke>
On GitHub there should be a dropdown to change from 0.15 branch to master branch
< esotericnonsense>
MarcoFalke: i'd need to force push, no?
< * esotericnonsense>
is not completely up to scratch on github's PR mechanism
< MarcoFalke>
jup, force push
< esotericnonsense>
done
< esotericnonsense>
hang on, why rebase on c2704 and not d97fe2016cc7739929aac5c44de5037163b17ad0 ?
< MarcoFalke>
d97fe2016cc7739929aac5c44de5037163b17ad0 works as well
< MarcoFalke>
Those are commit from before 0.15 was branched of
< esotericnonsense>
right that makes sense.
< MarcoFalke>
Actually you could use any commit from master, as we usually backport by cherry-picks. But, yeah...
< bitcoin-git>
[bitcoin] danra opened pull request #11199: Sync module: Use std locking primitives instead of boost ones (master...refactor/sync-boost-to-std) https://github.com/bitcoin/bitcoin/pull/11199
< 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.
< jimpo>
Now that there's a DB migration that runs on boot, you should be able to test it without resyncing from scratch.
< sipa>
jimpo: i'm confused
< sipa>
what is initChain, what consistency, what is branch 1034?
< jimpo>
sipa: Sorry, definitely posted that in the wrong channel