< bitcoin-git>
[bitcoin] meshcollider merged pull request #17458: Refactor OutputGroup effective value calculations and filtering to occur within the struct (master...cleanup-outputgroups) https://github.com/bitcoin/bitcoin/pull/17458
< bitcoin-git>
bitcoin/master f269165 Samuel Dobson: Merge #17458: Refactor OutputGroup effective value calculations and filter...
< bitcoin-git>
bitcoin/master 9adc2f8 Andrew Chow: Refactor OutputGroups to handle effective values, fees, and filtering
< bitcoin-git>
bitcoin/master 7d07e86 Andrew Chow: Use real value when calculating OutputGroup value
< gribble>
https://github.com/bitcoin/bitcoin/issues/17458 | Refactor OutputGroup effective value calculations and filtering to occur within the struct by achow101 · Pull Request #17458 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/14582 | wallet: always do avoid partial spends if fees are within a specified range by kallewoof · Pull Request #14582 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] laanwj merged pull request #17204: wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code (sipa) (master...201910_1negate_rebase) https://github.com/bitcoin/bitcoin/pull/17204
< bitcoin-git>
bitcoin/master 4d4bd5e Wladimir J. van der Laan: Merge #17204: wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in s...
< bitcoin-git>
bitcoin/master e629d07 Pieter Wuille: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code
< 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
< michaelfolkson>
It seems to me that the experiment has been very short. I will try to find out if there is genuine interest in contributing, reviewing on that Bitcoin Design Slack
< wumpus>
luke-jr_: that seems another issue, would make it imopssible to move bitcoin itself there
< luke-jr_>
also, while it used to be possible to have multiple forks under the same org (so bitcoin-core/gui and bitcoin-core/foobar), GitHub seems to have removed that possibility too
< wumpus>
then again if a lot of people feel like it would be easier if it's a bitcoin/bitcoin fork we could try asking github
< jnewbery>
if we delete bitcoin-core/gui and then recreate it as a fork of bitcoin/bitcoin, you'd be able to
< jnewbery>
wumpus: if you push a branch to <developer>/bitcoin , then you can't open a PR against bitcoin-core/gui because they don't share a common fork in gitub
< wumpus>
he wants to inherit it from bitcoin/bitcoin I think instead of having it as completely disparate repo
< luke-jr_>
Can we recreate bitcoin-core/gui so GitHub will let us do PRs from the same <user>/bitcoin forks instead of making a new remote for everyone?
< wumpus>
#topic Can we recreate bitcoin-core/gui (Luke-jr)
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] hebasto opened pull request #19710: bench: Prevent thread oversubscription and decreases the variance of result values (master...200813-var) https://github.com/bitcoin/bitcoin/pull/19710
< bitcoin-git>
[bitcoin] laanwj merged pull request #19070: p2p: Signal support for compact block filters with NODE_COMPACT_FILTERS (master...2020-05-node-compact-filters) https://github.com/bitcoin/bitcoin/pull/19070
< bitcoin-git>
bitcoin/master f5c003d Jim Posen: [test] Add test for NODE_COMPACT_FILTER.
< bitcoin-git>
bitcoin/master 132b30d Jim Posen: [net] Signal NODE_COMPACT_FILTERS if we're serving compact filters.
< bitcoin-git>
bitcoin/master b3fbc94 John Newbery: Apply cfilters review fixups
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13360: [Policy] Reject SIGHASH_SINGLE with output out of bound (master...insecure_single) https://github.com/bitcoin/bitcoin/pull/13360
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #16548: Make the global flag *fDiscover* an instance variable of CConnman (master...bitcoin_issue_14210) https://github.com/bitcoin/bitcoin/pull/16548
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19707: net: Remove unused conn_type default arg in OpenNetworkConnection (master...1908-netDefault) https://github.com/bitcoin/bitcoin/pull/19707
< bitcoin-git>
[bitcoin] meshcollider merged pull request #18654: rpc: separate bumpfee's psbt creation function into psbtbumpfee (master...psbtbumpfee) https://github.com/bitcoin/bitcoin/pull/18654
< bitcoin-git>
bitcoin/master 79d6332 Andrew Chow: moveonly: Fix indentation in bumpfee RPC
< bitcoin-git>
[bitcoin] laanwj merged pull request #19658: [rpc] Allow RPC to fetch all addrman records and add records to addrman (master...2020-07-addrman-get) https://github.com/bitcoin/bitcoin/pull/19658
< jonatack>
review beg for #19455 (which arguably should have been in the last release with -generate to make multiple bitcoin command line tutorials work again for users), as requested by ajonas and MarcoFalke. It's a quick review with complete test coverage.
< luke-jr>
#proposedmeetingtopic Can we recreate bitcoin-core/gui so GitHub will let us do PRs from the same <user>/bitcoin forks instead of making a new remote for everyone?
< gribble>
https://github.com/bitcoin/bitcoin/issues/19528 | rpc: Assert that RPCArg names are equal to CRPCCommand ones (misc) by MarcoFalke · Pull Request #19528 · bitcoin/bitcoin · GitHub
< phantomcircuit>
adiabat, no even then you can trivially detect that it's a bitcoin node
< phantomcircuit>
without significantly delaying block relay, it's impossible to hide that you're running a bitcoin node from the network operator
< phantomcircuit>
adiabat, it has to be easy to identify a bitcoin node that's listening, and it's inherently going to be easy to identify a bitcoin node based on the network traffic
< jonatack>
i'm running bitcoin locally with nLastBlockTime and nLastTXTime added to getpeerinfo for my peer connections dashboard
< troygiorshev>
certainly is difficult (i imagine) to distinguish between "this is a really clean PR and I really have no comments on it, it's RFM" and "I've done my best but I'm not familiar enough with bitcoin to really review this"
< aj>
adiabat: i think the reason not to do other ports was to prevent bitcoin nodes being used as a primitive botnet that'll start connecting to arbitrary services (or to be mistaken for being part of a botnet if someone spams military.gov's rsh port as a thing to connect to for bitcoin p2p maybe. never been able to judge if that makes much sense these days
< jnewbery>
sdaftuar: do you know whether there are nodes that disconnect on unknown message types? Bitcoin Core just drops them (which I think is the only sensible behaviour)
< ariard>
sdaftuar: I think that's good it was unclear between matt and I on bip339 implemn in rust-bitcoin about why 339 bumps both protocol version and wtxid-relay
< sdaftuar>
however, i think we need to make sure software on the network knows to ignore unknown messages pre-verack to make this a possibility. bitcoin core historically has disallowed unknown messages pre-verack
< ajonas>
Ok. A few months ago, I was reading over https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-07-priorities/, which articulates some possibilities for how to better coordinate review. Since then, I've been experimenting with asking for reviews directly. (This was also the motivation of #18949).
< * fanquake>
wonders if he should attend to achieve back to back to back bitcoin meetings 🤔
< bitcoin-git>
[bitcoin] naumenkogs opened pull request #19697: Minor improvements on ADDR caching (master...2020-08-addr-cache-follow-up) https://github.com/bitcoin/bitcoin/pull/19697
< gribble>
https://github.com/bitcoin/bitcoin/issues/19070 | p2p: Signal support for compact block filters with NODE_COMPACT_FILTERS by jnewbery · Pull Request #19070 · bitcoin/bitcoin · GitHub
< jonasschnelli>
can someone unban me in #bitcoin #bitcoin-dev?
< bitcoin-git>
[bitcoin] sipa opened pull request #19695: [do not merge] Test impact of secp256k1 endianness detection change (master...202008_test_appveyer_secp256k1) https://github.com/bitcoin/bitcoin/pull/19695
< bitcoin-git>
[bitcoin] laanwj merged pull request #19596: Deduplicate parent txid loop of requested transactions and missing parents of orphan transactions (master...2020-07-dedup-inputs) https://github.com/bitcoin/bitcoin/pull/19596
< bitcoin-git>
bitcoin/master 85fa648 Wladimir J. van der Laan: Merge #19596: Deduplicate parent txid loop of requested transactions and m...
< gribble>
https://github.com/bitcoin/bitcoin/issues/19596 | Deduplicate parent txid loop of requested transactions and missing parents of orphan transactions by sdaftuar · Pull Request #19596 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] achow101 closed pull request #16910: wallet: reduce loading time by using unordered maps (master...reduce-wallet-load) https://github.com/bitcoin/bitcoin/pull/16910
< bitcoin-git>
[bitcoin] instagibbs closed pull request #18245: Test some transaction creation with non-empty fee estimator (master...test_est_txn) https://github.com/bitcoin/bitcoin/pull/18245
< bitcoin-git>
[bitcoin] instagibbs closed pull request #19269: CKey::Sign : switch test arg to explicit additional entropy argument (master...sign_entropy) https://github.com/bitcoin/bitcoin/pull/19269
< bitcoin-git>
[bitcoin] fanquake merged 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/master 6d5a9fe fanquake: Merge #19605: doc: set CC_FOR_BUILD when building on OpenBSD
< bitcoin-git>
bitcoin/master 01cd24c fanquake: doc: set CC_FOR_BUILD when building on OpenBSD
< gribble>
https://github.com/bitcoin/bitcoin/issues/19444 | test: Remove cached directories and associated script blocks from appveyor config by sipsorcery · Pull Request #19444 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] laanwj merged pull request #19631: test: Wait for 'cmpctblock' in p2p_compactblocks when it is expected (master...2020-07-receive_block_announcment) https://github.com/bitcoin/bitcoin/pull/19631
< bitcoin-git>
bitcoin/master be11f94 Wladimir J. van der Laan: Merge #19631: test: Wait for 'cmpctblock' in p2p_compactblocks when it is ...
< bitcoin-git>
bitcoin/master 9e165d0 Ben Woosley: test: Wait for 'cmpctblock' in p2p_compactblocks when it is expected
< bitcoin-git>
[bitcoin] jonatack closed 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
< bitcoin-git>
[bitcoin] sanjaykdragon closed pull request #19586: test: moved from percent format to proper format for consistency (master...master) https://github.com/bitcoin/bitcoin/pull/19586
< bitcoin-git>
[bitcoin] theStack opened pull request #19687: refactor: make EncodeBase{32,64} consume Spans (master...20200807-util-make-encode-base3264-consume-spans) https://github.com/bitcoin/bitcoin/pull/19687
< gwillen>
I believe it is the same library, it just moved when it was finally standardized to a new name. But I agree it may not be suitable for inclusion into Bitcoin for real for now.
< Kiminuo>
gwillen, I don't think <experimental/filesystem> is way to go. It will make it more complex and it does not sound good to use something experimental in Bitcoin.
< gwillen>
I assume the compiler CI uses is the benchmark for "minimum supported to build bitcoin with"?