As some people already noticed,
ckTestBTC minter has been stopped andWe’re currently working on migrating the Bitcoin Testnet API from Testnet v3 to v4, which should be rolled out in approximatively 2 weeks if everything goes well.
Thank you for your understanding! 
Quick update: Work on the migration to testnet4 is ongoing but it will take a bit longer than we had hoped.
There won’t be any major changes during the Christmas season, so the roll-out is now expected to happen in early 2025.
Thanks for the update.
Omnity also aims to deploy testnet on testnet4 by January 2025 and hopes that support for testnet4 can go live quickly in 2025.
@juliansun , are you talking about deploying ord-indexer with testnet4 support?
@Buriburizaemon
Yes, our main goal is to test REE (How REE Unlocks Programmability for Bitcoin | Omnity Network) on Testnet4. REE depnds on ord-indexer, so we will also deploy ord-indexer on Testnet4.
Hi @cryptoschindler , @THLO
I’ve noticed that some code related to testnet4 has already been merged, so I’d like to know if there’s a launch date for testnet4.
The Omnity REE testnet currently has a target launch timeframe, and we need to decide whether to wait for testnet4 or implement a temporary solution ourselves.
Good observation!
We’re in the testing phase. We discovered that testnet4 has its own quirks, so the testing phase is taking a bit longer than anticipated. Internally, our plan is to launch the Bitcoin testnet canister synced to testnet4 by the end of this week.
However, it is no guaranteed that we will meet this deadline, that’s why I didn’t make any announcement so far. In any case, we expect to be able to launch the Bitcoin testnet canister (again) soon. I’ll keep you posted!
Another quick update: We decided to run a few more tests over the weekend and aim for a launch next week.
Good news: The Bitcoin testnet canister is now live again, fully synced to testnet4! 
Just to follow up, ckTESTBTC is also ready to use (after a full reset)
Vote: Rejected while no official response was provided Dfinity went ahead and voted to adopt.
Reason:
Hey @PaulLiu and @thlo and @manu could we get confirmation about proposal 135602 and the problem “Bitcoin canister has unfair prices” ?
Given the fact that there is no forum post linked to the proposal and the neuron used for submitting it was just created, and is not the usual Dfinity owned, I am inclined to reject it.
*Update:
While waiting on Dfinity, checked the BTC canister.
The last upgrade was executed on 2024-09-02 with proposal 132220. So I built it locally to confirm that the hash is indeed a match.
get_config we can see that currently we have the following set:
fees: This record specifies how many cycles must be attached when invoking the individual endpoints. More information about API fees can be found in the Bitcoin integration documentation." and then the “More info on api-fees-and-pricing” still doesn’t shine a light on anything specific to fees.
When looking at the proposal’s “solution”: to have the equivalent fees for the get_block_headers API as for the get_utxos.
We can see that for the given PROPOSAL_ARGS we have:
get_block_headers from current 0 to match get_utxos .
Still would like to have some more info on the unfair price issue. Thank you.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Hey @1eo just wanted to bring this to your attention as well.
Vote: Adopt
Reason: The get_block_headers fees, which are currently all set to 0, have been brought in line with the ones used for get_utxos API
I am voting with caution on this proposal and choosing to REJECT. The main reason is that the neuron is only 3 days old. There was no prior discussion with the community about changing the fee structure. While I don’t believe neuron age should be a strict gatekeeping factor, proposing significant changes—especially without prior proposals or engagement—requires community discussion. Additionally, a change of this magnitude should ideally go through testnet before being implemented on mainnet.
This proposal increases the fees for the following Bitcoin canister endpoints:
get_block_headers_cycles_per_ten_instructions: Increased from 0 to 10get_block_headers_base: Increased from 0 to 50_000_000get_block_headers_maximum: Increased from 0 to 10_000_000_000As stated in the proposal payload:
“The Bitcoin canister has unfair prices, causing different APIs to charge differently for the same amount of work.”
This change aims to standardize costs, ensuring fairness across APIs while also improving security by mitigating the risk of DoS attacks. Given these benefits, I support this proposal and vote to adopt it.
Vote: REJECT
There was no comment from DFINITY on why this change was happening and voted some time ago due to this.
DFINITY decided to adopt the proposal, most likely made by them on a new neuron (impossible to know the owner of the newly created neuron), but I am a bit disappointed that no clarifications were provided before voting. I understand that the questions were posted during the weekend and not everyone will check them then, but could have verified and checked the community’s opinion before voting.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Hi folks, thanks for your feedback. The reason we kept this low key was that there’s potentially a DOS attack involved with the wrong fees for bitcoin_get_block_headers.
This change posed a bit of a security issue as the bitcoin_get_block_headers fees were (incorrectly) set to 0, meaning that someone could DOS the bitcoin canister if they kept sending too many of these requests (recall that the bitcoin canister requires roughly the amount of cycles needed to execute the endpoint as payment).
We couldn’t really start an open discussion about this given the problem at hand, so we attempted to have a proposal which was trying to give some general idea (“making the fees more fair”) without directly revealing the underlying problem.
Thanks for the explanation. Doesn’t this justify executing the proposal under the security hotfix policy adopted by the NNS many years ago? Why wait 3 days to vote instead of DFINITY voting immediately? Also, why create a new, unknown, private neuron to submit this proposal? It would be good to know for future reference.
I think everyone agrees that we want fair fees, but there could have been a solid reason for the different fees. Even if the proposal is technically correct and seems to have logical and fair justification, it was impossible to gauge if the proposal would have caused a problem in some way without knowing why there was a problem to solve in the first place. I would have preferred to see DFINITY vote on this one immediately. Anyway, I think CodeGov made a reasonable choice, but I’m glad that DFINITY was in a position to make the final decision since you guys were the only folks who could know the background of the problem.
This proposal changes the configuration of the bitcoin canister, it’s not a code upgrade. I don’t think the current policy covers this case. There’s no way to make this proposal in a way that does not show what we change. Perhaps an amendment to the security policy is warranted.
Also, why create a new, unknown, private neuron to submit this proposal? It would be good to know for future reference.
Probably we could have used an already “known” neuron but I am not aware of any policy around it (to be clear, an engineer from my team submitted the proposal, we were perfectly aware of who and why internally). If it helps the community, we can certainly keep to “known” neurons in the future, but imo that should not be a requirement. The proposals ideally are self-contained and verifiable, no matter who submitted it (I understand this was not but I hope I covered why).
Ok that’s fair. I would still argue that DFINITY is free to vote with your own convictions on any proposal. If you know there is an attack vector that needs to be mitigated, then I see nothing wrong with casting your vote. An explanation for the proposal was provided in this proposal. The security policy justifies not having an explanation in the proposal. Hence, I think it would have been ok to vote immediately to mitigate the risk of the DOS attack. Just my two cents.