Estoy tratando de crear un nuevo tipo de depósito en garantía con bitcoin, no estoy seguro de si es posible

En primer lugar, entiendo que la forma estándar de hacer un depósito en garantía con bitcoin es un P2SH con un script de canje de 2 de 3 multisig. Me gustaría intentar hacer un depósito en garantía de la siguiente manera:

nombres de 3 partes involucradas:

  • money source
  • escrow agent
  • money destination

hay 2 transacciones involucradas:

  • escrow transaction: money sourceenvía fondos a un script de bloqueo personalizado
  • spending transaction: el escrow agentmueve fondos del escrow transactionalmoney destination

Con estas propiedades, el escrow agenttiene control total sobre el gasto de los fondos, PERO escrow agentsolo puede moverlos al money destinationy a ningún otro lugar. (es decir escrow agent, no puede robar los fondos)

Me doy cuenta de que para que esto funcione, el script de bloqueo personalizado de escrow transactionalguna manera tiene que hacer referencia a la money destinationdirección y proporcionar algún mecanismo tal que cuando el escrow transactionscript de bloqueo esté desbloqueado verifique que la transacción en la que se está utilizando sea de hecho. yendo a la money destination.

Parece que uno no puede hacer referencia directamente a la dirección de salida de spending transactioncuando spending transactionse está verificando. La única forma en que parece que la dirección de salida sea parte de la verificación es indirectamente a través de CHECKSIG (ya que los datos que se firman incluyen la dirección de salida del spending transaction). Pero para que esto funcione, necesitamos firmar spending transactione incluir esa firma en the escrow transaction, pero eso crea una dependencia circular: the escrow transactionincluye una firma de the spending transactionque incluye el hash de the escrow transaction(ya que the escrow transactiones una entrada para the spending transaction). Y entonces esto sería imposible. Desearía que hubiera un tipo de hash que le permitiera firmar solo el lado de salida de la transacción y no las entradas en absoluto.

Soy bastante nuevo en Bitcoin, así que tal vez me estoy perdiendo algo. Pero parece que diseñar un depósito en garantía con las propiedades que describí al comienzo de esta pregunta sería imposible, y la única forma de hacerlo es un P2SH estándar 2 de 3 multisig.

La razón por la que no quiero hacer un multisig estándar es para que funcione sin confianza. money sourcey tienen que intercambiar money destinationsus direcciones directamente (es decir escrow agent, no pueden dar a las otras 2 partes las direcciones apropiadas, porque podría dar las direcciones incorrectas). De esta manera, cuando escrow agentfirma el txn y se lo da a la otra parte para que lo firme, puede verificar que el agente de custodia lo firmó para ir al lugar correcto.

Me gustaría que el escrow agentsea el punto de contacto para las otras 2 partes para que no necesiten hacer un intercambio de direcciones antes de trabajar con el escrow agentpero aún así no tengan que confiar en elescrow agent

Esto me recuerda la propuesta de Bitcoin Covenants de Emin Gun Sirer. Los pactos aún no son posibles, pero creo que se han implementado como una cadena lateral.

Respuestas (1)

Respuesta parcial (no es una solución nueva; simplemente adapté el protocolo del canal de micropagos): si permite el intercambio de claves públicas, me parece que una solución es:

  • t1: sourcefinancia una dirección A controlada por sourceyescrow
  • t2: sourcefirma parcialmente la transacción T gastando A en destination. Luego envía esta transacción parcialmente firmada a escrow.

ahora toca escrowfirmar y transmitir T para que destinationreciba el fondo. Escrowno puede gastar los fondos de manera diferente (es decir, robar) como lo requeriría sourceser cosignatario.

(Problema: Escrowpodría decidir no firmar y "bloquear los fondos" (es por eso que las transacciones de Reembolso se incluyen en los canales de pago). Resuelto Escrowfirmando parcialmente y enviando a la fuente una transacción R enviando los fondos de A de regreso a sourcet0. Ahora depende de sourceenviarse a sí misma los fondos de A. ¿Es esto un problema? No realmente si tiene la transacción R con "tiempo fijo")

Parece más difícil encontrar una solución sin el intercambio de claves públicas... pero es un poco extraño prohibir el intercambio de claves públicas.

¡Gracias! Ahora me doy cuenta de que incluso la solución imposible que propuse aún requeriría un intercambio de clave pública, por lo que supongo que no hay forma de que el agente de custodia sea el punto de contacto para las otras partes y aún así no sea una fuente de confianza.