Schnorr + Taproot Soft Fork and What this Means to Bitcoin

[Darker45]

I have come across this news and I decided to create a thread here for the sake of discussion. Terms such "PROMISES BIG THINGS FOR BITCOIN" and "breakthrough for Bitcoin?" prompted me to do so. Perhaps some technical wiz could provide a friendly breakdown as to what this really means to all of us. For us laymen, who are not too familiar with the technical nitty-gritty of Bitcoin development, this could remain fuzzy.

Although this has been in the development pipeline for sometime, the adoption could take place in the late 1st quarter and early 2nd quarter of next year. That would be around 5 months from now.

In a nutshell this is what it looks like. There are basically three areas where development is focused.




Sources:
https://bitcoinist.com/schnorr-taproot-soft-fork-promises-big-things-for-bitcoin/
https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/

[1713899703]

1713899703

[1713899703]

1713899703

[1713899703]

1713899703

[dothebeats]

As I've read awhile ago concerning ECDSA and Schnorr algorithm, they went for ECDSA in generating cryptographic signatures simply because it's much more common in a lot of crypto libraries. Schnorr has its own merits, that's why a lot of developers are actually supporting and pushing it over ECDSA. Let me cite a few lines from Pieter Wuille's draft in Schnorr algorithm:

Bitcoin has traditionally used ECDSA signatures over the secp256k1 curve for authenticating transactions. These are standardized, but have a number of downsides compared to Schnorr signatures over the same curve:

• Security proof: The security of Schnorr signatures is easily provable in the random oracle model assuming the elliptic curve discrete logarithm problem (ECDLP) is hard. Such a proof does not exist for ECDSA.
• Non-malleability: ECDSA signatures are inherently malleable; a third party without access to the secret key can alter an existing valid signature for a given public key and message into another signature that is valid for the same key and message. This issue is discussed in BIP62 and BIP66. On the other hand, Schnorr signatures are provably non-malleable.
• Linearity: Schnorr signatures have the remarkable property that multiple parties can collaborate to produce a signature that is valid for the sum of their public keys. This is the building block for various higher-level constructions that improve efficiency and privacy, such as multisignatures and others.

Figures and technicalities speak for themselves. The only apparent problem with Schnorr algorithm is that not all crypto libraries have it, or it's not standardized yet.

[NeuroticFish]

I've also read that if implemented, this will help in fungibility. This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.
It can improve the anonymity by a great deal. I also don't know how much will the exchanges and financial regulators (dis)like this (isn't Monero out of the major exchanges in Japan?).

I also don't know much about the other benefits, it can help the multisig, but I don't know how much and some simple explanation for start could help.
I'll also add a link I've found, but didn't read it all yet, since it contains too many references to things I don't know yet https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287

[hv_]

... darkening the protocol - put btc more on black lists

[LeGaulois]

As I've read awhile ago concerning ECDSA and Schnorr algorithm, they went for ECDSA in generating cryptographic signatures simply because it's much more common in a lot of crypto libraries. Schnorr has its own merits, that's why a lot of developers are actually supporting and pushing it over ECDSA. Let me cite a few lines from Pieter Wuille's draft in Schnorr algorithm:

