Hola a todos,

Quería presentaros un proyecto en fase inicial llamado DNICoin:

https://dnicoin.com/

Lo comparto aquí porque creo que puede encajar mejor en una comunidad técnica que en un foro puramente financiero. No lo planteo como una moneda para especular, sino como un experimento sobre valor digital, privacidad, DNIe, claves públicas y recibos criptográficos verificables.

La idea de DNICoin parte de algo bastante concreto: permitir la emisión de unidades criptográficas donde la petición inicial requiere demostrar posesión operativa de un DNIe, pero sin convertir esa comprobación en una identidad pública dentro del sistema.

Es decir: el DNIe no se usa para crear una cuenta identificada, ni para publicar quién eres, ni para asociar una unidad DNICoin a un nombre, DNI, certificado o número de serie. Se usa únicamente como prueba local de que puedes operar con un DNIe en el momento de realizar la petición.

Después de esa petición, la unidad DNICoin queda asociada a una clave pública generada por el usuario. La posesión de la unidad no se demuestra con una identidad civil, sino con la clave privada correspondiente a esa unidad concreta.

Cada unidad DNICoin tiene su propio par de claves. Esto es importante: si se pierde la clave privada de una unidad, se pierde la posibilidad de demostrar la posesión de esa unidad. DNICoin no puede recuperarla, porque no funciona como una cuenta centralizada con usuario y contraseña.

Como punto de partida, comparto la información de la primera emisión registrada en DNICOIN-MAINNET-1:

```json
{
  "type": "dnicoin_receipt_v1",
  "network": "DNICOIN-MAINNET-1",
  "emission_index": 1,
  "issued_at": "2026-06-19T18:29:37Z",
  "recipient_public_key": "9zV+2fuO+doKRlEmyiJuU2dfGeVXnnZZvz7cU=",
  "value_display": "99.998894",
  "policy_format": "DNCv1",
  "policy_sha256": "a76862d0b89b2495d2b11bf5d5da1bb8dbf284d8e95e102cce330cfcfd0b975a",
  "previous_event_hash": "GENESIS",
  "event_hash": "766c7fccb3146ad338516e15a77ac510aaaf2ecc37651ed7137241e6a62eec26",
  "issuer_public_key_alg": "Ed25519",
  "signature_alg": "Ed25519"
}
```

Para mí, lo relevante de esta primera emisión no es el número en sí, sino el concepto: una emisión registrada mediante un recibo criptográfico verificable, asociada a una clave pública receptora, pero no vinculada públicamente a una identidad civil.

El sistema intenta separar varias cosas que normalmente se mezclan:

1. La posesión operativa del DNIe.
2. La petición de emisión.
3. La unidad criptográfica resultante.
4. La identidad civil del participante.

La parte del DNIe sirve para autorizar la petición inicial, pero la unidad resultante no debería contener datos personales. La intención es que el recibo público no incluya nombre, DNI, certificado, número de serie, CN, subject, issuer, huellas del certificado, hashes derivados ni ningún identificador civil.

Dicho de forma simple: no hay control de identidad dentro de DNICoin. Hay una prueba local de posesión operativa de DNIe para poder solicitar una emisión.

Esto tiene consecuencias buenas y malas.

La parte positiva es la privacidad. Si el sistema funciona como está planteado, la unidad DNICoin no queda públicamente asociada a una persona concreta.

La parte delicada es que, al no guardar identidades ni identificadores personales, tampoco se puede construir un control de usuarios (lo cual puede ser una ventaja). La limitación práctica no viene de saber quién es cada participante, sino de exigir una operación local con DNIe, lector, PIN correcto y software funcionando.

DNICoin tampoco se basa en potencia de cálculo. No se trata de aportar GPUs, ASICs, energía o hashpower. La fricción del sistema está en realizar una operación criptográfica local con DNIe, manteniendo separada esa comprobación de la unidad emitida después.

Otro punto importante es la verificabilidad.

Cada emisión genera un recibo autocontenido con datos criptográficos. Ese recibo puede conservarlo el usuario y verificarse de forma independiente. Además, las emisiones se registran en un ledger tipo append-only, donde cada evento referencia el hash del evento anterior mediante `previous_event_hash`.

La idea es que una alteración, borrado o reordenación del historial pueda detectarse mediante herramientas de verificación. La web facilita el uso del sistema, pero la comprobación de una emisión no debería depender únicamente de la web oficial.

También existe un algoritmo público que asigna una magnitud interna a cada emisión. Esa magnitud disminuye progresivamente conforme aumenta el número de emisiones. No debe interpretarse como precio, saldo, deuda, participación, depósito ni derecho económico. Es una magnitud interna del experimento, pensada para ordenar y cuantificar emisiones dentro del propio sistema.

En resumen, DNICoin intenta explorar una combinación de ideas:

* unidades criptográficas asociadas a claves públicas;
* prueba local de posesión operativa de DNIe;
* separación entre DNIe e identidad pública;
* privacidad por diseño;
* no vinculación pública con identidad civil;
* recibos criptográficos verificables;
* ledger append-only;
* verificación independiente;
* ausencia de emisión basada en potencia de cálculo;
* posible ámbito inicial español por el uso de DNIe;
* y futura evolución hacia auditoría, mirrors, herramientas externas, gobernanza abierta o validación distribuida.

Sé que hay muchas preguntas abiertas, y precisamente por eso lo comparto aquí.

Me interesan especialmente críticas o ideas sobre:

* privacidad real del planteamiento;
* posibles fugas de metadatos;
* diseño del proceso con DNIe;
* verificabilidad de los recibos;
* estructura del ledger append-only;
* riesgos de centralización;
* posibles mecanismos de auditoría;
* mirrors o verificadores independientes;
* gobernanza futura;
* encaje legal;
* límites del modelo;
* y posibles usos reales que no dependan de la especulación.

Insisto en que lo presento como un experimento técnico y social, no como una recomendación económica. Me interesa sobre todo saber si el planteamiento tiene sentido desde el punto de vista de privacidad, seguridad, verificabilidad y diseño de protocolo.

Cualquier crítica técnica será bienvenida.