Taproot proposal

[Wind_FURY]

FYI, lukejr regrets adding LOT to BIP 8

This upgrade is becoming more, and more complex than I thought. I was just trolling “in hoping” to see another drama between the miners, and the community again. I am starting to regret that Haha.

Here’s an link about LOT by Bitcoin Magazine, it’s confusing, https://bitcoinmagazine.com/technical/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation

But if less than half of all miners use LOT=true and the signaling period expires, the Bitcoin blockchain could “split” between LOT=true and LOT=false nodes. LOT=true nodes would only accept signaling blocks, even if non-signaling blocks make a longer blockchain. They would essentially be on their own “LOT=true chain.” LOT=false nodes, meanwhile, would reject the LOT-true chain in favor of the longer “LOT=false chain.”

Why didn’t the developers keep it simple, and have LOT=true as the default? Close to 90% of the miners already support Taproot, https://taprootactivation.com/

[xmready]

This upgrade is becoming more, and more complex

Chris Belcher is making the case for flag day activation.
https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/

[Wind_FURY]

This upgrade is becoming more, and more complex

Chris Belcher is making the case for flag day activation.
https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/

Didn’t we already learn from BIP148/UASF that an intolerant minority could still end with the overwhelming majority of the hashing power? I thought the upgrade was LOT=true from start to end, I was surprised that there was another political drama starting, with a “LOT=false” vs. “LOT=true”.

Shaolinfry, give us the wisdom to find the path forward, https://bitcointalk.org/index.php?topic=1805060.0

[DooMAD]

Shaolinfry, give us the wisdom to find the path forward, https://bitcointalk.org/index.php?topic=1805060.0

I'm still not convinced of that.  It's not necessarily accurate to say that a UASF can't be contentious.  I'm of the view that any time one "side" is trying to force the hand of another "side", then it's contentious.  Bitcoin depends on users, devs and miners working in unison.  Power struggles aren't conducive to that aim.

[Wind_FURY]

Shaolinfry, give us the wisdom to find the path forward, https://bitcointalk.org/index.php?topic=1805060.0

I'm still not convinced of that.  It's not necessarily accurate to say that a UASF can't be contentious.  I'm of the view that any time one "side" is trying to force the hand of another "side", then it's contentious.  Bitcoin depends on users, devs and miners working in unison.  Power struggles aren't conducive to that aim.

That’s the ideal path, but men/women being political creatures, never forget that Jihan Wu, and his friends used signalling as a political tool to hold Segwit because it would disable covert ASIC-Boost.

I believe without BIP148, Segwit would be delayed, and delayed, and delayed. Plus this is what decentralized governance is. There will be discord.

[DaCryptoRaccoon]

What exactly is LOT standing for?  

Can't seem to see anywhere what the word LOT actually references.

** Edit **

Found it..

lockinontimeout (LOT)

[Charles-Tim]

Can't seem to see anywhere what the word LOT actually references.

This is BIP8. If you want to know more about it, you can check BIP8 on GitHub. It  specifies an alternative to BIP9 that corrects for a number of perceived mistakes. Block heights are used for start and timeout rather than POSIX timestamps.

https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

It is about to force an upgrade or not to force an upgrade based on timeoutheight. 

BIP8 (true), also know as LOT=true, this mandate upgrade after 2016 block height has been reached.

BIP8 (false), also know as LOT=false, this makes upgrade to fail after 2016 block has been reached.

[icopress]

IMO miner's malicious behavior as happened with Segwit is unlikely to repeat itself. I guess people will run UASF code anyway, but it's a dangerous trend.

I would be grateful if someone could answer the two questions below. + Can anyone point me to where I can read about these events? (and it would be great if someone could point me to key links to the scaling debate that started in 2017).

• Why Insane Price Lowers Engagement in the Taproot Debate?
• Under what conditions can Taproot create backward compatibility issues?

[pooya87]

BIP8 (true), also know as LOT=true, this mandate upgrade after 2016 block height has been reached.

...it mandates upgrade regardless of how many are signalling for the upgrade.

