< GV>
I have a validator but I only works with the older addresses. I heard that the byte version is different but the implementation is not that different
< GV>
it*
< meshcollider>
GV: what do you mean by validate it? Check that the script you have corresponds to that address? Check that you can sign a transaction sent to that address? what?
< meshcollider>
GV: And what do you mean by 'older addresses', just normal P2PKH addresses?
< meshcollider>
GV: This is not the right channel for support, you should ask in #bitcoin
< GV>
To make sure that the address is a valid P2PKH or P2SH address.
< GV>
Oh okay, I'll try there
< Dylan>
watcha working on?
< meshcollider>
is there any way for the functional tests to assert two error messages in a row
< meshcollider>
assert_start_raises_init_error only checks the last error I think, which is a more general failure in the test I am working on, the error directly before it is more specific which is what I want to assert
< jonasschnelli>
I'm working on a RPC call "scantxoutset" (scan utxo set for particular scrips or pubkeys[->script]) based on luke-jr sweepprivkey work. Would it make sense to run the command async?
< jonasschnelli>
Like "scantxoutset start [<pubkeys>]",... and "scantxoutset status", where the later would tell about the progess... then maybe a "scantxoutset result <jobid>" for getting the txouts (compatible with listunspents for createrawtransaction usage)
< jonasschnelli>
It would require an additional thread (utxo-scan-thread) and only one scan in time would be allowed
< luke-jr>
jonasschnelli: this sounds like a "create ram-only wallet; add watch addresses; rescan" tbh
< jonasschnelli>
luke-jr: scantxoutset purpose is to crate a raw sweep transaction (and more)
< jonasschnelli>
it would spit out utxos that can directly been used in createrawtransaction.. like:
< luke-jr>
jonasschnelli: you would then do a fundrawtransaction after the rescan ;)
< luke-jr>
I guess difference is you don't look at history; but maybe that should just be an alternative to rescan
< jonasschnelli>
luke-jr: you don't want to do a rescan..
< jonasschnelli>
the purpose of the utxo scan is to be much faster and works on pruned peers as well
< luke-jr>
right
< luke-jr>
my point is that if we're considering an async UTXO scan, it'd be better to have "createwallet" make a RAM-only one, and add a "scanutxo" or something
< luke-jr>
and the RAM-only wallet is your state
< jonasschnelli>
luke-jr: What would be the benefit of a mem only CWallet instead of a mem only CKeyStore?
< luke-jr>
having only one kind of state instead of multiple
< jonasschnelli>
luke-jr: I can't follow
< jonasschnelli>
luke-jr: or do you mean the possibility to run multiple utxo scans concurrently?
< luke-jr>
jonasschnelli: I would expect that to be supported, yes
< jonasschnelli>
Okay. Yes. That would make sense...
< luke-jr>
although maybe it has little use case, not sure
< luke-jr>
so long as the scan can look for multiple things at the same time, that would seem much more sensible after all
< jonasschnelli>
The major point I'm worried about is an RPC call that requires a couple of minutes to response...
< jonasschnelli>
multiple scans during the same time seems nice to have, but not extremely important.
< luke-jr>
I would expect simpler code to use a temporary wallet too
< jonasschnelli>
ack on "Caller needs to make sure pindexStop (and the optional pindexStart) are on the main chain after to the addition of any new keys you want to detect transactions for"?
< jonasschnelli>
wumpus: I think this should be merged (#11616), maybe do a last review/test?
< gribble>
https://github.com/bitcoin/bitcoin/issues/11616 | Update ban-state in case of dirty-state during periodic sweep by jonasschnelli · Pull Request #11616 · bitcoin/bitcoin · GitHub
< vtt>
hi
< Provoostenator>
My entire machine almost completely froze while trying shutdown QT. Maybe because I set DB cache to 10 GB on a 16 GB machine, but it could have some other process I was running.
< Provoostenator>
More interesting is that when I restart it and then immedidately try to quit, it took about 5 minutes for it to honor that quit command.
< Provoostenator>
Not much memory and CPU usage at all, just lots of disk writing.
< Provoostenator>
It showed the "don't shut the computer down message" during the first time (when the computer froze), but it did not show that warning message the second time.
< Provoostenator>
Does the db cache get written to disk during idle time?
< gmaxwell>
Provoostenator: no because that would undermine its benefits. (well it gets flushed after 24 hours if fullness doesn't trigger a flsh first)
< gmaxwell>
the main purpose of the dbcache is to act as a buffer that prevents utxo from ever hitting the database at all.
< gmaxwell>
since the design changes in the last year we can now do partial flushing, which would allow for some incremental flushing-- e.g. flush things more than N blocks old-- but it hasn't been implemented yet.
< bitcoin-git>
bitcoin/master c853812 Jonas Schnelli: Update ban-state in case of dirty-state during periodic sweep
< bitcoin-git>
bitcoin/master 57ac471 Jonas Schnelli: Call BannedListChanged outside of cs_setBanned lock
< bitcoin-git>
bitcoin/master 8585bb8 Wladimir J. van der Laan: Merge #11616: Update ban-state in case of dirty-state during periodic sweep...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11616: Update ban-state in case of dirty-state during periodic sweep (master...2017/11/qt_ban) https://github.com/bitcoin/bitcoin/pull/11616
< Provoostenator>
gmaxwell: I see. I set it to a high number during IBD with the idea of then lowering it after that's done.
< Provoostenator>
Maybe doing a flush after IBD makes sense?
< gmaxwell>
yes, a flush after IBD would make sense and probably avoid a lot of complaints from users who crashed their system and are unhappy that its effectively revalidating the whole chain. it's not really clear at what point it should flush though, ibd doesn't have a bright boundary line
< luke-jr>
when the best known header chain has been fully processed?
< Provoostenator>
Does the flush block the UI? If not, then I guess it can be done once the "downloading blocks" dialog goes away (I don't know what triggers that).
< wumpus>
that's complicated - a flush doesn't block normal user activity in the GUI, however holding up cs_main will make it block once the user does any action that requires response from the node
< wumpus>
or wallet, such as sending a transaction (fee computation), looking at transaction details, pretty much anything
< Provoostenator>
So then a progress bar would be good.
< Provoostenator>
Even if the user can dismiss it (as they can the IDB popover), at least they'd have a clue as to why somethign is unresponsive.
< wumpus>
anyhow isn't this only a problem with huge dbcaches? with the normal settings, flushes are abundant
< wumpus>
showing a progress bar every time would be crazy
< Provoostenator>
If it's likely to take more than 10 seconds, there should be some UI indicator. But it doesn't have to cover the whole screen.
< wumpus>
we should just fix the GUI to be more async and not block the GUI thread on everything
< wumpus>
that's much better than hacking even more around it
< Provoostenator>
That for sure.
< Provoostenator>
Don't Block The Main Thread is a good mantra
< Provoostenator>
(iOs devs are obsessed by it, because blocking the main thread for more than 1/60th of a second breaks butter smooth scrolling.
< * luke-jr>
wishes his window manager didn't block the main thread :x
< Provoostenator>
And probably many crashes are a result of over complicated engineering to keep said scrolling smooth.
< wumpus>
my brain is too slow to notice 1/60th of a second :) but yes, as a mantra it makes sense, I really wish I could go in time and convince myself to design the GUI with that in mind instead of planning to leave it for later
< Provoostenator>
Well, if you'd done that, maybe Bitcoin would never have taken off :-)
< Provoostenator>
(because of the never shipping)
< wumpus>
yep, good point
< wumpus>
going from wx to qt was already a huge change
< wumpus>
luke-jr: how do you mean that?
< luke-jr>
? quite often when I alt-tab, my window manager blocks on I/O until whatever fsync something else did has finished
< wumpus>
even when not swapping?
< luke-jr>
yes, only at 24 GB used (of 32 GB)
< luke-jr>
I suspect btrfs-related, but oh well
< luke-jr>
when Talos arrives, I'll probably switch back to ext4 or something
< ryanofsky>
MarcoFalke, others, anybody know about "Configuring boost..., /bin/sh: 1: requires: not found" errors from travis depends? i filed #11906
< bitcoin-git>
bitcoin/master c79d73d Matt Corallo: Clarify getbalance meaning a tiny bit in response to questions.
< bitcoin-git>
bitcoin/master df71819 Wladimir J. van der Laan: Merge #11886: Clarify getbalance meaning a tiny bit in response to questions....
< bitcoin-git>
[bitcoin] laanwj closed 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
< fanquake>
wumpus I don't think so. I'll have a look again tonight and open an issue with some more info.
< wumpus>
thanks!
< fanquake>
I have a few depends changes I need to PR as well, will do it at the same time.
< SopaXorzTaker>
I want to propose using Bech32 for private keys
< SopaXorzTaker>
it would be quite useful, and if we want to phase Base58 out, we must do so everywhere we can
< wumpus>
there would be no point in defining a new format for normal private keys, but for a new format representing private key + segwit metadata, sure