Quote from: 9kek on December 19, 2020, 06:22:28 PM

le classiche mega-transazioni fatte dagli exchange con molti input e molti output potranno avere dimensione ridotta sulla blockchain? Oppure è una cosa che coinvolge solo le transazioni multi-sig (che credo siano una piccola minoranza)?

Dopo qualche altra ricerca devo correggere la mia prima risposta; pare che, anche se il metodo di firma Schnorr permette in linea di principio l'aggregazione delle firme, questa feature non verrà inclusa in un primo momento.

In pratica si è deciso di focalizzarsi inizialmente su Taproot, mentre le piene potenzialità del metodo di firma Schnorr vengono rimandate a future integrazioni del codice.

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

Quote

Combining all these ideas in a single proposal would be an extensive change, be hard to review, and likely miss new discoveries that otherwise could have been made along the way. Not all are equally mature as well. For example, cross-input aggregation interacts in complex ways with upgrade mechanisms, and solutions to that are still in flux. On the other hand, separating them all into independent upgrades would reduce the efficiency and privacy gains to be had, and wallet and service providers may not be inclined to go through many incremental updates. Therefore, we're faced with a tradeoff between functionality and scope creep. In this design we strike a balance by focusing on the structural script improvements offered by Taproot and Merkle branches, as well as changes necessary to make them usable and efficient. For things like sighashes and opcodes we include fixes for known problems, but exclude new features that can be added independently with no downsides.

https://bitcoinops.org/en/newsletters/2020/12/23/#taproot

Quote

Nearly every month of 2020 saw some notable development related to the proposed taproot soft fork (BIP341) which also adds support for schnorr signatures (BIP340) and tapscript (BIP342). Together, these improvements will allow users of single-signature scripts, multisignature scripts, and complex contracts to all use identical-appearing commitments that enhance their privacy and the fungibility of all bitcoins. Spenders will enjoy lower fees and the ability to resolve many multisig scripts and complex contracts with the same efficiency, low fees, and large anonymity set as single-sig users. Taproot and schnorr also lay the groundwork for future potential upgrades that may improve efficiency, privacy, and fungibility further, such as signature aggregation, SIGHASH_ANYPREVOUT, and scripting language changes.

Quote from: gmaxwell on October 20, 2020, 12:25:36 PM

Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature. This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.

Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing. Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available). Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.

https://it.cointelegraph.com/news/bitcoin-s-taproot-is-ready-to-go-but-it-s-unlikely-to-be-included-in-the-next-release

Quote

Taproot nasconde ogni condizione di spesa aggiuntiva a parte quella che viene attivata. Per esempio, una transazione può essere eseguita immediatamente se tutti e quattro i firmatari di una multisig sono concordi, oppure potrebbe richiedere un certo periodo di tempo prima che i fondi vengano sbloccati se solo tre dei quattro firmatari sono presenti. Normalmente, un estraneo è in grado di identificare ogni possibile condizione, ma con Taproot potrà vedere solo quella che è stata attivata.

Inoltre, grazie alle firme di Schnorr, una transazione puramente multisig può essere resa indistinguibile dai regolari trasferimenti. È importante sottolineare che Taproot non introduce alcun cambiamento ai protocolli di mixing come CoinJoin, che rimarranno facilmente distinguibili.

Quote from: gmaxwell on January 28, 2020, 05:56:13 AM

The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same. This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready. Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).