Taproot proposal

[JayJuanGee]

I hate to jinx this, but I am going to report anyhow on a seemingly near inevitability that this thingie is getting locked in this period.

Of course, getting the information from https://taproot.watch/

I understand that no one wants to count their chickens before they are hatched, and I am in that same camp.. so I would not be saying anything if I thought that there were some kind of meaningful and material risk that my celebration could be gamed in such a way to show that I am wrong (or to prove me wrong).. because no one is going to give any shits about what I say or think (except maybe my mom).

What I am trying to say is that there has to be some pretty damned extreme changes in miner behavior for this thing NOT to get locked in this difficulty period.. not out of the question.. but still odds?  I am going to say without specifying too much... "quite low".. and that is another reason for this ccccciiiiiiiittttttttteeeeee post.

As I type, we have about 97.85% of the blocks having had already signaled for taproot - more specifically - 1,093 out of 1,117 that have already been mined.

We also have ONLY 899 blocks remaining for the difficulty period and only 722 (which is 80%) have to signal for taproot to reach the 90% threshold.

As I type, I am considering opening up my specially-dedicated champaign right now, and maybe treating myself to an especially-dedicated slurpy too.  #justsaying.. call me premature, if you must.. I don't give no cares.        

[gmaxwell]

It would be neat if taproot.watch would add a indicator on how low the signaling would have to fall to block it this period.

[cAPSLOCK]

You know... it's funny.

I am certainly among those who are happy to see Taproot being activated both so smoothly, and quickly!

But I kind of think there is a bigger story in this taproot activation that we are not quite grasping yet.

That was the fact that this has been (please apply JJGs jinx disclaimer here as well) an absolute tour de force for bitcoin governance.  We have proven that not only can the network be upgraded, but it can be done in a clear, orderly, quick fashion!

It even makes me think that when time and tech converge along with bitcoin network use we *might* even be able to see something more controversial, like a block size increase, be implemented in the same way.  Again, this would be when consensus was there, and all the stakeholders were ready, etc.  If ever. Just saying.

In the aftermath of the SegWit activation I think we may have become overly pessimistic about what we may or may not be able to do insofar as network upgrades/tweaks.  The reason I chose the idea of the block size increase for this statement was because truly I did not think we would have a chance of something like that as the protocol began to be more and more set in stone.  Maybe not?!?

[franky1]

taproot did not impose any force measure.
there were some issues in regards to segwit. such as that it 'increase capacity 2.4x' and 'cheap fee pledges'*, which were obvious empty/false pledges and those 2 things were the 2 things people actually wanted at the time

taproot is different. its not really over promising anything
its not pretending to offer one thing but offer something else
its not attempting to force itself

so there is no controversy or resistance

taproot does not really hurt legacy/native users. if people want to use taproot they first have to move funds into taproot addresses.
segwit did hurt legacy users. eg: (WITNESS_SCALE_FACTOR = 4;) means legacy tx became more expensive*

so because taproot devs are not playing these flip flop false promise backstabbing games this year. they are not getting any drama towards taproot

*to name a few

EDIT to answer gmax below....


pre segwit activation blocks reached peak of 2.5k average tx per block..
post segwit activation blocks reached a peak of 2.7k average tx per block..check all time graph
so gmax misinforms about a +10% coupleday peak.. but 0% 3 year average change as his answer to 'cheap'
but does not acknowledge the 4x premium his friends added to the code that disadvantage 60% of users

witness scale factor is used to make legacy transactions 4x more than segwit
everyone knows that a hard data real byte of legacy is trapped into being recognised as a more bloated 'vbyte of 4x its actual hard drive stored size
its the very reason while the blocks can be 4mb bitcoin code can only store 1mb of legacy per block
search github and you will find this x4 premium in many examples of * WITNESS_SCALE_FACTOR
1, 2, 3, 4, 5, 6

theres more but i limited myself to spending just 20 seconds in debunking gmax. anyone can find these multipliers in 20 seconds.. even gmax
segwit dies not discount transactions. it just avoids a premium.
and not by just a segwit activation giving all bitcoin users a discount/ avoid premium fee.
but only those specifically having a segwit UTXO get this avoid premium fee

gmax. atleast be honest about how your team decided to play around with the fee structure to disadvantage legacy address users and try to promote/incentivise segwit users to try converting people

[gmaxwell]

segwit did hurt legacy users. eg: (WITNESS_SCALE_FACTOR = 4;) means legacy tx became more expensive*

That isn't true. Segwit increased capacity and as a result lowered fees for everyone, maybe not as much as you would like but that doesn't justify spreading hateful misinformation.

[xmready]

MARA Pool has signaled for two blocks   

