When Schnorr will be added?

[Anarchist]

I didn't follow the tech recently. What is the current situation with schnorr sig
Any proposal, planned implementation, or something?

[1715078637]

1715078637

[1715078637]

1715078637

[DooMAD]

There's certainly a proposal.  You can read the BIP here and the relevant part of the roadmap here.  Even small changes take time to go through the peer-review process and this one is actually a fairly big change, so I don't believe there is a fixed date for release or anything like that.  

[RGBKey]

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

Read theymos and achow101's replies

[theymos]

There's certainly a proposal.  You can read the BIP here and the relevant part of the roadmap here.  Even small changes take time to go through the peer-review process and this one is actually a fairly big change, so I don't believe there is a fixed date for release or anything like that.  

That draft BIP is only for the details of the signature algorithm itself, since there is no standardized way to do Schnorr signatures. It's the equivalent of the SEC 1&2 standards which specify how to perform the ECDSA signing currently used in Bitcoin. That BIP needs more time for review before it is finalized, and then a separate BIP will be needed for actually integrating it into Bitcoin. I'm not following its progress too closely, but I wouldn't expect it this year.

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

[cellard]

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

[achow101]

AFAIK Schnorr don't use similar method for backward compability.

Schnorr will be added via a new segwit version number. It will not require a transaction format change, there just be a witness version 1 in addition to the current witness version 0.

[theymos]

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

Yes, Satoshi always did UASF-style softforks. AFAIK future softforks, including Schnorr, are likely to use BIP 8, which is basically a UASF with an optional miner-enabled fast-track. So miners will be able to speed things up, but not block anything.

It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.

Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)
 - SegWit outputs are interpreted by pre-SegWit nodes as being spendable by anyone, but that doesn't really mean anything. P2SH outputs were also interpreted as more-or-less spendable by anyone by pre-P2SH nodes.
 - The signature is not removed. Between SegWit nodes, every transaction must be accompanied by its signatures or it's invalid.

[achow101]

It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.

TBF, BIP 9 is very similar to the method used in previous soft forks, namely that miners signal readiness via a different version number and that the rules activate when the signalling passes a certain threshold. This had worked for several soft forks in the past, so it didn't seem like that bad of an idea. BIP 9 just made this method more sane by not having to burn version numbers and to allow for simultaneous soft forks.

[bones261]

Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.

If all of the miners decided to run non-Segwit nodes, I'm sure that would hurt the market value of BTC, and hurt their bottom line. I am sure there will eventually be at least one pool that will relent and go back to verifying segwit transactions. Or someone in this space will create a new pool that does run a segwit node. Since that pool would be paying out slightly more due to the transaction fees, many miners would switch to that pool. Other pools would probably be swayed to abandon their little boycott and start mining segwit tx again.

[cellard]

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.
And this is one of the argument used by opposition used to stall/disrupt consensus years ago.

AFAIK Schnorr don't use similar method for backward compability.

Im aware of the segwit controversies and why it caused that. My point is, there are very conservative people in bitcoin and will basically reject forever anything that isn't a legacy transaction (addresses which begin with 1 only, and nothing else, as valid bitcoin transactions).

There is people that say the incentives to do an attack on segwit aren't there, and other's say that on a long enough timeline, the incentives will align and only these holding their coins in legacy addresses will be safe (therefore, the incentive to keep your coins in legacy addresses is already formed, unless you believe this to be nonsense and you are sure it will never happen)

[piotr_n]

IMHO, the idea behind the upgrade-able witness programs, that (allegedly) won't need the miners majority suport - it is not going to work.

Just consider a simple scenario:
 * 10% of miners already upgraded to support a new witness script
 * 90% is still using the old code.

The idea in such a scenario is that the 90% of miners will not be including new type of segwit transactions in the blocks they mine.
They will also not verify such a new type of segwit transactions, inside the blocks mined by the remaining 10% (they will simply always assume these transactions as valid).

Now, what is going to happen if you have one bad miner (and I heard they are all bad;)) who decided to mine a block containing a new type of segwit transaction, but with an incorrect signature?
He would be basically spending coins which he doesn't own, from a new type of segwit address that is currently being secured by only 10% of miners.
What happens then?
It's quite simple: the 10% of miners will reject the block and will be building their blocks on top of the previous one. At the same time the 90% will accept it and continue building on top of it.
And you end up with a classic hard fork. Plus the 90% branch has been given some free coins...

So I totally disagree with the statement that it won't be needing miners support, in order to introduce schnorr or any other type of consensus change.
I mean, sure you can always try again with the UASF little boys power play politics, maybe it will even work again, but IMO social science will never beat the computer science in a long run.
Only crazy people (like BCH or BTG supporters) would stick to the branch that can be 51% attacked with only a tiny fraction of the hash power currently owned by the competitor.

[DooMAD]

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.

Is the plan to implement Schnorr itself as one upgrade and leave the key aggregation part for a separate, later upgrade?  I'm still not clear on that bit.

Also, will SIGHASH_NOINPUT and whichever other opcodes are needed for eltoo be included at the same time, or is that yet another softfork?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then).

Yes, Satoshi always did UASF-style softforks.

That sounds like a bit of a stretch, IMO.  Prior to SegWit, the network hadn't really experienced any controversies on that kind of scale when upgrading.  UASF was considered revelatory (by some) as it was specifically designed to be implemented as:

"flag day activation" where nodes begin enforcement at a predetermined time in the future.

My understanding is that all the forks that occurred while satoshi was still around did not have a "flag day" (and were categorically not presented as an ultimatum to the miners).  Arguably, the network has never seen a UASF-style softfork.  Although many believe the threat of one pressured miners into taking the action they did to activate SegWit.

[bones261]

Looks like i misunderstood, however what if all miners use non-SegWit nodes, others use SegWit nodes and there's transaction from/to Bech32 address? AFAIK this will make such transaction never confirmed/included by miners.

If all of the miners decided to run non-Segwit nodes, I'm sure that would hurt the market value of BTC, and hurt their bottom line. I am sure there will eventually be at least one pool that will relent and go back to verifying segwit transactions. Or someone in this space will create a new pool that does run a segwit node. Since that pool would be paying out slightly more due to the transaction fees, many miners would switch to that pool. Other pools would probably be swayed to abandon their little boycott and start mining segwit tx again.

Interesting theory, but there are few things that i don't understand/agree,
1. Why would price of BTC hurt? I don't see anyone would dump Bitcoin (whether it's from pro-SegWit/anti-SegWit), unless they don't care about price of BTC/losses

I would think the fact that all of the miners are colluding to boycott segwit transactions would be considered bad news to traders.

2. I don't see correlation between SegWit transaction and higher fee transaction since SegWit have lower transaction size (which leads to less fees), unless SegWit supporters intentionally do that to attract people who actually don't care about the boycott OR block is far from full and mempool only contains SegWit transaction.

A pool verifying segwit transactions in their blocks would include both non-segwit and segwit transactions. The block would have more transaction and the total fee would be a little better than a pool that verifies non-segwit transactions only.

If A is the total fee of all of the non-segwit transactions and B is the total fee of the segwit transactions, then A+B>A.

[RGBKey]

Thanks theymos and achow for clearing things up. I wasn't aware that it could be added through a change in the witness version.