< mrannanay>
So if I did setup a miner on a regtest network, every nonce value would be accepted?
< sipa>
no, that variable just triggers the special testnet difficulty reset rule
< sipa>
it does not imply that every hash is always acceptable
< mrannanay>
Oh alright :) It just occurred to me that in this setup ```$ bitcoin-cli generate 100``` executes in ~ 1sec - is this an indication of low difficulty?
< Varunram>
yes
< sipa>
the difficulty in regtest is very low (iirc, 1 block attempt in 2 is valid
< sipa>
and it does adjust difficulty iirc
< mrannanay>
Okay, thanks! Another thing I learnt was the removal of the internal miner from testnet (setgenerate was retained for regtest) - would it be wise to write a miner for regtest?
< sipa>
mrannanay: the generate RPC suffices
< mrannanay>
Conceptually, a miner that runs on regtest would run (albeit much slower) on MainNet?
< sipa>
yes
< sipa>
GBT exists and works fine for both
< mrannanay>
Great, thanks again!
< fanquake>
wumpus I think 11921 and 11936 can go in. The later had a utACK from theuni in the previous PR.
< wumpus>
fanquake: thanks
< wumpus>
as for 11921 I'd prefer cfields to take a look there first, this seems strange
< wumpus>
could this be something like a shell change from openbsd 6.1 to 6.2?
< wumpus>
I really need to upgrade my openbsd box, maybe I'll get around to it today
< fanquake>
I'll checkout the 62 release notes
< wumpus>
good idea
< fanquake>
wumpus clang is now the default compiler there btw
< wumpus>
whoa, they changed that in a minor release?
< bitcoin-git>
bitcoin/master 3eb4d45 Varunram: [build] Warn that only libconsensus can be built without boost
< bitcoin-git>
bitcoin/master 483bb67 Wladimir J. van der Laan: Merge #11936: [build] Warn that only libconsensus can be built without Boost...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11936: [build] Warn that only libconsensus can be built without Boost (master...libcon-boost) https://github.com/bitcoin/bitcoin/pull/11936
< wumpus>
or at least marked as pre-6.2 only
< fanquake>
Possibly. My internet is currently too slow to load the entire changelog, so I'm still unsure about potential shell changes
< meshcollider>
btw wumpus #11178 might be RTM as well
< gribble>
https://github.com/bitcoin/bitcoin/issues/11178 | Add iswitness parameter to decode- and fundrawtransaction RPCs by MeshCollider · Pull Request #11178 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master bbdbe80 MeshCollider: Add iswitness parameter to decode- and fundrawtransaction RPCs
< bitcoin-git>
bitcoin/master 6f39ac0 MeshCollider: Add test for decoderawtransaction bool
< bitcoin-git>
bitcoin/master fee0370 Wladimir J. van der Laan: Merge #11178: Add iswitness parameter to decode- and fundrawtransaction RPCs...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11178: Add iswitness parameter to decode- and fundrawtransaction RPCs (master...201708_rawtx_bool) https://github.com/bitcoin/bitcoin/pull/11178
< bitcoin-git>
[bitcoin] laanwj opened pull request #11943: contrib: fix typo in install_db4.sh help message (master...2017_12_db5_typo) https://github.com/bitcoin/bitcoin/pull/11943
< wumpus>
bah install_db4.sh is broken on openbsd 6.2
< fanquake>
Broken more than that typo?
< wumpus>
yes
< fanquake>
:o I'll test it once you've pushed up some changes.
< wumpus>
it also seems openbsd 6.2 has both clang and gcc installed by default? can that be true?
< wumpus>
or is it just an artifact of upgrading
< wumpus>
so c++ --version gives "OpenBSD clang version 4.0.0", g++ --version gives "g++ (GCC) 4.2.1 20070719", of course our build system defaults to the old g++ :(
< provoostenator>
So I managed to install QT Creator and I'm able to use to run bitcoin-qt and edit C++ files. However what I'm trying to do is edit one of the .ui files. Unfortunately the Design tab is greyed out, and I don't see these .ui files in the project.
< bitcoin-git>
bitcoin/master ecf9b25 Pierre Rochard: remove unused fNoncriticalErrors variable from CWalletDB::FindWalletTx
< bitcoin-git>
bitcoin/master 81c89e9 Wladimir J. van der Laan: Merge #11923: Wallet : remove unused fNoncriticalErrors variable from CWalletDB::FindWalletTx...
< wumpus>
provoostenator: you mean the html generation in 'show payment info'? that code is mostly inherited as-is from satoshi's wx client
< provoostenator>
Git blame said it was you, but maybe you just touched it.
< wumpus>
provoostenator: I'm surprised no one addressed it before
< wumpus>
well I copy/pasted the code
< wumpus>
I mean it works, maybe it doesn't look super sexy or is super readable code, but it was one of the better parts of his GUI code
< provoostenator>
Great, I'll be able to remove "improved code written by Satoshi" to my bucket list.
< provoostenator>
*from
< wumpus>
also having one html document makes it easy to copy/paste the whole thing, which it wouldn't be if it's some huge qt form
< provoostenator>
Does QT not allow extracting form partials into seperate files?
< wumpus>
(which usually only allows copy/pasting field by field)
< wumpus>
I mean if you can create something that looks better and is more usable to users, I'm all for it, but yeah just doing it because you don't like the code style is .. dunno
< wumpus>
seems low prio to me at least
< provoostenator>
The specific example I put in that issue is probbly one where I can make the stuff I'm building on top of it look better.
< provoostenator>
I wouldn't necessarly want to refactor all of this everywhere.
< provoostenator>
But I will probably complain if someone does this in a future PR :-)
< wumpus>
but in high level I agree with you, it's better to specify the GUI stuff in XML than generate it in code where possible
< provoostenator>
Generally though, I am indeed trying to see if I make the QT client just a little prettier.
< provoostenator>
Often very small improvements can make huge difference in how it's perceived.
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11951: Remove dead feeest-file read code for old versions (master...2017-12-dead-feeest-load) https://github.com/bitcoin/bitcoin/pull/11951
< Murch>
laanwj, TheBlueMatt: Sorry for my lack of response on the PR, I just got the highlight here, I've been swamped at work and haven't been on Github at all. :(
< wumpus>
Murch: no worries
< wumpus>
I think your change was fine, there was no need to hold it up further, other people can do the rest of the work :)
< Murch>
Thanks!
< wumpus>
Murch: if you do have some time please review #11951 that BlueMatt just openend, it continues your work
< luke-jr>
[Thursday, December 14, 2017] [7:50:07 AM UTC] <jonasschnelli> luke-jr: a complete UTXO scan with sweepprivkeys takes ~3mins on my machine (mainnet)… is there a nice way to show progress? <-- does it really? I'm seeing under 34 seconds… (although on 0.13 codebase)
< sipa>
luke-jr: highly hardware dependent, i expect
< luke-jr>
6x though?
< sipa>
yes, sure
< sipa>
SSD vs spinning disk alone may do that
< sipa>
and then add things like disk encryption, low-end vs high-end CPU, ...
< jonasschnelli>
luke-jr: 34s? I have a couple of minutes on my relatively fast Intel Xeon SSD
< jonasschnelli>
Could the utxo per txout model slow down (wasn't in 0.13)
< sipa>
oh, it certainly could
< sipa>
i wouldn't expect a 6x slowdown from that
< sipa>
but there would be some
< gmaxwell>
the utxo set has grown a lot, are you comparing to current?
< gmaxwell>
morcos: sdaftuar: do either of you have opinions about the idea of removing the two week mempool expiration and replacing it with 48 hours of showing up in the top 4m weight of txn? (and perhaps also coupling it with a stored expired txn list, so that it won't get readded to the mempool?)
< gmaxwell>
by only looking at the top of the mempool we could expire things that aren't confirming MUCH faster... and this would eliminate the current bad interaction where expiration is keeping the relay fee from going up.
< aj>
gmaxwell: if we go back to fees varying so there's a lull over the weekend, don't you want to keep transactions that will confirm in the lull for the week they might need?