pull down to refresh

Yes65.6%
No25.0%
Mixed (please comment)9.4%
32 votes \ 54m left
Absolutely! From trust-minimized BTC bridging with BitVM to more scalable and private multisig with FROST and MuSig2, Taproot has given us some really great improvements.
btw @jimmysong any response to this?
reply
117 sats \ 3 replies \ @optimism 23h
Yes. The issue with changes to policy having unintended side effects would have eventually been triggered by something else if not taproot.
Learning from this now is better than learning from it in the future.
reply
Everything is good for Bitcoin in the context of learning and failing forward... perhaps the question then isn't optimally worded. Was it a failure or a triumph?
"It's bad but could have been worse and now we know should know better" is just a positive interpretation of failure.
reply
0 sats \ 1 reply \ @optimism 6h
Was it a failure or a triumph?
Depends on what you mean by it.
I think that the activation was a failure, not as in fail to activate but the implementation - in Core - clearly had unintended side effects, so it was activated too soon.
For the feature itself, it's only a failure if someone other than me spends my p2tr coin due to a bug or cryptographic weakness, so that's too soon to tell. For example, if the quantum doomers are right and this turned out to be the last protocol enhancement, then it could become a failure in the future, but I'm not particularly worried about this right now.
reply
Activated too soon AND still no compelling use-case or adoption... that's a failure along the same axis
The the proof-of-vulnerability is that it was activated at all... The one covenants are now attempting to exploit
reply
There's been 0 benefit to Bitcoin's value prop as money.
All it has achieved is giving ethead adjacent/script kiddies a morale boost via precedent, such that they'll be able to continue pushing to make Bitcoin more like Ethereum. Incentives for development have completely shifted to pet-usecase centralized application stacks.
Abject disaster.
Nobody voting yes is actually keeping a meaningful amount of Bitcoin in a Taproot address, can all but guarantee they're bandwagon jumping hypocrites.
reply
50 sats \ 1 reply \ @optimism 7h
Nobody voting yes is actually keeping a meaningful amount of Bitcoin in a Taproot address, can all but guarantee they're bandwagon jumping hypocrites.
My hot wallet is, by utxo count, 97% taproot. My cold storage is 100% taproot but I did that much too early and should have waited for greater adoption and rolled over to a new p2wpkh setup instead.
I remember p2sh taking forever to get used too though, would you say that that was a disaster too?
reply
Between you and @nout we've found the bulk of Taproot outputs....
Why do you use it? What's it doing it wasn't before?
The disaster is in the precedent it set, that useless forks can be astroturfed into activation... And now every shitcoiner that thinks Bitcoin should be an application stack is pushing for new ops
reply
17 sats \ 11 replies \ @nout 19h
Why not keep bitcoin in taproot addresses, what's the story there?
reply
You'll have to ask a Taproot enjoooyer why they don't walk the walk... I can only speculate.
reply
0 sats \ 9 replies \ @nout 19h
Oh, so your point is that there are not many taproot addresses with notable bitcoin amounts?
reply
... Or even a material amount across all addresses total.
Proponents would seem to be either afraid of using it, or lied about their urgent use-cases all along.
On a purely relative basis, a proponents burden of proof is that they're no less "safe" than address types with a longer track record... But they won't put any skin in the game on their experiment.
reply
0 sats \ 7 replies \ @nout 16h
I guess I'm special. It's been quite long time since I last used anything onchain that's not taproot. The only non-taproot is when using lightning.
(just to highlight for other readers - Taproot is now 10% by output value and 20% by output count)
reply
Could go all-in with Taproot Channels... why the hesitation?
reply
0 sats \ 5 replies \ @nout 16h
Simple Taproot Channels are just being developed, there's no actual prod solution yet. Acinq is making the most progress here from what I can tell.
there were theoretical benefits to privacy that haven't materialized yet.
bwcause no one actually cares about privacy.
but I say give it a little time.
main one that comes to mind is multisig indistinguishable from single sig transaction .
reply
Privacy is paradoxical, so I don't think anything should ever tout privacy as a feature or benefit, it should be incidental to something superior for its own reasons.
Things like Monero and Tor for example, privacy is the feature benefit, but that also makes them less private because it attracts a smaller anonset (retards) because they're otherwise useless, and more relative surveillance because it's a honeypot/target rich with said retards.
Privacy as a feature also leads users to stray from privacy practices due to a false sense of security. These undiscerning users fulfill the paradox of deanonymizing private systems through improper practices.
Taproot channels are often cited as a benefit to Lightning, but to your point nobody cares so use is negligible... and if we did get a flood of new privacy focused users, they'd quickly deanonymize an otherwise private network today through centralized swap services and ignorance of utxo management.
reply
0 sats \ 0 replies \ @OT 14h
Not yet. Soon maybe
reply
0 sats \ 0 replies \ @nout 19h
deleted by author