Published on: 2016-09-01T11:29:29+00:00
In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic.
Updated on: 2023-08-01T18:59:18.023773+00:00