< fanquake>
If anyone's interested, this sort of performance is pretty typical of the GUI (at least on macOS) at the moment: https://imgur.com/a/rUMhttV
< achow101>
fanquake: is that just during IBD?
< fanquake>
achow101: yea definitely the worse during IBD. Once you're synced it's pretty much ok.
< fanquake>
I've been planning around with reducing the GUI update frequency during IBD to see if we can make it a bit more responsive.
< harding>
Isn't that how the GUI's always been? At least that doesn't seem any different than my Linux usage for the past several years.
< harding>
(When syncing. Agree it works fine after you're caught up to the tip.)
< luke-jr>
doesn't multiprocess fix it automatically?
< kallewoof>
instagibbs: Yes. The Xsat/B stuff.
< luke-jr>
IMO putting variable unit ratios into strings is a bad idea
< luke-jr>
it's a RPC, not a GUI
< luke-jr>
logically we'd also then have to accept "1 BTC" as amounts; and maybe even "5 MBTC/MB"
< fanquake>
harding: yea, maybe I'm just imaging it getting worse.
< wumpus>
luke-jr: I don't really like it much either, on one hand explicit units are at least unambigious, but it does complicate parsing, all clients have to remove the unit, as well as check it against the units they expect, be sure to fail in the case where the unit mismatches
< wumpus>
then to be able to switch units later, all client software has to be adopted anyhow, it doesn't really make that easier
< bitcoin-git>
bitcoin/master 7d6f63c fanquake: Merge #16720: qt: Replace objc_msgSend() function calls with the native Ob...
< bitcoin-git>
[bitcoin] fanquake merged pull request #16720: qt: Replace objc_msgSend() function calls with the native Objective-C syntax (master...20190825-fix-catalina-build) https://github.com/bitcoin/bitcoin/pull/16720
< luke-jr>
IMO the "EXPLICIT" mode string was the way to go. "BTC/kB" was a reasonably justifiable ugliness. But passing a string with units is just too far IMO
< slave_blocker>
TLDR:
< slave_blocker>
Have slave blocks ever been considered to be done in monero ?
< slave_blocker>
well i had this unfundamented vague idea about having slave / master blocks. the current blocks are considered master blocks. and within them there are hash pointers from slave blocks. these slave blocks have transactions within them . what im saying is that instead of having just "your keys your coins" you also need the digital storage of the slave block. The advantage is that instead of storing the tx's themselves you
< slave_blocker>
only store one hash, per slave block. First and foremost if a block is mined wich does contain slave blocks how does the user get his slave block in a safe, reliable way. The second problem is that the amount of verifications done at each normal block is very high because the user needs to send to the miner his signed tx and his digital storage of the block. the third is preventing double spends. So within a slave block
< bitcoin-git>
[bitcoin] michaelfolkson opened pull request #16781: doc: Update comment describing CheckInputs in validation.cpp (master...20190901-checkinputs) https://github.com/bitcoin/bitcoin/pull/16781
< luke-jr>
maybe devs who want a user-friendly CLI wallet should make a real CLI client rather than trying to shove user-friendly stuff into an RPC interface? :p
< jb55>
luke-jr: I've been thinking about that. I have a bunch of bash scripts that make a few things more user-friendly. eg: https://github.com/jb55/bin/blob/master/coins would be cool to wrap it all into a nice to use cli program instead...
< jb55>
maybe could take the git approach and have a bunch of porcelain commands that you could extend over time. the alternative is a full blown curses client...
< bitcoin-git>
[bitcoin] theStack opened pull request #16786: test: add unit test for wallet watch-only methods involving PubKeys (master...add_wallet_watchpubkey_unit_test) https://github.com/bitcoin/bitcoin/pull/16786
< emilengler>
mishaki111400 is spamming
< emilengler>
Can someone ban him
< fanquake>
sipa / wumpus: can one of you block mishaki111400 when you’re around.