[pooya87]

We have proven that not only can the network be upgraded, but it can be done in a clear, orderly, quick fashion!

To be fair we had proven this half a dozen times (maybe more) before the 2017 fork when each upgrade went through smoothly and without any drama or at least very little. BIP16, BIP34, BIP65, BIP66, BIP112 are some of these soft forks that I can think of.

so because taproot devs are not playing these flip flop false promise backstabbing games this year. they are not getting any drama towards taproot

Wrong. The lack of "drama" is simply because unlike 2017 there is nothing to be gained from that drama. For example there is no shitcoin like bcash to be created to make money.

[PrimeNumber7]

so because taproot devs are not playing these flip flop false promise backstabbing games this year. they are not getting any drama towards taproot

Wrong. The lack of "drama" is simply because unlike 2017 there is nothing to be gained from that drama. For example there is no shitcoin like bcash to be created to make money.

When SW was being proposed, there was a community debate if bitcoin should be hard forked to allow for a max block size increase. SW was an alternative to increasing the maximum block size via the use of signature weights.

There is no alternative proposals to Taproot, and there is no serious technical opposition to it either, that I am aware of. I suspect the delay in signaling support for Taproot by the miners is due to them reviewing the code, running their own tests, and checking for security vulnerabilities.

[vjudeu]

It even makes me think that when time and tech converge along with bitcoin network use we *might* even be able to see something more controversial, like a block size increase, be implemented in the same way.  Again, this would be when consensus was there, and all the stakeholders were ready, etc.  If ever. Just saying.

This is not necessary. I can imagine some future Segwit version with Pedersen Commitments (without hiding amounts to make it small enough). Then, bigger blocks won't be needed if you could deposit your coins to some new address that will allow you to join many transactions together. I think if we have transaction chain A->B->C->...->Z, then there is no need to increase block size. What really is needed is storing A->Z transaction and make it resistant for double-spending attempts.

I wonder if joining transactions could be done with taproot. So far, I have no idea how to make it in a safe way, but if it could be reduced to ECDSA keys, then they could be joined with Schnorr signatures, so maybe there is some way to do so.

[cAPSLOCK]

We have proven that not only can the network be upgraded, but it can be done in a clear, orderly, quick fashion!

To be fair we had proven this half a dozen times (maybe more) before the 2017 fork when each upgrade went through smoothly and without any drama or at least very little. BIP16, BIP34, BIP65, BIP66, BIP112 are some of these soft forks that I can think of.

so because taproot devs are not playing these flip flop false promise backstabbing games this year. they are not getting any drama towards taproot

Wrong. The lack of "drama" is simply because unlike 2017 there is nothing to be gained from that drama. For example there is no shitcoin like bcash to be created to make money.

Very valid.  Yet I still think it is good, especially for the users who are not as keen about the details of past BIPs as well as development in general needed *this* particular upgrade to go smoothly.  I think it was palpably still tentative feeling out there because of all the drama in 2017.

Seems we are going to be dragging the shitcoins behind us possibly indefinitely, but it's becoming more and more dangerous for them to try to get in front of us.  The weight and momentum of Bitcoin is greater than it was a few years ago.

[JayJuanGee]

It would be neat if taproot.watch would add a indicator on how low the signaling would have to fall to block it this period.

Here's an update about Taproot (after a distracted comment about price):

I know.  I know.  I know.  Some people are getting depressed about ongoing testing of buy support and wondering how far the low is going to be able to go ...and many (including yours truly) don't want to say anything.. which is understandable - even if we have positive happenings of getting more and more good news about Taproot getting locked in during this difficulty period, that a day ago, I had already asserted, with a wee tiny bit of trepidation, to be in the ballpark of inevitable ... ..

So, since my post from yesterday (see my numbers and link below), we have had 3 blocks signal "no" (1.8%) and the other 167 blocks signaled "yes" (98.2%).

As I type, we have about 97.98% of the blocks having had already signaled for taproot - more specifically - 1,258 out of 1,284 that have already been mined.

We also have ONLY 732 blocks remaining for the difficulty period and only 557 (which is 76.09%) have to signal for taproot to reach the 90% threshold (but who is counting?).

As I type, we have about 97.85% of the blocks having had already signaled for taproot - more specifically - 1,093 out of 1,117 that have already been mined.

We also have ONLY 899 blocks remaining for the difficulty period and only 722 (which is 80%) have to signal for taproot to reach the 90% threshold.

[BrewMaster]

i couldn't figure one thing out here after this period ends assuming that taproot gets locked in are we going to start rejecting those blocks that don't signal for taproot or does it all end and we forget about it until November that it activates then reject them?