No, it's not the reason. If Bitcoin uses ECDSA it's because it couldn't make use of Schnorr's signature scheme because it was patented (it's ~30 years old), only recently it became public. Technically Schnorr's signature scheme has a simpler structure. Now it's open the dev. want to use it

I've also read that if implemented, this will help in fungibility. This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.

Say a group of n signers want to authorize an action (say, spend
some bitcoins) only if all of them agree, but do not necessarily wish to reveal
their individual public keys. Then, they can privately compute the aggregated
key Xe corresponding to their multiset of public keys and publish it as an ordinary
(non-aggregated) key. Signers are ensured that all of them will need to cooperate

https://eprint.iacr.org/2018/068.pdf

[Darker45]

... darkening the protocol - put btc more on black lists

Simply because of increasing privacy? Is that what you mean? Will the improved privacy through this soft fork enough to classify Bitcoin alongside Monero, Dash, ZCash, and other privacy coins?

No, it's not the reason. If Bitcoin uses ECDSA it's because it couldn't make use of Schnorr's signature scheme because it was patented (it's ~30 years old), only recently it became public. Technically Schnorr's signature scheme has a simpler structure. Now it's open the dev. want to use it

Hence the speculation that the algorithm was not included by Satoshi Nakamoto when he designed Bitcoin due to Schnorr's existing patent back then.

Perhaps some technical wiz could provide a friendly breakdown as to what this really means to all of us. For us laymen, who are not too familiar with the technical nitty-gritty of Bitcoin development, this could remain fuzzy.

1. Both of them reduce transaction size which means :

• You'll pay less transaction fees
• A block can contain more transaction, which can be seen as minor on-chain scaling

But is it comparable to the almost zero fees provided by the Lightning Network? Although LN of course is primarily designed for smaller and day to day transactions and is basically off-chain.

2. Both of them offer better privacy (through different method)

Exactly in a manner that NeuroticFish has shown?

This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.

[Kyraishi]

I've also read that if implemented, this will help in fungibility. This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.
It can improve the anonymity by a great deal. I also don't know how much will the exchanges and financial regulators (dis)like this (isn't Monero out of the major exchanges in Japan?).

I also don't know much about the other benefits, it can help the multisig, but I don't know how much and some simple explanation for start could help.
I'll also add a link I've found, but didn't read it all yet, since it contains too many references to things I don't know yet https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287

That's interesting. I didn't actually know a lot about fungibility since this post. I'm assuming the features this soft fork will bring will likely make it so the origin of the BTC will be much harder to find out, making stuff even more secretive.

This fork won't be enough to really push BTC to the levels of XMR and Dash, but it's a pretty good leap in the privacy section, and I learn't a lot from this.

Nice post.

[pooya87]

I also don't know much about the other benefits, it can help the multisig, but I don't know how much and some simple explanation for start could help.

in ECDSA, when you use m of n multi-sig you have to provide a signature for each m and a public key for each n. each signature takes up about 72 bytes and each public key takes up 34 bytes inside a transaction. so for a 15 of 15 you have to produce a signature that is nearly 1600 bytes.

in ECSDSA (Schnorr) when you use m of n multi-sig you only provide one signature and one public key (the aggregated pubkey) so a 15 of 15 multi-sig is the same size as a single sig (like P2PKH) signature ~106 bytes.
that is how Schnorr algorithm works, i haven't read the bips entirely yet but i believe they also changed the signature encoding. if that's true then signature size would be 64 bytes and it would take up 65 bytes in a signature (1 byte size + 32 byte R + 32 byte S)

[hv_]

... darkening the protocol - put btc more on black lists

Simply because of increasing privacy? Is that what you mean? Will the improved privacy through this soft fork enough to classify Bitcoin alongside Monero, Dash, ZCash, and other privacy coins?

No, it's not the reason. If Bitcoin uses ECDSA it's because it couldn't make use of Schnorr's signature scheme because it was patented (it's ~30 years old), only recently it became public. Technically Schnorr's signature scheme has a simpler structure. Now it's open the dev. want to use it

Hence the speculation that the algorithm was not included by Satoshi Nakamoto when he designed Bitcoin due to Schnorr's existing patent back then.

Perhaps some technical wiz could provide a friendly breakdown as to what this really means to all of us. For us laymen, who are not too familiar with the technical nitty-gritty of Bitcoin development, this could remain fuzzy.

1. Both of them reduce transaction size which means :

• You'll pay less transaction fees
• A block can contain more transaction, which can be seen as minor on-chain scaling

But is it comparable to the almost zero fees provided by the Lightning Network? Although LN of course is primarily designed for smaller and day to day transactions and is basically off-chain.

2. Both of them offer better privacy (through different method)

Exactly in a manner that NeuroticFish has shown?

This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.

When will all the good guys in Bitcoin  notice that the dark boys are driving the entire Project into the wrong dark waters ?

Doesn t that here do a good job to wake up ?

https://www.sec.gov/rules/sro/nysearca/2019/34-87267.pdf

Why have u so much 'issues' to get that a  protocol Level is not the right layer to fuck up?

[NeuroticFish]

Say a group of n signers

Sorry, I was talking about indistinguishable outputs (how I understood them), not about signing. So I don't know if you corrected me, or tried explain something better.. I'm a bit lost.



Edit: debt paid

[Wind_FURY]

... darkening the protocol - put btc more on black lists

Because it doesn't agree with your "on-chain scaling will fix Bitcoin" propaganda, it's "darkening" the protocol. OK.

You know what to do everyone. In case. #UASF

[squatter]

1. Both of them reduce transaction size which means :

• You'll pay less transaction fees
• A block can contain more transaction, which can be seen as minor on-chain scaling

But is it comparable to the almost zero fees provided by the Lightning Network?

The fee savings are much smaller with Schnorr and Taproot because they pertain to on-chain transactions -- a flat 30%-75% fee savings for multisig vs. exponential savings on LN. Of course, there are significant trade-offs to use LN, like keeping your private keys online.

The exciting thing about the fee incentives underpinning Schnorr signature aggregation is that they'll push more and more people to use CoinJoins.

Schnorr should make coinjoin transactions cheaper than regular bitcoin transactions.

Let that sink in for a moment. Sending a transparent transaction will be more expensive than sending an obfuscated one...

[franky1]

1. Both of them reduce transaction size which means :

• A block can contain more transaction, which can be seen as minor on-chain scaling

not true
the amount of utility of multisig is already low. so the benefits are not much. it just turns what would be a 2-2multisig bloated sig sitting in the witness areas appear as just 1 signature. basically bringing down the witness area from about 300kb to maybe 150kb

but what it does not do is do much for the baseblock scaling. paying into a multisig is the same as before. so no advantage of less inputs-outputs

but. with multisigs being used more (predicted) eventually there will be more people in the multisig, which when they finally want to get out will see alot more transactions of
bc1qmultisig 100btc -> bc1qsingleindependantusera 0.1btc
                              -> bc1qsingleindependantuserb 0.1btc
                              -> bc1qsingleindependantuserc 0.1btc
                              -> bc1qsingleindependantuserd 0.1btc
                              -> bc1qsingleindependantusere 0.1btc
                              -> bc1qsingleindependantuserf 0.1btc
                              -> bc1qsingleindependantuserg 0.1btc                            
                              and so on
(contract exits with hundreds of outputs) instead of currnt average of
3multisigtwooftwo 100btc -> 1singleindependantusera 50btc
                                      -> 1singleindependantuserb 50btc

meaning that the base block sees transactions bloat up with multiple output transactions at contract exit than compared to todays scenario which is more just 2ins and 2outs average
the tx data per tx in the base for these higher used multisigs will be higher meaning less transactions per block.
the only appearance of gain is that length and complex scripts wont fill up the witness area to the same extent to cause even worse bloat

in short. if you can imagine a multisig script traditionally being say 3kb of bloat. yes in a legacy multisig that means under 300 transactions can sit in the baseblock with the legacy script.. but only IF there were any real examples of such bloatable scripts.. their werent so we never had that scenario/problem so we generally kept to a average tx count of ~2500

with segwit. the 3kb script sits outside the baseblock meaning 1000 scripts could sit outside the base block meaning only 1000 txdata can be inside the baseblock. thus segwit just mitigate the damage future scripts would cause to prevent transaction DECREASE issues if bloated scripts were added to legacy. thus instead of an average from ~2500 going down to ~300. segwit mitigated the damage to ~1000
which is still bad but not as bad as if legacy handled scripts

which if you do the numbers
with a witnss area filled with 1000 scripts of 3kb is the witness are filled. meaning if that was represented as a 2in 2out tx in baseblock txdata (300byte) is only 300kb inside the base block (30%filled) yes 30% filled base of just 1000tx but cant put more tx data inside the base block because the witness area is at its limit.
(300kb base 3mb witness: 30%fill, 100%fill) thus only as i said 1000 tx in the base

now with schnorr it allows 3kb script to end up being just a single short signature thus mitigating bloated scripts from causing this issue to the witness area. which means more scripts can go in the witness which means it prevents witness bloat from damaging the base block potential. thus bringing the average transaction data that can sit in the base block back to original average levels
but here is the thing...
the big thing people are missing the point of
the base block has always had the potential of upto 4200 transactions per block, averaging ~2500 most of the time of a complete fill

schnorr, segwit are NOT achieving anything that resembles allowing 40x more transactions in the base block by converting 3kb scripts into ~75byte script. instead its to prevent the bloated scripts from hitting witness area limits that would cause UNDER utility of the base block

its not scaling.. its early prevention of de-scaling transaction counts

[franky1]

not true

the amount of utility of multisig is already low. so the benefits are not much.

So, which one is true? It's not true or it has small benefit?

the small benefit if any is not in scaling. but in avoiding descaling bcoming common
there have not been really any big utility of spammy bloated scripts thus far, which have produced a full 4mb weight to cause a major downtrend in base block transaction count occupancy.
thus not a major/regular problem YET which schnorr would have evaded if implemented sooner.

to my memory i can only remember 1 block that appeared 4mb weight spammy without offering good transaction count.
https://www.blockchain.com/btc/block/00000000000000000021868c2cefc52a480d173c849412fe81c4e5ab806f94ab
block 540107
cores 'weight' utility     3993.089 kWU (limit appears as full)
total actual hard drive spam 2,26mb
number of transactions 230

i think that there is a failure in scaling. 2.26mb for just 230 transactions,
not only that but cores myth of more transactions and upto4mb of space per block has failed because although thier wishy wash math conversions made a block appear as 4mb to hit the limit. the hard drive data and transaction count is no were near 4x of average

but anyway i digressed...
again its about preventing the risk of bloated scripts DE-SCALING block transaction count not increasing the transaction count
fun fact: bitcoin had been calculated YEARS before segwit to handle upto 600k tx a day.
even now we have not seen a single day exceed that. which shows core have not achieved scaling at all.

schnorr, segwit are NOT achieving anything that resembles allowing 40x more transactions in the base block by converting 3kb scripts into ~75byte script. instead its to prevent the bloated scripts from hitting witness area limits that would cause UNDER utility of the base block

its not scaling.. its early prevention of de-scaling transaction counts

And i didn't say it'd allow 40x more transaction on on-chain/base layer. I only claim "minor on-chain scaling"

again its about preventing the risk of bloated scripts DE-SCALING block transaction count. bloated by new scripts that would bloat blocks if they didnt implement schnorr and other stuff to hide the bloat they want to introduce
oh and last thing. reset your teachings from obvious sources..
calling onchain the base layer.. thus trying to push the narrative that other networks that dont even use a blockchain are somehow still a layer of 'bitcoin'.. (you really have been looking to the wrong people for your info)

if it aint on a bitcoin blockchain. it aint bitcoin

[CryptoBry]

I've also read that if implemented, this will help in fungibility. This means that Bitcoin will be closer to the way paper money behaves: if you have 200$, 100$ from a drug dealer and 100$ from a bank, no one will know which 100$ came from which source.
It can improve the anonymity by a great deal. I also don't know how much will the exchanges and financial regulators (dis)like this (isn't Monero out of the major exchanges in Japan?).

I also don't know much about the other benefits, it can help the multisig, but I don't know how much and some simple explanation for start could help.
I'll also add a link I've found, but didn't read it all yet, since it contains too many references to things I don't know yet https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287

That's interesting. I didn't actually know a lot about fungibility since this post. I'm assuming the features this soft fork will bring will likely make it so the origin of the BTC will be much harder to find out, making stuff even more secretive.

This fork won't be enough to really push BTC to the levels of XMR and Dash, but it's a pretty good leap in the privacy section, and I learn't a lot from this.

Nice post.

Privacy has been a big concern for some with Bitcoin as they feel that it is slowly losing ground with this cryptocurrency and that other private coins are way ahead on this respect. I understand some can be happy with this development but of course this can be raising red flags with the regulators. Let's see how countries like Japan and USA will take this...let's hope they will just allow this to pass with Bitcoin. Will this mean that illicit traders are soon coming back to using Bitcoin?

[pooya87]

thus not a major/regular problem YET which schnorr would have evaded if implemented sooner.

schnorr is not there to solve all the problems. it is an "option" to give to users who want smaller transactions. and its contribution to scaling is both smaller tx size and a lot faster verification of such transactions.

it is not just about multi-sigs either. it applies to all transactions that use schorr signatures. for instance i would switch to schnorr as soon as it is activated because all my (single sig) transactions would shrink by 9 bytes per input (signature) simply because the dumb ass DER encoding is dropped!

[NeuroticFish]

Privacy has been a big concern for some with Bitcoin as they feel that it is slowly losing ground with this cryptocurrency and that other private coins are way ahead on this respect. I understand some can be happy with this development but of course this can be raising red flags with the regulators. Let's see how countries like Japan and USA will take this...let's hope they will just allow this to pass with Bitcoin. Will this mean that illicit traders are soon coming back to using Bitcoin?

Yep, this is indeed a very deep problem.
Today people can use mixers, can be careful to not reuse addresses, can be careful to not spend together inputs that can give out too much of their identity - if they care about that. Most probably most users don't do that.
It's not normal to allow anybody look into your pocket. So adding a bit more privacy would be normal.
Just this can indeed attract various criminal activities into using Bitcoin once again, which will probably make the financial services be more wary about Bitcoin.

It's hard to make everybody happy.

[Wind_FURY]

franky1, if you are debating that Schnorr + Taproot won't scale more than 40x, then no one is debating that with you.

The point of these upgrades is to improve the network's latency, with the current block size that Bitcoin already has.

[franky1]

franky1, if you are debating that Schnorr + Taproot won't scale more than 40x, then no one is debating that with you.

The point of these upgrades is to improve the network's latency, with the current block size that Bitcoin already has.

take a look at the topic creators first post, the image more specifically what word is marked as 1.
oh look
so what is that misleading word that the graphic is implying that these innovations improve the most
no need to answer as its a rhetorical question as people can already see it for themselves

have a nice day. just dont be one of those people that try putting the word scaling into the same sentance of schnorr benefits. try using prevent descaling if you atleast want to be honest about the benefits

oh and one last thing..

You know what to do everyone. In case. #UASF

if you have not learned this already. cores new bypass technique does not need consensus, does not cause forks, is not a case of only activating at an acceptable threshold. there is no way to actually prevent devs putting it in and having such new funky tx's added to blocks.
the UASF you speak of is actually just a translation of 'if you dont like it F**k off and go play with an altcoin'
** = both UC and OR

EDIT:
because some centralising censor loving dv wants to stay as protocol decision leader

answering post below because answer got deleted
schnorr does not benefit scaling. because
1. you cannot schnorr already existing tx,
2. it only benefits new TX which would be bloated without it.

as of today the average multisig is not that signature/script heavy.
and
those signatures/scripts sit OUTSIDE the baseblock, thus no transaction count increase
what schnorr does is reduce the bloat in the witnss area so that the 3mb of witness is filled too fast to hit its limit that will limit how many transactions can fit into the base block

again what schnorr actually does is hide bloat of future scripts thus to avoid causing a DECREASE in transaction count utility.
yes thats right future scripts could be kilobytes big which would reduce the average transaction count from thousands to hundreds

take this example
https://www.blockchain.com/btc/block-height/540107
2.26mb hard drive
1mb of baseblock tx
but....... only 230tx
yep that block appears as full but only 230tx included
thats not about having features to bring tx count over the 600k a day threshold, its to stop new tx scripts from bringing transaction averages down

[Mandoy]

   
Schnorr + Taproot Soft Fork  improvement in bitcoin technology is a really advanced enhancement on bitcoin. This aims to develop and improve the scalability and privacy of bitcoin transactions. If this will be implemented then big people who are looking forward for privacy will step up and enter the bitcoin industry. Aside from that if the scalability is improve then the transactions will be much more faster and efficient and this will attract merchants to accept bitcoin as for of payment.

Overall, if this improvement will really succeed then this just means a bullish skyrocket for bitcoin once again.