< angela>
Hello! :) I have been reading a lot about bitcoin recently and have been thoroughly moved! I want to start understanding and contributing to bitcoin-core. Can someone recommend good newbie contributor resources? Thanks
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22296: doc: Final merge of release notes snippets, mv to wiki (master...2106-doRel) https://github.com/bitcoin/bitcoin/pull/22296
< bitcoin-git>
bitcoin/master 398dd67 MarcoFalke: Merge bitcoin/bitcoin#22296: doc: Final merge of release notes snippets, m...
< bitcoin-git>
bitcoin/master fa09fd1 MarcoFalke: doc: Final merge of release notes snippets
< bitcoin-git>
[bitcoin] jonatack opened pull request #22292: bench, doc: benchmarking updates and fixups (master...benchmarking-updates) https://github.com/bitcoin/bitcoin/pull/22292
< bitcoin-git>
[bitcoin] ViralTaco opened pull request #22291: Added comment about narrow contract for Span(T* begin, T* end) ctor (master...master) https://github.com/bitcoin/bitcoin/pull/22291
< bitcoin-git>
[bitcoin] glozow opened pull request #22290: Package Mempool Submission with Package Fee-Bumping (master...package-mempool-accept) https://github.com/bitcoin/bitcoin/pull/22290
< bitcoin-git>
[bitcoin] adriansmares opened pull request #22288: Resolve Tor control plane address (master...feature/tor-control-dns-resolve) https://github.com/bitcoin/bitcoin/pull/22288
< bitcoin-git>
[bitcoin] hebasto reopened pull request #22287: build: Avoid fcntl64@GLIBC_2.28 symbol when --enable-glibc-back-compat (master...210619-fcntl) https://github.com/bitcoin/bitcoin/pull/22287
< bitcoin-git>
[bitcoin] hebasto closed pull request #22287: build: Avoid fcntl64@GLIBC_2.28 symbol when --enable-glibc-back-compat (master...210619-fcntl) https://github.com/bitcoin/bitcoin/pull/22287
< bitcoin-git>
[bitcoin] hebasto opened pull request #22287: build: Avoid fcntl64@GLIBC_2.28 symbol when --enable-glibc-back-compat (master...210619-fcntl) https://github.com/bitcoin/bitcoin/pull/22287
2021-06-19
< kittywhiskers>
i think the idea of having a refactor where all references to bitcoin in filenames are replaced with core and all mentions of Bitcoin in the source lead back to a static variable is worth considering
< kittywhiskers>
similar to the PR that unified all uses of BTC across the codebase, now that with the word Bitcoin itself
< kittywhiskers>
would a PR that tries to unify all instances of the word "Bitcoin" be welcome?
< kittywhiskers>
i did some preliminary work on getting bitcoin core to build using cmake, like how monero does it
< bitcoin-git>
[bitcoin] whitslack opened pull request #22285: contrib/init: (OpenRC) use -startupnotify to wait for startup completion (master...openrc-startupnotify) https://github.com/bitcoin/bitcoin/pull/22285
< bitcoin-git>
[bitcoin] jonatack opened pull request #22284: p2p, refactor: performance improvements to ProtectEvictionCandidatesByRatio() (master...ProtectEvictionCandidatesByRatio-perf-enhancements) https://github.com/bitcoin/bitcoin/pull/22284
< bitcoin-git>
[bitcoin] dgoncharov opened pull request #22283: build: Replace $(AT) with .SILENCE. (master...replace_AT_with_dotsilence) https://github.com/bitcoin/bitcoin/pull/22283
< bitcoin-git>
[bitcoin] klementtan opened pull request #22282: refactor: CheckFinalTx pass by reference instead of ptr (master...CheckFinalTx_ptr_to_ref) https://github.com/bitcoin/bitcoin/pull/22282
< bitcoin-git>
[bitcoin] hebasto opened pull request #22281: build: Avoid @GLIBC_2.29 libm symbols when --enable-glibc-back-compat (master...210619-lm) https://github.com/bitcoin/bitcoin/pull/22281
2021-06-18
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22252 | policy: Trim Packages when transaction with same txid exists in mempool by glozow · Pull Request #22252 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/21329 | descriptor wallet: Cache last hardened xpub and use in normalized descriptors by achow101 · Pull Request #21329 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22154 | Add OutputType::BECH32M and related wallet support for fetching bech32m addresses by achow101 · Pull Request #22154 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22154 | Add OutputType::BECH32M and related wallet support for fetching bech32m addresses by achow101 · Pull Request #22154 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/21329 | descriptor wallet: Cache last hardened xpub and use in normalized descriptors by achow101 · Pull Request #21329 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22154 | Add OutputType::BECH32M and related wallet support for fetching bech32m addresses by achow101 · Pull Request #22154 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22154 | Add OutputType::BECH32M and related wallet support for fetching bech32m addresses by achow101 · Pull Request #22154 · bitcoin/bitcoin · GitHub
< vasild>
I am not sure either, but it just does not seem right if a user has bothered to setup I2P proxy and configure bitcoin core to use it and to have 0 i2p connections (same for tor)
< vasild>
laanwj: "it's not possible to not bind a P2P port at all" -- https://github.com/bitcoin/bitcoin/pull/20234 is not supposed to change this behavior which is - no, you can't specify "don't bind at all" using -bind=... if -bind is not given then we bind on 0.0.0.0, if -bind=foo is given then we bind on foo
< vasild>
and also I did not want to turn the bitcoin doc i2p.md into "how to install and configure i2p router", which obviously belongs to that i2p router docs
< vasild>
laanwj: "~monthly segfaults" -- I hope you mean i2pd, not bitcoin core
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22249: test: kill process group to avoid dangling processes when using `--failfast` (master...test_kill_process_group) https://github.com/bitcoin/bitcoin/pull/22249
< bitcoin-git>
bitcoin/master 0844084 MarcoFalke: Merge bitcoin/bitcoin#22249: test: kill process group to avoid dangling pr...
< bitcoin-git>
bitcoin/master 451b96f S3RK: test: kill process group to avoid dangling processes
< bitcoin-git>
[bitcoin] glozow reopened pull request #22253: validation: distinguish between same tx and same-nonwitness-data tx in mempool (master...2021-06-same-txid-diff-wtxid) https://github.com/bitcoin/bitcoin/pull/22253
< bitcoin-git>
[bitcoin] glozow closed pull request #22253: validation: distinguish between same tx and same-nonwitness-data tx in mempool (master...2021-06-same-txid-diff-wtxid) https://github.com/bitcoin/bitcoin/pull/22253
< michaelfolkson>
amiti: My two cents. I don't think you could have done any more to ensure everyone was aware of the PR and I can see why you're frustrated. A Bitcoin Core PR review club, bringing it up in P2P meeting(s), bringing it up in Core dev meeting, mailing list post etc
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22277: test: Properly set BIP34 height in CreateNewBlock_validity unit test (master...2106-test34) https://github.com/bitcoin/bitcoin/pull/22277
< amiti>
“I wasn't aware of your work before yesterday. I think late concerns are normal annoyance in software development, not specific to Bitcoin Core or decentralized projects (I worked 10 years in Oracle, I know!). It is annoying, but being late does not make the concerns automatically less valid.“ - I’m not suggesting that being late means the concerns are invalid. I am asking how we can pause to reflect on the disconnect.
< bitcoin-git>
[bitcoin] sipa opened pull request #22275: A few follow-ups for taproot signing (master...202106_taproot_sign_followup) https://github.com/bitcoin/bitcoin/pull/22275
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #22274: This will be implemented into bitcoin core at one point, with or without you.. your choice. (master...master) https://github.com/bitcoin/bitcoin/pull/22274
< bitcoin-git>
[bitcoin] steffanjensen opened pull request #22274: This will be implemented into bitcoin core at one point, with or without you.. your choice. (master...master) https://github.com/bitcoin/bitcoin/pull/22274
< schmidty>
ariard: Im happy to help planning. Some light discussions with Advancing Bitcoin about piggybacking there. But dates getting moved.
< bitcoin-git>
[bitcoin] steffanjensen opened pull request #22273: the banks and bitcon shills don't want this update (master...master) https://github.com/bitcoin/bitcoin/pull/22273
< laanwj>
so there are still plenty of PRs that can be seen as a feature tagged for 22.0, many close to being mergable (just need a bit more review), https://github.com/bitcoin/bitcoin/milestone/47
< roconnor>
michaelfolkson: Surely Bitcoin Core can pay to any segwit address of any version? That's the whole point of having forward compatable addresses.
< sipa>
i believe that policy wouldn't affect any bitcoin core versions in the past or those with the proposed change
< vasild>
you mean for the first "never send to anybody" -- I don't object the research, assume no such one exists now, but is it safe to assume that no such one would exist in the future? As for the second type - "Or send those messages occasionally" -- bitcoin core is such.
< vasild>
concern can be split in 2 sub-concerns: 1. these changes (extensions) to the protocol are done without a new BIP or modifying existent ones and 2. even if with BIP, on the technical level, I think assuming that if a node sends one of getaddr,addr,addrv2,sendaddrv2 then they participate in address relay is wrong, some examples: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-862312851
< vasild>
amiti: "In regards to the path forward for #21528 & #22245, it seems like the concerns are all focusing specifically on SENDADDRV2 and the wording of that specific bip" -- no, that's not the case. My biggest concern is changing the meaning of getaddr, addr, addrv2 (and sendaddrv2 if 22245 is considered). I explained that in https://github.com/bitcoin/bitcoin/pull/22245#issuecomment-862539375. My
< vasild>
amiti: "why are these approach concerns only being raised now?" I wasn't aware of your work before yesterday. I think late concerns are normal annoyance in software development, not specific to Bitcoin Core or decentralized projects (I worked 10 years in Oracle, I know!). In the same way you seem to be unaware of previous attempts to fix the black holdes problem and explicit signaling for address
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22120: test: p2p_invalid_block: Check that a block rejected due to too-new tim… (master...qa_timetoonew_retry) https://github.com/bitcoin/bitcoin/pull/22120
< bitcoin-git>
bitcoin/master dd24567 MarcoFalke: Merge bitcoin/bitcoin#22120: test: p2p_invalid_block: Check that a block r...
< bitcoin-git>
bitcoin/master 754e802 Luke Dashjr: test: check rejected future block later accepted
< bitcoin-git>
[bitcoin] jamesob opened pull request #22263: refactor: wrap CCoinsViewCursor in unique_ptr (master...2021-06-cursor-unique-ptr) https://github.com/bitcoin/bitcoin/pull/22263
2021-06-16
< bitcoin-git>
[bitcoin] hebasto reopened pull request #19882: depends: Export variables from make to environment explicitly (master...200905-build) https://github.com/bitcoin/bitcoin/pull/19882
< michaelfolkson>
hiii: #bitcoin
< michaelfolkson>
hiii: "Bitcoin Core development discussion and commit log"
< hiii>
Hi, is this the main bitcoin dev channel?
< amiti>
so, if 21528 only used ADDR, ADDRV2, GETADDR to indicate "interest in addr relay", then bitcoin core nodes wouldn't initiate any of those to outbound block-relay-only connections. but nodes who have started up in blocks-only mode would initiate a GETADDR to their outbound peers.
< amiti>
understanding was the biggest concern was about compatibility for other clients, so I wrote to the mailing list and researched / opened issues in every other bitcoin client I could find. I’ve additionally brought up these changes at a P2P meeting in early April and then again this week. I understand that time zones are hard and that not everyone can attend the meetings, but I’d hope the logs would be read and concerns to
< amiti>
To review the context of this work: I opened #21528 almost 3 months ago, and soon after brought it up at the weekly bitcoin-core-dev meeting to seek approach feedback. A lot of the concerns that are now being voiced (should there be a separate flag, could we do redundant relay for blackholes rather than selective, what are the implications for other clients) have already been discussed in relation to these changes. My
< WS_black22>
i got my old wallet.dat i need to imported to the new bitcoin core, how can i do this? i dont see the replasment of wallet.dat,
< bitcoin-git>
[bitcoin] jnewbery opened pull request #22261: [p2p/mempool] Two small fixes to node broadcast logic (master...2021-06-broadcast-fixes) https://github.com/bitcoin/bitcoin/pull/22261
< bitcoin-git>
[bitcoin] Sjors opened pull request #22260: Make bech32m the default, except where needed. Update GUI checkbox. (master...2021/06/bech32_gui) https://github.com/bitcoin/bitcoin/pull/22260
< jnewbery>
laanwj: I'd suggest re-reading the irc meeting logs from when this was discussed, both in the main Bitcoin Core meeting, and in the p2p meeting. You commented in the first meeting in March, so you were aware that this was a proposal.
< vasild>
hmm, actually laanwj is right that 21528 is not related to just bitcoin core - it changes the semantics of getaddr, addr, addrv2 and sendaddrv2. I guess that warrants a BIP.
< jnewbery>
laanwj: this has been discussed in many venues already. It's been raised on the mailing list, discussed in bitcoin core irc and p2p irc meetings, amiti has even done a survey of every other common node implementation to make sure it doesn't break them: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
< jnewbery>
a pre-bip155 bitcoin core node will send a getaddr, which implies that it wants to receive addresses
< vasild>
anyway, if sendaddrv2 signalled preference to receive unrequested address messages, then bitcoin core-pre-bip155 do not want to receive unrequested address messages?
< vasild>
But I think the bigger argument here is 22245+21528 and changing the semantic of sendaddrv2 in order to tweak address relay and attempt to fix the black holes problem. But would even that fix it? Some scenarios where it will not: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-862312851
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22258: build: Disable deprecated-copy warning only when external warnings are enabled (master...2106-buildEnableWarnDeprecatedCopy) https://github.com/bitcoin/bitcoin/pull/22258