< bitcoin-git>
bitcoin/master 446a8f9 Karl-Johan Alm: Trivial refactor: Remove extern keyword from function declarations, as they are extern by default.
< bitcoin-git>
bitcoin/master 72ae6f8 Pieter Wuille: Merge #9244: Trivial refactor: Remove extern keyword from function declarations...
< bitcoin-git>
[bitcoin] sipa closed pull request #9244: Trivial refactor: Remove extern keyword from function declarations (master...no-extern-funcdecl) https://github.com/bitcoin/bitcoin/pull/9244
< phantomcircuit>
works fine as a static in the file
< sipa>
phantomcircuit: you're defining a static variable in a header file. this means that every cpp that includes this header gets its own instance of that variable
< phantomcircuit>
oh
< phantomcircuit>
yeah that's not right
< phantomcircuit>
git exploded and i put it there but yeah
< phantomcircuit>
fixed
< phantomcircuit>
what's there now is right and works
< BlueMatt>
argggg, sipa
< BlueMatt>
please dont rebase when you squash unless you need to :(
< BlueMatt>
that said, #8580 needs rebased again :p
< BlueMatt>
there really needs to be a better way to say "give me the diff from a to b, ignoring signed-merge-commit changes"
< BlueMatt>
I need to build a script for that
< sipa>
yup
< sipa>
i'd say you do it by comparing a merge of the original with the new base with the rebase
< BlueMatt>
yea, probably
< BlueMatt>
you have to find a common fork point, though, by tracing back merge commits until you find the root of the two
< BlueMatt>
(ofc this assumes we continue to use git as if it were not git, but...whatever)
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #9253: Fix calculation of number of bound sockets to use (master...2016-11-nbind) https://github.com/bitcoin/bitcoin/pull/9253
< Victorsueca>
kaspersky is marking bitcoin-qt as coin stealing malware
< Victorsueca>
and in my case is compiled from source so... doubt it's a fake executable
< sipa>
sogh
< sipa>
sigh
< achow101>
Victorsueca: it's marked as coin stealing because it looks for a wallet.dat file :/
< Victorsueca>
achow101: lol
< Victorsueca>
404 logic not found
< achow101>
and sometimes they mark it as a bitcoin miner
< Victorsueca>
guess somebody will have to contact kaspersky so they whitelist it
< phantomcircuit>
Victorsueca, that sounds like it's doing the right thing actually
< phantomcircuit>
you compiled a binary yourself
< phantomcircuit>
so it's unique
< phantomcircuit>
which is trying to open wallet.dat
< luke-jr>
phantomcircuit: that's not the right thing to do :/
< gmaxwell>
we should probably encourage people to make initial vuln disclosures in private, even if not encrypted-- they might be wrong about where it applies.
< gmaxwell>
It would kinda suck for someone to report something 'in master' that also ended up in a recent backport release and was all over the network. :)
< wumpus>
I just mean that security@* is private enough
< wumpus>
and indeed we don't even list an encryption key there
< gmaxwell>
yea. indeed. well we should.
< gmaxwell>
I seem to recall some parties previously being opposed to that.
< wumpus>
how do you want to do that? a shared key?
< sipa>
gpg needs 1-of-n multisig encryption.
< wumpus>
I remember there's an open issue about adding an encryption key to the security reporting page, but no one could decide on a sensible approach
< sipa>
(it does of course, you can have multiple recipients, but you can't associate multiple keys with an email/identity)
< gmaxwell>
shared key would work fine. doesn't even need to be everyone, but should be more than one.
< phantomcircuit>
rebroad, i promise to act as 1-n for people i deem to be in the set
< wumpus>
we also don't necessarily want to reveal the list of people behind the alias, and having people encrypt to multiple recipients is meh anyway
< phantomcircuit>
"multisig as trust in patrick"
< gmaxwell>
sipa: unfortunately multiple recipents is too much to ask of the sender.
< gmaxwell>
probably we should have some webform on bitcoin-core.org that does gpg in the browser.
< wumpus>
it's too much to ask of the sender and it is an information leak in itself
< sipa>
(shared key, and suggests mailing individual members with their keys)
< wumpus>
gmaxwell: how is that more secure than just having a SSL-encrypted page?
< gmaxwell>
wumpus: because when its saved on the webserver the data doesn't lay around in a vulnerable form.
< wumpus>
I still don't buy this 'client side in the browser' stuff, not for wallets, but also not for this :)
< gmaxwell>
compromise is only point in time forward.
< wumpus>
well the websever could also encrypt it when it receives it
< wumpus>
I think we are overdesigining this
< wumpus>
let's generate a shared key?
< sipa>
sure
< gmaxwell>
Yes, though compromise is a little less detectable that way. (in any case I wouldn't even have mentioned it except I know there is prefab gpg-webform stuff) https://www.hanewin.net/encrypt/PGencode.htm
< wumpus>
I mean, this is like the alert system, there are tons of ideas but no one is going to implement one for the 1 in a year or so chance it's necessary
< wumpus>
s/chance/time/
< wumpus>
the only thing we receive on this security alias is support request crap even though it lists IN RED on the page that it shouln't be used for that
< gmaxwell>
sure. in any case, someone can do it if they have the time/interest.
< wumpus>
and apparantly people that want to report issues rather blather in here in public telling everyone they found something instead of discretely sending a mail, which even unencrypted would be better than that
< gmaxwell>
at least blabbing in here doesn't make it attractive to hack our email. :)
< rebroad>
perhaps rather than using PGP keys we could use bitcoin address keys
< gmaxwell>
that would only make things worse.
< wumpus>
so instead of this meta talk, can you just let us know the issue please?
< gmaxwell>
oh rebroad is here.
< rebroad>
wumpus, ah, it was a false alarm (said above)
< wumpus>
gah
< wumpus>
*goes back to bed*
< gmaxwell>
rebroad: we missed where you said that.
< rebroad>
although i did lose internet shortly after so perhaps it didn't send
< gmaxwell>
(doesn't show up in the logs)
< rebroad>
this is the problem with IRC.. I never know which messages have sent :-s
< rebroad>
why don't we use slack or something more "modern"?
< Lightsword>
rebroad, use a bouncer
< Lightsword>
then you can check logs on it
< wumpus>
I never have that problem on IRC, my client reports when a message couldn't send.
< rebroad>
wumpus, what client are you using please? I need to switch
< wumpus>
no, we will not switch to a proprietary solution
< rebroad>
wumpus, fair point. opensource is the way
< sipa>
i'm using irssi, running inside screen, on a vps
< rebroad>
(and decentralized of course)
< wumpus>
rebroad: I've used "quassel" and "irssi" and they both have that functionality
< Lightsword>
znc lets you use a normal client with it
< rebroad>
i hope no one actually got woken up to deal with this non-issue :-s
< wumpus>
rebroad: exactly, IRC is much more in the spirit of bitcoin, though not decentralized it is a generic internet protocol that everyone can write clients for, some of better quality than others, but interoperability is key
< rebroad>
didn't IRC used to be decentralized? i remember the days of the net splitting a lot and that doesn't seem to happen these days
< wumpus>
well it didn't wake me up literally, i was awake, but it caused a stressful morning agian
< Lightsword>
netsplits still happen
< sipa>
rebroad: distributed doesn't mean decentralized
< sipa>
you can't just run your own server and join the network
< sipa>
you can start your own network however
< rebroad>
I just spent a week meditating in a monastery - works well for stress - as does driving the road from Mae Hong Son to Pai - very beautiful part of Thailand
< gmaxwell>
It also works really well with the toolset most of us use. Far better than slack (which I find has an infuratingly slow interface-- compared to anything non-browser I use), ignoring perhaps the occasional netsplit.
< wumpus>
right, IRC *networks* are not decentralized, more like federated. IRC itself could be considered decentralized if you consider that everyone can create a network that's true...
< rebroad>
although despite that I do have a twitching eye - too much coffee and not enough sleep I suspect. anyway.. OT!
< wumpus>
gmaxwell: well you can use IRC to connect with slack - but anyhow let's not go there
< rebroad>
wumpus, I do like how slack lets one quote previous messages.. sort of threading in a sense
< sipa>
rebroad> wumpus, I do like how slack lets one quote previous messages.. sort of threading in a sense
< wumpus>
rebroad: nothing seems to work here, though I haven't tried going to a monastary I must admit :) I don't think I could.
< sipa>
rebroad> wumpus, I do like how slack lets one quote previous messages.. sort of threading in a sense <- i can quote too :)
< wumpus>
yea here you can do the age-old thing for quoting: just copy/paste
< rebroad>
I actually had not seen that message from wumpus about the monastery - so clearly I am losng messages recved too!
< wumpus>
rebroad: and you didn't even disconnect in between
< rebroad>
weird...
< wumpus>
rebroad: looks more like a client issue than a network one
< Lightsword>
maybe you should set up a cheap VPS and run a client from there
< wumpus>
unless someone is MiTMing you
< * Lightsword>
wants a good self hosted version of irccloud
< rebroad>
using hexchat - prett standard on linux
< Lightsword>
well if you run it over ssh on a cheap VPS with a reliable connection you shouldn’t get dropouts
< Lightsword>
and if ssh is unreliable you can even use mosh
< sipa>
i use mosh
< wumpus>
mosh <3
< rebroad>
oh ignore me.. I am losing my mind obviously. sipa didn't quote wumpus's comment about the monastery - it was wumpus's actual comment :-s
< rebroad>
sandwiches between two quotes
< gmaxwell>
with how unreliable rebroad's connection has been in the past, I bet he'd like mosh.
< rebroad>
s/sandwiches/sandwiched
< wumpus>
another false positive :p need to be more careful in checking things
< rebroad>
anothing thing I like about slack - i can edit spelling mistakes
< rebroad>
(or telegram, etc)
< rebroad>
somethng opensource like telegram would be nice - they have group chats on there
< gmaxwell>
msitakes?
< gmaxwell>
s/msitakes/mistakes/
< wumpus>
well it won't just let you edit spelling mistakes, also other mistakes, or retroactively change statements/opinions
< rebroad>
heh.. just need a front-end to parse those "s/" messages!
< paveljanik>
gmaxwell, :-) You s/yes/no/.
< wumpus>
"we've always been at war with eurasia"
< rebroad>
anyway, enough of this silliness^H^H^H^H^H^H^H^H^H^Husefulness
< gmaxwell>
the editing features are nice until they're not. very confusing when you read something and then its edited and then later you cant figure out where you read the original thing. :)
< sipa>
stackexchange lets you modify comments for up to a few minutes
< wumpus>
just need a front-end to parse those "s/" messages <- haha that'd be fun
< sipa>
which is very useful
< wumpus>
too much bother to implement though, seems my brain works well enough as a parser/frontend for that
< sipa>
wumpus: the context was that you were going back to sleep
< rebroad>
hmmm.. blockchain based chat... now that would be decentralized properly..
< sipa>
try bitmessage
< rebroad>
sipa, any advantage over IRC?
< sipa>
no
< wumpus>
and puts the burden of storing your logs on everyone on the network - yea, that'd work
< sipa>
and not sure if you're serious, but public blockchains don't actually work without the incentive of subsidy
< sipa>
which makes non-currency use pretty unsustainable
< rebroad>
sipa, speaking of that. dash has more nodes than bitcoin due to that I think
< gmaxwell>
bitmessage isn't a blockchain, its a hashcash ratelimited flooding network.
< rebroad>
and they are funding quite a few things from the blockchain also
< wumpus>
meh, bitmessage is used for some private communication, it's basically a "dead drop". I don't know how effective it actually is at that though given the small number of users.
< gmaxwell>
rebroad: please don't talk about dash here.
< rebroad>
they *cough* hard-forked *cough* a few times to get that in place though - I am surprised the miners (who were getting 90%) went along with it
< wumpus>
but if used through tor I guess it's pretty hard to do metadata analysis
< rebroad>
gmaxwell, just referring to it as an example in the context of what sipa just said
< luke-jr>
rebroad: don't confuse "works so far" with "can be relied on"; often scamcoins work only because nobody has bothered to attack them
< rebroad>
gmaxwell, it's ok to talk about bitmessage but not dash?
< rebroad>
luke-jr, good point indeed
< sipa>
this whole discussion is off topic now
< rebroad>
luke-jr, although are you meaning to imply dash is a scamcoin?
< wumpus>
altcoins are decidedly off-topic here, alternative communication methods for developers, well meh it doesn't hurt to have that discussion once ina while when we feel like it.
< wumpus>
but yes it's done
< wumpus>
back to coding
< luke-jr>
rebroad: we can discuss that further in ##altcoin-dev if you wish, but I'd suggest it's a distraction
< rebroad>
sipa, it is drifting occaionally OT but comes back to bitcoin often enough :)
< rebroad>
I do perceive an over-sensitivity to the conversation drifting to altcoins when they are relevant to the current context, as bitmessage was
< gmaxwell>
In general I would prever to not talk about altcoins here. Beyond it being offtopic, saying negative things about some altcoins has been known to get people harassed.
< gmaxwell>
And personally I find it somewhat stressful when someone is wrong about something on the internet and I can't even reply without knowing it's just going to create trouble for me.
< wumpus>
tldr: it's a waste of everyone's attention here
< wumpus>
too easy to get into fights, people feel too strongly about those things, this is a no-politics channel
< rebroad>
how about barring strong feelings AND politics? and just being able to talk about possible features without fear of attack?
< wumpus>
please take it elsewhere
< rebroad>
"it"?
< wumpus>
yes. This whole thread.
< luke-jr>
rebroad: ##altcoin-dev is a real channel you can discuss said things in
< rebroad>
I have lost the thread by now
< rebroad>
I am not clear on what thread is being referred to nor what are the taboo subjects
< sipa>
altcoins are definitely off topic
< sipa>
(in this specific channel; there is #bitcoin-wizards for example for exotic ideas that may or may not make it into bitcoin some day)
< wumpus>
"Bitcoin Core development discussion and commit log"
< rebroad>
sipa, so you mean mentioning them by name?
< luke-jr>
rebroad: there is no context on topic to this channel where mentioning them by name would make sense.
< rebroad>
I am also unsure what the definition of "altcoin" is
< sipa>
we used to have a link to channel rules
< sipa>
rebroad: other cryptocurrencies
< wumpus>
rebroad: go discuss that elsewhere
< sipa>
now, let's get back to development
< wumpus>
this is also not the meta-channel "what to discuss in #bitcoin-core-dev"
< rebroad>
wumpus, the conversation flowed to this - it was a co-creation we all had a part in that. anyway, i agree. where is that meta channel?
< luke-jr>
#bitcoin is as meta as I know of
< rebroad>
or #bitcoin-dev I'd have thought, since development is the key desire to talk about
< rebroad>
but I don't desire to have that meta conversation really. I'd rather talk about core development, which is why I am here - but I will refrain from mentioning the names of "altcoins" even though I don't understand why not, nor what "altcoins" are yet, so it's kind of impossible to make assurances at this stage given that.
< luke-jr>
general & meta=#bitcoin ; bitcoin development=#bitcoin-dev ; Core dev=#bitcoin-core-dev ; wiki=#bitcoin-wiki ; trading=#bitcoin-otc ; far future dev & hardforks = #bitcoin-wizards ; mining=#bitcoin-mining ; altcoins=##altcoin-dev
< jonasschnelli>
sipa: In case you once start with BIP150 (I know you'll wait until the net refactor has been completed), here is the extracted ChaCha20Poly1305AEAD code from openssh: https://github.com/jonasschnelli/chacha20poly1305
< rebroad>
I have attempted to seek clarification previously on a clear and concise definition of "altcoin" and raised an issue both on the bitcoin project and for bitcoin.org to address this
< luke-jr>
rebroad: seek clarification in #bitcoin, not here
< rebroad>
so it is really frustrating to come up against this again given all the proactivity so far
< sipa>
rebroad: again, please don't see a "go discuss this elsewhere" as "don't discuss this". people _are_ very willing to discuss these things and the reasons behind it. but not here.
< rebroad>
sipa, thank you for that clarification. EOT
< jonasschnelli>
sipa: why would it break backwards compatibility?
< jonasschnelli>
(remove of the default key)
< jonasschnelli>
Because of fFirstRunRet?
< sipa>
jonasschnelli: yup
< jonasschnelli>
hmm..
< sipa>
specifically, not having a default key in a wallet file would cause it to write the current chainstate
< sipa>
and thus potentially miss a rescan
< sipa>
writing a dummy default key... could result in the old wallet giving it out as address
< luke-jr>
what's the harm in having a dummy default key that's actually in the wallet? O.o
< jonasschnelli>
I don't like the default key for two reasons...
< sipa>
luke-jr: that's basically what we have now :D
< jonasschnelli>
1) seems to be unused/miused
< luke-jr>
exactly; I miss context as to why it should change
< jonasschnelli>
2) I want to have a private-key free wallet mode
< luke-jr>
jonasschnelli: just pretend it isn't there?
< sipa>
luke-jr: technical debt
< jonasschnelli>
We probably should have removed it with 0.13 hd wallets (not backward comp.)
< bitcoin-git>
[bitcoin] laanwj opened pull request #9255: qt: layoutAboutToChange signal is called layoutAboutToBeChanged (master...2016_12_qt_signals_warnings) https://github.com/bitcoin/bitcoin/pull/9255
< bitcoin070>
so, whatever is causing this, it's dangerous behavior and never happened before because
< bitcoin070>
a lot of scripts and daemons are monitoring bitcoin node balance
< gmaxwell>
bitcoin070: I suggest downgrading to 0.12.1, which will behave the same but will confirm that there is nothing new going on.
< bitcoin070>
and when it goes from XXX to 0 without any transactions it starts a lot of commotion unfortunately
< bitcoin070>
we want to support segwit, want HD wallet, etc
< wumpus>
sounds like the whole chain of transactions was evicted
< gmaxwell>
In prior attempts to assist you, going back a month ago, I was unable to extract the information I needed to make sense of your reports. If you have the patience now to work through things thats great, though we're about to begin a meeting in here.
< sipa>
a larger max mempool size may help to avoid that
< wumpus>
are you overriding fee or using the smart fee estimate?
< bitcoin070>
not doing anything with fees
< bitcoin070>
just letting the node handle it
< bitcoin070>
I have all the time in the world, obviously I don't want to interrupt your meeting but
< bitcoin070>
FWIW, BitGo is having issues right now too
< sipa>
though i'm not sure what the correct behaviour in this case is... you effectively don't have spendable balance until those transactions confirm
< sipa>
or you abandon them
< bitcoin070>
their node is returning a TXID which is also not propagating the network
< wumpus>
if you can queue up sends then use a sendmany you'd prevent nesting transactions so deeply
< bitcoin070>
wumpus/sipa: interestingly though this only started becoming problematic in bitcoin core
< bitcoin070>
sorry I mean 0.13
< sipa>
bitcoin070: network conditions change all the time
< gmaxwell>
bitcoin070: nothing about this was changed in 0.13, AFAIR.
< sipa>
my guess is that this is just due to interaction with the limited mempool, not the new bitcoin core version
< sdaftuar>
i think we do have an issue to fix, in that we should make it harder for the wallet to generate a transaction that violates the ancestor/descendant chain limits, right?
< sdaftuar>
wasn't there a PR relating to that?
< sipa>
sdaftuar: agree
< gmaxwell>
We do, I believe I created that in response to this person.
< bitcoin070>
damn, it's just strange because
< bitcoin070>
I didn't see this ever happen in .12
< sipa>
i believe that
< bitcoin070>
I know network conditions aren't static, etc
< bitcoin070>
so you're saying the root cause is too long of unconfirmed chain
< instagibbs>
meeting taimu
< wumpus>
if there is a PR for that, it'd make sense for bitcoin070 to test that
< sipa>
or an evicted chain
< BlueMatt>
meeting?
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Dec 1 19:00:33 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
bitcoin070: evicted because they pay the least fee/kb of the transactions in the mempool and the maximum size is reached, you can increase the maximum mempool size though
< michagogo>
Oh, right, now that I'm in the U.S. these are in the early afternoon
< morcos>
bitcoin070: please if you file an issue about this include the output of getbalance() and getunconfirmedbalance() without giving any accounts
< sipa>
i have a short topic for later, about vchDefaultKey (walking to office right now)
< wumpus>
wallet PRs need review at least
< wumpus>
espeically the multiwallet ones
< jonasschnelli>
Yes. An HD.
< gmaxwell>
The test before evict PR seems to be being forgotten a bit.
< jonasschnelli>
We need a restore feature.
< jonasschnelli>
We shouldn't keep users to long in the dark about how they can restore a HD wallet
< jonasschnelli>
Would be nice to have something in 0.14
< wumpus>
vchDefaultKey should die
< jonasschnelli>
heh. Lets discuss that when sipa is back
< morcos>
Now is probably a good time to do a thorough evaluation of which PR's need 0.14.0 milestone... who should we ping if we want someone to mark a PR?
< gmaxwell>
BlueMatt: do you have any more big wads of data race fixes.
< bitcoin070>
guys I agree 100% we need an HD wallet restore feature
< gmaxwell>
jonasschnelli: we should.
< morcos>
jonasschnelli: definitely
< bitcoin070>
I would make that top priority
< morcos>
bitcoin070: ha ha, it'll just make it always give -1
< bitcoin070>
:)
< BlueMatt>
gmaxwell: I think not...maybe one or two more that I should PR and then net things, but since net is in the middle of so mouch touching I dont want to step all over cfields' toes trying to fix things he already has fixes for
< gmaxwell>
BlueMatt: have you advised cfields about the racy things you found there?
< BlueMatt>
to we have topics?
< BlueMatt>
yes, we've been discussing them
< morcos>
answering your own question?
< BlueMatt>
topics? or are we meeting-chat-time-ing?
< gmaxwell>
Thanks, where are we on this? (the change to let the rawtxn returning rpcs return witness stripped results) I think it's moderately important but there seemed to be some disagreement on the general direction.
< cfields>
wumpus: as part of your named-arg PR, did you consider allowing any global named args?
< sdaftuar>
gmaxwell: initially i wasn't a huge fan of it, but it ended up being less work than i thought, so i don't really care if we do it
< gmaxwell>
sdaftuar: okay, it was mostly you I was concerned about.
< cfields>
where for ^^, any command could accept a "serialversion" named arg
< wumpus>
cfields: we're in a meeting
< sdaftuar>
"sdaftuar was here" i did mean to review the test changes though
< instagibbs>
sdaftuar, yes i basically failed to remember how the commitment worked :) thanks for the review
< cfields>
wumpus: eh? I was referencing 9194 :)
< gmaxwell>
wumpus: that is directly relevant here. :)
< gmaxwell>
okay, if sdaftuar is not concerned about it, -- instagibbs are you waiting for anything there or just more review?
< wumpus>
cfields: well that's not implemented in my pull, could be added later on I guess if you need "context" arguments
< instagibbs>
gmaxwell, more review I think. Want to make sure it doesn't screw up anything I don't touch often
< wumpus>
cfields: I don't have any problem with the idea at least.
< instagibbs>
(ie zmq/rest suggestion)
< instagibbs>
I think the tests actually work now, so confident on rpc side
< gmaxwell>
instagibbs: okay, sounds good to me then. I'll be happy to test and review.
< instagibbs>
great
< petertodd>
re: luke-jr's point on "stripped sigs", lots of code gets written that calculates its own txids and isn't using the RPC for that, e.g. python-bitcoinlib RPC code would likely do that, so stripped sigs mode isn't useful there; 100% backwards compatibility is
< gmaxwell>
I'd also like to ask about some other PRs? ##8895 and the checkqueue work for example-- but I don't think JeremyRubin is around.
< BlueMatt>
well I think #9183 is +/- ready for merge, jtimon just posted another comment I should look at, but probably ready in an hour or two, it has lots of acks, so question is when to do The Split
< wumpus>
if it has lots of acks it should be merged
< cfields>
no objections to splitting asap here. It'll only collide trivially with my current work.
< jonasschnelli>
BlueMatt: why when? Because of upcoming rebases?
< jtimon>
I would say open the PR as soon as 9183 gets merged
< wumpus>
no need to delay it if it is ready
< BlueMatt>
jonasschnelli: question is if we do it now or wait until like right before 0.14
< jonasschnelli>
I think all of us are happy to rebase for a such split
< BlueMatt>
ok!
< jonasschnelli>
IMO asap
< wumpus>
let's just go on with it
< jtimon>
BlueMatt: why? what's the advantage of waiting?
< BlueMatt>
ok! sounds good, will open as soon as 9183 is merged
< morcos>
Perhaps BlueMatt is asking if there are any more 0.13 backports to worry about first?
< cfields>
jtimon: to ease backports in the meantime i guess?
< BlueMatt>
morcos: oh, yea, that too
< jtimon>
morcos: cfields oh, right
< jtimon>
are there any backports on the horizon?
< jtimon>
do they conflict with this?
< wumpus>
speaking of 0.13.2, what still needs to go in? (that isn't merged into master yet)
< gmaxwell>
I'm more comfortable with 9183 since matt has been doing a lot of data race and locking testing. usually the worry I have with these sorts of rearrangements is that they'll invalidate hidden locking assumptions.
< gmaxwell>
wumpus: the estimatefee 1 thing. and uhhh
< sdaftuar>
i have one that could go in, the cs_main locking thing with compact blocks
< sdaftuar>
plus 9194
< cfields>
BlueMatt: is it 100% move-only?
< BlueMatt>
cfields: yes
< morcos>
huh is what move only
< BlueMatt>
splitting main.cpp
< gmaxwell>
yea, the locking around compact blocks
< sipa>
general request for move-only commits: leave functions/methods in the same order in the new file as in the old file; makes diffing much easier to verify move-onlyness
< BlueMatt>
I can rebase main split on top of all the "Backport needed" PRs
< BlueMatt>
but then we need to move fast on the backport-needed PRs
< sipa>
which is absolutely unused, except for determining whether a new wallet was just created
< sipa>
i'd like to get rid of it
< sipa>
however
< wumpus>
yes, we should get rid of it, but maybe not for 0.14, it's not really urgent
< sipa>
if we do that, a downgrade to an older wallet version would result in failing to rescan
< jonasschnelli>
Yes. We should combine it with other features.
< sipa>
as it would trigger the new wallet logic, which writes the current chainstate to the wallet file
< jonasschnelli>
We should have combined it with HD in 0.13. :/
< wumpus>
sipa: we could add fallback logic into 0.14
< wumpus>
then remove it for 0.15
< sipa>
writing a dummy has the disadvantage of actually risking giving out a dummy key as address (in very old versions)
< wumpus>
then it'd be possible to go back to 0.14 when 0.15 is released
< wumpus>
but o further back
< sipa>
a third option is introducing a new min wallet version, so for example 0.15 wallets will never be openable with 0.13
< wumpus>
(unless we backport the fallback logic ofc)
< wumpus>
yes, that'd be my preference
< wumpus>
no dummies and other hacks, just versioining
< jonasschnelli>
Yes. This only affect new wallets, right?
< wumpus>
it'd only apply to new wallets created with the new version anyway
< wumpus>
right.
< gmaxwell>
I'm okay with versioning, but we should keep it simple.
< wumpus>
it's not like you can't go back with an old wallet
< jonasschnelli>
If you have a wallet from 0.12, it won't upgrade unless you do an explicit upgrtadew
< sipa>
so let's switch in 0.14 to stop relying on vchDefault key, but still write it (as an actually valid key)
< wumpus>
in any case this isn't urgent
< sipa>
and then in 0.15 delete the vchDefaultKey and increase the min version to 0.14?
< jonasschnelli>
sipa: ack
< wumpus>
we could do it over 2-3 major versions
< gmaxwell>
ACK sipa.
< wumpus>
sipa: yes that's what I meant too
< jonasschnelli>
Downgrading new wallets is probably not required over more then 2 major versions.
< wumpus>
we could even backport that to 0.13
< jonasschnelli>
wumpus: Yes. We should.
< wumpus>
(e.g. work if there is no vchdefault, but do make it)
< wumpus>
that particular code hasn't been touched for years so backporting is trivial
< sipa>
ok, end topic
< morcos>
my 2 cents would be against backporting to 0.13.2 at least.. since i think 1 major version backport for downgrading the wallet seems sufficient
< jonasschnelli>
HD restore? anyone interested?
< morcos>
just to not hold up 0.13.2
< jonasschnelli>
morcos: whats the downside of the (simple) backport?
< jonasschnelli>
ok.
< jtimon>
ack min wallet version
< sipa>
jonasschnelli: certainly, but it requires some pretty big changes (like removing keypool entries with seen keys in received transactions)
< wumpus>
morcos: I mean to 0.13 *branch*, so 0.13.2 or 0.13.3 or whatever happens to be then
< wumpus>
morcos: I certainly wouldn't propose holding up 0.13.2 for it
< morcos>
wumpus: +1 if it doesn't hold 13.2
< jonasschnelli>
Okay. Yes. If the BP is non trivial, we can skip it.
< wumpus>
morcos: no one is saying that!
< gmaxwell>
yea, no holdup. but BP would be nice.
< jtimon>
jonasschnelli: who requires to downgrade wallets?
< wumpus>
"removing keypool entries with seen keys in received transactions"?
< wumpus>
is that required for removing the default key?
< morcos>
wumpus: is that HD restore he's talking about?
< jonasschnelli>
jtimon: Is more about the option to run your wallet.dat on an older version
< jonasschnelli>
morcos: not yet
< jonasschnelli>
default key != HD
< morcos>
jonasschnelli: yes understood, just trying to decipher sipas comment
< wumpus>
morcos: I don't know? I'm confused
< jtimon>
jonasschnelli: right, why do you want that? anyway, I was reading slow, we can discuss after the meeting
< gmaxwell>
I thought sip was responding to "hd restore"
< wumpus>
it'd make more sense, we're combinding topics is an awkward way now
< gmaxwell>
s/sip/sipa/
< jonasschnelli>
Ah. Sorry
< wumpus>
#topic HD restore
< jonasschnelli>
Can we have the HD restore topic then?
< jonasschnelli>
thx
< gmaxwell>
TM: Prefix all messages related to topic 1 with T1: and for topic 2 with T2:
< jonasschnelli>
Since 0.13 we have HD by default, we should have a feature to restore hd wallets
< jonasschnelli>
Maybe to late for 0.14, but in 0.15.
< jonasschnelli>
I think we need a concept first
< jonasschnelli>
IMO it should go over a seperate tool (bitcoin-wallet)
< morcos>
jonasschnelli: can you explain what that means... you lost the full wallet backup but have the master seed/key whatever it's called?
< jonasschnelli>
Because you ideally don't want to handle master xpriv in RPC or -cmd
< gmaxwell>
seperate tool sounds like something that would need a non-pruned blockchain .. which I don't think is desirable.
< jonasschnelli>
Yes. You have an (olx) xpriv or a wallet.dump and you wish to restore the complete wallet
< jonasschnelli>
gmaxwell: Yes. This is a good point.
< gmaxwell>
how is this different from having a wallet.dat that you backed up right at the start?
< jonasschnelli>
The tool should create wallet(s).dat and then you can run a rescan
< gmaxwell>
okay thats how.
< jonasschnelli>
Maybe the tool can interact with RPC and the UTXO set to detect the gap limits
< gmaxwell>
I think a tool to create a wallet.dat from dump data would be good, but perhaps not essential for restore functionality. which could work from just a wallet.dat that the user already backed up.
< jonasschnelli>
IMO it should result with a wallet with the corresponding keys up to the last detected UTXO (respecting a large gap)
< gmaxwell>
I'm really concnered that we didn't manage to split the change keypool for the HD wallet support. This makes recovery a mess.
< jtimon>
jonasschnelli: what about something like this, create first 100 addresses, rescan, while some of them got any funds, create the next 100 and loop
< jtimon>
I assume is horribly inefficient, reading slow again
< gmaxwell>
jtimon: sometime 100 years later your wallet is restored.
< jonasschnelli>
gmaxwell: there was a PR with that. But nobody reviewd it (external and internal chain)
< gmaxwell>
(rescans take hours, we should stop thinking of rescans as an option generally.)
< wumpus>
jonasschnelli: yea :/ review is always a problem with wallet pulls
< jtimon>
gmaxwell: thanks for confirming that is the flaw of my naive design
< wumpus>
I'd recommend that we first review and get the current wallet pulls merged, before working on even more
< sipa>
wumpus: +1
< jonasschnelli>
I think it would help to review #9143 and #9256
< jtimon>
what about not restoring the whole wallet but only what's currently in the utxo? would that be acceptable?
< jonasschnelli>
jtimon: Yes. That should be the default IMO
< jonasschnelli>
Then you can optionally do a rescan if you like.
< gmaxwell>
I think we should not add any more complexity to the HD support until we fix the path split issue.
< gmaxwell>
We're already going to have to support one legacy setup, lets try to not proliferate little changes.
< jonasschnelli>
Okay. I can focus on the path split
< jcorgan>
gmaxwell: background on the "path split issue" i can go read?
< jonasschnelli>
But users start to ask,... how can I recover a HD wallet. We need to give them a reasonable answer.
< jonasschnelli>
jcorgan: bip32 internal and external chains
< instagibbs>
jcorgan, change output is on same chain as spending
< jcorgan>
ah, yes, i should ack 8723
< instagibbs>
err receiving*
< gmaxwell>
jcorgan: the consequence is that you can end up giving out change keys as addresses for people to pay (hiding their payments from you) or have change show up as payments if you have wallets recovered from hd data.
< jcorgan>
yeah, i get it
< gmaxwell>
jcorgan: e.g. I give you an address. then recover my wallet. Then create a transaction and use the same addr for change. Then you pay that address, and I don't see the payment.
< gmaxwell>
yadda yadda.
< Chris_Stewart_5>
gmaxwell: Thanks for the explanation
< gmaxwell>
jonasschnelli: load your old wallet.dat. rescan. Where does that currently fall down?
< jonasschnelli>
gmaxwell: missing keys
< sipa>
?
< jonasschnelli>
you mean restore a old wallet.dat?
< jonasschnelli>
you need to loop(1000, getnewaddress) first. :)
< gmaxwell>
right we don't remove all keys up to the highest observed, only observed? that sounds like a simple fix.
< jonasschnelli>
Well, if you have 1001 keys, you miss one.
< jonasschnelli>
gmaxwell: this would result in multiple rescans.
< wumpus>
right, it doesn't automatically wind forward when it sees known keys
< sipa>
gmaxwell: what do you mean remove?
< gmaxwell>
sipa: mark used in keypool.
< sipa>
gmaxwell: that's not implemented at all
< luke-jr>
:x
< gmaxwell>
jonasschnelli: which is a workaround that you can answer.
< sipa>
gmaxwell: you need the keypool
< jonasschnelli>
Yes. The loop getnewaddress is the current workaround.
< jcorgan>
it seems the bigger issue is there is no standard way of archiving derivation path usage + metadata
< gmaxwell>
sipa: that needs to be implemented, at least that much would be small.
< jonasschnelli>
But we don't even offer a rescan down to the HD feature birthdate.
< jonasschnelli>
The UX is bad
< sipa>
gmaxwell: it's not easy
< jonasschnelli>
yes. It's pretty complex.
< sipa>
gmaxwell: as we don't have a way to store keys without private key
< sipa>
or rescan would require the passphrase
< gmaxwell>
sipa: we can still mark the right things as used!
< jonasschnelli>
We first need a Wallet record type hdkey
< sipa>
gmaxwell: ah, yes!
< sipa>
jonasschnelli: no we don't
< gmaxwell>
sipa: e.g. rescan, unlock, rescan. not great, but failing to mark things as used is really goofy.
< gmaxwell>
but should also be trivial to fix.
< sipa>
jonasschnelli: just a way to store a key without known private key (with semantics that it will get computed at first unlock)
< sipa>
or not at all, i guess
< sipa>
and always derive it on the fly
< gmaxwell>
sipa: No, we can't.
< gmaxwell>
(keys are hardened because we support export)
< jonasschnelli>
IMO we should just store pubkeys and the according keypath
< sipa>
gmaxwell: oh, right
< jonasschnelli>
maybe the relevant master key (if we support multiple=
< gmaxwell>
and yes, storing the private keys is a bit silly. :P but an optimization.
< jcorgan>
jonasschnelli: agree, if there were a standard way of documenting that
< sipa>
3 minutes
< gmaxwell>
( I meant that not storing the private keys is mearly an optimization and not important.)
< sipa>
gmaxwell: we could also stop rescanning whenever the keypool goes below some value, and require unlocking first
< sipa>
or something
< jtimon>
gmaxwell: I still don't know how you solve the problem you described
< gmaxwell>
in any case, IMO low hanging is to correctly do the use-marking, and also increase the default keypool for hdwallets.. 100 is somewhat absurdly small, 1000 would be better. And getting splitting in.
< gmaxwell>
the last is a path incompatible change unfortunately, :(
< gmaxwell>
but the rest does not need coordination with anything.
< sipa>
we should first split up the keypools into change and non-change, iguess
< jonasschnelli>
Okay. I can work on a patch.
< jtimon>
sipa: oh, I see
< sipa>
then do the use marking (as it will need to mark within each path)
< jcorgan>
jonasschnelli: let's pm after the mtg on that
< gmaxwell>
sipa: the split will make wallets that do that incompatible with older software.
< sipa>
gmaxwell: yes
< jonasschnelli>
gmaxwell: Yes. We just need to support both types
< jtimon>
does the change keypool have its own seed or is it derived?
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Dec 1 20:00:40 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jonasschnelli>
the one-chain-hd-wallet and the flexible-keypath-wallet with ext/int chain
< BlueMatt>
wumpus, cfields re #9229 should I just switch it to be a full-revert of #4421 instead of fighting with autotools to keep the inet_pton working? (is anyone aware of any bugs from dropping those calls and just always using getaddrinfo?)
< gmaxwell>
I really do not want to support 30 different kinds of wallets 5 years from now. :)
< cfields>
BlueMatt: looking
< jonasschnelli>
Yes. We don't have the splitting because we wanted a minimal sane change.
< sipa>
gmaxwell: we'll just do a softfork to require SNARKs in signatures that prove that keys were derived deterministically?
< jonasschnelli>
I think this was resonable. But we shouln't wait to long now
< sipa>
*ducks*
< jonasschnelli>
heh
< jtimon>
jonasschnelli: regarding donwgrading the wallet, no need for further discussion, I thought of an example case where I could want that myself already
< wumpus>
cfields: I guess we will use libevent for resolving anyway, when that lands?
< BlueMatt>
wumpus: yes, but need something to backport
< gmaxwell>
If we're going to be incompatible, not storing private keys for hd keys would also be a good move... as it will make it less costly to make the lookahead larger.
< gmaxwell>
so in any case, thats just why I was suggesting fixing the use-flagging first, no compatiblity concerns.
< wumpus>
BlueMatt: sure in the meantime we can revert #4421 if it's buggy
< cfields>
wumpus: yes. I'm not really concerned about dropping this back to sync for now for that reason
< BlueMatt>
ok, so I'll just do a full-revert of 4421
< BlueMatt>
sgtm
< cfields>
BlueMatt: i'm tracing through the ifdefs locally now to make sure it works like i assume
< gmaxwell>
BlueMatt mentioned to me that he thinks he's actually seen a getaddrinfo_a crash in production. (backtrace was really short and without symbols because it was off in libc someplace)
< wumpus>
BlueMatt: please do comment in the issue that you'regoing to revert it and why
< BlueMatt>
kk
< jtimon>
not sure what the conclusions about the wallet are
< BlueMatt>
yes, if you've ever seen a crash in prod with a backtrace of length three with ???s for all of them...it might be gai_a
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #9259: [0.13 backport] Release cs_main before calling ProcessNewBlock or processing header (cmpctblock handling) (0.13...cb-lock-13) https://github.com/bitcoin/bitcoin/pull/9259
< wumpus>
espeically if you have no debug symbols for libc I guess?
< BlueMatt>
wumpus: yes
< BlueMatt>
wait, gmaxwell why do we want backport of #9252? I dont think releasing cs_main gives us anything in backport, but does carry risk
< gribble>
https://github.com/bitcoin/bitcoin/issues/9252 | Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) by sdaftuar · Pull Request #9252 · bitcoin/bitcoin · GitHub
< wumpus>
I still wonder if we're misusing it or whether libc is really buggy. It's not impossible that libc is buggy just sounds so unlikely
< wumpus>
in any case reverting it for now makes sense
< BlueMatt>
its possible I'm thinking of another issue wrt having seen this in prod - I've seen other issues in -qt that I think are just X instability
< BlueMatt>
and I may be thinking of those, but gai_a is definitely unsafe
< cfields>
in any case, I'm working furiously now on event-ifying the net code, pr should be up within the next few days, and is looking pretty simple. After that, the libevent changes come in. So the end is near for that code anyway :)
< BlueMatt>
good riddance
< luke-jr>
sdaftuar: BIP 90; what's with the "foo" and "tmp.mediawiki" files?
< sdaftuar>
luke-jr: gah, let check
< sdaftuar>
let me check*
< wumpus>
cfields: thanks for the update, looking forward to that :)
< cfields>
BlueMatt: ah i see, the inet_pton is just used to skip the getaddrinfo in the event that an ip was passed as a string
< cfields>
(sorry, was trying to figure out what that had to do with gai_a)
< cfields>
and actually, still not sure why they're entangled
< cfields>
but either way, full revert sounds good to me
< sdaftuar>
BlueMatt: gmaxwell: regarding #9252, i appear to have misremembered and thought we backported #8968 -- looking back on it, though, it appears we didn't (though it was tagged for backport at one point).
< gribble>
https://github.com/bitcoin/bitcoin/issues/9252 | Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) by sdaftuar · Pull Request #9252 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master 9e1f468 Matt Corallo: Fix calculation of number of bound sockets to use
< bitcoin-git>
bitcoin/master c1a5227 Pieter Wuille: Merge #9253: Fix calculation of number of bound sockets to use...
< bitcoin-git>
[bitcoin] sipa closed pull request #9253: Fix calculation of number of bound sockets to use (master...2016-11-nbind) https://github.com/bitcoin/bitcoin/pull/9253
< BlueMatt>
sipa: none of those touch main.{h,cpp}, which is the only thing 9183 touches
< BlueMatt>
so...I doubt it?
< sipa>
ok!
< bitcoin272>
does sendtoaddress have any way to prioritize not making transactions that will have issues because of too many unconfirmed ancestors?
< bitcoin272>
running into a ton of issues here and i don't want to disable spending 0 conf change tb
< bitcoin272>
tbh8
< bitcoin272>
tbh*
< bitcoin272>
but sendtoaddress is making huge chains when it would be more sensible to build multiple chains based on the output set as opposed to only building 1 so that it goes over 25 unconfirmed ancestors and makes a huge mess
< instagibbs>
bitcoin272, I started take a look at that today. I can probably at least have the send fail if it's going to run into mempool limits
< sipa>
BlueMatt: it actually tries to avoid using very recently created change
< sipa>
eh
< bitcoin272>
instagibbs -- it's a huge huge issue unfortunately
< sipa>
bitcoin272: ^
< bitcoin272>
I don't know if this was ever a problem pre 0.13
< sipa>
it should in 0.12 as well
< instagibbs>
coin selection didn't change since then
< instagibbs>
afaik
< sipa>
indeed
< bitcoin272>
what about mempool limits?
< instagibbs>
nope
< sipa>
mempool limits were added in 0.12
< instagibbs>
right, since 0.12 i mean
< bitcoin272>
i see
< bitcoin272>
this behavior guys
< bitcoin272>
is resulting in some very unfortunate things :/
< bitcoin272>
where is the mempool constraint defined
< bitcoin272>
is that something we could modify / recompile
< sipa>
it's a setting
< sipa>
limitancestorcount and limitdescendantcount
< bitcoin272>
it defaults to 25?
< sipa>
yes
< instagibbs>
you can crank those up, but the wallet simply shouldn't violate those limits(I'm working on that)
< bitcoin272>
and that's specifically meaning, dump things after 25 from the mempool, even if they are our own TX?
< sipa>
yes, indeed
< sipa>
bitcoin272: they're not dumped; they're just not accepted
< bitcoin272>
i see... but
< bitcoin272>
they are still broadcast to the network?
< sipa>
no
< sipa>
not until the rest is confirmed
< bitcoin272>
ok right but
< bitcoin272>
so to be clear
< bitcoin272>
sendtoaddress will fail
< bitcoin272>
the TX will sit in the wallet though
< sipa>
yes, the wallet behaviour is bad currently
< bitcoin272>
and when the parents confirm, it will auto rebroad cast
< bitcoin272>
right?
< sipa>
it should at least give an error instead of silently not doing anything
< sipa>
yes, i believe it will
< bitcoin272>
oh man so
< bitcoin272>
this is the problem then
< bitcoin272>
okay.. at least I know
< bitcoin272>
it shouldn't queue that transaction because what happens is
< sipa>
well it would be useful to verify this, by increasing your descendant and ancestor counts
< bitcoin272>
it's easy for business logic to believe a transaction send has failed
< bitcoin272>
and resend it
< bitcoin272>
only for the wallet to send the same coins again when the parents confirm
< bitcoin272>
resulting in multiple payments being facilitated
< sipa>
yup
< bitcoin272>
most unfortunate indeed
< bitcoin272>
okay well this is a start
< bitcoin272>
and this would've never been apparent pre 0.12 right
< BlueMatt>
aaccctuuallllyyyyy....anyone have any objections if main.cpp gets renamed to "blocktxprocessing.cpp"?
< sipa>
indeed
< bitcoin272>
okay
< bitcoin272>
sipa, I really appreciate this
< bitcoin272>
this clarifies things
< bitcoin272>
what is a reasonable limitancestorcount if resource consumption is low
< bitcoin272>
I am going to bump ancestor/descendant count to 200
< sipa>
that sounds reasonable to me
< sipa>
just to be clear: don't expect these chains to confirm quickly
< sipa>
because other nodes in the network won't accept these long chains, at least not immediately
< sipa>
on rebroadcasts they should go out piecewise, though
< bitcoin272>
well
< bitcoin272>
it's more important that the sendtoaddress command doesn't fail
< bitcoin272>
but still enqueue an automatic payment
< bitcoin272>
that is 100% the most important
< bitcoin272>
we just need sendtoaddress to return a txid
< bitcoin272>
whether or not it hits the network immediately isn't so bad, we just can't have sendtoaddress failing but also having the wallet sending the coins again of its own accord
< bitcoin272>
is there a way to purge a transaction
< bitcoin272>
so it doesn't send?
< bitcoin272>
(on this automatic queue)
< bitcoin272>
will abandontransaction do it?
< sipa>
yes
< sipa>
that's the intended behaviour... if your transaction doesn't confirm and gets evicted, you can manually abandon it
< sipa>
though it's not very well integrated or good guidelines for it
< bitcoin272>
i hear you
< bitcoin272>
well
< sipa>
as that obviously doesn't guarantee that the old one won't confirm still if it went out to the network
< bitcoin272>
this has been a fun day, lol
< bitcoin272>
right
< sipa>
there is work on a bumpfee command which will use bip125 to increase a txn's fee, and replace it with another one
< bitcoin272>
so, the biggest issue with this ancestor/descendant stuff is that the wallet doesn't keep count of how many are chained when doing input selection
< sipa>
indeed
< bitcoin272>
and sendtoaddress fails but it enqueues the transaction for broadcast automatically
< bitcoin272>
is there any way to verify what the ancestor limit is
< bitcoin272>
I bumped both limits to 250
< bitcoin272>
just want to know if it's reflected in current config (I restarted daemon)
< sipa>
if you used the correct option name, it should
< sipa>
limitancestorcount=250
< sipa>
in bitcoin.conf
< sipa>
BlueMatt: so there will be the blockprocessing file and the rest? where does ProcessMessage go?
< BlueMatt>
sipa: net_processing
< BlueMatt>
net_processing.cpp and blocktx_processing.cpp
< BlueMatt>
or blockandtxprocessing.cpp
< sipa>
and will there still be main.cpp?
< BlueMatt>
no
< BlueMatt>
(!)
< sipa>
really, is there nothing that doesn't fit either of those
< BlueMatt>
theres some variables declared that dont
< BlueMatt>
but aside from that, not really
< BlueMatt>
FormatStateMessage, GetTransaction, AbortNode are the only things you can argue in that file (outside of declarations) dont fall into mempool/block processing/block disk state management
< gmaxwell>
bitcoin272: aside and unrelated to your issues, you should _really_ adjust your workflow to use sendmany. And if you cannot for some reason and must continue to depend on unconfirmed chains you should start paying higher fees than default to assure that they get confirmed relatively quickly.
< BlueMatt>
AlertNotify is used exclusively for fork notification
< BlueMatt>
and GetWarnings mostly is as well
< sipa>
BlueMatt: how about calling it validation.cpp?
< bitcoin272>
gmaxwell: understood, thank you
< BlueMatt>
ok!
< sipa>
BlueMatt: in that it's a bit more generic than just processing... something like TestBlockValidity would go there as well, i guess
< gmaxwell>
bitcoin272: you can also split up coins you deposit into the wallet to reduce the need for chaining
< bitcoin272>
gmaxwell: yup
< gmaxwell>
e.g. if you were going to put 10 BTC in that will likely be paid out in .9 BTC chunks, making your payment of ten is as a sendmany with ten 1 BTC outputs would be prudent.