Diesen Artikel teilen

Día 4 de Kleiman v. Wright: Se retrasa el testimonio de Craig Wright

El autodenominado “Satoshi” probablemente tomará posesión del cargo el lunes.

"Justice" (ca. 1440), Metropolitan Museum of Art
"Justice" (ca. 1440), Metropolitan Museum of Art

MIAMI — Craig Wright, el científico informático australiano mejor conocido por suampliamente disputado Se espera que quien afirma ser Satoshi Nakamoto, el creador seudónimo de Bitcoin , testifique en un tribunal de Miami el lunes.

  • Wright estaba inicialmente programado para testificar el jueves, según un cronograma anterior elaborado para el jurado por la jueza Beth Bloom del Tribunal de Distrito de los EE. UU. para el Distrito Sur de Florida.
  • Sin embargo, el interrogatorio del equipo de defensa de Wright a Ira Kleiman, el demandante en el caso, duró todo el día del jueves y se espera que se prolongue hasta la mañana del viernes.
  • Después de que finalice el testimonio de Kleiman, se espera que los demandantes presenten el testimonio en video pregrabado de dos testigos, incluida la ex esposa de Wright, Lynn Wright.
  • Kleiman está demandando a Wright por lo que alega es la parte de las ganancias que le corresponde a su hermano Dave derivadas de acuerdos comerciales entre los dos hombres, incluida la propiedad intelectual y el Bitcoin que Ira dice que minaron juntos.
  • Ira basó estas afirmaciones en información que recibió de Wright y otros después de la muerte de Dave en abril de 2013, así como en correos electrónicos y otros documentos.
  • Sin embargo, no está claro si Wright tiene acceso a alguno de lospresunto 1,1 millones de Bitcoin (que valdrían más de 67 mil millones de dólares).
  • Gran parte de ella se encuentra en billeteras asociadas con Nakamoto y otras fuentes, pero Wright nunca ha estado dispuesto o ha podido demostrar que controla las billeteras del creador de Bitcoin.
  • Andrés Rivero, abogado principal de la defensa de Wright, centró su interrogatorio de Ira en su tensa relación con su hermano Dave antes de la muerte de este último, en un intento de retratar a Ira como una persona puramente motivada por el beneficio económico.
  • La defensa también intentó restar importancia al supuesto papel de Dave en la concepción de Bitcoin al establecer una cronología de su mala salud física en 2008, el año en que Libro blanco de Bitcoinfue publicado.
  • Bajo el interrogatorio de Rivero, Kleiman afirmó haber borrado y sobrescrito datos de todos los dispositivos, excepto ONE , que se recuperaron entre las pertenencias de David, y haber tirado otro. La defensa argumenta que si Dave tenía Bitcoin u otra información e Ira no pudo encontrarla, es culpa suya.

Sigue leyendo:En el juicio de Craig Wright, los demandantes exponen un patrón de fraude, engaño y arrogancia

jwp-player-placeholder
CONTINÚA MÁS ABAJO
Verpassen Sie keine weitere Geschichte.Abonnieren Sie noch heute den Crypto Daybook Americas Newsletter. Alle Newsletter ansehen
Cheyenne Ligon

On the news team at CoinDesk, Cheyenne focuses on crypto regulation and crime. Cheyenne is originally from Houston, Texas. She studied political science at Tulane University in Louisiana. In December 2021, she graduated from CUNY's Craig Newmark Graduate School of Journalism, where she focused on business and economics reporting. She has no significant crypto holdings.

CoinDesk News Image

Mehr für Sie

Las Fallas en Multisig Domina­n como Principal Factor en la Pérdida de $2 Mil Millones en Hacks de Web3 en el Primer Semestre

Alt

Una ola de hackeos relacionados con multisig y una configuración operativa incorrecta condujeron a pérdidas catastróficas en la primera mitad de 2025.

Was Sie wissen sollten:

  • Más de 2 mil millones de dólares se perdieron debido a hacks en Web3 durante la primera mitad del año, con el primer trimestre superando por sí solo el total de 2024.
  • La mala gestión de billeteras multisig y la manipulación de la interfaz de usuario causaron la mayoría de los principales exploits.
  • Hacken insta a la monitorización en tiempo real y a controles automatizados para prevenir fallos operativos.
(
)