Moving signatures to a separate field does not actually solve it. However one of the things that segwit did was to redefine the message that is hashed and signed. This is specified in BIP 143. Signature verification requires three things: the public key, the signature, and the message that was signed. In Bitcoin, the public key and the signature are ...


Varying the signature per input helps prevents some attacks during multi-party transaction construction. Consider a coinjoin involving Alice and Bob. Alice selects one of her UTXOs for the coinjoin. Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected. Alice does not ...


Quadratic means that something grows as a square function of something else. If you're just talking about a single transaction, there is nothing that changes. The quadratic hashing issue is that the amount of data to hash to compute or verify signatures grows as a square of the number of non-segwit inputs.


Note: As of 2020 this answer is obsolete, as BIP143 / SegWit has been in use for years which fixes this concern. You can fix it this way, and someone is in the process of doing so. The problem with hashing the entire transaction is that in order to create a transaction hash, you must know the signature. However, in order to create the signature, you need to ...


It's like that because that is how Satoshi wrote the code for it and it has never changed. It can't change without some sort of fork, and thus far, no fork has happened to change it (although segwit will once it activates). However doing it this way allows for people to more easily do multi-party transactions like CoinJoins. They don't require you to know ...


The quadratic hashing issue appears in the verification of all pre-segwit transaction formats. It stems from the method of verifying the input scripts. For each input the transaction has, all the other inputs are stripped from the transaction to check that remaining input against the output it spends as wells as the corresponding signature. As the effort ...


I'd been wondering about this for quite a long time, since it was the reason behind the quadratic hashing problem. The best answer I found so far is the one given by Pieter Wuille in the Bitcoin talk forum. The answers is most likely not going to be satisfying though.


Double-SHA-hash duration is dependent linearly on the size of the template? Yes, of course. So, increasing the count of inputs twice we also increase the size of each template ~twice and the work for signing/verifying whole transaction increased quadratic

Only top voted, non community-wiki answers of a minimum length are eligible