Topic: opinion: it would be better off if taproot was rolled back (Read 233 times)

i agree

it doesnt need a chain re-org orphan event of weeks-months
just needs to make the softened consensus rules hard and structured again

Taproot promised lean witness utility. so a simple fix. make taproot only allowed 80byte witness

i find it funny how legacy cant have lengthy signatures(old name for witness) but new features have been softened to allow it. when it is these new features that promised they wouldnt bloat the blocks with excessive witness data

a simple hardening of the rules does not mean removing old data. it just means not letting the bloat continue in future and far far easier to implement

Rolling back a consensus rule change doesn't necessarily need rolling back blocks specially when months have gone by and it requires thousands of blocks to be rolled back. Not that it would happen but something like that would be like disabling the soft fork by removing the extra rules. So in case of Taproot all the Taproot outputs become anyone-can-spend.

Only if the attacker can collect enough hashrate to do it, no way to make it happen by any consensus.

If any entity is part of Bitcoin community and join with financial incentives, they will no have any single reason to support such idea to roll back the Bitcoin blockchain, Taproot or anything else. They know such rollbacks are only harmful for Bitcoin network and consequently it will cause dramatic loss in loyalty, trust in Bitcoin from the crowd.

If the attacker wants to get profit from rollback, attacks, such attacks won't be helpful for attackers but if they are from governments, they can get benefit from it. Above all, I did not see governments come too close to attack Bitcoin network.

500g is bad enough to convince people to run full nodes and with the demonstrated spam abuse by Ordinals it can only get worse fast. Leave it unchecked and all blocks will be 4m now, and not from transactions, unfortunately...

Hmm, never would have thought ordinals would get this much blowback, the threads in Project didn't suggest it.

There are probably counter examples, but apart from rollbacks to prevent catastrophic consequences and with few enough nodes to easily control majority (I'm also ignoring Ethereum's non-catastrophe), when has a rollback ever been supported anyway?

So even if you're right, the consequence isn't real enough or tangible enough, even those who wouldn't understand enough (like me) wouldn't support it.

