*Lea esto en otros idiomas: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
deseen profundizar en estos supuestos, existen otras opciones para [aprender más](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/).
Una curva elíptica con el objetivo de criptografía es simplemente un gran conjunto de puntos que llamaremos _C_. Estos puntos
pueden sumarse, restarse o multiplicarse por números enteros (también llamados escalares). Dado un entero _k_ y
usando la operación de multiplicación escalar podemos calcular `k*H`, que es también un punto en la curva _C_. Dado otro
entero _j_ también podemos calcular `(k+j)*H`, que es igual a `k*H + j*H`. Las operaciones de suma y multiplicación escalar
en una curva elíptica mantienen las propiedades conmutativas y asociativas de suma y multiplicación:
(k+j)*H = k*H + j*H
En ECC, si escogemos un número muy grande _k_ como clave privada, `k*H` se considera la clave pública correspondiente.
Incluso si uno conoce el valor de la clave pública `k*H`, deducir _k_ es casi imposible (o dicho de otra manera, mientras que
la multiplicación es trivial, la "división" por puntos de curva es extremadamente difícil).
La fórmula anterior `(k+j)*H = k*H + j*H`, con _k_ y _j_ ambas claves privadas, demuestra que una clave pública obtenida de
la adición de dos claves privadas (`(k+j)*H`) es idéntica a la adición de las claves públicas para cada una de esas dos
claves privadas (`k*H + j*H`). En la cadena de bloques Bitcoin, las carteras jerárquicas deterministas se basan en gran
* **Verificación de importes nulos.** La suma de las salidas menos las entradas siempre es igual a cero, lo que demuestra que
la transacción no creó nuevos fondos, _sin revelar los importes reales_.
* **Posesión de las claves privadas.** Como con la mayoría de las otras monedas criptográficas, la propiedad de los
resultados de las transacciones está garantizada por la posesión de claves privadas ECC. Sin embargo, la prueba de que una
entidad es propietaria de esas claves privadas no se consigue firmando directamente la transacción.
Las siguientes secciones sobre el saldo, la propiedad, el intercambio y las verificaciones detallan cómo se logran esas dos
propiedades fundamentales.
#### Balance
Basándose en las propiedades de ECC que hemos descrito anteriormente, uno puede ocultar los valores en una transacción.
Si _v_ es el valor de una transacción de entrada o salida y _H_ una curva elíptica, podemos simplemente insertar `v*H` en
lugar de _v_ en una transacción. Esto funciona porque usando las operaciones ECC, todavía podemos validar que la suma de las
salidas de una transacción es igual a la suma de las entradas:
v1 + v2 = v3 => v1*H + v2*H = v3*H
Verificar esta propiedad en cada transacción permite que el protocolo verifique que una transacción no crea dinero de la
nada, sin saber cuáles son los valores reales. Sin embargo, hay un número finito de valores útiles y uno podría intentar cada
uno de ellos para adivinar el valor de su transacción. Además, conocer v1 (de una transacción anterior por ejemplo) y el
resultado `v1*H` revela todas las salidas con valor v1 a lo largo de la cadena de bloques. Por estas razones, introducimos
una segunda curva elíptica _G_ (prácticamente _G_ es sólo otro punto del generador en el mismo grupo de curvas que _H_) y una
clave privada _r_ utilizada como *factor de ocultación*.
Un valor de entrada o de salida en una operación puede expresarse como:
r*G + v*H
Donde:
* _r_ es una clave privada utilizada como factor de ocultación, _G_ es una curva elíptica y su producto `r*G` es la clave
pública para _r_ en _G_.
* _v_ es el valor de una entrada o salida y _H_ es otra curva elíptica.
No se puede deducir ni _v_ ni _r_, aprovechando las propiedades fundamentales de la criptografía de curva elíptica. `R*G + v*H` se llama _Compromiso Pedersen_.
Por ejemplo, supongamos que queremos construir una transacción con dos entradas y una salida. Tenemos (ignorando las cuotas):
* vi1 and vi2 como valores de entrada.
* vo3 como valores de salida.
De tal forma que:
vi1 + vi2 = vo3
Generando una clave privada como factor de ocultación para cada valor de entrada y sustituyendo cada valor por sus
respectivos Compromisos de Pedersen en la ecuación anterior, obtenemos:
Esta sección explica con más detalle la creación de transacciones discutiendo cómo se introduce el cambio y el requisito de pruebas de rango para que se demuestre que todos los valores no son negativos. Ninguno de los dos es absolutamente necesario para entender MimblewimbleWimble y Grin, así que si tienes prisa, no dudes en ir directamente a
El formato de bloques Mimblewimble se basa en esto introduciendo un concepto adicional: _cut-through_. Con esta incorporación, una cadena Mimblewimble gana:
* Extremadamente buena escalabilidad, ya que la gran mayoría de los datos de las transacciones pueden ser eliminados con el
tiempo, sin comprometer la seguridad.
* Mayor anonimato al mezclar y eliminar datos de transacciones.
* Y la capacidad de los nuevos nodos para sincronizarse con el resto de la red de forma muy eficiente.
#### Agrupación de transacciones
Recuerde que una transacción consiste en lo siguiente -
* un conjunto de entradas que hacen referencia y gastan un conjunto de realizaciones anteriores
* un conjunto de nuevos resultados (compromisos de Pedersen)
* un kernel de transacción, que consta de
* kernel excess (compromiso de Pedersen a cero).
* firma de la transacción (usando el exceso de kernel como clave pública).
Se firma una tx y se incluye la firma en un _transaction kernel_. La firma se genera utilizando el _kernel excess_ como clave pública, lo que prueba que la transacción suma 0.
"Dividimos" la clave `k` en `k1+k2` durante la construcción de la transacción. Para una transacción kernel `(k1+k2)*G` publicamos `k1*G` (el exceso) y `k2` (el offset) y firmamos la transacción con `k1*G` como antes.
Durante la construcción del bloque podemos simplemente sumar las compensaciones `k2` para generar una sola compensación
agregada `k2` para cubrir todas las transacciones en el bloque. La compensación `k2` para cualquier transacción individual es
imposible de recuperar.
#### Cortado a medida
Los bloques permiten a los mineros ensamblar múltiples transacciones en un solo conjunto que se añade a la cadena. En las
siguientes representaciones en bloque, que contienen 3 transacciones, sólo se muestran las entradas y salidas de las
transacciones. Los ingresos hacen referencia a las salidas que gastan. Una salida incluida en un bloque anterior está marcada
con una x minúscula.
I1(x1) --- O1
|- O2
I2(x2) --- O3
I3(O2) -|
I4(O3) --- O4
|- O5
Observamos las dos propiedades siguientes:
* Dentro de este bloque, algunas salidas son gastadas directamente por las entradas incluidas (I3 gasta O2 e I4 gasta O3).
* La estructura de cada transacción no importa realmente. Como todas las transacciones se suman individualmente a cero, la
suma de todas las entradas y salidas de transacciones debe ser cero.
Al igual que en una transacción, todo lo que hay que comprobar en un bloque es que la propiedad ha sido probada (que proviene
de _núcleos de transacción_) y que todo el bloque no ha añadido ninguna cantidad de fondos (aparte de lo que permite la base
de datos de la moneda).
Por lo tanto, se pueden eliminar las entradas y salidas que coincidan, ya que su contribución a la suma total se anula. Lo
que conduce a los siguientes bloques, mucho más compactos:
I1(x1) | O1
I2(x2) | O4
| O5
Tenga en cuenta que se ha eliminado toda la estructura de transacciones y que el orden de las entradas y salidas ya no
importa. Sin embargo, la suma de todas las salidas de este bloque, menos las entradas, sigue siendo cero.
Un bloque se contruye simplemente a partir de:
* Una cabecera de bloque.
* La lista de entradas que quedan después del corte.
* La lista de las salidas que quedan después del corte.
* Un único offset del kernel para cubrir todo el bloque.
* Los núcleos de transacción que contienen, para cada transacción:
* La clave pública `r*G` obtenida de la suma de todos los pagos.
* Las firmas creadas utilizando el exceso de valor.
