< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20568: rpc: Use FeeModes doc helper in estimatesmartfee (master...2012-rpcDocFee) https://github.com/bitcoin/bitcoin/pull/20568
< bitcoin-git>
[bitcoin] laanwj opened pull request #20567: test: Add option to git-subtree-check to do full check, add help (master...2020_12_subtree_check) https://github.com/bitcoin/bitcoin/pull/20567
< bitcoin-git>
[bitcoin] laanwj reopened pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
< bitcoin-git>
[bitcoin] laanwj closed pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
< wumpus>
Connecting to chat.freenode.net:6697 with nick bitcoin-git and channels: #bitcoin-commits,#bitcoin-core-dev: There was a problem sending messages to IRC: timed out
< wumpus>
one thing I had never imagined was having to do this for the bitcoin P2P protocol, I mean usually it's about trying to smuggle bitcoin P2P data like blocks and transactions over some other layer
< bitcoin-git>
[bitcoin] hebasto opened pull request #20563: build: Check that Homebrew's berkeley-db4 package is actually installed (master...201203-bdb) https://github.com/bitcoin/bitcoin/pull/20563
< wumpus>
aj: if there are plans for bitcoin-util it's okay with me
< aj>
might make sense to do it in bitcoin-tx now, and have a new PR later that adds bitcoin-util with multiple functionality bits (and better arg handling like MarcoFalke suggests)
< wumpus>
it's too bad we already have bitcoin-tx with the same (in)dependency idea
< aj>
wumpus suggested adding it to bitcoin-tx which works fine (it already links libconsensus), but is klunky
< wumpus>
I guess the drawback is adding yet another executable, which links in a lot of stuff, but if we have other plans for bitcoin-util apart from just the signet grinding it may be worth it
< aj>
bitcoin-util as a generic thing has been proposed in #14671 iirc for doing things like psbt without needing a running node
< aj>
signet mining has high enough difficulty that grinding in python doesn't work. but gridning needs libconsensus code so can't be stuck in bitcoin-cli without bloating it
< bitcoin-git>
[bitcoin] achow101 opened pull request #20562: tests: Test that a fully signed tx given to signrawtx is unchanged (master...test-signraw-fullysigned) https://github.com/bitcoin/bitcoin/pull/20562
< gribble>
https://github.com/bitcoin/bitcoin/issues/17204 | wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code (sipa) by meshcollider · Pull Request #17204 · bitcoin/bitcoin · GitHub
< jnewbery>
luke-jr: not trolling. If a PR is opened where the goal is primarily to make things easier for downstream projects, then (1) that should be explicitly declared in the PR description (2) it should be judged for inclusion in Bitcoin Core solely on whether it's a benefit to the users of this project.
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #20561: p2p: periodically clear m_addr_known, and choose new peers to receive relayed addresses (master...2020-12-moar-addrz) https://github.com/bitcoin/bitcoin/pull/20561
< luke-jr>
then people who want to switch between versions regularly can just put strict=0 in bitcoin.conf
< fanquake>
Yes that's possible, and probably quite likely. I'd imagine there are many people running bitcoin nodes, that have no interest in it supporting UPNP, ZMQ, or even having the wallet compiled into it.
< miketwenty1>
in the future / even with guix .. would you imagine gitian sigs for multiple common options for each minor/major release of bitcoin? like one with everything enabled.. another build is just the node.. another build with zmq and maybe a few other things .. etc..
< miketwenty1>
Question about bitcoin builds and gitian builds, when you build from source you can put in build options/flags to exclude/include certain things like whether or not the wallet, UPnP, zmq.. are these build options baked into gitian builds to enable everything? If I for example wanted to do a gitian build and not build someone or include something do I have this flexibility?
< bitcoin-git>
[bitcoin] laanwj merged pull request #20520: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux (master...201127-pch) https://github.com/bitcoin/bitcoin/pull/20520
< bitcoin-git>
bitcoin/master a3186b6 Wladimir J. van der Laan: Merge #20520: depends: Do not force Precompiled Headers (PCH) for building...
< bitcoin-git>
bitcoin/master c82d15b Hennadii Stepanov: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux
< aj>
#proposedmeetingtopic bitcoin-util cli utility for 19937 (see also 14671 and 18573)
2020-12-02
< bitcoin-git>
[bitcoin] luke-jr opened pull request #20551: RPC/Net: Allow changing the connection_type for addnode onetry (master...rpc_onetry_conntype) https://github.com/bitcoin/bitcoin/pull/20551
< bitcoin-git>
[bitcoin] luke-jr closed pull request #12674: RPC: Support addnode onetry without making the connection priviliged (master...rpc_onetry_nonpriv) https://github.com/bitcoin/bitcoin/pull/12674
< bitcoin-git>
[bitcoin] hebasto opened pull request #20544: build: Do not repeat warning names in -Werror=... options (master...201202-werror) https://github.com/bitcoin/bitcoin/pull/20544
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20507: sync: print proper lock order location when double lock is detected (master...double_lock_print_location) https://github.com/bitcoin/bitcoin/pull/20507
< bitcoin-git>
bitcoin/master db058ef Vasil Dimov: sync: use HasReason() in double lock tests
< bitcoin-git>
bitcoin/master a21dc46 Vasil Dimov: sync: const-qualify the argument of double_lock_detected()
< bitcoin-git>
bitcoin/master 6d3689f Vasil Dimov: sync: print proper lock order location when double lock is detected
< jnewbery>
vasild: if you're still around, I have a question about addrv2 support negotiation. There seems to be a discrepency between the bip and the implementation in Bitcoin Core
< gleb>
So I switched the code to do sketch extensions instead. It's much less code, and the code complexity is now more aligned with general Bitcoin project complexity.
< gleb>
In practice, the implementation turned out to be too complicated on the Bitcoin Core p2p protocol side.
< cdecker>
If there's interest from miners to get access I can write up a faux-bitcoin-node that acts as a bridge between bitcoin p2p and the ln overlay relay network
< sipa>
i was hoping LN, because it's an inherently different situation than bitcoin's identityless P2P
< ariard>
sipa: define general ? if you mean for any bitcoin protocol without care of protocol designer I likely agree with you
< ariard>
michaelfolkson: note also that pinning doesn't only affect LN but also bitcoin protocol like vaults, DLC
< bitcoin-git>
[bitcoin] naumenkogs opened pull request #20539: Avoid rebucketing on restart when it's not necessary (master...2020-12-01-rebucket-asmap-fix) https://github.com/bitcoin/bitcoin/pull/20539
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20519: Handle rename failure in DumpMempool(...) by using the RenameOver(...) return value. Add [[nodiscard]] to RenameOver(...). (master...renameover-nodiscard) https://github.com/bitcoin/bitcoin/pull/20519
< bitcoin-git>
bitcoin/master ffd5e7a MarcoFalke: Merge #20519: Handle rename failure in DumpMempool(...) by using the Renam...
< bitcoin-git>
bitcoin/master ce9dd45 practicalswift: Add [[nodiscard]] to RenameOver(...)
< bitcoin-git>
bitcoin/master 9429a39 practicalswift: Handle rename failure in DumpMempool(...) by using RenameOver(...) return ...
< bitcoin-git>
[bitcoin] theStack opened pull request #20537: refactor: replace manual Satoshis-to-BTC conversions with FormatMoney() (master...20201129-use-formatmoney) https://github.com/bitcoin/bitcoin/pull/20537
2020-11-30
< bitcoin-git>
[bitcoin] achow101 opened pull request #20536: wallet: Error with "Transaction too large" if the funded tx will end up being too large after signing (master...fundtx-error-large-tx) https://github.com/bitcoin/bitcoin/pull/20536
< sipa>
seed.bitcoin.sipa.be may not even *have* a full node
< pinheadmz>
oh I see, so it still may not be the full node at bitcoin.sipa.be that we conenct to, but any one of the nodes returned in A records to the exit node, which thinks we are just resolving a single service by name
< sipa>
yes, because you can't do DNS resolving over Tor (that'd require a DNS implementation in bitcoin core, and route it over tor)
< sipa>
but from bitcoin core's perspective there is no such thing as A or AAAA or CNAME or whatever records or DNS involved
< pinheadmz>
actually im not getting anything from seed.bitcoin.sipa.be but I am from `dig dnsseed.bluematt.me`
< sipa>
doing so likely makes your OS's/ISP's resolver connect to the DNS seed server, but that's transparent from bitcoin core's perspective
< pinheadmz>
ah, TIL so there is no `dig bitcoin.sipa.de` or whatever. I always thought we use A records from the seed to bootstrap
< willcl_ark>
Agreed. I imagined Luke might be trying to grep bitcoin and bitcoin-gui repos at the same time, and using some small script to bolt together two git searches? Not familiar with git-grep-all tbh :)
< sipa>
i've never had a situation where "git grep" in the bitcoin repo wasn't fast enough
< willcl_ark>
luke-jr: I've been trying out ripgrep recently. It can handle multiple directories and seems to be pretty fast. e.g. `rg CTxDestination bitcoin*` will search all directories in current dir starting with bitcoin.
< miketwenty1>
hebasto: then maybe im not understanding something or something is failing silently on my side after the build is done.. in your inputs dir does it create the version file and the non version file? -> gitian-builder/inputs/bitcoin-win-unsigned.tar.gz