Voting on Priority Projects for 27.0

[achow101]

Please leave your votes for project priorities for the next ~6 months (until the 27.0 feature freeze).

Project priorities are those which the frequent contributors to this project have voted on to have more focused review on until the next feature freeze (or until they are completed). They will become permanent topics in our weekly IRC meetings so that we can get updates on the progress of each project and determine the next step to move them forward.

Voting will close at the start of the IRC meeting on October 19th at 14:00 UTC. To vote, please leave a comment containing the three projects from the list below that you would like to be the priority projects. The priority projects will be the three with the most votes.

Voting is limited to those who are part of the bitcoin github organization. Comments in this issue from those outside of the organization will be ignored, and may be deleted. If you are not part of the organization and believe that you should be, please send me an email or message me on IRC.

The projects to vote on are:

• Multiprocess Multiprocess bitcoin #10102
• Silent payments BIP352 tracking issue #28536
• Package Relay Package Relay Project Tracking #27463
• Legacy wallet (BDB) removal Proposed Timeline for Legacy Wallet and BDB removal #20160
• Erlay Erlay Project Tracking #28646
• Cmake CMake-based build system tracking issue #28607
• Kernel Libbitcoinkernel Project Tracking #27587 (removed by request of the author)
• Logging Migration Severity-based logging -- parent PR #25203 (removed by request of the author)
• Stratum V2 [WIP] add a stratum v2 template provider #27854
• cluster mempool Proposal for a new mempool design #27677 (removed by request of the author)

[achow101]

• Legacy wallet removal
• Package relay
• Silent payments

[luke-jr]

• Stratum V2
• Cmake

[dergoegge]

• multiprocess
• package relay

[theStack]

• Silent payments
• Package relay
• Legacy wallet removal

[hebasto]

• Multiprocess
• Cmake
• Kernel
• Package Relay

EDIT: "Kernel" replaced with "Package Relay" after #28642 (comment).

[pinheadmz]

• legacy wallet removal
• silent payments
• stratumV2

[brunoerg]

• legacy wallet removal
• multiprocess
• package relay

[willcl-ark]

• cmake
• silent payments
• stratumv2

[TheCharlatan]

• cmake
• multiprocess
• legacy wallet removal

[instagibbs]

I can't actually tell which projects have active/committed champions for the next 6 months, aside from personally speaking to some.

That said...