a. doesnt require a roll back
other ways are even simpler.. new rule to reject formats that use more then 80 bytes of witness/script per Tr input/output.
and even maybe a rule to limit outputs per tx
(there is no reason any transaction deserves say XXkb of space for bloat each to fill a block with just YY tx's)
thus avoids spam.
thus then still allowing those on taproot users that only wanted to taproot to spam metadata not be able to spam metadata, but still exit taproot without being frozen in the network

b. if you think the only option is blind follow core else create an altcoin. again you have no clue(like certain people) of how consensus mechanisms work, nor should work, yes core found a bypass to allow them to make new formats without needing a united consent to activate. but that can change and revert back to how consensus run pre 2017
again if you think the only option is let core do as they please or run an altcoin.. you have lost any credibility of knowing the purpose of what bitcoin solved in 2009+ which made bitcoin unique to any previous "digital money" platforms before it.
the delay in using bitcoin how it should be is just a re-education. to make people learn what real decentralisation and consensus is all about
if your wiling to learn. learn what the byzantine generals problem was and how bitcoin solved it via a consensus that united multiple peers
and un-learn the idolisms of a core'poral being in charge of rules

I am sure you can not get any 100% vote in life with very rare exceptions in countries with dictators like North Korea, Cuba, China, Russia and whatever countries which are controlled by dictators.

Bitcoin network is decentralized and community have their voices that of course can not the same, so no 100% agreement with any vote for Protocol changes, Upgrades.

If you don't agree and can vote, you can choose the Disagree option and go with a fork. Bitcoin Cash was born like that but forks are failures, not successful projects. Almost 6 years since 2017 hard fork, Bitcoin Cash is a failed fork and Bitcoin SV (forked from Bitcoin Cash) is a worse failure.

Rollback, sorry it is not for Bitcoin and its network. If any blockchain that can be reverted /rolled back too easily, that is a shit blockchain. With such crap blockchains, you can lose your money any time.

MAHF have been used many times
and yes a certain group want to make it appear that nodes have no say, no vote. but that has been since 2017

oh you might forget the berkely-leveldb drama of 2013
that was sorted out by node reorg. not by GPU power


oh and you do know that mining pools collate the data of a candidate block
oh and you do know that mining pools ises workers of ASICS just to get a strong ID
but its the nodes that the do the block rejections, orphans, and re-orgs

i know you want to pretend that mining pools are the controllers/trojan injectors, to shy away peoples eyes from wanting to look closer at the developers of code rules
but its the developers of the code rules(nodes) that is where the power lays

CORE made taproot not mining pools

its just the devs can set the rules but then not allow users to veto the rules(backward compatibility=turn user nodes into abstainers)
this is becasue most of the activations is by the "follower the leader" where economic nodes have more sway than user nodes.
after all how many users would go against a ruleset of the major exchanges and merchants. meaning users cant pay value to merchants/exchanges if they were accepting/rejecting different sets of transactions/blocks, etc.

---

i understand not every bitcoiner needs to be a full node. but those that want to be a full node should not be downgraded to be a fool node, while having their head stroked and ass kissed and being told to go to sleep pretending they are a full node becasue it sounds the same

oh and you have no clue about the features of bitcoin
you have no understanding of the byzantine generals problem and how bitcoin node code solves it (blocks dont change rules they just collate data. there is no code in a block) devs make the code not block miners.


also eve having a feature that even allows a change of rules without requiring full node validation of a potential ruleset ready to validate a change if it activates is the most biggest risk there is. it should have never been allowed.

network security should have that the software be ready and able to validate a rule before a rule is activated.

its like this
imagine you owned all the amazon servers and one day said.. hmm we are going to receive new data, but lets not update our cloudflare or antiviruses or operating systems or firewalls to be ready to check and monitor this new data.. . lets instead just write one like of code into our servers "new data=default: isvalid" and then tell everything we are still validating everything and ensuring the security of the AWS network(facepalm)

That's nonsense. Full nodes have never been part of the voting process from day one which never changed either. It has always been 1 CPU 1 Vote (aka miner with actual hashrate) not 1 Node 1 Vote. The reason is pretty simple, there is no way to know for sure the IP you connect to is actually running a full node or is faking it or is one of many IP addresses linked to a single node (in other words you can run a single node but with many IP addresses pretending to be that many).

You also seem to be ignoring the history. The first soft fork (with backward compatibility) if memory serves was BIP16 (ie. P2SH) which happened over a decade ago in early days of Bitcoin.

P.S. Your arguments regarding "validation data" is also weak. It is like saying "SPV clients not validating anything is a bullcrap feature" too. It's a good feature that allows users to continue using bitcoin and running a "semi full node" until they get around to upgrading instead of being punished and have everything stop abruptly after the hard fork and be forced to upgrade.

Grabbing a bucket of popcorn, this is 2017-2018 segwit kind of discussions all over again, will get back to you after some reading to know what TR actually is.
However regarding transaction censor, if it's a spam, they should do it, and for the record, if the miners want the fees for ordinal txs then they should suffer the consequences when fees go up and people stop using bitcoin. There should not be such fee manipulations happening consistently. Moreover, why would the "devs" open a door for the possibility of these metadata/ non transactional data existing in the first place? Either they didn't know about such possibilities or they did know, both of which shows how incompetence they are, that's OK though because that also shows bitcoin is really being developed in a decentralized manner, open source flaw.

---

Dude stop using AI to write your posts for you, Will report if you keep doing that.

This is a controversial opinion about the Taproot soft fork in Bitcoin and its potential consequences. The writer argues that the Taproot soft fork was rushed and could have unintended consequences for both the Bitcoin network and its users. On the first layer, the writer fears that the introduction of ordinal could lead to the blockchain becoming bloated with illegal or inappropriate content, which could be used as an excuse by politicians and regulators to target people using Bitcoin. On the second layer, the writer is concerned about the TARO proposal, which could allow stablecoins and other digital assets to be transmitted via the Lightning Network. The writer believes that this would be harmful to many people and goes against the purpose of Bitcoin. They suggest undoing the Taproot soft fork via a future fork with a 95% consensus threshold of full nodes and miners. The writer also believes that only security-enhancing forks should be implemented in the future.

a. the sily subnetwork BRIDGE you speak of is not even a skin of bitcoin. its a bridge(crossborder) system for multiple currencies. its just had such crap development and shoddy work done on it not one has really bothered to use it apart from idiots that think its just for bitcoin" thus snake oil phish pitched it as a bitcoin only thing
heck even poon called it a cross border network so get a clue

b government regulators are not attacking that silly subnetwork due to stable coins.. its about facilitating the routing of payments on the behalf of third parties for a commission.. (or as the americans call it running a money service business) which has always put LN routers at risk even moving msats..
the reason governments have not chased after people that open up their msats for route utility. is becasue the amounts are too small to give a crap about chasing someone for a $2 profit per month

c. core are the defacto authority. every proposal has to go through them an be moderated out quick or sponsored in .. any other implementation brand ever trying to offer proposals not part of the core roadmap gets REKT

d. allowing funcky new formats in that do not require nodes to be upgraded first to recognised the rules set of new formats is BAD. it means nodes are not verifying and validating the full blockchain data. SUPERBAD
going soft is a way that consensus strictness has been softened to allow possible bugs/trojan functions into bitcoin without any vetting review or prevention by the decentralised network. its done to bypass the requirement of full nodes to be ready to validate everything. its done to let core get their way while not allowing there centralised network to object to it

e. anyone saying let it happen let it carry on. is revealing they dont care about bitcoins concept and protocols and just wants a certain group to remain the central point of failure, knowing a central point of failure will fail at some point

f. i do laugh how those central point adoration guys pretend there is no one controlling /authorising proposals.
YET bitcoin is not AI.. its not self generating code..
its done via devs. <-emphasis

there is an OBVIOUS group of devs sponsored by corporations, and its those corporate features that get added above any "community" desire
(and no im not talking about volunteer contributors that just translate the GUI or grammar/spell check minor comments, im talking about paid devs with commit, merge and release candidate publishing privileges)
yep devs write code. and we need to hold the accountable, review them, critique them.. not let them have "god mode" (soft access) to upgrades

Big difference is that this stable coins on LN and other layer2 is backed only by Bitcoin, and they don't need other centralized shitcoin blockchain.
I would not keep anything is stable coins long term, but I could see bug use case for them in some real decentralized exchange, as alternative to fiat currencies.
We could argue that most of the current stable coins wouldn't exist if we had something similar on Bitcoin.
Saying that regulators will now attack Bitcoin because of LN is hilarious to me.

Go ahead and make a proposal about this.
There is no single authority who makes decisions in Bitcoin, and I don't think we should fork anything or ''undone'' Taproot at all.

Oh yeah, ban all softworks  
I don't know if you live under the rock, but Taproot can really improve privacy a lot, and it's not here because of ''cool features''.

just because they took "longer" from proposal-review-testing, does not mean something should then be pushed fast into activation where it does not require node upgrades of majority

the whole "backward compatibility" softening of consensus years ago has its disadvantages
if nodes are not part of the vote nor even validating data.. then that is a bullcrap feature
the whole idea of fullnodes validating fulldata across the network is the whole point of bitcoins invention.. which has been ruined with this bypass trojan generator in 2017


new stuff can be slipped in that can bloat the blockchain where even as "non-standard".. the nodes are to treat it as "isvalid" and not do any validation on such new funky stuff

where by to undo such things then requires a majority consensus mostly in the form of a MAHF to then fix a rule to then reject formats slipped in,

Not at all. The time it took for its preparation process (proposal, implementation, review, testing, deployment) was longer than most soft forks and the threshold was also the same as other soft forks.

Just because someone is exploiting the new protocol doesn't mean the whole thing should be removed!
Taproot is already offering a lot of things from the Schnorr signatures (aggregated signatures, faster verification, batch verification, etc.) to all the new things we could do with Taproot.

Not to mention that the solution is very simple too. The same way we have been preventing such garbage data to be pushed to the blockchain, by introducing standard rules that prevent such things!
That also doesn't need any kind of fork.
After all this is how we prevented people from doing a similar spam back in 2010 IIRC by introducing standard rules that rejected non-standard outputs (eg. scriptpub that contains the big ass JPG file).

Is this on Layer 1?  Is this a real thing?  Is there anywhere I can go to read more about this?  Censoring the transactions they do not like sounds like something irreversible and with very powerful negative consequences that will change the way Bitcoin works forever.  Unless I did not get what you were trying to say.  Have to mention I do not have much idea about how Taproot really works.

-
Regards,
PrivacyG

it doesnt matter how long devs "work on it"
the activations are "fly by nights" as they now use the soft bypass mechanisms to activate without requiring nodes to upgrade

to stop it, just requires doing a 2017
mandate that merchant and miner nodes use bitcoin node v.X(old version with edit*) or else, by certain date

*to reject blocks that contain transactions that have certain opcode in blocks after blockheight 7XX,XXX

thus only take a few lines of code edit to a pre-taproot codebase

obviously to do this on the outputs(receiver) not the input(spenders) so that those with funds on existing TR utxo can put funds back to native or legacy tx formats without harm or lock-in

---

what this actually does reveal is that now that "backward compatible" is a mechanism* to soft introduce new tx formats**.. also has the flaw of easy adoption without consensus (need of activation broadly by mass adoption) to activate..
but to then roll back becomes something that does need contentious MAHF to undo***

*done in (june-july)2017 via mandated contentious MAHF
**subsequently in (aug)2017 forward
*** like the (june-july)2017 event

---

as for LN
who gives a crap
LN is not a bitcoin later(skin) that only fits around bitcoin
IT HAS ALWAYS BEEN:
a. a cross border subnetwork bridge
b. for those acting as routes. a money service business/payment service provider (use of routes facilitating the movement of value for a third party for a commission)

LN is a flawed and failed to launch subnetwork bridge where by in 7 years it has not gained the same liquidity cap and usage as other subnetwork bridges have in 2 years

anyone can create a new subnetwork that is locked to only use bitcoin referenced locks without a crossborder facility to be a subnetwork with unique functionality and solely tethered to bitcoin.. but LN is not it

---

its not really a TR flaw.. its more of a flaw noticed due to TR not caused by TR.. because it was used in taproot.. people realised there is a pre-TRexisting flaw that can be abused
its actually a soft backward comparability flaw
by being able to treat a certain output to be treated 'as valid' without checking/validating data after a certain opcode means people can then put in whatever junk they like without nodes rejecting it.
this is a flaw that has existed for many many years. a flaw that has been treated as a feature

I don’t think it would be an easy task to roll back taproot. It was worked on and planned for a great deal of time before it was activated. It wasn’t a fly by night upgrade. Seeing it having unintended consequences now doesn’t seem like a serious issue to me yet. Developers have already started submitting proposals to censor the transactions they don’t like and some are supporting it. Undoing the upgrade hasn’t been floated by anyone as a serious solution that I’m aware of.

You can use bitcoin cash as much as you want, why don't you and why doesn't everyone else? Why isn't it worth more than bitcoin if so many people agree with you.

If 95% agree on something, why wait for the other 5 it's a stable shift regardless?

You can't upload a jpeg to most blockchains (eth included) you can upload a pointer but that's not a jpeg or parts of the file across multiple transactions but I doubt anyone's done that recently or found a way to do it that's useful. Anyone can already do that too.

i'd like to share my opinion on a controversial topic and see what are the thoughts of bitcoiners here.

the taproot soft fork was pushed too fast, unlikely past soft forks with over 95% of consensus.
now it will have unintended consequences both for bitcoin layer 1 and layer 2:

on layer 1, with the introduction of ordinal, now bitcoin's blockchain is getting bloated with useless jpegs, nfts, and it could possibly become worse: child porn, porn in general, violent images, death threats, images that aim to dox someone, etc. Politicians, legislators and other state parasites will try to use it as an excuse (regardless of whether it makes sense) to arrest people whom they don't like under the claim of "sharing, transmitting child porn and other illegal content". It does not matter if (1) you didn't put the image there, or if (2) the image can only be displayed special software that can read, parse and understand Inscriptions (or other silly protocol) so that what is there is just a bunch of bytes unless you have the proper software. None of that will mater if they want to starting arresting people to use bitcoin (of course this will not be the end of bitcoin, it will continue to exist, but certainly will be bad for many people).

on layer 2, there is this horrible proposal called TARO, which makes use of taproot and pretends to bring digital assets to the LN, such as stablecoins, arbitrary tokens, nfts, etc. That way, people would be able to use the LN infrastructure to relay metadata of those digital assets, allowing folks to issue their shitcoin on LN. The LN protocol is decentralized, permissionless and anyone can use it without making the LN node public available or without revealing that you are actually using it, or with whom. It does not matter though: for regulators, it does not matter what you are using it for, they will say you are "operating money transmitter services" without a license, etc. Bring stablecoins (aka, shitcoins, fiat coins) to LN goes against the purpose of Bitcoin. If TARO enables that (as promised), it will just be another excuse for regulators to chase bitcoiners, node operators, and anyone using LN. Again, this will not be the end of LN, which is decentralized and will continue to exist, but this will cause harm to many.

we would be better off undoing taproot via a fork with at least a 95% consensus threshold of full nodes and miners. This would probably take some years to implement a safe code to undo/block taproot; in the meantime, we would have to tolerate taproot in the blockchain.
Also, I think these kinda of softforks should not happen anymore. Only forks that fix bugs, fix vulnerabilities, enhance security, but not forks that "add cool features".