The "making 1.21-dev great again" plan

[patricklodder]

Currently there are several issues with the 1.21-dev branch that block the CI and other testing efforts:

1. The macOs Native CI job needs to be converted to arm64 because Cirrus no longer supports Intel Mac native builds - reported here
2. Newer boost versions cause several issues on x86_64 linux and ARM macOS reported here and here
3. The crc32c subtree needs updating to support non-linux ARM, reported here
4. Porting build: bdb detection and configuration fixes for macOs/brew #3308 will fix bdb5 inclusion for mac in the same way it did for 1.14.7-dev
5. secp256k1 subtree needs an update because that has evolved to be more stable now, and I've seen the occasional unit test error in the wild on the current bitcoin-core/secp256k1@3967d96 we have
6. contrib/devtools/security-check.py does not support arm64-darwin, reported here

Because at least 1, 2 and 3 needs to be done to get a working macOS native CI, I think we should just disable that CI job for the initial steps of...

... the plan

• 1. Disable macOS Native CI - ci: disable macOs native task #3350
• 2a. Update crc32c subtree to bitcoin-core/crc32c-subtree@0bac72c4 - Update crc32c subtree #3374
• 2b. Cherry-pick a32eb26 from 1.14.7-dev and fix configure.ac brew bdb selection - build: fix bdb detection with macOs/brew #3375
• 2c. Cherry-pick bitcoin/bitcoin@058eb69 to fix boost 1.82 compatibility - Fix boost compatibility until 1.82 #3376
• 3. Enable macOS Native CI as an arm64 host
• 4a. Update the boost pinned dependency to 1.82
• 4b. Update secp256k1 to v0.4.0 (because this has a windows symbol fix that will be important later on)
• 4c. Update devtools checks (security, symbols) to support arm64-darwin.

Please let me know if there are any objections to this plan.

[patricklodder]

Additional finding from #3260 that I forgot to mention: contrib/devtools/security-check.py does not support arm64-darwin at this time, so we will incur some tech debt until we port in fixes from bitcoin/bitcoin. I'll add "updating devtools checks to support arm64" as an additional item under 4.

[JunsenD]

Hey Pat,
thanks for the contribution.
I am just wondering is possible dogecoin could have the same feature EIP-4844 (sharding) as TPS enhancement in the future plan?

[patricklodder]

Not in that exact form (we have Bitcoin script, not EVM) but you can probably hack together optimistic rollups today (but I wouldn't recommend it, it will be very hard to do securely.) However, if the Dogecoin network wants to adopt taproot at some point, things like TapRet and BitVM will become possible, permissionlessly. And people have only just started to look at the potential application of rollups using taproot - it's an interesting space to watch right now.

[JunsenD]

Not in that exact form (we have Bitcoin script, not EVM) but you can probably hack together optimistic rollups today (but I wouldn't recommend it, it will be very hard to do securely.) However, if the Dogecoin network wants to adopt taproot at some point, things like TapRet and BitVM will become possible, permissionlessly. And people have only just started to look at the potential application of rollups using taproot - it's an interesting space to watch right now.

BitVM is an interesting topic and dogecoin networks would explode if that being implement.
I am not sure what X is doing right now, ppl discuss a lot X will onboard doge later.
In your opinion, how does dogecoin network react later?

[cedricfung]

What are the main goals of 1.21? Are we going to have SegWit addresses and CSV op code? I guess no taproot yet.

[patricklodder]

What are the main goals of 1.21?

The goal is updating the codebase safely to a point where we can propose protocol improvements without being scared of unforeseen consequences, like happened with 1.14's CLTV softfork. Basically, creating a baseline from which we can work linearly from there on out.

Are we going to have SegWit addresses and CSV op code?

1.21.0 should prepare for at least CSV and hopefully segwit in a slightly modified/optimized form, but do note that in earlier discussions, devs agreed that actually proposing activation for these should be done in a follow-up release, making sure that we have a 1-on-1 compatibility with the current protocol first, as the 1.21 code has significantly evolved vs 1.14. I also think today that doing this is the way to go, but am happy to discuss if anyone has a different opinion.