• Package Relay
• Erlay (if there's a committed champion)

[stickies-v]

• kernel package relay
• cmake
• multiprocess

[ismaelsadeeq]

silent payment
package relay
kernel

[mzumsande]

• erlay
• package relay

[josibake]

• Silent payments
• Kernel
• Legacy wallet removal
• Package Relay

[aureleoules]

• Legacy Wallet Removal
• Silent Payments
• Package Relay

[jonatack]

Review is done on an ad-hoc and free choice basis for each reviewing contributor, and (I believe) merge decisions have historically taken rebase conflicts more or less into account. So if I understand correctly, this vote is primarily about the following process:

They will become permanent topics in our weekly IRC meetings

As the weekly IRC meetings were moved a few months ago to a time that doesn't work for me where I am currently located, severity-based logging can probably be removed from the voting. I do plan to propose improvements, as I think our logging can be more useful and reveal more issues.

I try to look at most of the merged code, and follow the context/conversations on the open pulls. That said, I'd like to become more active in reviewing these pre-merge, alongside regular reviewing in areas I happened to be looking deeper into:

• Stratum v2, provided the author is actively working on it and able to attend the weekly IRC meetings, otherwise Package Relay
• Kernel Silent Payments
• Multiprocess

Finally, it's good to re-read from time to time On Consensus and Humming in the IETF in thinking about how to arrive at rough consensus decisions with the best technical outcomes.

[jonatack]

https://github.com/red0bear this issue only affects people who perform regular, frequent review that is needed for technical progress. You can freely become one over time by doing consistent and helpful review on this project, which is generally much appreciated. You can also open a pull request to implement changes that you would like to propose. Some resources for both steps are here.

[murchandamus]

Package Relay
Legacy wallet (BDB) removal
Silent payments

[ajtowns]

• Package Relay
• Erlay
• Cmake / musig2 descriptors/psbt

Would be good to have a tracking issue for multiprocess if there's going to be progress on it?

[fjahr]

Package Relay
Kernel Multiprocess
Silent Payments

[TheCharlatan]

I'm a bit late to shutting down my own party, but I would like to get the kernel removed again from the list of potential priority projects. While I am prepared to continue working on it, the project is currently at a point where I don't anticipate it occupying much of the upcoming release cycle to complete its first stage. Since the second stage of the project is still not well defined, there is little point in making it a priority for the better half of the release cycle. Seeing the continued amount of enthusiasm for the project is great, but I would like to encourage those that voted for the kernel to change it to something else.

[w0xlt]

Silent Payments
CMake
Stratum V2

[glozow]

• Package relay
• Legacy wallet removal
• Multiprocess

[ccdle12]

This is just a note on the stratumv2 work as suggested by jonatack #27854 (comment)

Given that we've already implemented most (if not all) of the features, a six-month window for refactoring, adding a lot more tests and structuring the proposed changes in a way that is easier for contributors to review sounds doable to me.

And yep, both myself and other contributors involved with this project can definitely attend the weekly #bitcoin-core-dev IRC meetings to provide updates and field any questions.

[naumenkogs]

• erlay
• multiprocess
• package relay

[amitiuttarwar]

I'm most interested in reviewing:

• erlay

I think are cool and should be a priority (for merge conflicts, updates during meetings, etc.):

• package relay
• silent payments

[pablomartin4btc]

• Package Relay
• Erlay
• CMake

[vasild]

The initial idea of the priority projects was to not merge other PRs that are otherwise ready if they conflict with a priority project if that would slow down the priority project (unwanted rebase and re-review). But:

voting == "i'm aiming to review" [1]

this isnt a vote of "what would you like to see in bitcoin core" and more signaling "i will prioritise working on and reviewing x" [2]

"I want to not make them rebase" + "I will review" [3]

which projects have the most reviewer interest, so are likely to make the most progress, and are least likely to spend a long time unmerged, and hence will only cause minimal rebasing in conflicting PRs [4]

the priority projects help break the cyclic dependency in decisions of the form "i'd like to work/help on X, but only if sufficient other people think the same" [5]

one being "what should be priority" and another being "what will i actively contribute to" [6]

two different votes thing of "priority" and "review" ... for deciding the actual priority, I think having each person vote for 3 is still good [7]

Seems that the initial idea has evolved to two possible meanings:

1. I will personally work on that ("vote" is not the most appropriate word for that - "I vote that I will work on that" does not sound right. This is more expressing intent and aggregating people's intentions)

2. I think it would be nice to have that in 27.0 ("vote" is the right word for that)

So, what are we "voting for" here?

I am expressing intent to work on the following (mostly by review and testing):

• Package relay
• Erlay
• Cmake

I think it would be nice to have in 27.0:

• Silent payments
• Legacy wallet (BDB) removal
• Cmake

[darosior]

Signaling my intention to help with package relay (and related projects) as time permits. Don't have an opinion/vote on what other people should be doing.

[ajtowns]

The initial idea of the priority projects was to not merge other PRs that are otherwise ready if they conflict with a priority project if that would slow down the priority project (unwanted rebase and re-review).

FWIW, I'd still say that's what the effect of making a project a priority is; but you still want to pick the projects that are getting lots of prompt review, not ones that would be good, but no one is actually reviewing, so PRs aren't actually able to get merged quickly. It's also not like other PRs won't get merged, just that they'll tend to be the ones that get held up and need to be rebased more often. YMMV, just my opinion, etc.

[ariard]

speaking on my own only: erlay, cluster mempool and package relay (the p2p part)

[murchandamus]

Per the opening post, voting closed about three hours ago, @achow101 announced the final tally in the meeting:

achow101 10:03:
The final count for the voting is Package relay - 19, Silent payments - 11, Multiprocess - 9, Legacy wallet removal - 9, cmake - 8, erlay - 7 stratum v2 - 4

It seems to me that your vote would have not changed the outcome though: Cluster mempool was removed per request of the champion, Package Relay will be a priority project, and Erlay wouldn’t have made the top three even with your additional vote.

[achow101]

The priority projects are package relay, silent payments, and multiprocess.

[ariard]

i like multiprocess

[quinteiroh]

Hi everyone,

I really believe that´s important to advance with the Stratum V2. Especially after this recent situation with F2pool and the transaction censorship

https://www.nobsbitcoin.com/f2pool-is-filtering-transactions-from-ofac-sanctioned-address-report/

The owner admits on Twitter (he deleted the post after)

The original link was: https://twitter.com/satofishi/status/1727220109780136287