New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The "making 1.21-dev great again" plan #3349
Comments
Additional finding from #3260 that I forgot to mention: |
Hey Pat, |
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. |
What are the main goals of 1.21? Are we going to have SegWit addresses and CSV op code? I guess no taproot yet. |
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.
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. |
Currently there are several issues with the
1.21-dev
branch that block the CI and other testing efforts:crc32c
subtree needs updating to support non-linux ARM, reported herecontrib/devtools/security-check.py
does not supportarm64-darwin
, reported hereBecause 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
crc32c
subtree to bitcoin-core/crc32c-subtree@0bac72c4 - Update crc32c subtree #3374arm64-darwin
.Please let me know if there are any objections to this plan.
The text was updated successfully, but these errors were encountered: