< fanquake>
wumpus: I think I've tracked down the issue with your test for the ELF header LOAD commands 🚀
< fanquake>
Just looks like some alignment issuses in the readelf output.
< fanquake>
Still need to investigate your queries about potential alignment issues in the actual binary
< fanquake>
The problem only shows up in readelf when the binary itself is large, and the addr/size columns push into the Flg column. So you ended up with '9 R' rather than 'R E' etc
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19604: Pass mempool pointer to UnloadBlockIndex/GetCoinsCacheSizeState (master...2007-memPointer) https://github.com/bitcoin/bitcoin/pull/19604
< bitcoin-git>
bitcoin/master fdf697f Hennadii Stepanov: ci: Increase CCACHE_SIZE in some builds on Travis
< bitcoin-git>
bitcoin/master 24ead1a MarcoFalke: Merge #19519: ci: Increase CCACHE_SIZE in some builds on Travis
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19519: ci: Increase CCACHE_SIZE in some builds on Travis (master...200714-ccache) https://github.com/bitcoin/bitcoin/pull/19519
< bitcoin-git>
[bitcoin] fanquake opened pull request #19605: doc: set CC_FOR_BUILD when building on OpenBSD (master...openbsd_cc_for_build) https://github.com/bitcoin/bitcoin/pull/19605
< bitcoin-git>
[bitcoin] jnewbery opened pull request #19607: [p2p] Add Peer struct for per-peer data in net processing (master...2020-07-peer) https://github.com/bitcoin/bitcoin/pull/19607
< jnewbery>
ah, it's for my backport to the 0.20 branch
< jnewbery>
I suppose I need to backport the ShellCheck fix too?
< fanquake>
Just PR that separately. If it's going to break any other builds / backports and be a pain no need for it to wait on your PR.
< jnewbery>
will do. Thanks!
< fanquake>
Should be able to merge right away
< bitcoin-git>
[bitcoin] jonatack opened pull request #19610: p2p, refactor: add `CInv` block message helpers; use in net processing (master...CInv-block-message-helpers) https://github.com/bitcoin/bitcoin/pull/19610
< bitcoin-git>
[bitcoin] jonatack opened pull request #19611: p2p: refactor CInv::type from public int to private uint32_t (master...CInv-type-refactoring) https://github.com/bitcoin/bitcoin/pull/19611
< shesek>
I released Minsc, a compile-to-Miniscript scripting language with some additional features and syntactic sugar. Documentation and a live compiler are available on https://min.sc/, source code is at https://github.com/shesek/minsc
< bitcoin-git>
[bitcoin] fanquake opened pull request #19614: util: use HAVE_FDATASYNC to determine fdatasync() use (master...use_have_fdatasync) https://github.com/bitcoin/bitcoin/pull/19614
< sdaftuar>
i saw i missed some discussion around wtxid-relay being deployed in advance of taproot, driving some desire to backport it
< sdaftuar>
jnewbery: sipa: ^^
< sdaftuar>
it's not clear to me how important that is...
< sdaftuar>
for instance, a simpler solution might be to just backport a patch to 0.20 (and 0.19 and older, however far back people want to go) that adds txids of transactions that fail the AreInputsStandard check to the reject filter
< sdaftuar>
that might take some small refactoring of the logic, but would involve a much less involved p2p change and would presumably be much easier to test and reason about
< sdaftuar>
i haven't tried doing it to see how hard it would be though, so up to whoever is interested in what direction to go
< sipa>
sdaftuar: another alternative that was suggested somewhere was just not relaying taproot spending txn to non-wtxidrelay peers
< sdaftuar>
i guess that would work too -- and also is much simpler than backporting
< sipa>
(i'm not a fan in general of adding these ad-hoc assumptions about relay policy, but if there is a concern about timelines of wtxid relay and taproot interacting, that's a simple solution)
< sdaftuar>
i like the simple fix to the reject filter because it gives users concerned about bandwidth considerations a simple way to mitigate the issue
< sdaftuar>
without redoing a lot of p2p code, which is higher risk
< sdaftuar>
and it should be exactly correct
< sdaftuar>
and it should be exactly correct/
< sdaftuar>
that was supposed to say: taproot doesn't support p2sh, right?
< sipa>
indeed
< sipa>
adding AreInputsStandard failures to the reject filter also seems simple
< sipa>
but it will only benefit nodes that adopt that patch
< sdaftuar>
which i think is (more than?) sufficient for this type of concern
< sipa>
regarding p2dh: that isn't relevant i think?
< sipa>
sends to future witness versions are standard already
< sipa>
only spends from them aren't
< sipa>
ah.
< sdaftuar>
i'd have to double-chekc, but i think if taproot supported p2sh wrapped outputs, the witness check would happen elsewhere no?
< sipa>
but this also means that AreInputsStandard won't detect this
< sipa>
it needs script execution to detect?
< sdaftuar>
i think it will -- i think spending a (bare) v1 output will fail there
< sdaftuar>
we use that solver thing in AreInputsStandard? i'll double check
< sipa>
ah ye
< sipa>
Solver will return WITNESS_UNKNOWN, which isn't automatically rejected
< sipa>
by AreInputsStandard, but it easily could be made so
< sdaftuar>
oh, you're right -- i assumed that was a failure