BITCOIN: aplicaciones no monetarias

tastas dijo:
Me da la impresión de que si no se han hecho muchas tras*acciones MAD es en parte porque técnicamente no son sencillas.
Estoy probando tanto con direcciones segwit como sin, y voy a perder bastante tiempo y puede que también dinero ya que parece que coinb.in no tiene testnet y la opción electrum la he desechado ya. Permite raw tras*actions pero que yo sepa no tiene modo orates y solo son desde la consola.

Gracias.

Taptap
Hacer clic para expandir...
Ojito que las raw tras*actions son peligrosillas. Bastante gente ha perdido pasta al equivocarse poniendo las cantidades (y las comisiones) en las tras*acciones y, al final, ha parado toda la pasta a manos de los mineros en forma de comisiones de tras*acción. Si no recuerdo mal, hay que meter las cantidades en satoshis y deducir la comisión a modo de diferencia entre los outputs y los inputs.

Yo creo que, lo más sencillo, sería pasar los bitcoins de direcciones segwits a direcciones no-segwit y, desde ahí, construir los contratos multifirma de destrucción mutua asegurada con coinb.in. Meterse a hacerlo mediante raw tras*actions ("a pelete") es arriesgarse mucho.
 
Thundercat dijo:
Lo de la destrucción mutua en una compra-venta me ha gustado mucho, muy interesante.
Hacer clic para expandir...
Bajo mi punto de vista, ese tipo de contrato que se puede construir con Bitcoin es extremadamente potente y la gente no es todavía consciente de ello.

Es la verdadera manera de emplear la certidumbre que ofrece la red Bitcoin para garantizar que los "intereses" de dos personas que no se conocen, que no están cerca e, incluso, que ni siquiera coinciden temporalmente durante una tras*acción, converjan.

Poquísima gente es consciente de las posibilidades que abre esto.

Somos muy afortunados de habernos dado cuenta de todo esto antes que el grueso de la población.
 
Sr.elemento dijo:
Ojito que las raw tras*actions son peligrosillas. Bastante gente ha perdido pasta al equivocarse poniendo las cantidades (y las comisiones) en las tras*acciones y, al final, ha parado toda la pasta a manos de los mineros en forma de comisiones de tras*acción. Si no recuerdo mal, hay que meter las cantidades en satoshis y deducir la comisión a modo de diferencia entre los outputs y los inputs.

Yo creo que, lo más sencillo, sería pasar los bitcoins de direcciones segwits a direcciones no-segwit y, desde ahí, construir los contratos multifirma de destrucción mutua asegurada con coinb.in. Meterse a hacerlo mediante raw tras*actions ("a pelete") es arriesgarse mucho.
Hacer clic para expandir...
Por suerte o por desgracia mi mente no da para iniciarme en las raw tras*actions y cagarla. He empezado a ver por dónde iban los tiros y si consigo hacerme entender con coinb.in me doy por contento, y si consigo hacer ver a alguien que habría que llevar el proyecto de coinb.in al día o desarrollar otra herramienta aparte para facilitar estos intercambios, me doy con un canto en los dientes.

La tras*acción firmada solo con un input y el otro por firmar hacia la dirección multifirma, no es una tras*acción normal, verdad? En las instrucciones pone que "Una vez construida la tras*acción, el que la contruido firmaría su input y le haría llegar la tras*acción a la otra persona para que firmase el suyo y lo enviase a la red Bitcoin". Imagino que entre una firma y otra habría que utilizar algún tipo de signature hash types.
 
tastas dijo:
Por suerte o por desgracia mi mente no da para iniciarme en las raw tras*actions y cagarla. He empezado a ver por dónde iban los tiros y si consigo hacerme entender con coinb.in me doy por contento, y si consigo hacer ver a alguien que habría que llevar el proyecto de coinb.in al día o desarrollar otra herramienta aparte para facilitar estos intercambios, me doy con un canto en los dientes.

La tras*acción firmada solo con un input y el otro por firmar hacia la dirección multifirma, no es una tras*acción normal, verdad? En las instrucciones pone que "Una vez construida la tras*acción, el que la contruido firmaría su input y le haría llegar la tras*acción a la otra persona para que firmase el suyo y lo enviase a la red Bitcoin". Imagino que entre una firma y otra habría que utilizar algún tipo de signature hash types.
Hacer clic para expandir...
No es una tras*acción "normal" pero tampoco es nada fuera de lo común. Es una tras*acción idéntica a la que se hace para "incrementar las comisiones" si no entra en un plazo razonable de tiempo en un bloque.