BIP8 (false), also know as LOT=false, this makes upgrade to fail after 2016 block has been reached.

This is wrong, LOT=false simply disables LOT, it doesn't do anything to fail/pass the upgrade. The upgrade can go ahead as before when it reaches the threshold of how many should signal for it (ie. 95% of the blocks).

[xmready]

Russell O'Connor has proposed an interesting BIP8 false "succeed or fail fast" alternative.
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09604.html

[Karartma1]

We now have three different threads on Taproot and its activation path and since we are talking about the same subject I am mostly doing this for myself for further reference and to have quick links to jump from one thread to the other.
Apart from this one, which is the main thread, we are having further specific discussions on the points below regarding taproot activation

• Taproot softfork "Speedy trial" activation
• Taproot softfork lukejr removing option to lock-in on timeout...

[fillippone]

Sorry If I am rewinding the discussion a little bit, but I only recently found this article that describes quite well what the LOT=ture discussion is all about.

LOT=TRUE OR LOT=FALSE? THIS IS THE LAST HURDLE BEFORE TAPROOT ACTIVATION

The discussion around LOT=true and LOT=false remains the final hurdle in Taproot activation. So, what’s the difference and why is it important?

The article dated a few weeks back, so a few bits might be already obsolete, but of course, these are difficult topics, and a good "recap post" is often needed for the less technical plebs, like me.

[PrimeNumber7]

During 2017, miner-signalling for activation was used as a political tool to hostage/stop the network from doing an upgrade that the community wanted. BIP8/UASF is a method of activation wherein the full nodes decide, not the miners. The miners simply follow.

Does activation just mean a node is running 0.21.1 or do they have to take extra steps after the the upgrade to 0.21.1?

Put simply...

Either:

• Miners activate the fork. This happens when a certain % of miners are making blocks with a special "taproot ready" flag embedded in their mined blocks. This % of blocks must continue for ~2 weeks (for 2016 blocks)
• Users activate the fork. This happens when the timeframe for activating the fork expires

It's a little more complicated than though. Not much.

As of yet, the % for triggering the 2016 block lock-in stage hasn't been decided. Suggested figures are 90% or 95% of blocks (95% was used for some recent fork activations). The overall timeframe is also not exactly decided, but 1 year (measured in blocks...) seems to be a popular suggestion.

It is trivial to create an unlimited number of full nodes, and the cost of doing so is near zero. It is not trivial to purchase and operate a miner, and the cost of mining is far from zero. The miners have a real economic incentive to do what is best for the long term interests of bitcoin.

