< bitcoin-git>
[bitcoin] fanquake opened pull request #20939: build: fix RELOC_SECTION security check for bitcoin-util (master...fix_bitcoin_util_reloc_section) https://github.com/bitcoin/bitcoin/pull/20939
< bitcoin-git>
[bitcoin] fanquake opened pull request #20938: Fix linking against -latomic when building for riscv (master...fix_riscv_atomic_usage) https://github.com/bitcoin/bitcoin/pull/20938
2021-01-14
< bitcoin-git>
[bitcoin] dongcarl opened pull request #20937: guix: Make nsis reproducible by respecting SOURCE-DATE-EPOCH (master...2021-01-nsis-sde-reproducibility) https://github.com/bitcoin/bitcoin/pull/20937
< gribble>
https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/20715 | util: Add ArgsManager::GetCommand() and use it in bitcoin-wallet by MarcoFalke · Pull Request #20715 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/0.21 66e6742 Wladimir J. van der Laan: doc: Move 0.21.0 release notes from wiki
< wumpus>
why call a non-existing RPC at all :) it's only still there as a service to (human) users following old wiki pages with bitcoin-cli, and who tend to care more about the English message than the return code
< sdaftuar>
and i am opposed to creating such a group that is somehow affiliated with the bitcoin core software
< sipa>
i think it's more likely that someone reads this and wonders why it's mentioned at all and what bitcoin core's role in this is, than that it would affect their upgrade behavior
< sipa>
bitcoin core's developers and maintainers shouldn't be using the release notes to further the goal of activation
< wumpus>
harding: that's good to know! i was afraid it would make a link to the bitcoin/bitcoin issue of the same number that would be bad, but yes that seems acceptable really
< wumpus>
harding: hi! for 0.21.0 we have a new kind of PR which comes from the bitcoin-core/gui repository, I've used the syntax "gui/#xxxx" to refer to these, if we want these to point to the right repository we'll need to update the link conversion
< vasild>
MarcoFalke: so you decide to ban torv3.onion, do "setban torv3.onion add". The ban is effective and works. 2 days later bitcoin core is restarted. The ban is lost, silently.
< wumpus>
I did use the gui#1234 convention in the release notes, likely we need to update the bitcoin-core.org HTML-izing plugin as well to recognize these and generate valid links to them
< MarcoFalke>
so you can do title.startswith('Merge bitcoin-core/gui#')
< MarcoFalke>
the merge commits start with "bitcoin-core/gui#123 remove foobar"
< wumpus>
norisgOG_: #bitcoin please, this channel is for development ony
< norisgOG_>
Hello all I have a question concering signatures in bitcoin, where in the transaction can I see which HASH_Type I have to use to calculate the transaction hash ?
< bitcoin-git>
[bitcoin] jnewbery opened pull request #20925: RFC: Move Peer and PeerManagerImpl to separate header (master...2021-01-peermanimplh) https://github.com/bitcoin/bitcoin/pull/20925
< wumpus>
darosior: invited you to the "frequent contributors" group for bitcoin and bitcoin-core orgs (this is not currently a requirement for editing the wiki but will likely become so)
< bitcoin-git>
[bitcoin] laanwj merged pull request #19935: Move SaltedHashers to separate file and add some new ones (master...mv-saltedhash) https://github.com/bitcoin/bitcoin/pull/19935
< bitcoin-git>
bitcoin/master 281fd1a Andrew Chow: Replace KeyIDHasher with SaltedSipHasher
< bitcoin-git>
bitcoin/master 95e61c1 Andrew Chow: Move Hashers to util/hasher.{cpp/h}
< bitcoin-git>
bitcoin/master 210b693 Andrew Chow: Add generic SaltedSipHasher
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20915: fuzz: Fail if message type is not fuzzed (master...2101-fuzzFailMsgType) https://github.com/bitcoin/bitcoin/pull/20915
< jonatack>
let's meet at bitcoin beach for the p2p meetings
< ariard>
to be back on the question "should bitcoin core relay addrs to software sending these messages?" _currently_ we don't accept addr msgs from outbound-block-relay peers so why it's worsening the black-hole problem?
< jnewbery>
It also helps with https://github.com/bitcoin/bitcoin/issues/19398, which is gradually moving data into the Peer struct. Having that only declared internally in net_processing.cpp reduces header churn
< sipa>
i can understand someone spamming a bitcoin address, or people confusing pull request to be something they need to get the source code... but this?
< bitcoin-git>
[gui] hebasto closed pull request #174: refactor: No need to implement index for non-hierarchical models (master...210102-index) https://github.com/bitcoin-core/gui/pull/174
< bitcoin-git>
[bitcoin] fanquake closed pull request #20849: net: disconnect peers by address without using a subnet (master...disconnect_by_subnet_fix) https://github.com/bitcoin/bitcoin/pull/20849
< bitcoin-git>
[bitcoin] glozow opened pull request #20895: p2p: mildly discourage peers that violate feefilter (master...p2p-feefilter-violations) https://github.com/bitcoin/bitcoin/pull/20895
< bitcoin-git>
[gui] jonatack opened pull request #179: gui: add direction and type columns to peers window (master...add-peers-dir-and-type-columns) https://github.com/bitcoin-core/gui/pull/179
< jamesob>
(veering off topic) what's the easiest way for non-technical end users to enable that; just editing bitcoin.conf?
< jamesob>
bitcoin-qt doesn't start the RPC server by default? I didn't see anything in the GUI configuration for it, so I assume it did it by default
< jamesob>
running bitcoin-qt, can access RPC via the console view, but oh, can't see *8332 in lsof
< sipa>
don't have -server=0 or running bitcoin-qt?
< jamesob>
I don't think so - I'm `ls`ing the datadir and seeing debug.log/bitcoin.conf I expect, but no cookie file