En lugar de firmar todos los inputs y todos los outputs de la tras*acción, firmas tus inputs, el único output, y el importe de los bitcoins que deben llegar a ese output. De manera que esa tras*acción sólo será válida cuando la otra parte firme sus inputs, el output y el importe de la tras*acción.

Si falla algo, la tras*acción será inválida. Así que es la forma tras*parente y sincronizada de que ambos participantes metáis dinero en el fideicomiso de la destrucción mutua asegurada a la vez y sin desconfianzas.

Por cierto, para sacar el dinero del fideicomiso una vez realizada satisfactoriamente la tras*acción sería exactamente igual, pero lo único que cambiaría es que sólamente habría un input y dos outputs (un output para cada uno de los participantes), pero seguiría necesitándose la firma (conformidad) de ambos para que fuese válida. De ahí lo de destrucción mutua asegurada. Si alguna de las dos partes se siente estafada por la tras*acción, jamás firmará esa tras*acción de salida del fideicomiso y ambos perderán la pasta que depositaron para siempre
 
Última edición:
Ya lo he conseguido con tras*acciones normales, es espcialmente complicado que no te deje cargar dos inputs de manera automático, teniendo que introducir manualmente los datos para el segundo input.
No me ha dejado enviar como caja fuerte a una dirección segwit tipo bc1..... así que no creo que me vaya a molestar en tratar de hacerlo todo con direcciones segwit.

Qué pena que no haya más desarrollo de esta herramienta o hayan hecho una similar.
 
jorobar, he leido vuestras últimas intervenciones y he sentido vergüenza ajena. No se como podéis ir tan perdidos. Aunque gracias, rápido la vergüenza se ha convertido en carcajadas.

Enviado desde mi SM-G930F mediante Tapatalk
 
Aprovecho para reflotar este magnífico hilo y preguntar:
Hay alguna manera de limitar la cantidad máxima de bitcoins que puede almacenar una dirección? O al menos, conocéis algún programa al que se le pueda decir que no envíe una tras*acción a una dirección si esta ya tiene una cantidad máxima?
Y las loterías descentralizadas aún no existen, verdad? La idea sería meter en una dirección X BTC y que lo recaudado vaya a una dirección aleatoria de entre un conjunto establecido, por ejemplo entre las direcciones de donde llegaron esos bitcoins.

Es para un trabajo de clase.
 
BISQ es un ejemplo perfecto de otra aplicación de BItcoin NO MONETARIA. Me explico.

BISQ es un exchanger descentralizado, pero que dispone de un sistema de gobernanza que opera a través del sistema de "colored coins" que tiene Bitcoin. Significa que han establecido un sistema de incentivos y de gestión (toma de decisiones mediante votación) gracias a Bitcoin. Es una DAO (Decentralized Autonomous Organization).

Y esto es impresionante. Pensadlo bien. Es una "corporación" descentralizada, sin una sede social, sin cabezas visibles, que se autogestiona y toma decisiones económicas de forma segura, tras*parente y sin depender de depositar confianza en un tercero.

Los sistemas de gobernanza descentralizados y autónomos son otra de las aplicaciones disruptivas, no monetarias y exclusivas de Bitcoin.
 
The Fucking Andyteleco dijo:
Otra aplicación interesante es para votaciones auditables sin posibilidad de fraude.

Cada votante se identifica con su DNI antes de cada votación y recibe una clave privada con una cantidad mínima de satoshis, que mediante un algoritmo de código abierto auditado le es asignada de manera anónima (para que no se pueda asociar con su identidad a la hora de contar los votos), y al mismo tiempo se marca su perfil en la base de datos como "asignado" para que no pueda obtener otra clave.

A la hora de votar, a cada candidato se le asigna una billetera BTC a la que los votantes pueden enviar el saldo de las billeteras durante un margen de tiempo, y una vez finalizado se pueden contar de manera sencilla y automatizada los votos obtenidos por cada candidato.

Se elimina la posibilidad de fraude al hacer pública la lista de claves públicas autorizadas para votar (descartando las que hayan votado sin estar en esa lista). Cada votante puede comprobar en la cadena de bloques que su voto ha sido contabilizado como es debido sin saber lo que han votado los demás.
Hacer clic para expandir...
Cuanto seria una cantidad minima de satoshis???
 
Voto electrónico. Lástima que el NOM no tenga pensando que votemos muy a menudo.
 
Iniciar sesión o registrarte para responder aquí.
Volver