< bitcoin-git>
[bitcoin] achow101 opened pull request #13289: [Qt] Re-setup args after translator setup to translate help text (master...qt-help-translations) https://github.com/bitcoin/bitcoin/pull/13289
< provoostenator>
IIRC someone recently suggested that too much of a dbcache is not a good thing. Why would that be? Is that only the case for n < dbcache < max_historical_utxo_size ?
< provoostenator>
Reason I ask is because in my benchmarking for #12404 my impression is that luke-jr's 10% pruning approach is faster than my aggresive prune approach. That effect appears more pronounced as I increase dbache. Pruning 10% should lead to more prune events, which in turn would keep dbcache smaller as a side effect.
< provoostenator>
If that doesn't make any sense at all, then maybe I'm just seeing random noise, so thoughts welcome.
< luke-jr>
provoostenator: I imagine the 10% pruning is most of the advantage
< provoostenator>
That could well be, which is why I'm testing it, but I'm surprised if it's actively harmful to prune more. That suggests something else is going on.
< luke-jr>
yes, I wouldn't expect pruning more to be harmful
< luke-jr>
except in terms of wallet syncing perhaps
< luke-jr>
or similar
< provoostenator>
This one is configured with --disable-wallet.
< mmgen>
question for the devs: to get a complete wallet backup with all historical transactions is it enough to back up wallet.dat, or must the database dir be backed up too?
< luke-jr>
mmgen: the recommended way is to use the backupwallet RPC (or GUI equivalent)
< luke-jr>
but if you must copy the data manually, you need both
< luke-jr>
and from the same instant.. which may not be easy to get reliably
< mmgen>
luke-jr: however, backupwallet just makes a copy of wallet.dat, nothing more
< mmgen>
luke-jr: it doesn't copy the database directory, as far as I know
< luke-jr>
mmgen: it closes the database first, and makes a copy with it closed
< mmgen>
luke-jr: so the wallet.dat it produces is a complete backup that contains all the history?
< luke-jr>
right
< mmgen>
luke-jr: ok, that's what I neede to know. Thanks!
< mmgen>
Just something I noticed: I'm running bitcoind with --connect=0, yet I'm getting error messages "Potential stale tip detected, will try using extra outbound peer". Sort of silly, considering the daemon is running offline.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 (master...openbsd-warnings) https://github.com/bitcoin/bitcoin/pull/13294
< Emzy>
Moin
< jamesob>
cfields: is there a good place for me to undef HAVE_THREAD_LOCAL based on our findings that it's unsuitable for use on __APPLE__ and (apparently) __WIN32__? Can do it in threadutil.cpp as before, but it seems like there'd be a better place
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3 (master...openbsd-6.3) https://github.com/bitcoin/bitcoin/pull/13295
< Chris_Stewart_5>
Does the protocol allow for different hash types for each signature in a multisig script?
< jamesob>
ryanofsky: I think for the time being we want to undef HAVE_THREAD_LOCAL for certain platforms even after that autoconf check - any idea of the appropriate place to do that?
< cfields>
jamesob: for platforms where we're enabling thread_local, we should add a runtime sanity check for sure
< jamesob>
cfields: what specifically are you thinking there?
< jamesob>
something more in the AC_LINK_IFELSE program?
< cfields>
jamesob: see compat/glibc_sanity.cpp as an example. Imo we need compat/thread_local_sanity.cpp too
< cfields>
jamesob: no, something that's actually executed by bitcoind as a quick runtime check
< jamesob>
the testcase I wrote results in a stackoverflow though - is there a way to safely include something like that at runtime?
< cfields>
basically, if it compiles and links ok, there's still a chance something's busted. We need to be able to catch the mingw failure and refuse to run, even if we didn't know that it was busted
< cfields>
jamesob: see the link above. seems to give predictable-ish results
< ken2812221>
jamesob: I test your code on Ubuntu 18.04, it seems not an issue anymore.
< ken2812221>
I test it on native Windows and wine3.0
< jamesob>
ken2812221: interesting. thanks for testing.
< pierre_rochard>
Additionally, if you would like to provide a short blurb quote explaining why you find the site useful, that would be appreciated!
< Chris_Stewart_5>
pierre_rochard: Very cool
< Chris_Stewart_5>
pierre_rochard: Are you going to add that blurb to a help menu on the site?
< pierre_rochard>
@chris_stewart_5 thanks! I was going to append blurbs to the blog post itself, and publish it as an "About" tab on the acks website, as well as on medium / my own website
< jamesob>
cfields: you're pretty confident that the bug described in that issue is the same one affecting us in the gist?
< cfields>
jamesob: not sure, no. An issue either way, though
< bitcoin-git>
[bitcoin] naumenkogs opened pull request #13298: Net: Random delays *per network group* to obfuscate transaction time (master...delay_per_net_group) https://github.com/bitcoin/bitcoin/pull/13298
< skeees>
anyone here looking at / spending time reviewing the latest dandelion proposal (either bip or code)?
< Varunram>
Is anyone else having this bug on macOS? bitcoind starts fine but I can't seem to query it using bitcoin-cli
< Varunram>
I'm on regtest and on commit d792e47421fcb9ce3b381c1e6d8902777ae3f9f3 for ref.
< sipa>
define "can't seem to query it" ?
< sipa>
what do you do, what do you see, what do you expect to see
< Varunram>
sorry, should've been clearer: `Could not connect to the server 127.0.0.1:8332`
< sipa>
are you sure bitcoind is running?
< Varunram>
yep
< Varunram>
btw, why is it trying to connect on that port?
< Varunram>
it should be 18443 right?
< sipa>
ah
< sipa>
are you passing -regtest to bitcoin-cli?
< Varunram>
oh my
< sipa>
:)
< Varunram>
was this added in 0.16? I can pretty much be sure I didn't do this in 0.15
< sipa>
there is no way bitcoin-cli can know you're trying to connect to regtest without it
< sipa>
ever
< Varunram>
oh, ok. I guess i'd have had it in the conf then
< Varunram>
thanks!
< sipa>
that's possible
< satwo_>
Hello all. Is the "witness_unknown" script type in Bitcoin Core essentially in place for backward compatibility in the event of a future soft fork adding a new witness script type (or increasing the version of an existing one)?
< sipa>
yes
< sipa>
because BIP173 defines an address type for future segwit versions, we need a way to parse and represent those
< satwo>
Ok, thanks sipa. Would it be possible for someone to manually construct such an address type right now that the parser represents as "witness_unknown"?
< satwo>
Not asking because I plan on doing so, but just want to make sure I understand things properly.
< luke-jr>
satwo: yes, but it would be basically an anyone-can-spend and rejected by network policies
< sipa>
satwo: creating such an address would be trivial, yes
< sipa>
BIP173 even contains an example: bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj
< Chris_Stewart_5>
Does anyone know how to compile bitcoin core when there is a name conflict for threading libraries on windows?
< satwo>
Ah, that's what I was getting at, whether a tx with such an output could be relayed/mined at the present time. Thanks for the clarification gents.
< Chris_Stewart_5>
what is the flag that needs to be set on ./configure ?
< sipa>
Chris_Stewart_5: are you compiling _on_ windows or _for_ windows?
< Chris_Stewart_5>
sipa: Using the "Windows subsystem for Linux" which I beleive is the former?
< sipa>
the two footnotes there are specifically about issues when building on ubuntu for windows
< sipa>
i doubt they apply to WSL
< sipa>
ah, but WSL is derived from ubuntu?
< Chris_Stewart_5>
sipa: Possibly? I'm not 100% sure. Today is the first day of learning of this :-)
< Chris_Stewart_5>
"The Windows Subsystem for Linux lets developers run Linux environments -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a virtual machine. "