Activate Taproot #244
Activate Taproot #244
Conversation
Activate Taproot
|
Hello @SogobiNapiasi, thank you for your contribution on this to activate Taproot & welcome to the DGB Github. The activation window seems perfectly reasonable and should work. Have you ran any test simulations of the soft fork activation on Testnet or Regtest? Have you ran the function tests at all? I believe we still have some of the taproot python tests deactivated. Would be great to fix them and run them before an activation. Testrunner.py was commented out here: digibyte/test/functional/test_runner.py Lines 115 to 116 in 22528bf The main test is here: https://github.com/DigiByte-Core/digibyte/blob/develop/test/functional/feature_taproot.py I think we should encourage a broader community discussion on taproot, get more peoples input. |
|
Hasn't anyone payed attention to how much of a mess taproot made for Bitcoin? Ordinals are hugely wasteful and it's just one way taproot can be exploited. |
What about the potential use cases that would open up for DigiByte with this implemented? |
|
I do share some of @mctrivia concerns about taproot. In my opinion, Taproot activation should not occur in the 8.22 final release. It should be considered after 8.22 is out by the community in another future release. There are 100s of thousands of code line changes in 8.22. It is by far the biggest release we have ever done. In the future DGB should split up releases into smaller chunks. If there are any issues with taproot on the main net it will be very hard to troubleshoot along with all the other changes already in 8.22. As for the merits of taproot, I think that can be debated at a later point for the pro's and cons. I think the discussion should be should taproot even be in a final 8.22 release since we are so close to the release, not necessarily if taproot should be added right now. I want to thank everyone for their input on this & I would encourage everyone who reads this read if you haven't yet, to make a GitHub account and join the discussion. It would be great to foster a professional discussion about this here on GitHub. |
I was bullish on taproot it has some cool use cases. However they are all things that most people will not use. And Bitcoin has proven there are some drastically detrimental ways people can abuse it. The cons drastically out way the pros in my opinion. That said I am not apposed if safe guards are put in place to prevent abuse. Say contract size limits. No real reason with Bitcoin script a contract needs to be more than 1k |
What are the pros/cons of limiting contract sizes to 1K? Where in the code would this limit be applied? Be good to share in detail what it means to apply it. In addition, define the ways people can abuse it. |
There are pretty much no cons(accept for those wanting to abuse taproot to dump lots of data on to the chain). Honestly you could set the limit much lower then that and not block normal usage. |
The testnet activation window needs to be adjusted for that to happen and for activation to occur on the testnet. You lot crack me up. I have been exploring multiple chains for my app and decided to get involved here, starting to build outside my other work. I will continue looking elsewhere if digi has no interest in supporting taproot. |
What is the plan to obtain 70% consensus from miners when we don't even know who all the miners or can't gain access to them? Does this pose an issue? |
|
Pools and solo miners just need to use the new version.. |
|
@SogobiNapiasi what do you need for your app? Do you need the ability to do hidden contracts until published? Or do you want NFT capability? The first is a good use of taproot, though rarely desired by people. The second is a horrible use for it and DigiAssets already exist to allow you to have this capability and its more efficient with more features. |
What if a large pool is not aware of the new version and can't be contacted? |
|
@ycagel that's just the way hard forks work. If you want it to go through you try to convince more then 70% to upgrade. If you don't want it to go through you try to convince more than 30% not to upgrade. If the 70% win then the left overs get discarded until they upgrade. |
Taproot is a soft fork isn't it? |
That pretty well sums it up. It's called a soft fork though because there is no hard/ set date/time and or specific block height when consensus changes happen forcing everyone to agree by a certain point in time. But a soft fork is still a hard forking of the chain when it happens. With the soft fork process, the upgrade can happen at any point during the proposed 2-year window. As long as Lines 88 to 91 in 22528bf Every week the period starts fresh. The last time we did this was the Odo Fork and SegWit soft fork before that. You can have 40% of miners agree one week, 60% the next week, and could go back to 50% the following week period. If I remember right the % of blocks was changed from 80% to 70% because we were stuck at like 78% for the Segwit soft fork for months. The question is what does the community believe a "majority" should be? BTC used 80%. US Congress says a super majority is 67%. 70% was used for odo fork. If you remember the groestl miners kept going on another chain for some time before it was abandoned. This is a consensus change so anyone not upgraded will be left behind and will have issues sending/ receiving taproot enables tx's. Exchanges, wallet providers etc all need to upgrade ahead of miner consensus. The possibility exists for miners to adopt a change before exchanges/ wallet providers etc and could cause issues. |
|
Thank you, @SogobiNapiasi, for suggesting this PR. I am working on drafting a more in-depth comment, but for now, I wanted to make sure that it is clear to all reviewers that taproot activation is not a hard fork. This PR represents a fully backward-compatible soft fork. Taproot introduces new rules and features, such as Schnorr signatures and Merklized Abstract Syntax Trees (MAST), but it does so in a way that is compatible with the existing protocol. This means nodes not upgraded to support Taproot can validate blocks and transactions according to the old rules. Since non-upgraded nodes continue to see the new transactions as valid, there is no risk of a blockchain split. This preserves a single, unified DigiByte blockchain. See: https://www.chainalysis.com/blog/bitcoin-taproot-upgrade/ |
Have we been at 70% consensus for all changes via DigiByte as a baseline? Is there any benefit to lowering that threshold to 50%-60% for Taproot? |
In case of taproot taproot Tx's might still be readable by non-upgraded nodes, and old nodes will still be able to send tx's and old style tx's to new taproot nodes. So in that respect it is backwards compatible. I need to fully check on this before I say more. |
Pretty sure it's a hard fork. A simple test is can people right now publish a transaction using it's features manually. If the chain will allow it then it's a soft fork. If it won't then it's a hard fork. |
It is not a hard fork. It is a soft fork and considered backwards compatible. https://www.chainalysis.com/blog/bitcoin-taproot-upgrade/ "Taproot adoption timeline Adoption of taproot is expected to grow slowly over a period of years, just as it did with SegWit, the last major Bitcoin upgrade. Two years after SegWit’s activation, roughly 50 percent of transactions used it; today, four years after, that proportion is 80 percent. The main reason for this slow rate of adoption is that cryptocurrency wallets and service providers choose to opt-in on their own schedule." |
According to the BIPs, it is a soft fork. Additionally, the activation of taproot on Bitcoin's network, which is where our code comes from, was in fact a soft fork: |
|
Fair in that case it can already be exploited, the transactions would just need to be manually decoded to be read. |
|
I think this is a good answer found online:
For Taproot specifically, from what I can tell in code you will not be able to send DGB to newer wallets/ services giving you a taproot address, but you could still send older style tx's to them. An old node would not be able to receive taproot coins and verify them. This is definitely something to test, I can not find a clear answer on how "backwards" compatible taproot really is. There are no mining consensus changes so mining stays the same. This is a great intro article to taproot for anyone reading along here: https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade |
|
I also want to point out BTC went with a 90% threshold for activation with Taproot specifically. When you get 90% of any group to agree to changes the issue of backward compatibility is a lot less of an issue for the network. |
|
My final thought today on this is just like any other change, it will take time for any new wallets, services, etc to use DGB taproot addresses. But we do benefit from this though because BTC has had it for 3 years now, so a lot of work has been done to adopt infrastructure that supports this. Regardless, I don't think this should be in the 8.22 final release. It should come later, if at all, after we had time to test all this thoroughly and not break anything. Just my perspective. I Would love to get some more people's thoughts on here. A great conversation we have going on here. Informative for everyone. I could go either way on Taproot. A clear community consensus should decide on what to do with Taproot. I would love to hear more about use cases/ apps that could be built on DGB because of Taproot @SogobiNapiasi. Perhaps this should be set up as a feature branch for now, so the work is not wasted? |
|
This is one of the most informative discussions I’ve seen, when it comes to DigiByte Core development. It is important weigh things out carefully with a critical eye. There was a previous community discussions on Taproot activation and it was in front of a Digiabyte community audience. The discussion ended with 8.22 should be released and taproot should be activated at a later time. This proposal PR244 is one review from being approved, which I think is hasty. A lot of information has been shared but mainly on the benefits, I like to think that there was a good reason the Core developers decided to delay activation. I think it was mainly due to the negative effects on Bitcoin. Mempool backlog, fee spikes, chain bloat with jpegs. Recently Ordinals were delisted from Binance but also Ordinals have been the target of MEV attacks. The only benefit I see is Bitcoin miners making a good profit. I know Taproot, Schnorr signatures, and tapscipt bring more functionality besides ordinals, but the negative effects are what seems to standout. I recommend the information shared in this discussion be shared by the main DigiByte accounts across all social media platforms to inform, spread awareness about the benefits but also the potential negative effects that it might have on DigiByte. If community input is wanted then this is a good approach, the alternative will look like community input wasn’t needed and it was decided by two people. PR244 was submitted 2 days ago, one day later it received a review with approval and it seems kind of rushed in my opinion. |
|
My understanding of taproot is very limited but what I have read about it, it seems to be something that Digibyte may benefit from in the future but not necessarily today. I recommend wrapping up 8.22 and voting on the addition of taproot later. We do need to compete with other chains but we need to get over the 8.22 hurdle first. IMHO |
|
First, I agree that 8.22 should avoid activating Taproot, and we should quickly follow another release so that we can stay focused on the immediate task at hand and deal with any issues that may arise from the release of 8.22 without piling on Taproot. That said, we may consider adjusting the activation window to a sensible period so that we don't necessarily have to do a second release. I'm still trying to think through the logistics due to how long it takes to propagate new versions through the network. If this is the general short-term consensus on Taproot activation, we could create a feature branch that this PR can target, allowing the community to build and test Taproot locally with regtest and testnet. Addressing the chain bloat/spam concern. I used to be very concerned about the potential for chain spam and bloat due to abuse. However, the longer I have contemplated activating Taproot, the more I favor it for these reasons:
Given the above three points, I have become less concerned about chain bloat and finding ways to police how the blockchain is used. Trying to apply too much control over how the world uses the network can and probably has led to low adoption of the blockchain, so this concern has become less of a problem for me. That said, I am open to considering @mctrivia 's suggestion of adding a limit to script sizes. Still, again, I am weary of trying to police this risk at the expense of kneecapping future use cases we can not even think of today. I can't help but imagine what the world would look like if the developers of the core internet protocols applied these kinds of data caps and constraints. In summary, I favor activating Taproot, but not before the release of 8.22 has had time to settle. |
|
@gto90 did I miss something? I don't believe taproot adds a new scripting language to allow more complex smart contracts |
Taproot activates BIP342 which is an updated version of Bitcoin's scripting language that allows for the creation and execution of more complex smart contracts by providing a more flexible and efficient scripting environment. This does not mean it supports Turing complete ETH-style smart contracts, but it unlocks more complex contracts that were impossible with the previous Bitcoin scripting language. Taproot also activates BIP 341, making implementing more complex contracts feasible without bloating the blockchain. Finally, it activates BIP 340, aggregating complex multi-signature transactions more efficiently and privately, which is essential for sophisticated smart contract operations. |
|
@gto90 just read through bip342 I don't see anything in there to allow anything more complicated than what can already be done. Just allows for efficiency gains by better key management. It also removes the current 10k script size limit which I think should not be removed. |
I think the point is that the taproot BIPs enable more room for larger and more complex scripts and data, which enables use cases like the following:
Examples of DeFi Applications Enabled by Taproot1. Decentralized Exchanges (DEXs)Scenario: Alice wants to trade DigiByte for Ether with Bob on a decentralized exchange.
2. Lending PlatformsScenario: Alice lends DigiByte to Bob, who must repay with interest by a certain date.
3. Staking and Yield FarmingScenario: Alice stakes her DigiByte in a DeFi protocol to earn interest.
4. Insurance ContractsScenario: Alice buys insurance against a specific event (e.g., flight delay).
5. Collateralized LoansScenario: Alice takes out a loan using DigiByte as collateral.
Detailed Example: Collateralized LoanParticipants: Alice (borrower), Bob (lender)
As I shared above, I believe the benefits outweigh any negatives. I remain unmoved by chain bloat concerns but am willing to consider and understand the impacts of artificially constraining the size of the scripts. Unless I can see a compelling case, I'm weary of limiting potential use cases more than I am chain bloat. |
|
Most of those I don't see how you would do. Multi sig definetly. Escrow is definetly doable through time locks. Time locks sure. Proof of a completed service. How does that work? Staking can't be done, and yield farming I don't see how that can be done. The insurance example is ridiculous. colateralized loan can be done I guess by setting up multiple pay back periods. Could be a good use and would be less desirable without taproot. |
Schnorr Signatures and Pay-to-Taproot scripts are indeed indispensable for the creation of a PTLC or Point Time-Locked Contract. An innovative and game-changing application, which leverages PTLC's, can be developed to create the most extraordinary use case DGB hodlers have ever encountered. It shall empower DGB on a level that will astound and captivate people's imagination, elevating it to newfound heights of utility and purpose.
Source: |
|
It’s been a few weeks since the last comment was made, lot of good information in the comments. I get the impression that 8.22 will be released without Taproot activation, however, it might be activated at a later date in a feature branch. Just following up to see if a decision was made. |
|
Dear @SogobiNapiasi would you mind updating the activation dates for the taproot upgrade? I am 100% in favor in moving forward with taproot activation on the DigiByte blockchain. I believe long term it will be a win win for everyone. Thanks for taking the time to work on this. It seems there is an abundance of support in the DGB community for taproot activation as well. |
|
@SogobiNapiasi I agree as well. It seems the community is 100% on board
with your suggestion. This is a really great addition for the chain
…On Mon, Nov 4, 2024, 12:16 PM Jared Tate ***@***.***> wrote:
Dear @SogobiNapiasi <https://github.com/SogobiNapiasi> would you mind
updating the activation dates for the taproot upgrade? I am 100% in favor
in moving forward with taproot activation on the DigiByte blockchain. I
believe long term it will be a win win for everyone. Thanks for taking the
time to work on this. It seems there is an abundance of support in the DGB
community for taproot activation as well.
—
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJURTIULJM45JUMHVJZWXV3Z67BX7AVCNFSM6AAAAABJHHUMKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJVGYYTONBSGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Definetly not 100% on board. I think it is a huge mistake to include taproot as it will allow huge amounts of spam to be published to the chain. This could in a few years make it to expensive to run a core wallet for most users centralizing the chain. |
|
I understand your concern and it's valid. However "most users" don't have a
core wallet. And to be fair shouldn't. They are not built for the everyday
person.
…On Tue, Nov 5, 2024, 5:46 AM Matthew Cornelisse ***@***.***> wrote:
Definetly not 100% on board. I think it is a huge mistake to include
taproot as it will allow huge amounts of spam to be published to the chain.
This could in a few years make it to expensive to run a core wallet for
most users centralizing the chain.
—
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJURTIRKAESYL6O3ZVACTT3Z7DD2VAVCNFSM6AAAAABJHHUMKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJXGIZDIMZWHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Most should not use core wallet for holding funds. But for a strong chain as many as possible should run a core wallet to share blocks. |
|
I have also changed my mind and have come around to including this with 8.22. While I agree that there is a risk that our blocks will be filled with spam transactions (whether spam or productive remains a debate), I think the value in having more transactions and blockchain adoption outweighs the risks and we can work on mitigating solutions if that risk is realized. |
|
Great to see this conversation started again, there definitely needs to be a decision made on whether to activate taproot or not in order to finalize 8.22. I’ve been going over the economic majority referenced on the DIP and the community chat on the DIP given by @gto90 and it only seems fair to get feedback from the DigiByte economy the merchants and users. I’m in communication with the team at Cryptwerk.com, I asked them to run an article for me and they would. Maybe we can reach out to Cryptwerk and ask if we can use their platform to gage the support for activating taproot. Maybe a one pager of risks vs benefits pros/cons. Just an idea. |
|
I believe the upside of Taproot and Schnorr Signatures is there, so I would include it in the new release. |
Quick follow up, I wrote another article specific to Taproot activation and I’m waiting to hear back from Cryptwerk if they will publish this as well. Understanding Taproot Activation on the DigiByte Network. Cryptwerk is an online directory of merchants who accept cryptocurrencies. DigiByte is ranked 19 out of 59 by merchant popularity. 825 companies accept DGB for services and goods compared to Bitcoin BTC 9000+. I don’t know of any other site that has this type of information, but if we want more adoption, DigiByte economy involvement, then this is a great source. At the very minimum the information will get shared across social media but best possible outcome is that we can communicate directly to the merchants and users on Cryptwerk about DigiByte. |
Pull request updated with Taproot activation threshold from 10th January 2025 to 10th January 2027. |
There was a problem hiding this comment.
cACK. Thank you @SogobiNapiasi. Taproot activation dates have been updated.
There was a problem hiding this comment.
cACK. Awesome! Thank you @SogobiNapiasi. Once we get this PR merged I will work on finishing taproot tests to make sure everything is good to go there. I think Taproot will be very beneficial for the DGB blockchain long term.
|
So awesome!
…On Fri, Nov 8, 2024, 11:34 AM GTO90 ***@***.***> wrote:
Merged #244 <#244> into
develop.
—
Reply to this email directly, view it on GitHub
<#244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJURTITBVKHRIEAJGZCPAFTZ7UG5PAVCNFSM6AAAAABJHHUMKSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGIZDINRXGM2TKNQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This commit updates the `rpc_blockchain.py` functional test to include the Taproot soft fork status in the `getblockchaininfo` RPC call. The Taproot soft fork is defined using the BIP9 activation mechanism with specific start and timeout times. The test verifies that the Taproot soft fork is correctly reported as "defined" and not yet active. Changes include: - Adding Taproot soft fork details to the expected `softforks` field in the `getblockchaininfo` test. - Ensuring the test checks for the correct status, start time, timeout, and activation state of the Taproot soft fork. This update ensures that the `getblockchaininfo` RPC call accurately reflects the status of the Taproot soft fork, which is crucial for testing and validation purposes. Refs #244
I propose to initiate the Taproot activation soft fork on the DigiByte blockchain. I have an innovative application to develop, and I believe DGB is the most suitable blockchain for it. Taproot is essential for building this application.
This pull request will commence the Taproot activation window from 1st August 2024 to 2026. Additionally, it will begin the testnet activation window from 20th June 2024 to 20th June 2025. Seventy percent of miners will need to agree for one week’s worth of blocks for Taproot deployment to be successful at any point.
Taproot will enable the use of Schnorr signatures on DGB, providing highly advanced smart contract capabilities as well as Tapscript functionalities.