Taproot- Discussion

[JohnnyLawDGB]

Before I share my thoughts, want to make sure I am in the appropriate space.

[DGBNOOB]

I believe you’re in the right place to start a discussion, and if I’m not mistaken, it is encouraged. Were you looking for Activate Taproot PR244 which was closed, or did you want to share your thoughts about Taproot?

[JohnnyLawDGB]

If DigiByte activated Taproot, it seems like we’d get a ton of improvements in privacy, efficiency, and overall functionality. Here's what I think it would enable—jump in and correct me if I’m off here:

Improved Privacy
Transactions involving multisig or quasi smart contracts would look just like regular transactions on-chain. That seems like it could make the network harder to analyze, right?

More Efficient Smart Contracts:
With MAST (Merkelized Abstract Syntax Trees), only the part of a script that’s actually executed needs to be revealed. So, does that mean less data on-chain for more complex functionality? If so, that seems like a win.

Schnorr Signatures:
These apparently allow multiple signatures in a transaction to get combined into one. Does that mean we’d see smaller transactions overall? Or is there a tradeoff in terms of computational load for nodes?

More Transactions Per Block:
By shrinking transaction sizes, would this increase throughput without needing to alter block size? Just curious how much of a real-world impact that would have.

Future Upgrades:
Taproot has something called "script versioning," which I think makes future upgrades easier. Is that just for things like additional opcodes, or are there bigger applications?

What About Blockchain Bloat?
Okay, so if Taproot opens up the possibility for more data-heavy use cases—like ordinals, NFTs,—how do we avoid the blockchain growing out of control? A few ideas come to mind, but I’d love to hear feedback: With SegWit, something like 3.6 Mb per block?

Archival Nodes:
Could we have a system where older parts of the blockchain are archived for safekeeping but not stored by every node? Maybe institutions or trusted groups could maintain full archives. How do we ensure this doesn’t lead to centralization?

Pruned Nodes:
Pruned nodes seem like an obvious option for regular folks running nodes. If they only keep the most recent blocks, does that reduce their overall ability to validate the chain? Or is it just about storage?

Data-Heavy Transactions:
Should we think about dynamic fees for transactions with a ton of data, like ordinals or other stuff embedded in the witness field? Would that discourage bloat, or would people just pay the higher fees anyway?

Node Incentives:
If storage costs go up significantly for node operators, should we look at ways to incentivize them? Maybe share a portion of transaction fees, or something else that keeps things balanced.

How Do We Keep This Manageable?
I’d love to hear everyone’s thoughts on this. Are we already thinking about tools to manage blockchain size if Taproot opens the door to more creative use cases? What’s the best way to strike a balance between innovation and sustainability?

[DGBNOOB]

I just realized that the discussion was opened in the DIP repository, which still works because every DIP begins with a good idea.

I think that some of the solutions and incentives mentioned here are good ideas to address some of the cons of ordinals coming to DigiByte due to Taproot activation.

Just to clarify, Taproot activation will require the DigiByte economy—meaning miners, merchants, and users—to signal support for the upgrade, which is not a guarantee although highly probable. 70% of the network needs to signal support for Taproot activation during a sustained period of one week within the two-year activation period.

I am also interested in the analysis done prior to setting the activation dates for Taproot, but what’s important is that conversations like these happen to draw out viable, workable solutions.

Some of the options you mention might be viable solutions to future blockchain bloat. I think managing the risk of data-heavy transactions is a great conversation to be had with other blockchains and developers who have had this issue and solved it. It would be great to get them in this conversation and even better if they were interested in contributing through the DIP process.

I think you’re a great analyst and have more years of technical experience, resources and connections within and outside of this community to find answers to the question, “How do we keep this manageable?”

These, of course, are just my opinions.

[JohnnyLawDGB]

Opinions is all we have friend, living out here on the edge. Hopefully, we can all learn to share our unfiltered perspective and recognize we are all doing our best to understand.
 
Should this conversation be somewhere else? I apologize for my confusion as I would love to invite people on to the right platform to have this discussion out in the open.

Bitcoin/Litecoin have a few things that work as natural throttle controls, to prevent frivolous use of the capacity without cost.

1. Bitcoin- Targeted 10 minute blocks, 4mb per block theoretical with SegWit- Higher dynamic fee structure and Fee/weight unit. At max capacity: 144mb/day added to total chain.
2. Litecoin- Targeted 2.5 minute blocks, 4mb per block theoretical with SegWit- RBF, and Fee/weight unit. At max capacity: 576 mb/day added to total chain.
3. Digibyte- Targeted 15 second blocks, 4mb per block theoretical with SegWit- Low fixed rate, I'm assuming we introduce a Fee/KB. At max capacity: 20.73 gb/day added to the total chain.

I think enabling it would bring significant interest to the chain, but I think we need to discuss both the fee structure and how to mitigate potential bloat challenges. If adopted, it could potentially create significant bandwidth/resource requirements for archival nodes.

[DGBNOOB]

I assume all the Core Devs can see this conversation, maybe they're working on other things and can't join this conversation. However, you can try @ and core-developer name in this discussion or create a discussion on DigiByte-Core/discussions to put it in a more visible place.