Topic: Taproot proposal (Read 11248 times)

That's weird. They announced they will be supporting and upgrading their systems for Taproot at the beginning of November. What is positive from all this is that the affected user has received a refund of his coins and he has withdrawn them into his private wallet. Whether or not he managed to withdraw to a taproot address is still unclear. But if you still can't do it, I assume there is still a problem with taproot addresses.

No, you are reading it wrong, image you posted from Binance exchange clearly shows it's written bc1p (taproot address), and you wrote in previous post bc1q (Bech32 - native segwit).
Binance and few other exchanges does support receiving and generating bcq1 segwit address, but no exchange so far supports Taproot bc1p (some of them are only planning support).
When it comes to sending coins from from exchange to Taprot bc1p address, than we have some exchanges who are supporting that and you can track progress on this wiki page:
https://en.bitcoin.it/wiki/Bech32_adoption

Here with binance, the user had a problem after sending btc to the address of the new bc1p format.... now he has to deal with the exchange. I also wanted to withdraw btc from binance to the bc1q address.... but when selecting it in the address book on the exchange, I received a warning: "Withdrawal to addresses starting with bc1q are not supported at the moment, please proceed if otherwise, thank you." and the address just wasn't added to the output line, I don't understand how he managed to send funds to his wallet?


https://bitcoin.stackexchange.com/questions/111440/is-it-possible-to-convert-a-taproot-address-into-a-native-segwit-address
https://twitter.com/murchandamus/status/1475120106695008260

https://www.kraken.com/learn/what-is-taproot

only 54% of Bitcoin nodes (that's 33030 nodes) are currently using taproot ... in my opinion there should be more every day ... i will follow it

https://luke.dashjr.org/programs/bitcoin/files/charts/taproot.html

Technically that's an anyone-can-spend transaction not a Taproot one. If you look closely you can see that the transaction has no witnesses (no signature). In fact one of the outputs being spent is to a fake (but valid) public key (0101010101010101010101010101010101010101010101010101010101010101).

The first taproot transaction after taproot activation, or the first taproot transaction with a valid signature.

This is a taproot transaction before activation:
https://www.blockchain.com/btc/tx/b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41

This was included in block 692261 while taproot was activate in block 709632

the 1st taproot transaction ever


https://mempool.space/tx/33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036

Not exactly data compression but more like data omission. In Taproot we get rid of some extra (useless) bytes:
1- Removed DER encoding used by ECDSA signatures
2- Changed how last byte in signatures known as SIGHASH_TYPE works (it can be removed to represent SIGHASH_ALL)
3- Dropped the first byte of public keys indicating y coordinate oddness/evenness
4- By using Schnorr signatures (ECSDSA) we can now easily have aggregated signatures and keys which means even with multiple participants (such as multi-sig) we still need a single signature + a single public key

The first 3 are affecting all types including the "wallets with only 1 signature" ie. the simple key path spending rules and the last one affects more complex scripts ie. script path spending rules.

To know more about pay-to-taproot (P2TR) transaction virtual size and how the transaction can look like, you can check this, it can be of help:

Pay-to-taproot (P2TR) transaction fee

One thing about P2TR is that all transactions (be it multisig, closing of lightning network, swapping and any other transaction that make use of taproot) can have the same fee as just as single public key wallet. So if taproot also support just a single key (but I don't know yet), the fee will still be the same. Only what can alter the fee are the inputs and outputs of a transaction.

Im looking for some information about taproot upgrade. I know it will increase privacy & reduce the transaction size for multi-signature wallets. But how does it apply to personally owned wallets with only 1 signature? Is there any data comparison if the transaction size after upgrade in this case could be bigger than before?

the taproot countdown timer is slowly ticking down towards zero

https://www.nicehash.com/countdown/btc-forking-2021-11-15-12-00

This should be more of transaction and not message signing.

Well, I believe the people that are making use of Bitcoin Core (if true it can not sign a message with segwit address) can still make use of SPV wallet like Electrum for message signing, there are still many other SPV wallets that are able to sign and verify segwit address message. In this regard, no privacy invasion because an address that is only generated and not used (not introduced to the blockchain) can be used to sign a message.

What I think would be the reason is that many people do not even know the types of bitcoin address, no to talk of knowing the differences between them and how segwit (native segwit) has lower transaction fee. Also because some SPV wallets (which is obvious, the wallet most people are using) and exchanges are not supporting segwit, even the so called blockchain.com started to support segwit not quite long and few exchanges that are not yet supporting it(I don't know why people should be using such outdated wallets and exchanges)

The number of people using segwit address for transaction has now significantly increased, which has jumped now from around 60% the last time I checked in the beginning of his year to over 85%.


Just that it should have been 100% if other few wallets that have not supported it are supporting, this will even make ignorant people about it to still make use of segwit and take the advantage of lower fee.

There are still some reasons why legacy addresses are used. For example, signing a message with Segwit address can be done in different ways, but if you make a signature for legacy address, it will be the same for all clients. If you start Bitcoin Core and try to sign any message with Segwit address, you will get an error: "The entered address does not refer to a key. Please check the address and try again". Of course you can convert P2WPKH address to P2PKH, because the 160-bit hash is the same in both cases, but still, it is not implemented in Bitcoin Core and implemented in different ways in different wallets. Not to mention about script hashes, where nobody knows how to sign any message for that, also because scripts can be complex and not require any keys at all or require different keys in different cases. Another thing is signing messages with taproot addresses, where you cannot simply use taproot public key, because it could be unknown if all participants decided that spending by key should be disabled. In that case, signing messages with taproot addresses can be as hard as signing P2(W)SH.

Yes, it is good to use native segwit addresses because it has very low fee, 42% to 52% lower than legacy addresses, also still lower than while paying with nested segwit addresses, but that does not change the fact that the soft fork is backward compatible, which I believe is the best to make people decide which address type they prefer. Due to one reason or the other, some people still make use of legacy addresses, like a payment company that make it mandatory for payment, but to be sincere, I still do not know why people haven't make legacy the thing of the past.

These days, it does not make much sense to use Legacy addresses (1xxx...), even if you can. You should be using at least wrapped segwit legacy compatible addresses (3xxx...), but even better are the most recent segwit native addresses (bc1qxxx...)

Of course you still can, because this is a soft fork, which means that existing consensus rules and protocol are preserved. It's only *adding* new functionality to it.

It's not like they can mandate everyone to use Taproot addresses anyway.

After this update... will it still be possible to use LEGACY addresses normally? And also create raw transactions in the same way as we currently create?

in this article, which was published by bitcoinmagazine.com, taproot is explained very well and, i think, made understandable for everyone

https://bitcoinmagazine.com/technical/short-bitcoin-taproot-explainer

and here is another taproot article...

https://cryptonews.com/news/bitcoins-major-upgrade-taproot-set-for-activation-this-week.htm

Although not completely wrong but this is a very strange comment and for your information bitcoin only had 1 hard fork back in 2010 and roughly about 7 soft forks, I'm not aware of any serious chain splits during any of the soft forks.

I hope you are not thinking of forkcoins because they are not "hard forks" of bitcoin but instead they are "copies of bitcoin".