Pages:
Author

Topic: Taproot proposal - page 16. (Read 11516 times)

legendary
Activity: 2898
Merit: 1823
April 09, 2021, 01:35:54 AM

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.


That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.
legendary
Activity: 3472
Merit: 10611
April 09, 2021, 01:29:49 AM
In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.
It wasn't because of the futures fake markets but because they saw that going ahead with the hard fork part of SegWit2x would split bitcoin and it was not in their best interest. Believe it or not miners have a bigger stake in bitcoin since they both invest in equipment and bitcoin at the same time. Unlike nodes ore regular users who many not even own any bitcoin (anything at stake).

Quote
~ a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.
Proposals should be discussed and then approved/rejected based on their merits not based on what the
market (day traders who only care about their short term profit) think. Keep in mind that it is very easy to manipulate the market price on a centralized exchange specially when not enough people turn to that option.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
April 09, 2021, 01:15:14 AM
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,

The point you're trying to make is a valid one, but your expression of it isn't technically correct.  Miners can easily fake their 'support' for any flag, and they often have in the past-- e.g. signaling BTC1 when they weren't running it and had zero intention of ever running it.
I suspect major mining pools are running their own custom implementations of bitcoin for broadcasting, receiving, and validating blocks. 

In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.

So while it's true that miner signaling is sybil resistant,  the mining pools signaling flags don't necessarily have much skin in what they signal, so fairly little incentive to do so honestly.  This is particularly true because the parties with an investment in hardware are hashers (whom don't control the flags) and not pools (who do control the flags. 
The mining pools earn income from the blocks they mine, and they need to invest in infrastructure to allow their pool to operate. If a pool has fewer hashers, it will have less income. It is also trivial for hashers to move their miners to pools that are signaling for or against a proposal that is in line with the long-term best interest of bitcoin. If a pool is signaling for or against a proposal that is not in bitcoins best interest, it will lose customers.


Many pools have significant altcoin investments and it's not too hard to imagine a kickback or altcoin play making fake signaling in a pool's interest.  Even hashers can move hashpower to altcoins that might gain value if Bitcoin had issues.
I would have to disagree with the bolded part of your statement. The altcoins that can be mined using ASIC miners that can also mine bitcoin have a very low network hashrate as a function of the hashrate of the bitcoin network. If 1% of the hashers (measured by hashrate) currently mining bitcoin were to move to bitcoin cash, the difficulty would more than double, which means the price of bitcoin cash would need to more than double for the hashers to have the same amount of revenue. This is simply not something that will scale for enough hashers to oppose a bitcoin proposal whose failure would benefit bcash. Even if it did scale, once these hashers start mining bcash, any proposal whose failure would benefit bcash could subsequently be implemented.

The real unfakable metric is the eventual market price of the asset -- but we can't know that in advance, only make educated guesses.
I mentioned futures markets for various fork-coins above. Any futures market would need to either be centralized, or run on an altcoin blockchain, such as etherum in order to be reliable.

My position continues to be that it is best to get miners' consent prior to implementing a fork (soft or hard). If there is a BIP proposal that is receiving pushback from the miners (based on what they are signaling), or if the miners are signaling support for a "bad" BIP proposal, a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.
legendary
Activity: 3472
Merit: 10611
April 08, 2021, 11:21:19 PM
~
The argument is flawed because security of Bitcoin is not defined based on individual outputs but as a whole system. If some day the technology advances enough to be able to reverse a 256-bit public key to get its corresponding private key that means Bitcoin as a whole becomes insecure and whether or not Taproot is using public key is not going to change that.
legendary
Activity: 2310
Merit: 1422
April 08, 2021, 11:53:51 AM
I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss! Grin
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?
It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.
I see, thanks for clarifying. I understand that from a press point of view it is very clickbaity and juicy to use such wording and avoiding to be specific. Shame on them as usual.
Now, whatever the way we should move on, let's get this upgrade on its way.
legendary
Activity: 2730
Merit: 7065
April 08, 2021, 10:00:58 AM
It doesn't look like anyone mentioned the article I just read by Mark Friedenbach, so I thought I would mention it here. If it was discussed, I apologize.

It's this one:
https://freicoin.substack.com/p/why-im-against-taproot.
He discusses Taproot and reasons why he is against its activation.

Mark fears that exposing the public key within the output on the blockchain downsizes Bitcoin's quantum protection. If and when quantum computers that are powerful enough to attack secp256k1 are created, they could (potentially) calculate the private key from a public key. The way Bitcoin works now, public keys are exposed when the coins are spent. With Taproot, they are exposed right away after an output is created.

According to Mark, it's quite possible that a quantum computer that can become a treat to Bitcoin can see the light of day by the end of this decade:
Quote
We’re only about six doublings away from the scale needed to attack secp256k1 using current algorithms. At about 18 months between doublings, that could be as soon as the end of the decade.

The article goes on to mention that 6.25 million bitcoins in 2019 were kept at addresses whose public keys are known. If the algorithm gets broken, it's those coins that become vulnerable. Another good reason not to reuse addresses. 

When Taproot gets activated (because I assume it will), what is currently being done on improving the security of the network where the public keys will become exposed as soon as an output is created (if I understood Mark's concerns properly)? Quantum computers could be something we have to worry about in 10-20 years, but what if the technology becomes available sooner? We will have Taproot, but how soon can quantum-resistant solutions be built?

Does Mark have valid concerns or is he wrong? I read somewhere that the exposed public keys with Taproot could get hashed preventing possible private key calculations in that way. Is that the way to go or what happens next?
staff
Activity: 3458
Merit: 6793
Just writing some code
April 07, 2021, 02:57:05 PM
I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss! Grin
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?
It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.
legendary
Activity: 2310
Merit: 1422
April 07, 2021, 02:52:58 PM
I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss! Grin
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?
staff
Activity: 4242
Merit: 8672
April 04, 2021, 08:28:22 PM
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,

The point you're trying to make is a valid one, but your expression of it isn't technically correct.  Miners can easily fake their 'support' for any flag, and they often have in the past-- e.g. signaling BTC1 when they weren't running it and had zero intention of ever running it.

So while it's true that miner signaling is sybil resistant,  the mining pools signaling flags don't necessarily have much skin in what they signal, so fairly little incentive to do so honestly.  This is particularly true because the parties with an investment in hardware are hashers (whom don't control the flags) and not pools (who do control the flags.  Many pools have significant altcoin investments and it's not too hard to imagine a kickback or altcoin play making fake signaling in a pool's interest.  Even hashers can move hashpower to altcoins that might gain value if Bitcoin had issues.

You could imagine a scheme where people pay _ethereum_ into a black hole to vote for bitcoin proposals. ... it would be an unfakable measurement, but if anything it would be anti-correlated with the wants and best interest of the Bitcoin community. Smiley

More generally,  we should always be careful when we're substituting what we can measure with what we need.  Measuring hashpower is probably only a reliable proxy when people haven't realized that they can game it, and we know for a fact now that they have.

The real unfakable metric is the eventual market price of the asset -- but we can't know that in advance, only make educated guesses.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
April 04, 2021, 04:24:38 AM

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.
legendary
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
March 31, 2021, 03:25:13 AM
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.
legendary
Activity: 2898
Merit: 1823
March 17, 2021, 04:46:27 AM

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?
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
March 17, 2021, 01:39:56 AM

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.
legendary
Activity: 2898
Merit: 1823
March 17, 2021, 01:08:08 AM

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”.

Quote from: Cøbra

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
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
March 16, 2021, 10:27:37 AM

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.
legendary
Activity: 2898
Merit: 1823
March 16, 2021, 07:01:44 AM
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.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
March 16, 2021, 02:23:10 AM
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.
legendary
Activity: 2268
Merit: 16328
Fully fledged Merit Cycler - Golden Feather 22-23
March 11, 2021, 07:28:59 PM
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

Quote
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.
legendary
Activity: 2310
Merit: 1422
March 07, 2021, 06:18:41 AM
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
Wink



copper member
Activity: 37
Merit: 14
March 07, 2021, 01:29:58 AM
Russell O'Connor has proposed an interesting BIP8 false "succeed or fail fast" alternative.
https://www.mail-archive.com/[email protected]/msg09604.html
Pages:
Jump to: