Topic: Schnorr + Taproot Soft Fork and What this Means to Bitcoin (Read 462 times)

Cannot agree more - btc kinda sold out.

Good: Bitcoin was and is not bound to a ticker. Let them hodl a ticker - Satoshi hodl the protocol

   
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.

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

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.

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.

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!

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?

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.


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

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

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.

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

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

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?

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)