Malleability is an accounting software issue, not a bitcoin issue.
If you track the transactions you own and the addresses you own, malleability doesn't matter.
Thus it's not a bitcoin fork issue, it's a good or poorly written accounting software issue.
While it is an issue of wallet software, malleability has also been known to wreak havoc on many popular services and exchanges that people use. While it does not really cause a loss of funds, it can also be extremely confusing and frustrating when transactions are being malleated. While I agree that those services and exchanges should get their act together and fix their own system to handle malleability, they don't always do so and users cannot easily check whether those services have handled malleability since they typically do not publish the source code for their service.
Furthermore, malleability causes issues with unconfirmed transaction chains. Nearly all major wallets allow you to spend from unconfirmed change outputs. When these are spent from, they create unconfirmed transaction chains which can be broken by transaction malleability. Here, this can cause some loss of funds as people are likely to still send goods once they see the unconfirmed transaction, even though they really should wait for a confirmation.
Lastly, malleability makes implementing further layer 2 scaling solutions such as payment channels much more difficult. Dealing with transaction malleability for such solutions, while not impossible, makes the task much harder. In order for Bitcoin to successfully scale, we will need layer 2 solutions and thus will need some way to make transactions non-malleable.
The quadratic issue I've yet to understand why it even matters?
Anyone want to chime in here and explain why it 'actually' matters in the real bitcoin world?
A miner can create a 1 MB transaction inside a block which, due to quadratic sighashing, can take a long time to validate. This has been done before. The block and the transactions are still valid, they just take a long time to validate due to quadratic sighashing.
Is there some bad design issue in bitcoin where the necessary results of this processing are thrown away, so the processing has to be repeated at later times?
Yes.
Currently sighashing requires a unique preimage that is hashed for every single input of a transaction. This preimage consists of the entire unsigned transaction, the output script being spent from, and the sighash type. As you add more inputs, the preimage for every single input that must be hashed becomes larger and larger. This makes it grow quadraticly. With a massive 1 MB transaction, this means that you could end up hashing more than 1 GB of data just to verify a transaction. Since the preimages for every single input is unique, none of the signashing can be cached for later use as it is all useless for anything else.
What segwit does is that it makes the preimage for every single input basically a fixed size. This means that it will grow linearly as the preimages do not change in size, just the number of preimages that must be hashed.
Now people don't like to throw away blocks, so if someone puts a "slow" hidden transaction (i.e. unknown elsewhere on the bitcoin network) into block mining work, that they then distribute the transaction normally with a block they find, that will increase the chance of that block being orphaned if it is "slow"
Sounds like a bad choice by anyone wanting to do that.
Suppose a miner has connections to a number of other miners through something like FIBRE. He can create a block that takes a long time to validate by including a large transaction that requires a lot of sighashing. This block is then broadcast on the miners, who then begin validating it. While they are validating it, they will likely still be working on the previous block, but the miner who made the block has an advantage and thus is more likely to find the next block on top of the slow block before other miners do while they are bogged down with validating the thing. This gives that miner an advantage over the other miners.
From a mining point of view, if these transactions are able to be identified, then it might even be worth considering not mining them?
Yes. In fact, such large transactions are considered non-standard so miners using Core would not choose to mine those transactions at all. However that does not stop a miner from making and including such a transaction in their own blocks.
Show Posts
