Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Prevent high S signatures (and possibly other malleability causes) by consensus

Abierto
  • ¿Algo no está bien?
#1,301 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
blockchain

Línea de trabajo

El issue no menciona archivos, pruebas ni puntos de entrada. Es necesario llegar a un acuerdo de diseño sobre el cambio de consenso propuesto, las posibles reglas adicionales de maleabilidad y los requisitos de despliegue antes de que alguien que empieza pueda identificar una ruta de implementación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Is your feature request related to a problem? Please describe.

Pre-segwit inputs cause problems for services building on both Bitcoin and Liquid, due to potential tx malleability (discussed extensively elsewhere). This increases the complexity of coding software which mediates or processes txs for users.

In Bitcoin the relationship to block miners is adversarial - if it is in their interest to do so, they can malleate a tx (or accept a malleated tx via non-standard means) and mine a valid block with it. In Elements/Liquid however the block producers are financially invested in the integrity of the chain and are are expected to not be malicious. A block producer including a malleated tx which facilitates a double spend or theft could erode the trust in the chain and its functionaries. Note that this could happen if a block producer is hacked for example, and not just out of malice/greed.

Liquid/Elements are potentially more sensitive to this issue given the push to build more complex contract structures, where dependent txs can be invalidated by malleation.

Describe the solution you'd like

High-S signatures are already non-standard and cannot be relayed. I propose for Elements we make such signatures invalid by consensus also. By doing so we prevent any possible bad behaviour by block producers, and at the same time reduce the barrier of entry/complexity of creating services using the chain.

Describe alternatives you've considered

The alternative is to do nothing and continue with the status quo. As above this makes building on Elements chains more difficult which could hamper future growth.

Additional context

Note that anyone holding back an old, validly-signed high-S tx must already transmit it OOB to a block producer in order to have it included in the chain. They, or the block producer can always maleiate the sig back to low-S in order to include it after this change is made.

A consensus failure can only occur while this change is deployed to the block producers, and only if one of them decides to fork the chain deliberately. As above the block producers are not incentivized to destroy the chain they work on, nonetheless this risk should be mitigated where required by whatever means are available (For example, updates to any legal contract).

It is possible that other standardness checks could also become consensus checks for Elements however they are not detailed here.

Lenguaje dominante
C++
Estrellas
1.2k
Forks
417
Merge medio
23 h 21 min
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ElementsProject/elements

Todos los issues de ElementsProject/elements

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.