[NotATether]

i couldn't figure one thing out here after this period ends assuming that taproot gets locked in are we going to start rejecting those blocks that don't signal for taproot or does it all end and we forget about it until November that it activates then reject them?

They won't start rejecting blocks immediately even though lockinontimeout=true, because the timeout is all the way at the end of October. That's when non-signaling blocks will start being rejected. It will not be activated at the end of a successful signaling period.

[Carlton Banks]

They won't start rejecting blocks immediately even though lockinontimeout=true, because the timeout is all the way at the end of October. That's when non-signaling blocks will start being rejected. It will not be activated at the end of a successful signaling period.

hmmm, I thought that the October/November activation simply permits witness v1 spends? (and so any non-upgraded miner will reject blocks containing witness v1 spends, and subsequently find themselves mining a fork)

[gmaxwell]

No blocks will be rejected unless they contain an invalid taproot spend after the lock-in height or are a descendant block of a block that has an invalid spend.  By invalid I mean breaks the taproot rules, e.g. last a signature or has one that doesn't pass validation.

The normal construction of softforks tries pretty hard to avoid creating any conflicting chain, as much as is possible.

[franky1]

as long as this activation does not include code/rule to only accept a new flag number/version number block then no hardfork/no mandatory split will occur.. thankfully
so far no plans to do so.. thankfully this time

as usual and has always been the case
blocks that dont meet the rules of validation get rejected as standard.
as gmax said

meaning and as already said in previous posts.
(unupgraded nodes blindly accept new tx formats)

the only fork risk is if non-upgraded nodes blindly accepts a duff(bad/error/invalid) block which a upgraded node rejects as part of normal consensus.
 
and the unupgraded node is continually getting new blocks that build ontop of the duff block.
but this is like a below 0.0025% chance of occuring. and only affects that small percentage of users in that case. so not a 5% or 50% risk. but a 0.0025% risk. and only to those in that small group

meaning an igornant/intentional pool and a few nodes solely peered to it, will have to intentionally build ontop a duff block for them to make their own altcoin

[kano]

...
meaning and as already said in previous posts.
(unupgraded nodes blindly accept new tx formats)

the only fork risk is if non-upgraded nodes blindly accepts a duff(bad/error/invalid) block which a upgraded node rejects as part of normal consensus.
 
and the unupgraded node is continually getting new blocks that build ontop of the duff block.
but this is like a below 0.0025% chance of occuring. and only affects that small percentage of users in that case. so not a 5% or 50% risk. but a 0.0025% risk. and only to those in that small group

meaning an igornant/intentional pool and a few nodes solely peered to it, will have to intentionally build ontop a duff block for them to make their own altcoin

Alas this is the majority of the Bitcoin hashrate.

While it is only a short timeframe after each block change, the majority of the network hashrate will mine on an invalid transaction for a short period of time after the block change.

As I've mentioned before, the issue is if anyone else then finds a quick block without any invalid transactions in it, on top of the invalid one, what pools will continue on that block, and for how long?

[franky1]

While it is only a short timeframe after each block change, the majority of the network hashrate will mine on an invalid transaction for a short period of time after the block change.

majority of network does not just stop mining their own block attempt when first seeing a new block header.
majority of network actually continues its block effort until a new block is validated.

less than 0.5% of blocks are 'empty blocked' (280blocks of 58k are empty(2020stats))
adding to that the amount of pools that are not signalling for TR is under 5%

so at very max its a 0.5% of 5%. meaning with other factors at play. the end the result is a 0.0025% risk
definitely not a 'majority of network will mine'

so calm down(seems im repeating myself)

As I've mentioned before, the issue is if anyone else then finds a quick block without any invalid transactions in it, on top of the invalid one, what pools will continue on that block, and for how long?

um i dont think any would. as the odds are super low
as there is no large economic incentive /positive reason to waste so much cost on doing this intentionally. (standard game theory)
but it seems you believe majority of pools will do this because its your belief that majority of pools do use crappy stratums and spv wallets and do empty blocks as standard.. so maybe you should be asking yourself which pools would be doing this.

[kano]

While it is only a short timeframe after each block change, the majority of the network hashrate will mine on an invalid transaction for a short period of time after the block change.

majority of network does not just stop mining their own block attempt when first seeing a new block header.
majority of network actually continues its block effort until a new block is validated.

No idea who you got that statement from, but it's not true.

less than 0.5% of blocks are 'empty blocked' (280blocks of 58k are empty(2020stats))

Yep, that's the time spent mining on non-validated blocks.
average 600 seconds per block, 0.5% gives an average of 3 seconds per block change.

