Topic: Taproot proposal - page 11. (Read 11258 times)

Yes bro, they are getting there: looking at the stats, one thing was a bit odd, Binance pool had only one block signaling taproot over 40. There are a few pools which are behaving in a weird way but maybe that is me that I do not know very much about how the whole thing works.
As I write we are above 78.08%: only 12% missing. Not so bad 

Taproot won’t be activated in this period.



We all knew that, but now it is official.
Support is growing amongst miners, and the hash power of pools that signalled activation in at least one block is now well above 90%.
Sound promising.

1st signalling block from BTC.TOP. So now there is a clear margin of over 90% of hash power that has voted in favour.

So mid June looking highly likely assuming all pools who have signalled once start signalling with all their blocks before end of May.


Wonder if that will help Bitcoin regain its dominance - as fallen to 40% recently. As a successful soft fork shows current governance processes are at least functional!

Cartel surely does not seem to be a correct word to describe bitcoin mining.. even though there seemed to have been some common interest (resistance) in the 2017 forkening drama.. but even then the factual play out of those events do not really seem to rise to the level of cartel then, and maybe even less so now.

cartel just seems like a misleading term that exaggerates and hardly describes with very much accuracy.

OK, plus the upgrade is not facing fierce resistance from the mining cartel. You’re right, if everyone is cooperative, the network should do a regular Miner Activated Soft Fork, and minimize the risks.

One block from Binance! So we have just enough pools to activate in the next period.

We just need all the pools who have signalled with one or more blocks to be singling 100% of the time (and a bit of luck) and will activate in mid June.

So now likely that Speedy Trial will be a success.

Never mind me generalizing the importance of taproot. In lowering transaction fee, taproot will focus on key aggregation in a way to favour multisig transactions, making it not distinguishable and with low fee as I explained above. As I calculated its transaction weight with that of segwit, there was only slight difference if comparing it with segwit single payment wallet.

If using native segwit instead of legacy address for transaction

• There will be 42% fee reduction for 1 input 2 output
• There will be 50% fee reduction for 10 input 2 output
• There can still be up to 52% reduction as the number of input increase

You can read this to know more about how to minimize Bitcoin transaction fee.

1. Increasing privacy
2. Blockchain data bulid up will be reduced if compared to recent multisig
4. Non-malleability, ECDSA signature malleability was addressed in BIP62
5. MuSig, that can make private smart contracts outside of the blockchain possible
6. Creating way for generalized taproot (G'root) which would be a transition from key aggregation to cross-input, making CoinJoin possible (but not sure or certain this will be allowed).

Thank you
yes, I use  legacy address , that make fee feel high
if use segwit addresses send, when sent will get lower fee right?
and in case if use segwit addresses for receive , that will help sender to paid fee lower too or not?

We aren't facing any kind of deadline after which bitcoin ceases to exist if it hasn't upgraded yet! We are also just in the second week after the release of v. 0.21.1 and I'd rather everyone upgraded naturally specially miners who run modified software not just bitcoin core as is.

Just as ETFbitcoin explained, it depends.

You can try to make use of the transaction size or weight tools calculator to calculate legacy, nested segwit, native segwit and taproot transaction fee, you can also make use of the public key per input and signature per input to calculate P2SH multisig transactions. If used correctly, you will be able to know the differences in vbytes of each which will determine how transaction fee can be.

I do not have to tell you how legacy address transaction fee will be almost twice that of native segwit addresses and as native segwit transactions have the lowest fee for now, so I will be comparing native segwit transactions with that of taproot.

If you check the transaction vsizes or vbytes of both native segwit and taproot, they are almost the same, but segwit is slightly lower which can be very insignificant. Which means for transaction that require 1 public key, the transaction fee will be almost the same for both native segwit and taproot transactions.

But taproot make use of schnorr signature to make multisig transactions indistinguishable from transactions that require just only 1 public key (normal bitcoin transactions). Multisig transaction fee is higher than normal single wallet transactions, the higher the number of public key required in a transaction, the higher the transaction fee. If segwit transaction is low, but the more the the public key still required for a transaction, the higher the fee, but the fee will be much lower if compared to legacy addresses, but taproot makes the multisig transactions indistinguishable by making use of key aggregation in which the transaction will look like single payment wallet. Which means, increase in the number of public key needed in a transaction still will require the same amount of transaction fee as that of single payment wallet.

Which means taproot reduces the fee of multisig wallets, and making its transaction indistinguishable from other Bitcoin transactions.

BTC.com, ViaBTC and Huobi have all mined one block that is signalling. So if we assume they are in the testing phase and will be onboard in next week all looking good.

Now we just need Binance Pool! (And the testing pools to signal on all bocks).

So looking positive for period 3.... so Mid June....

Fair point but a miner must be extraordinarily committed to bitcoin and its underlying values to switch from non-signalling to signalling pools. This would be a great sign anyway, any shift in this sense will be like an act of war towards the pool which refuses to signal the upgrade.
In the end it depends if the miners are here for the cash or the vision (because any pool works for getting cash). On the other side, if non-signalling pool see a decrease in their HP, well, they should get in line and update or they can prepare themselves to lose money.
I like it

Agree this period looking unlikely.

Other scenario though is that miners start moving from the non-signalling to the signalling pools. Which for them is a relatively minor change.

BTC.com has also started signaling, this time more convincingly (5/20), probably that lonely block the previous period was indeed a test. With them on board, the problem list is down to two pools that could reach 10% on their own. Binance and ViaBtc, and I'm not surprised at all by the second one.
We're not going to reach 90% this period either, so next one, I just hope we won't have to wait one period/pool.

They are, but signalling for an upgrade is simply signalling their readiness, not if they want to allow, or not to allow to upgrade. It’s not only up to them.


That’s why I believe there should be a fierce campaign for community awareness.

Are you OK if miners won’t signal for the upgrade?

Yes, because Taproot transaction size is smaller on many cases, although only noticeable on transaction with script which have multiple condition or have many inputs.


IMO Taproot won't bring much impact towards transaction fee, besides it'll take few months to years before wallet supporting Taproot.


Additional information would be great,
1. What's the number of peer/incoming connection? 10? 100? 1000?
2. How do you ban fake spy nodes? A fixed list from someone else, automatic detection or manually created list by yourself?

FWIW, 22% of my peers claim to be running 0.21.1 or 21.99.0 (master), may be because I ban a massive amount of fake spy nodes which may be diluting the figures.  I also have tor inbounds which may tend to be more frequently updated.

(To be clear, I don't claim that this little sample is representative, just adding a bit of color)

My point was to say that it is not just miners who take time to upgrade their backend and start signalling, it is also the "community" running full nodes.
I've also made a small mistake and reported the wrong percentage, it is actually 7.6% of listening nodes running 0.21.1 (the 16% was for 0.20.1) which is still good for this short time. The other one is also 0.9% which is not as good.

Yeah, I understand the point of contingency planning and being prepared for all eventualities.  But at the same time, we don't want to alienate anyone in the process.  If you start talking as though this is a foregone conclusion, miners could conceivably interpret that to mean you have no respect for their opinion, since you haven't really made an effort to find out what their opinion is yet.  If miners aren't supporting it, the first step is to open a dialogue to find out why.  It's a little premature to start talking about options like UASFs.  That sort of talk comes across as unnecessarily hostile.