< theStack>
ad libevent 2.0.21: the problem is that the fuzz test http_request calls functions from libevent that are not part from the API, i.e. internal functions: evhttp_parse_firstline_
< emilengler>
icota: Can you send a link to a pastebin with the error message?
< bitcoin-git>
bitcoin/master 1abbdac Fabian Jahr: wallet: Prefer full destination groups in coin selection
< bitcoin-git>
bitcoin/master a2324e4 Fabian Jahr: test: Improve naming and logging of avoid_reuse tests
< bitcoin-git>
bitcoin/master c189bfd Samuel Dobson: Merge #17824: wallet: Prefer full destination groups in coin selection
< wumpus>
theStack: thanks, that sounds easy to work around with an ifdef at least then :)
< bitcoin-git>
[bitcoin] meshcollider merged pull request #17824: wallet: Prefer full destination groups in coin selection (master...i17603) https://github.com/bitcoin/bitcoin/pull/17824
< wumpus>
meshcollider: if it's minor things, just mention it in the release notes
< wumpus>
(and in this case it is, I don't have much of an optinion on the PR itself looks like it slightly improves consistency, though, no one has written strong guidelines when to use what RPC error code)
< meshcollider>
Yeah, alright
< theStack>
wumpus: yes, a preprocessor check should solve the problem for libevent 2.0.21
< meshcollider>
promag: what's the status of #18471
< wumpus>
what in libc was blocking thread-local support, I have been unable to figure this out, compiled a few small C++ programs using __thread but didn't see any libc dependencies appear
< wumpus>
the only tls-related libc function I could find is " __tls_get_addr@GLIBC_2.3", which would suggest libc 2.3
< bitcoin-git>
[bitcoin] laanwj opened pull request #18681: donotmerge: build: Enable thread-local with glibc compat (master...2020_04_thread_local_compat) https://github.com/bitcoin/bitcoin/pull/18681
< fanquake>
wumpus: I haven’t gone back to read the old threads, but a gitian build sounds like a good idea
< wumpus>
right, probably most efficient way to find out :)
< fanquake>
In regards to libevent 2.0.21. Also tried to find all the old discussion, my gut feeling was bugs that we were trying to avoid, maybe shutdown related. Haven’t got anything conclusive though
< fanquake>
It's also possible in the mean time that we've done refactorings such that those concerns are no longer relevant.
< wumpus>
given that everyone with xenial has been building against 2.0.21 and we got, afaik, zero complaints about that (besides the fuzzer build issue), it can't be *that* bad
< wumpus>
yes, that's possible too
< wumpus>
it highlights that it's kind of important to document *why* something is the minimum version somewhere, sure, it's always possible to find it between reams of commits and github comments, but for older projects that gets less and less efficient
< bitcoin-git>
bitcoin/master c2e53ff MarcoFalke: Merge #18467: rpc: Improve documentation and return value of settxfee
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18467: rpc: Improve documentation and return value of settxfee (master...txfee0) https://github.com/bitcoin/bitcoin/pull/18467
< hebasto>
theStack: on xenial trying to replicate compiling bug for fuzzing code. Currently, configure returns error: checking whether C++ compiler accepts -fsanitize=fuzzer,address,undefined... no
< hebasto>
did you encounter it?
< hebasto>
having system clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
< theStack>
hebasto: i only tried with clang-8 so far, where the configure script didn't cause problems
< hebasto>
theStack: ok, going to upgrade clang :)
< jonatack>
MarcoFalke: I run them locally. Rerunning now on master.
< MarcoFalke>
They reproducibly fail for me, so either no one is running the tests or everyone has horribly slow machines or no one reports test failures
< MarcoFalke>
They are broken for the last 3 days or so
< jonatack>
yup it fails line 161
< jonatack>
first run both via the runner and directly calling it
< bitcoin-git>
[bitcoin] pierreN opened pull request #18689: rpc: allow dumptxoutset to dump human-readable data (master...feature-utxo-ascii) https://github.com/bitcoin/bitcoin/pull/18689
< bitcoin-git>
[bitcoin] robot-visions opened pull request #18690: test: Check object hashes in wait_for_getdata (master...wait-for-getdata) https://github.com/bitcoin/bitcoin/pull/18690
< bitcoin-git>
[bitcoin] jonatack opened pull request #18691: test: fix intermittent error in interface_bitcoin_cli (master...fix-intermittent-credentials-issue) https://github.com/bitcoin/bitcoin/pull/18691
< captjakk>
Currently the behavior of Bitcoin Core in a pruned state is to return an RPC error when a block is requested that has been pruned. I was thinking about working on a change that would allow Core to dynamically fetch a block it didn't have, and verify it against the retained headers. This ultimately implies a slight implementation change to the peer protocol, but at first glance this seems harmless and potentially very helpful
< captjakk>
as we get to larger numbers of applications/protocols that depend on core. Does anyone know of a reason this would be bad?
< gwillen>
that's kind of interesting. I'm not an expert so you should wait for one of those to chime in, but I expect this sort of thing mostly doesn't exist due to lack of demand?
< gwillen>
you would need a more complicated scheme for managing pruning if you have random old blocks lying around because an RPC client wanted them, you'd want some kind of cacheing or pinning scheme, presumably you'd need new RPCs to implement that (not just make it implicit, it's too expensive an operation for that I think)
< captjakk>
Here's why we want it. At Start9 We are building the Embassy which allows you to run a pruned node quite easily. Archives are necessary for some and helpful for everyone, but we want to make it such that running a full node that is usable by various wallets today does not necessitate full archives/txindex
< gwillen>
I think it's rare to want single old blocks, do you have a specific place that's coming up?
< captjakk>
Here's the situation
< captjakk>
say you have a full node synced from genesis but it's pruned to only keep 5GB of data
< captjakk>
if you want to add a new application, say, c-lightning, you either require a resync or it needs to be able to register itself with core to inform core to retain all blocks newer than a certain height
< captjakk>
OR
< captjakk>
it would need to be able to dynamically fetch a block that had been pruned
< captjakk>
my understanding is that currently pruned nodes keep ALL block headers
< captjakk>
even if the associated blocks have been long since purged
< sipa>
<opinionated mode> applications that require access to historical blocks are broken, except for debugging/emergency recovery situations
< captjakk>
even for new syncs?
< gwillen>
well "new syncs" are why I asked about "random" blocks specifically
< sipa>
a new wallet doesn't need access to old blocks, because its keys are new
< captjakk>
OK so dynamic fetching may be unnecessarily expensive here
< gwillen>
also, isn't "retain all blocks after a certain height" in fact already supported in RPC
< sipa>
that said, i see no technical reason why implementing your suggestion would be a problem
< gwillen>
so you might already have what you need
< captjakk>
it needs to support it from multiple dependents
< captjakk>
if I want both C-lightning and wasabi to share a full node, they need a way to deconflict the specification of which old blocks they need
< sipa>
captjakk: there is a recently opened issue about multiple applications being able to register they need blocks, and letting them individually declare to be done up to block X
< captjakk>
do you know what number? or the name of the rpc call?
< captjakk>
This was opened by my brother, I am the other commenter :)
< captjakk>
captjakk == ProofOfKeags
< captjakk>
haven't changed my irc handle yet
< gwillen>
ah! hah.
< captjakk>
But either way, great!
< captjakk>
We are more than happy to develop this proposal/code it up
< gwillen>
this seems like it may be a "patches accepted" situation -- that is, it's probably not too hard to write 'keepheight', but you might have to do it if you want it
< captjakk>
I just wanted to check in to see if it may be controversial
< sipa>
gwillen: well there already exists manual pruning mode
< sipa>
where you need to issue an RPC to prune
< sipa>
the issue is that this is "single user"
< captjakk>
correct
< gwillen>
right, so it seems like modifying it to track multiple "pins" wouldn't be too complex
< captjakk>
because it pruning is done via positiva
< captjakk>
This will be the first code contributions we've made
< captjakk>
so yes, any info on how to do this from a process standpoint is appreciated
< gwillen>
cool, definitely read through CONTRIBUTING.md, whatever links from it look relevant, plus productivity.md, which has some big time-saving tips in it
< jonatack>
good tips. also don't miss doc/developer-notes.md
< gwillen>
honestly the whole 'doc' folder is good to skim for stuff that appears relevant
< gwillen>
also I would consider fleshing out your proposed RPC interface and detailing it on the issue thread before you start coding too much, so people can comment on the design
< proofofkeags>
yeah I figured
< gwillen>
(probably come back here with a link once you have that)
< proofofkeags>
is this something that should be detailed in the issue, or does it warrant a Bip
< proofofkeags>
seems that since it's limited to RPC the bip isn't necessary
< proofofkeags>
but I'm not sure what heuristic is used for bips
< sipa>
proofofkeags: BIPs == things that require cross-application standards
< sipa>
i don't think that's applicable here
< proofofkeags>
cool, makes sense
< proofofkeags>
so any change or addition to the peer protocol or address schemes and the like
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18692: test: Bump timeout in wallet_import_rescan (master...2004-qaBumpTimeout) https://github.com/bitcoin/bitcoin/pull/18692
< sipa>
P2P protocol changes, consensus changes, address formats, but also general things like standard derivation paths for keys, ...
< sipa>
there is a BIP for the "bits" denomination
< proofofkeags>
lol, I suppose that's fair
< sipa>
changes to the BIP process itself (BIP 1, BIP 2)
< proofofkeags>
cool, thanks for the input y'all
< yevaud>
for a rare one, BIP50 is a report, not a change.
< sipa>
ah, indeed
< yevaud>
an incorrect report, but one none the less.
< proofofkeags>
incorrect how?
< yevaud>
it's conclusion is wrong, fundamentally. it suggests that the correct option was to encourage people to downgrade to 0.7, limit block size to 500KB, and increase the number of locks allowed in berkleydb.
< yevaud>
simply, no version of Bitcoin before 0.8 was able to maintain consensus even between nodes of the same version. realistically there's no amount of increase in berkeleydb which can allow nodes to operate properly, and the number in that document is well, well below the value required even for the time.
< sipa>
the document does mention "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the
< sipa>
exact arrangement of the blkindex.dat on...
< sipa>
due to the way locks were grabbed for an entire reorg, arguably for any finite value of the lock limits, pre-0.8 was unable to handle arbirarily long reorgs, which is arguably a consensus failure
< sipa>
then again, i believe there have been plenty of other versions since 0.8 that also weren't practically capable of doing very deep (say 1000s of blocks) reorgs
< yevaud>
true. in those versions reverting a UTXO change wrote back into the mempool for every block (or something close), it was excruciatingly slow.
< yevaud>
I've attempted to sync 0.7 with 2**32 locks, it ends up failing consensus effectively at random. it was never clear exactly why.
< sipa>
by unable i don't just mean infeasibly slow - i mean it'd go OOM
< yevaud>
right. it would be an interesting exercise to get 0.7 to sync with the modern network, but it's in the order of months of sync time, even entirely in NVMe cache.
< yevaud>
I'm not even confident it can process blocks fast enough to stay in sync at the head.
< sipa>
haha, yes
< sipa>
that too is arguably a consensus failure...
< yevaud>
presumably if we had CPUs that were orders of magnitude faster, it would be consensus compatible again. sort of stretching the definition.
< gwillen>
ugh, I hate the fact that every time some fucking altcoin brings over a commit that has my name in it, I get pinged
< gwillen>
if anybody knows a way to prevent that I'd love to hear it
< sipa>
i think we have some recommendation somewhere not to put @username in commit messages
< sipa>
someone even suggested having a linter for it
< gwillen>
welp
< fanquake>
sipa: ok
< sipa>
fanquake: were you... asleep?
< fanquake>
Yes I was hah
< fanquake>
Can you also block amirabbaska
< sipa>
done
< achow101>
fanquake sleeps? that's new :p
< sipa>
it must be a sporadic activity
< dongcarl>
achow101: You see, he has a secondary brain directly attached to an X server, which never sleeps