The above does not mean that miners should have absolute veto power over changes to consensus rules, but it does mean that miners should first be consulted before changes to consensus rules are made. It will always be best to get the miners to agree to changes to consensus rules, and if they do not initially agree, substantial effort should be put into trying to convenience the miners that said changes are in the best long term interest of bitcoin (and the miners' long term business interests). Rejection of changes to consensus rules by the miners should be given significant consideration and the community should consider if it is best to move forward with changing consensus rules without the consent of the miners.

To put the above a different way, a BIP should be first attempted to be implemented via gaining the consent of the miners. If the miners do not agree to implement a BIP, a USAF can be considered, but significant weight should be placed on the fact that the miners do not believe the BIP is in the long term best interests of bitcoin. A USAF implementation of a BIP will be contentious, and it is always better to implement a BIP via non-contentious means.

[Wind_FURY]

During 2017, miner-signalling for activation was used as a political tool to hostage/stop the network from doing an upgrade that the community wanted. BIP8/UASF is a method of activation wherein the full nodes decide, not the miners. The miners simply follow.

Does activation just mean a node is running 0.21.1 or do they have to take extra steps after the the upgrade to 0.21.1?

Put simply...

Either:

• Miners activate the fork. This happens when a certain % of miners are making blocks with a special "taproot ready" flag embedded in their mined blocks. This % of blocks must continue for ~2 weeks (for 2016 blocks)
• Users activate the fork. This happens when the timeframe for activating the fork expires

It's a little more complicated than though. Not much.

As of yet, the % for triggering the 2016 block lock-in stage hasn't been decided. Suggested figures are 90% or 95% of blocks (95% was used for some recent fork activations). The overall timeframe is also not exactly decided, but 1 year (measured in blocks...) seems to be a popular suggestion.

It is trivial to create an unlimited number of full nodes, and the cost of doing so is near zero. It is not trivial to purchase and operate a miner, and the cost of mining is far from zero. The miners have a real economic incentive to do what is best for the long term interests of bitcoin.

The above does not mean that miners should have absolute veto power over changes to consensus rules, but it does mean that miners should first be consulted before changes to consensus rules are made. It will always be best to get the miners to agree to changes to consensus rules, and if they do not initially agree, substantial effort should be put into trying to convenience the miners that said changes are in the best long term interest of bitcoin (and the miners' long term business interests). Rejection of changes to consensus rules by the miners should be given significant consideration and the community should consider if it is best to move forward with changing consensus rules without the consent of the miners.

To put the above a different way, a BIP should be first attempted to be implemented via gaining the consent of the miners. If the miners do not agree to implement a BIP, a USAF can be considered, but significant weight should be placed on the fact that the miners do not believe the BIP is in the long term best interests of bitcoin. A USAF implementation of a BIP will be contentious, and it is always better to implement a BIP via non-contentious means.

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

[PrimeNumber7]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

[Wind_FURY]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?

IMO miner's malicious behavior as happened with Segwit is unlikely to repeat itself. I guess people will run UASF code anyway, but it's a dangerous trend.

I would be grateful if someone could answer the two questions below. + Can anyone point me to where I can read about these events? (and it would be great if someone could point me to key links to the scaling debate that started in 2017).

https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

[PrimeNumber7]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.

SegWit was implemented after the miners agreed to the upgrade. A USAF upgrade was threatened, but this threat was never carried out. Read the article you posted, especially the last several paragraphs.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?

BIPs should be implemented the same way they are implemented now. Once a BIP is agreed upon and put into the codebase by the devs, the miners should signal support or opposition to a BIP via their found blocks.

[Wind_FURY]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.

SegWit was implemented after the miners agreed to the upgrade. A USAF upgrade was threatened, but this threat was never carried out. Read the article you posted, especially the last several paragraphs.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?

BIPs should be implemented the same way they are implemented now. Once a BIP is agreed upon and put into the codebase by the devs, the miners should signal support or opposition to a BIP via their found blocks.

What if the miners hold the network hostage again by not signalling readiness for an upgrade the community wants?

[DooMAD]

ASK
ask
ask

Translation:  "No one is allowed to do anything unless I say so".

So much for permissionless, I guess.  Unless of course, everyone simply ignores you, which they will.

If you have an issue, raise it on GitHub.  That's what it's there for.  Have all the discussion you want.  They're not begging for your approval, though.

[PrimeNumber7]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.

SegWit was implemented after the miners agreed to the upgrade. A USAF upgrade was threatened, but this threat was never carried out. Read the article you posted, especially the last several paragraphs.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

This is speculation. What ultimately matters is the economic supermajority.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?

BIPs should be implemented the same way they are implemented now. Once a BIP is agreed upon and put into the codebase by the devs, the miners should signal support or opposition to a BIP via their found blocks.

What if the miners hold the network hostage again by not signalling readiness for an upgrade the community wants?

I previously discussed this possibility. If a BIP is not receiving support from the miners, the community could consider implementing a USAF, while taking into consideration the amount of support the miners gave. As I mentioned before, there is a difference between a small minority of miners supporting a BIP and a miner basically using veto power to oppose a BIP. The community should also consider alternatives to a USAF, such as lowering the activation threshold or modifying the BIP in a way that makes the miners more comfortable.

As I previously stated, the miners are the only entity that cannot fake their level of support. It is trivial to run an arbitrary number of fakes nodes, it is trivial to create an arbitrary number of online personas, and it is trivial to send many transactions to yourself to make it appear your business has a lot of economic activity, when your business does not have any customers.