Topic: When Taproot? (Read 334 times)

Coinbase has now enabled sending to Taproot addresses: https://x.com/CoinbaseAssets/status/1843712761391399318

Since this thread was opened, only 'Unchained Capital' has enabled sending to Taproot addresses.

You don't understand: These exchanges don't support sending to taproot addresses.


^ So you are just simply wrong since an exchange can't fund an address format that it doesn't recognize. That's the entire purpose of this topic, you should try reading the OP before posting a wall of irrelevance.

YOU were the one listing that exchanges are not supporting it
YOU therefore feel that exchanges need to be

Wasabi Wallet's new release now fully supports taproot receive addresses. Exchanges, when taproot???

No one ever claimed that the exchange is a part of the contract. How did you get that idea in your head?

But they might in the future. I don't want to be in the same position as those, who thought that "there will probably always be nodes willing to process transactions for free", just because Satoshi said so. At that time, someone could think: "Well, if I create more outputs, then I could reach better anonymity, right? After all, I can always combine it cheaply, or even for free, right?". And then, that person can look at today's network, and be very disappointed. In the same way, I guess some Taproot users could be also disappointed in the future, if Ordinals will abuse the chain so much, that people would seriously think about downgrading from Taproot, to not be marked as a source of spam.

But you can do an artificial multisig on other address types, beyond Taproot. For example: https://duo.com/labs/tech-notes/2p-ecdsa-explained

Not to mention old, good methods of making 1-of-2 multisig, if you perform a simple addition and multiplication with reality keys: https://bitcointalksearch.org/topic/m.8665571

And then, not only you are hidden behind some more popular address type (so your anonymity set is bigger), but also you are clearly separated from Ordinals, and other spammers.

If someone creates a Taproot output, then you don't know, if it would require pushing 4 MB data to be spent, or not. If you use P2WPKH, then you can always expect a single signature, and you can always calculate, what is the maximum size of your on-chain footprint. In case of Taproot, the spamming ability is simply unbounded.

let me make things clear for you

when someone makes a taproot address.. that address is a hash of some terms
much like multisig is a hash of multiple addresses, a taproot address is a hash of multiple terms in a merkle tree

it does not require a exchange to know the terms or create the terms. they just put the finished hash(provided by customer) as a destination of a withdrawal.. they only need to know the destination of withdrawals not the terms of that hash, thats it. they dont need to be "taproot" compliant because there is no need to create the hash within the exchange they just need to know where funds go.

user that want complex contracts create those contracts in private and offchain they only need to reveal part/all of the terms to the blockchain later on after receiving funds to it. where the user(s) then want to spend the funds on the address..  so dont need to get involved with the exchange to need the exchange to be part of the contract terms. all a exchange need to know is the destination of a withdrawal

ill say it again in different wording to save having to post again to correct your mis understanding
an exchange does not need to be part of the contract to fund the address so an exchange does not need to be taproot compliant just to fund it

and you do not need to publish the terms to the blockchain prior to handing the taproot address to people who you wish to fund it

FWIW, LN will move from HTLC or PLTC which should boost Taproot adaption. If those exchange or service intend to support LN, maybe they should support sending to Taproot address first.


That makes sense, although i expect people simply just secure their mnemonic words or password of their wallet where they expect it'll be unsecured after they die.

Normal single people should also use multisig. Even something as simple as a 1 of 2 with a timelock can be useful for inheritance purposes if you were to suddenly die.


The agreement of terms is enforced by the contract on chain, not off chain. Taproot makes the terms of the contract private when the keyspend path is used.

It takes centralized exchanges some years to adopt Segwit addresses Bech32 for deposits and it's explainable on how they need a quite long time to accept Taproot addresses Bech32m.

Bitcoin Taproot (Bech32m - bc1p) adoption
https://en.bitcoin.it/wiki/Bech32_adoption

I did not know about this https://whentaproot.org, so I thank you for sharing it.

but if you are just a normal single person just wanting to withdraw from an exchange there is no major point, hence why exchanges see no point in using taproot for users withdrawals

taproot is mainly for 'federations'(groups/syndicates) that have a private agreement of terms offchain of how they collectively want to have their funds co-mingled and shared. which is mainly used for other utility unrelated to just paying out single users exchange funds

so far the majority of utxo's that are using taproot outputs are the junk crap spam of the ordinals and brc crap, hardly any is actually used/needed for what was proposed as taproots true purpose.. so again exchanges dont care and are in no rush

infact many exchanges still like using legacy standard and legacy multisig. yep even binance prefers them

Fine how about most large regulated exchanges & services are paranoid beyond belief
The point still stands. They took a while to go segwit, they more then likely will take just as long to do this.

-Dave

Taproot allows for larger, cheaper, and more private multisigs, there's definitely a point.

there is some features that need taproot. but just withdrawing funds to a address is not really one of them so no point using something that doesnt do any different to standard address types.

taproot is mainly for grouping individuals into special multisig configurations with terms of use contracts..
.. and mainly used right now for junk metadata

It may take more months or years. People prefer to use bech32 because the fee for p2pkh is much. Segwit reduces the fee to like 42% or more. For the sites that was not able to adopt p2wpkh fast, p2wpkh-p2sh was created which was the reason it was also common that time.

Wallet developers know that p2pkh has too much fee and were fast to to support p2wpkh and make it their default. Some wallets like Electrum even removed p2pkh. That makes p2wpkh very common. Segwit still has the lowest fee till now except your transaction has more inputs.

There are even some wallets like Electrum that has not support p2tr but they will likely support it soon.

The fee will not make people really talk about it as an issue because people still like p2wpkh.

Filters don't work for censorship: https://mempool.space/tx/38086f6079c9eeb1e1a637600645e99982281f5f8ee23dd9680d879b9e7da204

In order to censor Ordinals, you would have to change the consensus rules. Here's the software that implements those rules: https://github.com/rot13maxi/bitcoin-purifier

Regardless, if you are using the Taproot key path when spending then you won't be targeted by filters.

Exactly. I actually downgraded some of my wallets from Taproot, back into Segwit, to send a message, that "I am not a spammer, and I am going to spend that output in the future, by using just a single signature".

Of course, I support Taproot, but it is nice to have a way to say to the world, that "I am not a spammer". In case of P2WPKH, I can explicitly state, that "I know, what is the maximum amount of on-chain bytes that I am going to push". In case of P2TR, it is not the case: it can go as far, as the maximum size of the block. And this is a good reason to downgrade, and not be filtered out by some nodes, which try to fight with Ordinals spam.

More than that: I guess some people didn't upgrade to Segwit, just because you can sign a message conveniently, only if you have some legacy address. In other cases, it is more complicated.

Ordinals are unrelated to Taproot. Inscriptions use the script path instead of the key path to embed data, the only difference with Taproot is that some limits were lifted on the data size.


This isn't necessarily the case. Bitgo, for example, adopted both Segwit and Taproot almost immediately. Also, Whentaproot.org describes the process and provides a code example.