so at very max its a 0.5% of 5%. meaning with other factors at play. the end the result is a 0.0025% risk
definitely not a 'majority of network will mine'

Not a very small number ... though using your numbers 0.5% times 5% is ... 0.025%
As I've made clear before, the issue is what the other pools do on top of the following valid block if it is quick.

Statistics says it doesn't matter how long it took to find the first block, since it's already been found, the next block is the same probability or 0.5% chance of finding a quick block on the empty block and continuing the bad chain.

In the past when this happened, two big pools went off on their own invalid chain, with a hash rate close to half the network, and continued that until FUPool noticed the issue in their discussion channel and I contacted Bitmain.

um i dont think any would. as the odds are super low
as there is no large economic incentive /positive reason to waste so much cost on doing this intentionally. (standard game theory)
but it seems you believe majority of pools will do this because its your belief that majority of pools do use crappy stratums and spv wallets and do empty blocks as standard.. so maybe you should be asking yourself which pools would be doing this.

It has nothing to do with wallets, it's to do with SPV mining - though that term has been modified after it's inception to include something else.

I guess the more recent name is 'Spy-mining' where a pool gets the work change from a miner connected to other pools, and uses the header in the miner to switch to the next block.
Since they don't know what transactions were used to produce the block, they must mine an empty block until they get and verify the full block.
Same can be done with a hacked bitcoind itself and use the header when it's first received before validating the block, and again the same reason: they don't know what transactions where used yet, so must mine an empty block until they verify it.

However, it's simply a case of ignorance, resistance to change and following what the other big pools do.

Edit: if you wish to test this, mine on a large pool that produces empty blocks and look at the 1st work sent each block change.

[franky1]

oh kano...(facepalm)
no the 0.5% is not some time conversion meaning 3 seconds(your premiss)
its actually the blocks that occured throughout 2020 where out of 58000 blocks only 280 of them were empty blocks. its got nothing to do with YOUR "3 second" maths of 600seconds / 5%.

its got everything to do with the small insignificant utility of doing empty blocks

anyway. as for your "not sure where you got that statement from but its not true"
i quoted YOU. infact you quoted me quoting you. thus double obvious where that statement came from

seems your forgetting what you wrote and then spinning a different version of events as if you never said the first version of events you implied even when its clearly been quoted of what you said

one last time.. so take a seat. relax and slowly understand things. have a cup of coffee after and actually let the information be absorbed.
YOU said majority of network would build onto a invalid block..
I SAID no. majority of blocks are NOT built ontop of via the 'empty block strategy'
as proven by only 280 blocks out of 58000 blocks statistic

i debunked you by showing you the under 280 of 58000 stat for 2020. which shows that majority of pools DO NOT build ontop of invalid blocks due to the low amount of empty block strategy being used.

i hope you get it now. accept that empty block strategy is not used as often as you presume

.
now a reminder of the math. for the last time. so please allow it to soak in
0.5% is the number of empty blockers (those who build on a block thats not been validated yet)
5% is the under 5% that have not signalled a desire to upgrade to TR
=under 0.025% that 'could' ignorantly accept an errored block
then with other factors included..(basically assuming a 10% risk/intent) puts it at a 0.0025% risk of an intentional event.

...
so lets just pretend you stepped a few steps forward and realised the chance of it happening is 0.0025%

your then asking what about those that then build on top of that
seriously your talking about "those".. meaning you want to interrogate who the 0.0025% pools are
well it does not matter in the end. as its a small insignificant proportional risk of a insignificant amount that would want to make an alt. and even if they did. so be it. they are an alt.. bye bye moving on

meaning 99.975% have rejected that block and moved on and just accepting normal blocks
yawn. no drama. non event. didnt even notice it happen coz its such an insignificant event
just like all other orphans that have ever occured in the last 12 years that no one talks about or realised even occured unless they specifically went and looked

realise that is like a negligible amount/opportunity that would make their own altcoin if they wished to proceed down their path. and thus it does not impact the rest of the network
..
the orphan rate drama just self regulates it out.
at a risk of 0.0025%
a meaningless number of insignificance

again.. the chances of a pool making an empty block is about 280 out of say 52k+
the chances of a empty block building ontop of a faulty block due to not being an upgraded node is even less
the chance of a pool  normal game theory incentive. and intentionally wanting to cause an error even less

so please stop saying/thinking that majority of the network does the empty block strategy, let alone other false presumptions
because stats show the very opposite.

majority of stratum servers(pools) are NOT SPV nodes making empty blocks

this is the final time im going to repeat myself. because it seems you are not understanding stats and numbers and quotes
step passed your pre conceived notion that majority of pools are amateurs that use crappy stratum software.
as thats not reality.