¿Hay alguna bifurcación de bitcoin cuyo objetivo sea almacenar información arbitraria?

Sé que existe Namecoin, que guarda el par clave:valor. ¿Hay otras soluciones similares? ¿Quizás para bloques de texto arbitrarios?

Actualización: ¿cómo lo hacen? Iniciativa Blockchain de Delaware para agilizar el mantenimiento de registros para empresas privadas http://flip.it/wqxKJ

Respuestas (3)

Storj es una solución basada en blockchain para cifrar y almacenar datos. Se puede encontrar más información sobre el proyecto en storj.io

Storj no guarda datos en la cadena de bloques, pero esta es una buena opción.
También Siacoin y Filecoin

No es exactamente una bifurcación de Bitcoin, pero el proyecto Factom (factom.org) utiliza sus propias estructuras de datos y la cadena de bloques de Bitcoin para almacenar información de forma inmutable.

El usuario primero crea una huella digital de sus datos que ingresa al libro mayor/cadena de bloques de Factom. Luego, a intervalos regulares, la huella digital de ese libro mayor se publica en la cadena de bloques de Bitcoin. De esta manera, la cantidad y complejidad de los datos puede ser mucho mayor que si ese usuario pusiera el hash de su información directamente en la cadena de bloques de Bitcoin, que tiene un tamaño limitado y es costosa de publicar.

El proyecto trata de dar herramientas para prueba de existencia, prueba de proceso y prueba de auditoría.

Este par de videos pueden darle una buena visión general del proyecto:

Factor es para siempre: https://www.youtube.com/embed/gVwT-XrrekY

Cómo funciona la tecnología Blockchain de Factom: https://www.youtube.com/embed/MlzyI1bfyD4

Pero Factom no almacena información en realidad. Almacena únicamente las firmas de los documentos.
Tienes razón. Solo almacena hashes, no la información real. No estoy seguro de si algún proyecto intenta almacenar la información real en la cadena de bloques, pero eso sería realmente ineficiente.
¿Por qué no eficiente? Puede ser algo así como un foro basado en blockchaine.
Una cadena de bloques no es eficiente para almacenar información porque genera miles de copias de la información. En el caso de Bitcoin, las transacciones son pequeñas, pero aun así mucha gente argumenta que no tiene ningún sentido copiar el pago de un café en miles de copias de la cadena de bloques que viven en diferentes computadoras.
Sí, no tiene sentido guardar copias del pago del café, pero para alguna información valiosa puede tener sentido.
No tiene sentido. Si su objetivo es el almacenamiento de datos y sobrecargar a los usuarios con esos datos, no puede proporcionar una moneda competitiva. Sin moneda valiosa, no puede recompensar a sus mineros por su cooperación. Sin incentivos para los mineros, la propiedad de inmutabilidad de la cadena desaparece y podrías haber usado bittorrent en su lugar.

Las cadenas de bloques son más complicadas que otras aplicaciones de almacenamiento distribuido, porque tienen que aplicar un historial ordenado global. Es muy importante si la Transacción A o la Transacción B fue primero.

Esta es una gran restricción de diseño y hace que sea mucho más difícil diseñar soluciones de escalado. Cualquier bloqueo anterior podría afectar potencialmente la validez de un nuevo bloque, por lo que los nuevos clientes deben descargar todos los bloques antiguos y verificarlos.

No tiene ningún sentido mantener esta restricción si está diseñando un sistema de almacenamiento de datos distribuido. Si falta un dato para un bloque antiguo, el sistema de almacenamiento debe ignorarlo y continuar.

Según tengo entendido, la mayoría de las bases de datos como PostgreSQL también garantizan un orden sólido de todas las transacciones.
No imponen el orden entre diferentes bases de datos. Si tengo una base de datos que rastrea las migraciones de aves y usted tiene una base de datos que rastrea las piezas en un almacén, no hay sincronización entre ellas. Si empiezo una operación antes de que tú empieces una operación, no hay garantía de que la mía termine antes que la tuya. Por el contrario, si mi transacción ingresa a la cadena de bloques antes que la suya, siempre se ejecutará primero, incluso en los nodos que realizan la descarga inicial del bloque años después. (Salvo una reorganización, de todos modos).