< xmsx>
I'm trying to generate segwit address in PHP but not sure if I got it right, and my bitcoin got corrupted database for some reason so I can't test it properly
< xmsx>
Also, don't try to run that code above, it won't work for you, it's just a pseudocode :)
< sipa>
xmsx: sorry, this the dev channel for bitcoin core, a c++ bitcoin client
< xmsx>
Can you just import this private key: 5KAwW31HxQW5Jrp4HM3o59BPRXarMP87imDR1nrjQpGvnTzwafK and tell me if segwit for it is 37fZYysB6c2iMt2cywZyUUydqQkR6vkCri?
< bitcoin-git>
[bitcoin] kallewoof opened pull request #11884: [trivial] Remove unused include in hash.cpp (master...20171213-unneeded-include-hash-cpp) https://github.com/bitcoin/bitcoin/pull/11884
< bitcoinNOOOB>
Hello?
< bitcoinNOOOB>
Anyone here?
< jonasschnelli>
[OT] what is the fastest way to amend commit the current changes into a non HEAD commit? (instead of git stash & git rebase -i HEAD~3 (edit) & git stash apply & git commit --amend & git rebase --continue)?
< sipa>
i usually just write a new commit at the end, and then move/apply/squash it with rebase -i
< wumpus>
same here
< sipa>
so <make changes>; git commit -am "fix"; git rebase -i HEAD~~~~~~~~, and move the last commit up in the list turning the 'pick' into 'fix'
< wumpus>
I make lots of temporary commits, then at some point I merge them into the commit they belong
< sipa>
if the changes are to a commit in the middle which you can't just do at the end (because they're already overwritten in a later commit), git rebase -i HEAD~~~~~~ and 'edit' the commit itself
< sipa>
(i squash very liberally, but try to avoid actually rebasing0
< wumpus>
if you already have changes in your working tree that need to be spread into multiple commits, git add -p is great
< jonasschnelli>
thanks!
< jonasschnelli>
There is no direct way for git rebase -i HEAD~3 (then select edit)? Something that directly rebased back in edit mode to ~3 (or other depth)?
< jonasschnelli>
I whish my IDE would have a way to directly amend commit a line-change (or block) into a selected historical commit
< wumpus>
I think everything you can do with -i (interactive) should be possible without -i, it's just a longer sequence of commands
< wumpus>
in a way an interactive mode makes you lazy :)
< wumpus>
yes that'd be quite useful as a command, what I usually miss is a way to refer to commits by say, a name, instead of their (ever changing) commit id
< wumpus>
that would be so much easier for referring to them in rebase commands
< jonasschnelli>
wumpus: indeed
< Provoostenator>
There's a Github issue or PR about consolidating translation files, but I can't find it. Not even with Google...
< fanquake>
There are various issues for translations open at the moment. Do you want to add discussion somewhere?
< fanquake>
cfields did you end up sending the zeromq mingw64 patch upstream?
< Provoostenator>
I want to link to it from #11875 because reducing the number of locales would probably be helpful for review.
< Provoostenator>
I remember the issue was quite specific about whch language files could be combined.
< wumpus>
I don't think there's a hard rule for that; in some cases the same language for multiple countries is spurious, in some cases there's actually a language difference
< wumpus>
'reducing the number of locales' is not a goal in itself, it means leaving people without translations for their language, though removing low-quality ones would be good (but this has to be judged on transifex somehow)
< Provoostenator>
I think the PR (which I can't find) was just combining (mostly) identical languages like Dutch and Flemish.
< sipa>
jonasschnelli: my odroid iseems be having some trouble... i just had a block that took 12 hours to validate
< sipa>
it looks like it's just insanely slow I/O (7.5s per txin), but it's much faster after a reboot
< Provoostenator>
In transifex there's nl, nl_BE, and nl_NL, although in src/qt/locale there's only nl. So maybe this has already been done.
< wumpus>
yes, I have already been selective which languages I include in the repository
< wumpus>
also translations with too few messages don't get included
< wumpus>
(although that threshold is at 10, should probably be higher with the huge volume of translatable strings we have these days)
< Provoostenator>
As long as the fallback is sane and the translations are reviewed, wouldn't 1 be a low enough threshold?
< Provoostenator>
E.g. if Flemish falls back to Dutch and Dutch falls back to English. Similarly Latin american versions of Spanish should fall back to European Spanish, before falling back to English.
< Provoostenator>
But if instead languages immedidately fall back to English then it's probably better to leave them out if they're seriously incomplete.
< sipa>
Provoostenator: we've had issues in the past once where there was an austrian german translation which was apparently full of dialect that offended peoe
< Provoostenator>
Without review even worse things could happen.
< sipa>
oh yes.
< Provoostenator>
So I think the amount / quality / trustworthyness of review is more important than the number of translated phrases (depdneing on fallback behavior).
< Provoostenator>
Obviously it's not worth monitoring reviewers for a language with 5 words, so I guess it's the same outcome.
< wumpus>
what use would a translation with one translated phrase be? I don't see it
< wumpus>
for translation to be useful the entire application needs to be translated, more or less, certainly the most visited parts
< sipa>
i don't know how i'd translate anything dirrectly in dutch vs flemish
< wumpus>
I do agree the threshold could be lower for XX_yy languages that just override some messages than for XX "top level" ones
< wumpus>
but otherwise the number of message is a measure of compleness
< Provoostenator>
There's probably no use for a translation with 10 words, but if someone believes it's useful (for whatever reason I can't think of) and it's reviewed, and the fallback behavior is correct, I don't see a downside.
< Provoostenator>
But as a general rule I would agree the majority of the frequently used parts of the app should be translated and maintained.
< Provoostenator>
There are some cases where XX_yy languages have subtle differences that are genenally not a problem, but can be very confusing in just one or two places. That's the only scenario I can think of and I doubt it's relevant with so much technical jargon.
< wumpus>
another reason why a language with many translations is preferable is because, very likely, there is more translation activity for it
< wumpus>
a language with 10 messages will likely have had 1 person type in some messages
< wumpus>
but sure, in the end it's just a time-saving heuristic - I don't have time nor language skills to judge every translation separately
< wumpus>
I like the idea of having a glossary of 'words to not translate' btw, though I'm not sure it works for every language
< wumpus>
e.g. what about chinese or arabic? it just doesn't make sense t ohave english words interspersed there
< Provoostenator>
The glossary for each language would contain the suggested translation, which in most cases would not be a translation.
< wumpus>
you want to make one for every language?
< Provoostenator>
Well, every language where it's useful.
< Provoostenator>
Isn't that how it already works?
< wumpus>
that's awesome
< wumpus>
I mean we've never had anyone spend a lot of time on translations or helping translators, i've tried to do it on or off (usually by removing overly-technical messages from translation or rewording them)
< Provoostenator>
It's seems problematic to have a process that nobody can focus enough on to prevent things from breaking.
< wumpus>
it's not clear to me what kind of process works for translating open source software
< wumpus>
though the current one works, more or less, it's certainly better than not translating at all
< Provoostenator>
I think it's better to not translate when in doubt
< wumpus>
whose doubt?
< wumpus>
that's the problem really here, you'd have to mobilize lots of volunteers
< wumpus>
unless you know all languages yourself :)
< wumpus>
maybe it's realistic now that bitcoin is so well-known
< Provoostenator>
There's a lot of websites and applications out there where the translation is worse than the original.
< wumpus>
and still it helps some people
< Provoostenator>
I think requiring review of translated strings would be a good improvement.
< wumpus>
a large portion of the world doesn't know english at all, so even somewhat broken form of their own language is more understandable
< wumpus>
by whom?
< Provoostenator>
Not always, because if you google a word like "snoei" you won't find help in any language.
< wumpus>
well it literally translates to prune
< Provoostenator>
Same as with pull requests; anyone can review translations, don't merge unless it has enough review.
< wumpus>
so does transifex have a process for that?
< wumpus>
I know you can make teams etc
< wumpus>
and that messages can be flagged as 'reviewed'
< Provoostenator>
Yes, when you download the strings, you can select that you only want reviewed strings.
< Provoostenator>
At least in the UI.
< wumpus>
yes, but what does that mean?
< wumpus>
who clicked 'reviewed' in that case?
< Provoostenator>
That part I'm still figuring out
< Provoostenator>
Transifex is broken for me, I can't see some of the pages.
< wumpus>
I guess that a language reviewr needs to be assigned for every language?
< wumpus>
or review team
< Provoostenator>
Every language has a team, feel free to add me to Dutch.
< wumpus>
I think German has a review team, from back when diapolo was a contributor
< wumpus>
oh they can choose their own team?
< wumpus>
I really have no clue :)
< Provoostenator>
I think you (or whoever has admin rights over transifex) can invite people to language teams.
< wumpus>
I'll see if I can add you for dutch
< Provoostenator>
So a process could be: 1) all translations need review by someone in the team 2) before or after merging the final version, remind people on Github to quickly skim through whichever language they know 3) if (2) leads to problems, fire the reviewers
< wumpus>
but I can't coordinate this for every language
< Provoostenator>
(3) could be less drastic :-)
< Provoostenator>
So maybe we need a github issue for a translation coordinator?
< Provoostenator>
Sounds like a good role for a non-technical person who wants to help out.
< wumpus>
I can't even find where to add you, I can go to https://www.transifex.com/bitcoin/teams/159/nl_NL/ and see your name under "translators" but I don't see how to move you to coorindator or reviewer
< Provoostenator>
I'll try to make an org for myself and see if I can figure out the UX.
< Provoostenator>
I've used half a dozen translation services in the past and they all have serious issues.
< wumpus>
might be that I don't have the required permissions
< Provoostenator>
Yeah, I was assuming you were the admin.
< Provoostenator>
Maybe Satoshi is? :-)
< wumpus>
I'm "project maintainer"
< wumpus>
seone, apparently
< wumpus>
haven't seen them in a long time...
< wumpus>
on the other hand I have access to all the settings, even the "delete project" button, so I would find it slightly strange if I don't have access to teams
< Provoostenator>
Projects are not the top lovel.
< Provoostenator>
Organization is
< wumpus>
ok
< Provoostenator>
If you click on the dropdown next to Bitcoin at the top, you shoudl see Organization Settings.
< Provoostenator>
(I don't see that for Bitcoin because I don't own that org, but I do see it for the org I just created)
< wumpus>
the only solution is to call everyone bitcoin core developer that contributed one patch, or heck even a translation message
< meshcollider>
yes all users on transifex are core developers too :)
< wumpus>
yup!
< wumpus>
in that regard I've been trying to get credit info from the API (for the release notes) but haven't been succesful
< Provoostenator>
Yes, which would include the bitcoin diamonds(?) person whose gitian signature was recently added to a PR.
< gmaxwell>
Nah, they media does this when people use it to promote themselves or at least don't say don't do that.
< gmaxwell>
that new spinoff is especially scammy, in they they confiscate most of the coins; -- any coin that wasn't moved in the last 30 days.
< Provoostenator>
Ah, that's where they get their "sizable reserve to stabilize its price relative to fiat currencies"
< wumpus>
the confiscation part is extrememly scammy, I mean deleting coins after 30 days that's one way to *bludgeon* the utxo set down, a very ugly way, but moving that money into their pocket is simply criminal
< gmaxwell>
(moved in the last 30 days before their fork, and their domain was only registered <12 days before the fork...)
< Provoostenator>
I'm sure it will stabilize at 0. I personally don't find it very productive to try and get media to report bitcoin related thing correctly.
< gmaxwell>
well they design the rules, so ... well the really misleading part is to claim it is really related to bitcoin at all, it's just a massively premined dumb altcoin, where they happened to give a small portion to people who generated excess tx volume in the last week.
< wumpus>
right, just yet another fork, at some point people will start ignoring them like they do for new altcoins and icos
< Provoostenator>
There will probalby be plenty of malware too, maybe even in the reference client.
< wumpus>
yep, also waiting for the first fork with malware in their reference client, it has been done with altcoins
< Provoostenator>
Let's see if they get it right "at block height: #498,777"
< wumpus>
garzik is pretty just wasting everyones time
< wumpus>
+much
< Provoostenator>
On the bright side, some of these airdrop developers might end up contributing to Core in the long term.
< wumpus>
at some point his reputation will go down enough he can't keep pulling these stunts off anymore
< Provoostenator>
Whaha, you'd be surprised.
< Provoostenator>
I can point you to some biographies...
< wumpus>
I'm not sure we even want that, the forks don't really seem to attract much talent, just people full of themselves that think they can do everything better
< Provoostenator>
Not always, not if they're hired developers.
< Provoostenator>
Then it's just their boss telling them to work on X, which they might feel reluctant about.
< gmaxwell>
Provoostenator: someone once said that about altcoins in 2011... so far it seems almost none have done so.
< Provoostenator>
Were any of these altcoins run by companies though? I would not expect single founder coin devs to do this. But yeah, I'm probably too optimistic.
< fanquake>
The altcoins were run in bitcointalk threads. And eventually "generators" just churned them out.
< Provoostenator>
My favorite comment so far: "UnionBitcoin god mode block generator" (anyway, off topic I guess, unless there's a zero-day?)
< gmaxwell>
Provoostenator: in 2011 no, but ripple...
< Provoostenator>
Does Ripple have any code overlap with Core that would make it easy for their devs to help out here?
< wumpus>
I don't think they have any code overlap
< meshcollider>
certainly doesn't look like they do, from a quick browse at their repo
< gmaxwell>
generally companies won't have code overlap, paying people to rewrite the codebase (not necessarily well or with any originality :) ) is cheap to do and lots of people are eager to do it.
< Provoostenator>
I created #bitcoin-airdrop-code-shenanigans if anyone is interested. Not sure how to log it.
< cluelessperson>
question, which flag indicates an RBF transaction?
< mryandao>
nsequence
< cluelessperson>
< some maximum?
< meshcollider>
cluelessperson: yep RBF if any sequence value is less than 0xffffffff - 1
< cluelessperson>
oh that's easy
< cluelessperson>
I overlooked it in my code
< * cluelessperson>
makes a comment
< cluelessperson>
wait
< cluelessperson>
my previous code looks at nsequence in all of the inputs
< cluelessperson>
is that right?
< cluelessperson>
should be nSequence of the current transaction, not inputs, right?
< aj>
cluelessperson: depends on if the inputs have confirmed already
< cluelessperson>
aj: What depends?
< aj>
cluelessperson: RBF inherits; if the ancestors have nSeq signalling RBF, current tx is RBF too
< aj>
cluelessperson: (provided the ancestors haven't confirmed yet)
< meshcollider>
cluelessperson: Depends what you are referring to by an input. If you mean the vin of the transaction, then yes, thats correct, sequence numbers are per-input
< meshcollider>
that is different from looking back at the parent being spend
< meshcollider>
spent*
< meshcollider>
but yes aj is right, RBF also inherits
< cluelessperson>
I see
< cluelessperson>
for txin in tx.vin: if txin.nSequence < 0xfffffffe: return True
< bitcoin-git>
bitcoin/master 68e021e Wladimir J. van der Laan: Merge #11558: Minimal code changes to allow msvc compilation...
< DeadCode>
hello world
< DeadCode>
I would like to ask some questions to jonasschnelli but he seems offline, anyone would like to help regarding libbtc implementation, please?
< promag>
MarcoFalke: ping
< promag>
wumpus: int64_t GetArg returns 0 if conversion fails
< promag>
should it return default value? should it throw or signal some *bool?
< wumpus>
I guess that has always been the case?
< promag>
we have ParseInt64 that indicates success or not
< wumpus>
no, if that's changed, I'd say make it use ParseInt64 instead of atoi and raise an actual error
< wumpus>
yes
< promag>
for instance, -prune=foo
< promag>
atm it's the same as -prune=0
< wumpus>
it should throw an error and exit imo
< promag>
my opinion also
< wumpus>
using the default value when parsing fails isn't better
< promag>
right
< promag>
it's bad configuration
< promag>
should be fixed
< promag>
the problem is that dealing with failed conversion will make the code ugly throughout, GetArg is used everywhere
< wumpus>
yeah...
< wumpus>
that's kind of the annoying thing about the current argument parsing code
< wumpus>
that it's called from everywhere, not just init
< wumpus>
also why I didn't fix this before, I did know of that use of atoi when I introduced ParseInt64
< wumpus>
seems it's something better left for when there's more structured argument parsing
< promag>
is validation.h the best place for LookupBlockIndex definition?
< promag>
I guess so because extern BlockMap& mapBlockIndex; is in validation.h
< BlueMatt>
yes, though tbh I'd like to quickly move to LookupBlockIndex being in validation.h and mapBlockIndex being validation.cpp-static, but thats more work so can be a separate pr
< BlueMatt>
I just really want to get #10692 in, and #11041 should simplify it a bunch
< gribble>
https://github.com/bitcoin/bitcoin/issues/10692 | Make mapBlockIndex and chainActive and all CBlockIndex*es const outside of validation/CChainState by TheBlueMatt · Pull Request #10692 · bitcoin/bitcoin · GitHub
< BlueMatt>
and I can probably skip making mapBlockIndex const and just move it to validation.cpp, cause making it const is a stupid hack (that possible invokes ub? I'm not actually 100% sure)
< promag>
haven't compiled locally to verify the annotation LookupBlockIndex(const uint256& hash) EXCLUSIVE_LOCKS_REQUIRED(cs_main), waiting for travis
< BlueMatt>
you just have to compile with CXX=clang++ ./configure --enable-werror
< bitcoin-git>
[bitcoin] jimhashhq reopened pull request #10922: New file-partition.md doc describing how to partition files to ensure fast initial blockchain synchronization.. (master...master) https://github.com/bitcoin/bitcoin/pull/10922
< bitcoin-git>
[bitcoin] practicalswift closed pull request #11734: rpc: Work around Clang thread safety analysis quirks (master...clang-thread-safety-quirks) https://github.com/bitcoin/bitcoin/pull/11734
< ThemoonMoth>
Thoughts about the upcoming FCC vote?
< ThemoonMoth>
And it's effect on bitcoin development in the US
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11886: Clarify getbalance meaning a tiny bit in response to questions. (master...2017-12-getbalance-docs) https://github.com/bitcoin/bitcoin/pull/11886
< jonasschnelli>
But for a "fullnode-in-a-box", I think you need more horsepower... that's why I think the Jetson TX1 would be a good choice.
< jonasschnelli>
Also,... you don't pay for stuff you don't need (HDMI, 4USB, etc.)
< gmaxwell>
the gpu is useless, and otherwise it's just an arm a57 and wouldn't be faster than other a57s
< wumpus>
with modern GPUs you can certainly do cryptography, would'nt be surprised if you could port secp256k1 to opencl, but gpus are unreliable, even the high-end cloud computing ones, but especially customer ones. It'd be a mess.
< gmaxwell>
well there have been gpu key generators, for example, that were a couple times faster than openssl, but significantly slower than libsecp256k1.
< wumpus>
and as we already get a enough reports of errors due to overheating *CPUs*...
< gmaxwell>
lack of 64,64->128 multiply is a big performance hit.
< wumpus>
still, you could distribute over both the CPU and PGU
< gmaxwell>
the pdf jonas linked to showed only a 6x speedup over naieve code on the cpu given arbritarily high parallelism, with a gpu using ~3x the power, and having a 21x hit in latency. Not especially attractive even if you ignore the historical stability issues.
< gmaxwell>
(and the man power required to write and maintain the software, and the requirement for propritary drivers, etc.)
< wumpus>
yes
< Provoostenator>
wumpus: I can't find "snoei" in the nl_NL Transifex translations, maybe it's in the nl one? Can you add me there?
< wumpus>
it's possible that it was removed since last update from transifex
< wumpus>
but no, I can't add you to anything, I somehow don't have access to teams there
< Provoostenator>
But you were able to add me to nl_NL, or did I just social engineer Transifex staff?
< wumpus>
no, I didn't add you to anything
< wumpus>
I can only delete stuff apparentlly, transifex access controls make no sense
< wumpus>
oh that's not true I can also create new translations, and sub-projects, just not teams
< Provoostenator>
Does the translation script only use nl_NL? Because then there's no need for me to have access to nl (or nl_be)
< wumpus>
for the next major version I should probably create the transations in a new organization
< jonasschnelli>
can you explain that a bit more for me?
< jonasschnelli>
I think locking cs_main during the AddToWalletIfInvolvingMe() part would be removing most of the lock optimization done in this PR
< BlueMatt>
jonasschnelli: the !chainActive.Contains(pindex) check *must* be in the same cs_main lock as AddToWalletIfInvolvingMe
< jonasschnelli>
BlueMatt: But AddToWalletIfInvolvingMe is currently (in the PR) done without cs_main
< jonasschnelli>
If we remove the general locks and add those back in ever block, it seems like a wast of effort. I don't see why AddToWalletIfInvolvingMe would need cs_main...
< jonasschnelli>
*every
< jonasschnelli>
I way expecting that we can do the two most significant time consumers (ReadBlockFromDisk, AddToWalletIfInvolvingMe) without cs_main
< BlueMatt>
jonasschnelli: uhhhh well thats a second bug then
< BlueMatt>
its still helpful to *unlock* cs_main after every block
< jonasschnelli>
if we add AddToWalletIfInvolvingMe under cs_main two, alomst every code part will aquire the lock
< BlueMatt>
so?
< BlueMatt>
another thing you could do (which I thought you were going to) is push down the cs_main in the ReadBlockFromDisk
< jonasschnelli>
BlueMatt: yes. I wanted to do this after the PR
< BlueMatt>
then you take cs_main to get the diskpos out of CBlockIndex and then lose cs_main during the actual reading
< jonasschnelli>
BlueMatt: yes
< jonasschnelli>
Would adding a function ReadBlockFromDiskLock() be a bad design (where the function would lock cs_main for pindex->GetBlockPos() but not for the actual reading ReadBlockFromDisk()
< gmaxwell>
normally you'd want to push up the lock by passing in the offset so the lock acqusition can be merged into the caller grabbing cs_main for other reasons.
< gmaxwell>
like to decide if it knows about the block at all.
< BlueMatt>
gmaxwell: I disagree 100%...
< BlueMatt>
jonasschnelli: we already do, just push down the lock instead of taking it outside
< BlueMatt>
gmaxwell: there are already two ReadBlockFromDisk's - one that does not require cs_main (and is often called without it), and one which does, but only for the non-disk-read part of the function
< BlueMatt>
no reason to require the caller take cs_main for the whole time if they dont want to
< BlueMatt>
cs_main is recursive for a reason....
< gmaxwell>
BlueMatt: you think you should take a lock to fetch a single integer, when the caller already needed the lock in the first place to get the pindex member?
< BlueMatt>
I mean that version of ReadBlockFromDisk already is barely called anywhere, iirc jonasschnelli's use-case here would be one of two places its used, and in his case you clearly *dont* want to be holding cs_main
< BlueMatt>
his whole goal is to reduce its usage in this case
< gmaxwell>
sure, so look up the offset when you check if the block is in the index to begin with.
< BlueMatt>
well in jonasschnelli's use-case above you cant do that...
< BlueMatt>
you *must* do the check after reading, when processing
< gmaxwell>
okay I didn't see the usecase then
< BlueMatt>
the race in AddToWalletIfInvolvingMe in the rescan stuff is subtle af
< jonasschnelli>
BlueMatt: so acquiring cs_main in ReadBlockFromDisk() just for reading CDiskBlockPos blockPos;,... right?
< jonasschnelli>
Doesn't it hurt to acquire it twice for the existing use cases of ReadBlockFromDisk()?
< BlueMatt>
i think thats fine
< BlueMatt>
indeed
< BlueMatt>
its recursive
< jamesob>
somewhat related question... was browsing getrawtransaction and noticed we acquire cs_main in a slightly more broad scope than necessary (though not by much) -- is it worth making a change to scope cs_main use as tightly as possible, or does it not matter so much (i.e. within the context of a single rpc call)?
< jonasschnelli>
jamesob: I think it would be worth... though ask BlueMatt, he is actually working on optimising concurrency
< jamesob>
also, is there somewhere we're having an ongoing discussion about splitting cs_main into separate read & write locks?
< BlueMatt>
jamesob: I mean looks like getrawtransaction only acquires it too broadly for like the parsing of two parameters, dunno if thats worth it...for something where you hit disk or are parsing a huge map and have a ton of logic it'd probably be worth it, but no need to create review burden to avoid holding cs_main for a ParseHashV...
< jamesob>
BlueMatt: yup, makes sense
< BlueMatt>
jamesob: heh, I dont think cs_main has made much progress of late....I think most of the curren progress is on making things use cs_main less
< BlueMatt>
I think the generally-accepted goal is for things to have their own "view" of the chain - eg wallet probably can/should start doing checks on a cached/validationinterface-updated chainActive.Tip() instead of ever locking cs_main to query for the current validation state
< BlueMatt>
same goes for other subsystems
< BlueMatt>
but its a long road ahead...I think we may be not too far off on wallet in my brief glancing a few weeks ago when sipa was saying we should do it sooner rather than later, but I dunno if anyone's tried to implement it
< BlueMatt>
gonna be lots of corner cases either way, I'm sure
< BlueMatt>
also working on (very slowly) migrating CNodeState out of cs_main, but I havent picked that work up in a while due to number of outstanding prs :/
< jamesob>
yeah, that sounds like the right way to go. definitely easier to make gradual changes that way instead of having to (delicately) modify cs_main itself.
< BlueMatt>
exactly
< BlueMatt>
I mean the other (obvious) thing is to make, as you suggested, cs_main a read/write/upgrade lock so that simple things like reading CBlockIndex->nStatus dont require a full cs_main global lock
< BlueMatt>
just doing that for CBlockIndex fields feels like it'd be helpful (see, eg, the above discussion about needing cs_main for ReadBlockFromDisk....), but also not something I've tried to do in like 5 years, dunno if anyone else has
< ossifrage>
Did changing the wallet passphrase stop dumping the keypool in 0.15.x? I just changed the passphrase but keypoololdest is still old?
< BlueMatt>
did it ever dump the keypool?
< * BlueMatt>
sees no evidence that it did in 0.13.2
< ossifrage>
BlueMatt, okay, I guess I had bad information, someone told me that it discarded the keypool when you changed the passphrase as a security feature.
< BlueMatt>
it does when you *first encrypt* (I'm 90% sure)
< BlueMatt>
changing, I do not believe so
< ossifrage>
Ah yeah, my wallet was unencrypted before that
< ossifrage>
So I'm stuck calling getnewaddress 980 times :-(
< instagibbs>
It should only throw away your master privkey on first encryption, yes
< instagibbs>
I have not tested that sequence myself however
< BlueMatt>
ossifrage: heh, 980? thats not too bad...I had to do like 99k recently...that took a while
< ossifrage>
I basically want to get an address that is not in my backups
< ossifrage>
My poor 'receiving addresses list' is already painfully long as it is (mostly with discarded/unused addresses)
< BlueMatt>
getrawchangeaddress intead, I think
< luke-jr>
I thought it discarded keypool on change passphrase also
< ossifrage>
luke-jr, I changed the passphrase and keypoololdest is 109 days old
< ossifrage>
which is about when I initially set the passphrase
< sipa>
changing your passphrase doesn't change your masterkey, though
< luke-jr>
sipa: no?
< luke-jr>
hmm
< luke-jr>
is there a reason not to?
< BlueMatt>
yea..not having to re-encrypt everything
< Randolf>
In comparison, TrueCrypt works this way -- re-encrypting the whole hard drive every time the user wanted to change their boot-password would be very time-consuming.
< luke-jr>
why would you need to reencrypt everything, just to add a new master key?
< BlueMatt>
luke-jr: how in the hell would you do it otherwise?
< ossifrage>
My goal was to invalidate my backup for new transactions without loosing the history/metadata
< sipa>
luke-jr: the encryption master key, not the hd master key
< luke-jr>
oh
< BlueMatt>
luke-jr: we're not talking about HD master key
< ossifrage>
In my case it is *not* a HD wallet (I think it predates the HD stuff)
< luke-jr>
I was XD
< sipa>
rotating out the hd master key is something we should support, but it can be orthogonal to the encryption question
< BlueMatt>
ossifrage: yes, I think over time we need to support that use-case by upgrading to hd then letting people rotate the hd seed and optioanlly flush keypool at that time
< ossifrage>
Is there a way to 'decrypt' the wallet so I can reencrypt it and dump the keypool?
< luke-jr>
I don't think so
< BlueMatt>
not atm
< BlueMatt>
i mean you can also hack in your own rpc that empties keypool
< BlueMatt>
in one db batch
< BlueMatt>
which would make it faster
< ossifrage>
The 'receiving address list' UI is already insanely long, adding another 960 entries will suck
< luke-jr>
[21:48:00] <BlueMatt> getrawchangeaddress intead, I think
< ossifrage>
luke-jr, yeah, that might work until I forget to do it
< ossifrage>
getrawchangeaddress caused keypoolsize to go down by 1
< ossifrage>
and 'bitcoin-cli listreceivedbyaddress 0 true | jq .[].address | grep <getrawchangeaddress>' does not return the address
< sipa>
by definition transaction outputs to a change address are not treated as incoming payments
< ossifrage>
sipa, ok yeah... but the getrawchangeaddress comes from the keypool
< sipa>
yes?
< sipa>
i don't understand what you're expecting
< ossifrage>
Ah, I understand now, use getrawchangeaddress 980 times to discard the old keys... duh
< sipa>
it will only discard change keys
< ossifrage>
Okay calling getrawchangeaddress 980 times did what I wanted, it consumed all the keys in the (non HD) keypool without bloating the 'receiving address' list.
< ossifrage>
Now both getrawchangeaddress and getnewaddress fail with "Error: Keypool ran out, please call keypoolrefill first" as expected
< luke-jr>
that's convenient
< ossifrage>
I wanted to invalidate my backups without loosing the history that goes back to 2011
< ossifrage>
BlueMatt, thanks!
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11892: [Qt] Warn if fallback fee has been used (master...2017/12/qt_warn_fallbackfee) https://github.com/bitcoin/bitcoin/pull/11892
< gmaxwell>
We might actually be running low on sockets on the network, not critically so, but low none the less.
< gmaxwell>
I am seeing multiple nodes with all or nearly all inbound sockets in use, and it doesn't appear at first analysis to be a connect flood attack.
< jonasschnelli>
gmaxwell: due to a lot of peers in IBD? Or plenty of SPV?