Correos intercambiados entre Satoshi Nakamoto y Dustin D. Trammell en enero del 2009

Quien es Dustin Trammell ?

Dustin de Austin, Texas, fue el elegido por Satoshi Nakamoto, para gestionar la plataforma de SourceForge en los comienzos de Bitcoin, hay una gran cantidad de mail intercambiados entre Satoshi y Dustin desde enero del 2009 https://nakamotostudies.org/emails/re-bitcoin-v0-1-released/

Agradecimientos a Dustin Trammell por compartir los correos que intercambio con Satoshi

el libro de Satoshi
PHIL CHAMPAGNE
Copyright © 2014
Publicado en español por Blockchain España
https://libroblockchain.com/wp-content/uploads/2018/07/Libro-de-Satoshi-Blockchain-Espana-v1-junio-2018.pdf

Dustin Trammell – SourceForge https://t.me/joinchat/Vlm2uAXrH13D_wQO

http://www.dustintrammell.com https://www.dustintrammell.com/blogs

https://about.me/Dustin.D.Trammell

https://www.instagram.com/druidian/

https://bitcointalk.org/index.php?action=profile;u=23696

Nakamoto Family Foundation

«Actualmente estoy aprovechando mi experiencia en los campos de Seguridad de la Información y FinTech para evaluar oportunidades de inversión para los fondos de capital de riesgo de Trammell Venture Partners, así como para continuar construyendo e incubando nuevas empresas tecnológicas innovadoras.

Mi carrera se ha centrado principalmente en la investigación y el desarrollo de seguridad de la información en las áreas de investigación de vulnerabilidades y desarrollo de exploits, ingeniería de código inverso e investigación general de seguridad avanzada de tecnologías como tarjetas inteligentes, voz sobre IP (VoIP) y comunicaciones encubiertas. Soy uno de los primeros en adoptar Bitcoin y tengo experiencia con Bitcoin, libro mayor distribuido y blockchain FinTech. También soy partidario de los movimientos bodyhacking y biohacking.»

https://www.linkedin.com/in/dustintrammell

Minute 40
Dustin Trammell was added to SourceForge

4. Copyright on the Bitcoin White Paper – Satoshi Nakamoto – Dr. Craig S. Wright & Ryan X. Charles
•26 ene 2021
https://www.youtube.com/watch?v=XsQJVqvGBLY

1- 01.11 23_14 – Dustin – Lanzamiento de Re_ Bitcoin v0.1
2- 01.12 12_52 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1
3- 01.12 21_29 – Dustin – Lanzamiento de Re_ Bitcoin v0.1
4- 01.12 21_40 – Dustin – Lanzamiento de Re_ Bitcoin v0.1
5- 01.12 21_49 – Dustin – Otra pregunta
6- 01.13 01_55 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1
7- 01.13 18_40 – Dustin – Lanzamiento de Re_ Bitcoin v0.1
8- 01.15 00_05 – Dustin – Algunas reflexiones…
9- 01.15 13_15 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1
10- 01.15 13_46 – Satoshi – Re_ Algunas reflexiones…
11- 01.15 19_03 – Dustin – Re_ Algunas reflexiones…
12- 01.15 19_14 – Dustin – Lanzamiento de Re_ Bitcoin v0.1
13- 01.16 12_35 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1
14- 01.16 12_42 – Satoshi – Re_ Algunas reflexiones…
15- 01.17 08_58 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1
16- 01.18 09_23 – Dustin – Transferencia de BitCoin
17- 01.18 11_01 – Satoshi – Re_ Transferencia de Bitcoin
18- 01.18 18_09 – Dustin – Re_ Transferencia de Bitcoin
19- 01.19 11_02 – Satoshi – Re_ Transferencia de Bitcoin
20- 01.19 19_58 – Dustin – Re_ Transferencia de Bitcoin
21- 01.25 10_03 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1

————————————————– ——————————–

1- 01.11 23_14 – Dustin – Re_ Bitcoin v0.1 lanzado
El viernes, 2009-01-09 a las 03:27 +0800, Satoshi Nakamoto escribió:> Anunciando el primer lanzamiento de Bitcoin, un nuevo sistema electrónico de dinero en efectivo> que utiliza un par -red de igual a igual para evitar el doble gasto.> Está completamente descentralizado sin servidor ni autoridad central.Actualmente estoy leyendo su artículo. En la sección del servidor de marca de tiempo menciona periódicos y usenet, así que pensé que podría estar interesado en esto si aún no lo ha visto:http://www.publictimestamp.org/
Por cierto, actualmente también estoy ejecutando el código alfa en una de mis estaciones de trabajo. Hasta ahora tiene dos mensajes «Generados», sin embargo, el campo «Crédito» para ellos es 0.00 y el saldo no ha cambiado. ¿Se debe esto al requisito de edad/vencimiento para que una moneda sea válida?

Saludos,

— Dustin D. Trammell dtrammell@dustintrammell.com
http://www.dustintrammell.com

2- 01.12 12_52 – Satoshi – Re_ Bitcoin v0.1 publicado
> Actualmente estoy leyendo su documento. En la sección del servidor de marca de tiempo> menciona periódicos y usenet, así que pensé que podría estar interesado en esto si aún no lo ha visto:> > http://www.publictimestamp.org/Gracias, no había visto eso aún. Se ve muy bien presentado. Había uno más antiguo que ha estado funcionando durante mucho tiempo y publica sus hashes en Usenet. Me sorprende que este no esté usando Usenet, aunque es un poco difícil obtener acceso para publicar en Usenet de forma automatizada en estos días. Si pueden conseguir que una revista o periódico publique sus hashes, sería mucho más fácil en los tribunales para sus propósitos. Bitcoin y todos los servidores de marcas de tiempo comparten la funcionalidad básica de recopilar elementos periódicamente en bloques y convertirlos en una cadena.> Por cierto, actualmente también estoy ejecutando el código alfa en una de mis > estaciones de trabajo. Hasta ahora tiene dos mensajes «Generados», sin embargo, el campo «Crédito» para esos es 0.00 y el saldo no ha cambiado. ¿Es esto debido al requisito de edad/madurez para que una moneda sea válida?
Correcto, el campo de crédito se mantiene en 0,00 hasta que vence, entonces será
50,00. ¿Crees que sería más claro si dejara el campo de crédito en blanco hasta que venza? Debería poner algo de texto en los detalles de la transacción (al hacer doble clic en ella) explicando cómo funciona. (¿era obvio que puede hacer doble clic en una línea para obtener detalles?)

Asegúrese de actualizar a v0.1.3 si aún no lo ha hecho. Esta versión
realmente ha estabilizado las cosas.

3- 01.12 21_29 – Dustin – Re_ Bitcoin v0.1 lanzado el martes
, 2009-01-13 a las 02:33 +0800, Satoshi Nakamoto escribió:> Gracias, no había visto eso todavía. Se ve muy bien presentado.> Había uno más antiguo que ha estado funcionando durante mucho tiempo que> publica sus hashes en Usenet. Me sorprende que este no esté > usando Usenet, aunque es un poco difícil acceder a > publicar en Usenet de forma automatizada en estos días. Si pueden conseguir una revista o periódico para publicar sus hashes, sería mucho más fácil en la corte para sus propósitos. Bitcoin y todos los servidores de marca de tiempo comparten la funcionalidad básica de recopilar cosas periódicamente en bloques y convertirlas en una cadena.En realidad, publica los bloques hash en un grupo de Google llamado ‘proof-hashes’, un resultado tan similar como si estuviera publicando en Usenet.http://groups.google.com/group/proof-hashes
Dado que dirijo ese grupo, y su único propósito es archivar hashes de prueba de trabajo, no dude en unirse a una cuenta para que su sistema también publique allí si lo desea. .

> Correcto, el campo de crédito permanece en 0.00 hasta que vence, entonces será
> 50.00. ¿Crees que sería más claro si dejo el campo de crédito> en blanco hasta que venza? Debería poner algo de texto en los> detalles de la transacción (cuando haces doble clic en él) explicando cómo funciona. (¿era obvio que puede hacer doble clic en una línea para> detalles?)

No, creo que tener $ 0.00 allí es más apropiado que estar en blanco. Sin embargo, las entradas en mi software BitCoin (4 de ellas ahora) dicen «sin confirmar», así que No estoy seguro de lo que eso significa, pero comprendí que las monedas se generaron y aún no estaban ‘maduras’, pero también había leído su documento técnico, por lo que es posible que haya entendido ese concepto a partir de ahí. Cuando las monedas venzan, ¿generará una nueva transacción de «crédito» o se actualizará el campo de crédito de la línea de transacción de generación existente?

No, no sabía que podía hacer doble clic en una línea de transacción para obtener más detalles… Acabo de hacer eso y actualmente solo tiene la misma información que está en la línea de transacción. Poner más información allí definitivamente sería útil.

> Asegúrese de actualizar a v0.1.3 si aún no lo ha hecho. Esta versión> realmente ha estabilizado las cosas.

Estaba ejecutando 0.1.1… Actualizaré ahora. ¿Quizás una nueva función de notificación de versión o actualización automática está en orden? (:

La moneda electrónica y la criptografía son dos cosas en las que estoy muy interesado, por lo que supondrá que me atrajo este proyecto inmediatamente cuando lo vi publicado en la lista de correo electrónico de Criptografía. No dude en enviarme un ping para recibir comentarios o probar nuevas funciones. Estaré encantado de ayudar.

Saludos,

— Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com

4- 01.12 21_40 – Dustin – Lanzamiento de Re_ Bitcoin v0.1

El martes, 2009-01-13 a las 02:33 +0800, Satoshi Nakamoto escribió:
> Asegúrese de actualizar a v0.1.3 si aún no lo ha hecho. Esta versión> realmente ha estabilizado las cosas.

Dos problemas con la actualización:

al cerrar mi versión anterior (la ayuda decía 0.1.1 pero creo que en realidad era 0.1.0), el proceso no se cerró. La interfaz de usuario salió pero el proceso permaneció. Tuve que eliminar manualmente el proceso antes de poder iniciar la versión 0.1.3.

Al abrir la versión 0.1.3, las cuatro entradas de mis transacciones aún dicen «sin confirmar», pero ahora las descripciones dicen «Generado (no aceptado)». ¿Significa esto que algún otro nodo había extendido la cadena primero y mis monedas se generaron en rama muerta? Si es así, ¿por qué la instancia anterior del software no lo detectó de inmediato y comenzó a generar monedas en la rama ganadora? Error en 0.1.0? Veré

esta instancia y veré cómo va…

Gracias,

— Dustin D. Trammell

dtrammell@dustintrammell

5- 01.12 21_49 – Dustin – Otra pregunta
Otra pregunta que tenía… ¿Qué impide que el nodo único con la mayor potencia de CPU genere y retenga la mayoría de las BitCoins? más poderoso que los otros, ¿no es probable que este nodo llegue a la conclusión adecuada antes que otros nodos? Un nodo con poca potencia puede tener suerte de vez en cuando, pero si tienen una ventaja de potencia significativa, esperaría que la mayoría de las BitCoins sean generadas por el nodo más poderoso.–
Dustin D. Trammell
dtrammell@dustintrammell.com

6- 01.13 01_55 – Satoshi – Re_ Bitcoin v0.1 publicado
> En realidad publica los bloques hash en un grupo de Google llamado > ‘proof-hashes’, un resultado tan similar como si estuviera publicando en Usenet.> > http://groups .google.com/group/proof-hashes>
> Dado que dirijo ese grupo, y su único propósito es archivar
> hashes de prueba de trabajo, siéntase libre de unirse a una cuenta para tener su sistema> publique allí también si me gusta.Dulce, estaba buscando un grupo como ese en Usenet en un momento para ver qué usaría si lo necesitara, y nada realmente encajaba. Estoy seguro de que es mucho más fácil publicar en Googlegroups.Hay algunos escenarios en los que un grupo de Usenet o Google podría usarse como defensa adicional. Bitcoin es más vulnerable al principio, cuando la potencia total de la CPU de la red es pequeña. Eso se compensa con el hecho de que el incentivo para atacarlo también es bajo cuando es pequeño. Con suerte, la solución fácil de simplemente crecer y superar esa etapa funcionará. Si no es así, hay formas en que un grupo de Google podría ayudar, si realmente llegara a eso.
> La moneda electrónica y la criptografía son dos cosas en las que estoy muy> interesado, así que supondrá que me atrajo este proyecto> inmediatamente cuando lo vi publicado en la lista de correo electrónico de criptografía. Siéntase libre de enviarme un ping para obtener comentarios o probar nuevas funciones, estaré encantado de ayudar.

¡Definitivamente tenemos intereses similares!

Sabes, creo que había mucha más gente interesada en los años 90, pero después de más de una década de fallas en los sistemas basados en terceros confiables (Digicash, etc.), lo ven como una causa perdida. Espero que puedan hacer la distinción, que esta es la primera vez que sé que estamos probando un sistema basado en la confianza.

> Cuando las> monedas venzan, ¿generará una nueva transacción de ‘crédito’, o se actualizará el campo de crédito de la línea de transacción de generación existente?

La línea de transacción existente cambiará.

> Al abrir la versión 0.1.3, las cuatro entradas de mi transacción aún dicen> ‘sin confirmar’, pero ahora las Descripciones dicen ‘Generado (no aceptado)’.> ¿Significa esto que algún otro nodo había extendido la cadena primero y mi> se generaron monedas en una rama muerta? Si es así, ¿por qué la instancia anterior del software no detectó esto de inmediato y comenzó a generar monedas en la rama ganadora? Error en 0.1.0?

Tienes razón, lo siento. Es el error que se solucionó en 0.1.3. El hilo de comunicaciones se bloquearía, por lo que haría conexiones, pero se silenciarían después de un tiempo. Cuando encontraba un bloque, no podía transmitirlo a la red, por lo que no entraba en la cadena. Tampoco estabas recibiendo nada para saber que la red había continuado sin ti, hasta que la reiniciaste.

El error también es lo que causó que bitcoin.exe no pudiera salir. El
subproceso de comunicaciones se bloqueó y no pudo salir. Bitcoin se apaga cuidadosamente en caso de que esté en medio de una transacción importante, pero en realidad es completamente seguro matarlo.

Todo esto está arreglado en 0.1.3. Si me das tu IP, te enviaré algunas monedas.

> Otra pregunta que tenía… ¿Qué impide que el único nodo con la mayor potencia de CPU genere y retenga la mayoría de los BitCoins?> Si cada nodo funciona independientemente de todos los demás, si uno es significativamente más poderoso que el otros, ¿no es probable que este> nodo llegue a la conclusión adecuada antes que otros nodos? Un nodo con poca potencia puede tener suerte de vez en cuando, pero si tienen una ventaja significativa de potencia, esperaría que la mayoría de los BitCoins fueran generados por el nodo más poderoso.

No es como una carrera en la que si un auto es el doble de rápido, siempre ganará. Es un SHA-256 que tarda menos de un microsegundo y cada intento tiene una probabilidad independiente de éxito. La posibilidad de que cada computadora encuentre una colisión de hash es linealmente proporcional a su potencia de CPU. Una computadora que sea la mitad de rápida obtendría la mitad de monedas.

> Veré esta instancia y veré cómo va…

Déjame saber cómo va. Si tiene algún problema con él, envíeme su archivo debug.log. A menudo puedo averiguar qué salió mal solo por eso.

7- 01.13 18_40 – Dustin – Lanzamiento de Re_ Bitcoin v0.1

El martes, 2009-01-13 a las 15:39 +0800, Satoshi Nakamoto escribió:> Dulce, estaba buscando un grupo como ese en Usenet en un momento dado para ver> qué usaría si lo necesitara, y nada encajaba realmente . Estoy seguro de que es mucho más fácil publicar en los grupos de Google>.

Sí, ese grupo en particular está completamente abierto, no tienes que unirte para publicar (de hecho, creo que dificulté que la gente se uniera), solo envías un correo electrónico a proof-hashes@googlegroups.com y el contenido del correo electrónico se publica. al grupo

> Hay algunos escenarios en los que un grupo de Usenet o Google podría usarse como > una defensa suplementaria. Bitcoin es más vulnerable al principio, cuando la potencia total de la CPU de la red es pequeña. Eso se compensa con el hecho de que el incentivo para atacarlo también es bajo cuando es pequeño. Con suerte, la solución fácil de crecer y superar esa etapa funcionará. Si no, hay formas en que un grupo de Google podría ayudar, si realmente llegara a eso.

Sí, estaba pensando que podría hacer que un cliente publique la cadena de bloques actual cada 10k bloques o algo así, solo para documentar ocasionalmente la cadena de prueba de trabajo ganadora actual.

> ¡Definitivamente tenemos intereses similares!

Por cierto.

> Sabes, creo que había mucha más gente interesada en los 90,> pero después de más de una década de fallas en los sistemas basados en terceros confiables> (Digicash, etc.), lo ven como una causa perdida. Espero que puedan hacer la distinción, que esta es la primera vez que sé que estamos probando un sistema no basado en la confianza.

Sí, esa fue la característica principal que me llamó la atención. El verdadero truco será hacer que la gente realmente valore los BitCoins para que se conviertan en moneda. Actualmente, son solo colecciones de bits…

> Todo esto está arreglado en 0.1.3. Si me das tu IP, te mando unas monedas.

Actualmente estoy en 24.28.79.95, pero eso es dinámico, por lo que puede cambiar. He tenido esa dirección por un tiempo, así que espero que mi cliente dhcp tenga éxito en la renovación y no pierda mi dirección. Cambia de vez en cuando, pero esa dirección debería ser buena por un tiempo.

> No es como una carrera donde si un auto es el doble de rápido, siempre ganará. Es un SHA-256 que tarda menos de un microsegundo, y cada intento tiene una probabilidad de éxito independiente. La posibilidad de que cada computadora encuentre> una colisión hash es linealmente proporcional a su potencia de CPU. Una computadora que sea la mitad de rápida obtendría la mitad de monedas.

Ahh, ya veo… Así que cada suposición es como el giro de una rueda de ruleta,
completamente independiente de todas las demás suposiciones y la potencia adicional de la CPU se traduce en más suposiciones exitosas que cualquier otra persona. Estoy en criptografía (:

> Déjame saber cómo va. Si tienes algún problema con eso, envíame tu> archivo debug.log. A menudo puedo averiguar qué salió mal solo con eso. Lo

haré…

— Dustin D. Trammell

dtrammell@dustintrammell.com

8- 01.15 00_05 – Dustin – Algunas reflexiones…

Me alegra ver que consideró la posibilidad de que un cliente de BitCoin se pague a sí mismo y tenga una descripción adecuada en el registro de transacciones (:

Hice esto principalmente para poder obtener una captura de paquetes del tráfico de red durante una transacción para analizar. Sin conociendo la estructura de su paquete, solo veo un poco de información de texto claro en los paquetes, principalmente lo que se muestra en los detalles de la transacción, como el nombre y los comentarios. Hay un par de otras cadenas que se muestran en el cable, como ‘versión’ y ‘respuesta’ , pero el resto es bastante críptico.

Mientras reflexionaba sobre las transacciones, me di cuenta de que no hay información identificable involucrada además de una dirección IP o una dirección BitCoin. En el caso de la transacción IP, el cliente BitCoin parece confiar en que
la IP que ha conectado realmente es el destinatario de la
transacción. Es bastante trivial lanzar un ataque de hombre en el medio y robar transacciones entrantes. Considere el escenario en el que un compañero de trabajo y yo tenemos ve nuestras estaciones de trabajo en la misma LAN. Siendo nefasto, podría estar envenenando ARP el dominio de transmisión local y enrutando todo el tráfico destinado a su estación de trabajo a través de mi estación de trabajo como intermediario. Ambos, al no ser buenos empleados, jugamos el MMORPG-du-jour y nos gusta comprar y vender artículos de juegos usando BitCoins. Podría vigilar fácilmente las conexiones entrantes en el puerto TCP 8333 y finalizarlas en mi estación de trabajo en lugar de pasar esas conexiones particulares a su estación de trabajo. Un poco complicado, sí, pero ilustra el punto. Este tipo de ataque podría realizarse en cualquier salto a lo largo de la ruta entre las dos partes de la transacción. Si yo fuera un administrador malvado en Big ISP USA, bueno, entiendes la idea.

Recomendaría no permitir el uso de direcciones de red como la dirección de un destinatario previsto. Creo que sería un poco más seguro requerir siempre una dirección de BitCoin y hacer transacciones de esa manera. Si entiendo cómo se hace eso correctamente, simplemente calcula la transacción en la cadena de bloques y deja que el destinatario deseado la «descubra», ¿correcto? Una alternativa podría ser permitir que los nodos de la red brinden un servicio de resolución, donde preguntan por la dirección de red de una dirección de BitCoin, y si ese nodo está en línea, una vez que la red acuerda un consenso para esa dirección, la aplicación de envío de BitCoin se conecta directamente allí. . Debido a que las direcciones de BitCoin están vinculadas a las claves del nodo, creo que se podría idear algún método para probar la propiedad de esa dirección de BitCoin por parte del nodo de envío y no continuar con la transacción si es así. Como mínimo, recomendaría, si tiene la intención de retener el direccionamiento del destinatario por el método IP, es permitir la coincidencia de un hash de un secreto compartido entre las partes o algo que un intermediario no sabría, pero dado que tiene la criptografía en su lugar, las claves generadas, etc. de todos modos, usar eso sería una solución mucho más fuerte.

¿O estoy pensando demasiado en esto y la conexión de red es solo para enviar una notificación inmediata de la transacción y la información de contexto, como el comentario? La aplicación BitCoin mencionó obtener la clave pública del destinatario y algunas otras cosas, y parece haber mucho más en el tráfico de la red de lo que se requeriría para una simple notificación.

Hablaremos pronto,

— Dustin D. Trammell

9- 01.15 13_15 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1

> He tenido esa dirección por un tiempo, así que espero que mi cliente dhcp> tenga éxito en renovar y no perder mi dirección.> Cambia de vez en cuando, pero esa dirección debería ser buena> por un tiempo.

Hay al menos un nodo cuya IP de entrada cambia todo el tiempo dentro de la misma clase B. Tal vez cada vez que se ejecuta el programa. No esperaba eso.

¿Te importa si envío una copia del resto de esto a la lista de bitcoins o a la criptografía?

Por cierto, la lista de bitcoins es:bitcoin-list@lists.sourceforge.netSubscribe/unsubscribe page:http://lists.sourceforge.net/mailman/listinfo/bitcoin-listArchives:http://sourceforge.net/mailarchive/forum. php?forum_name=bitcoin-list

> Dustin D. Trammell escribió:> > Satoshi Nakamoto escribió:> > Sabes, creo que había mucha más gente interesada en los años 90,> > pero después de más de una década de Trusted Third fallido Sistemas basados en partidos > > (Digicash, etc), lo ven como una causa perdida. Espero que puedan hacer la distinción de que esta es la primera vez que sé que estamos probando un sistema no basado en confianza. > > Sí, esa fue la característica principal que me llamó la atención. El verdadero truco
será hacer que la gente realmente valore los BitCoins para que se conviertan en
moneda.

Hal aludió a la posibilidad de que pudiera verse como una inversión en contrapartida. Me sorprendería si dentro de 10 años no estemos usando la moneda electrónica de alguna manera, ahora que conocemos una manera de hacerlo que no se volverá inevitablemente simplista cuando el TTP se acobarde.

Incluso si no despega de inmediato, ahora está disponible para que lo use el siguiente tipo que presente un plan que necesite algún tipo de token o moneda electrónica. Podría comenzar en un sistema cerrado o en un nicho estrecho como puntos de recompensa, tokens de donación, moneda para un juego o micropagos para sitios para adultos. Una vez que se arranca, hay tantas aplicaciones si pudiera pagar unos centavos en un sitio web sin esfuerzo, tan fácilmente como dejar caer monedas en una máquina expendedora.

Ya se puede utilizar para pagar por enviar correo electrónico. El cuadro de diálogo de envío es redimensionable y puede ingresar un mensaje tan largo como desee. Se envía directamente cuando se conecta. El destinatario hace doble clic en la transacción para ver el mensaje completo. Si alguien famoso está recibiendo más correos electrónicos de los que puede leer, pero aún quisiera tener una forma para que los fanáticos se comuniquen con ellos, podría configurar Bitcoin y dar la dirección IP en su sitio web. «Envíe X bitcoins a mi línea directa prioritaria en esta IP y leeré el mensaje personalmente».

Los sitios de suscripción que necesitan una prueba de trabajo adicional para su prueba gratuita para no canibalizar las suscripciones podrían cobrar bitcoins por la prueba.

Satoshi

10- 01.15 13_46 – Satoshi – Re_ Algunas reflexiones…

Agrupo los ataques en dos clases: 1) Ataques que solo puede realizar alguien que esté realmente en la cadena de comunicación 2) Ataques que puede realizar cualquiera en Internet desde cualquier lugar

El tipo 1 lo expone a personas en su casa o empresa en su LAN local, administradores en los ISP en el medio, y la LAN en el lado del destinatario. El tipo 2 lo expone a mil millones de personas que pueden autoseleccionarse para ser atacantes y obtener una economía de escala cuando desarrollan una técnica para atacar a múltiples víctimas.

El envío por IP solicita una nueva clave pública, por lo que sí, es vulnerable al tipo 1 man-in-the-middle. Si eso es una preocupación, enviar a una dirección de Bitcoin no tiene esa vulnerabilidad, aunque hay una pequeña compensación de privacidad. Tengo la sensación de que la mayoría de las veces las personas obtendrán direcciones de Bitcoin de sitios web que no sean SSL y correos electrónicos de texto claro sin firmar, que ya son vulnerables al tipo 1 y al tipo 2 a través del envenenamiento de DNS.

Una solución sería usar tanto la dirección IP como la de Bitcoin al enviar (tal vez 1.2.3.4-1Kn8iojk…), donde el destinatario usa la clave pública de la dirección de Bitcoin para firmar la nueva clave pública para demostrar que está enviando a quien usted creo que eres Si el sistema comienza a usarse para fines comerciales reales, ciertamente lo implementaré. Otra solución es usar SSL.

Por ahora, es bastante obvio que si envía a una IP, no proporcionó ninguna otra información de identificación sobre el destinatario, por lo que está enviando a ciegas a quien responda a esa IP.

Otra característica para más adelante es una opción para cifrar su billetera.

> Si entiendo cómo se hace eso correctamente, simplemente computas la> transacción en la cadena de bloques y dejas que el destinatario previsto> la ‘descubra’, ¿correcto?

Eso es correcto.

> Una alternativa podría ser permitir que los nodos de la red brinden un servicio de resolución, donde preguntan por la dirección de red de una dirección de BitCoin, y si ese nodo está en línea, una vez que la red acuerda un consenso para eso. la dirección de envío> La aplicación BitCoin se conecta directamente allí.

Sería bueno solo necesitar la dirección de Bitcoin y tener la IP entre bastidores. Puede tener problemas de privacidad o denegación de servicio. Ciertamente, antes de que se implemente otro método de envío, ahora hay mucho tiempo para pensar completamente en el diseño y asegurarse de que sea la mejor manera.

Satoshi

11- 01.15 19_03 – Dustin – Re_ Algunas reflexiones…

El viernes, 2009-01-16 a las 03:42 +0800, Satoshi Nakamoto escribió:> El envío por IP solicita una nueva clave pública, así que sí, es vulnerable> para escribir 1 hombre en el medio. Si eso es una preocupación, enviar a una dirección de Bitcoin no tiene esa vulnerabilidad, aunque hay una pequeña compensación de privacidad. Tengo la sensación de que la mayor parte del tiempo> la gente obtendrá direcciones de Bitcoin de sitios web que no sean SSL y> correos electrónicos de texto claro sin firmar, que ya son vulnerables al tipo 1
> y al tipo 2 a través del envenenamiento de DNS.

Cierto, pero la ventaja de usar la dirección de BitCoin es que dos personas pueden comunicarse a través de varios canales diferentes para verificar la dirección. Si mi amigo obtiene mi dirección de mi sitio web y piensa que algo raro está pasando, puede llamarme o enviarme un mensaje instantáneo. mí, o envíeme un correo electrónico, etc. para verificar la dirección. Entonces, un atacante tendría que reemplazar básicamente mi dirección con la maliciosa en todos los canales de comunicación posibles, incluida la voz, lo cual es una hazaña difícil. MITMing la comunicación directa a través de direcciones de red no tiene ese beneficio porque el atacante está falsificando la dirección o interceptando. Mi amigo puede verificar cuál es mi dirección conmigo de la misma manera, sin embargo, verificar la dirección en realidad no mejora la situación.

> Una solución sería usar tanto la dirección IP como la de Bitcoin> al enviar (tal vez 1.2.3.4-1Kn8iojk…), donde el destinatario usa> la clave pública de la dirección de Bitcoin para firmar la nueva clave pública> para probar que estás enviando a quien crees que eres. Si el > sistema comienza a usarse para fines comerciales reales, ciertamente lo implementaré. Otra solución es usar SSL.

Esa es una buena solución. Si realiza transacciones regularmente, probablemente ya tenga la dirección de BitCoin de la otra persona en su libreta de direcciones.

> Otra característica para más adelante es una opción para cifrar su billetera.

Una cosa que me vino a la mente sobre este tema es el potencial de BitCoinloss si tiene una falla en el sistema. La aplicación no parece almacenar ningún dato en el directorio en el que se ejecuta, por lo que asumo que está almacenado en el registro y en otros lugares (no he descifrado ProcessExplorery aún para comprobarlo yo mismo), por lo que puede ser una buena idea tener la aplicación lista. capaz de exportar todo lo que necesita para la recuperación a un archivo del que se puede hacer una copia de seguridad fuera del sistema.

> Sería bueno solo necesitar la dirección de Bitcoin y tener la IP> resuelta detrás de escena. Podría tener problemas de privacidad o denegación de servicio. Ciertamente, antes de que se implemente otro método de envío, ahora hay mucho tiempo para pensar completamente en el diseño y asegurarse de que sea la mejor manera.

Siempre puede hacer que eso sea opcional, como un interruptor que dice ‘Anunciar mi dirección de BitCoin en la red’ que el usuario puede activar o desactivar. Si no se encuentra en la red cuando se busca la dirección de BitCoin, la transacción se inserta en la cadena de bloques de manera normal. Si es así, los metadatos de la transacción podrían comunicarse a la dirección de red.

Otra cosa que noté hoy es que si cierras la aplicación, no parece cerrar limpiamente sus sockets de red (el inicio de vuelo de TCP RST). Probablemente un elemento para la lista de tareas pendientes de baja prioridad (:

Hablamos más tarde,

—
Dustin D. Trammell

12- 01.15 19_14 – Dustin – Lanzamiento de Re_ Bitcoin v0.1

El viernes, 2009-01-16 a las 03:10 +0800, Satoshi Nakamoto escribió:> Hay al menos un nodo cuya IP entrante cambia todo el tiempo dentro de la misma clase B. Tal vez cada vez que se ejecuta el programa. No esperaba eso.

Estoy bastante seguro de que no soy yo. Mi aplicación BitCoin en el trabajo debería convertirse en nuestra dirección NAT estática y mi conexión en casa ha tenido la IP que les di durante al menos 3 días (que he estado transfiriendo monedas entre ellos con fines de prueba).

> ¿Te importa si envío una copia del resto de esto a la lista de bitcoins o > a la criptografía?

Claro, no hay problema.

> Por cierto, la lista de bitcoins es:> bitcoin-list@lists.sourceforge.net> Página de suscripción/cancelación de suscripción:> http://lists.sourceforge.net/mailman/listinfo/bitcoin-list> Archivos:> http:// sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

Me uniré ahora mismo, gracias (:

> Hal aludió a la posibilidad de que podría ser visto como una
inversión de probabilidades largas. Me sorprendería si dentro de 10 años
> no estamos usando moneda electrónica de alguna manera, ahora que sabemos > una forma de hacerlo que no se volverá inevitablemente simplista cuando el TTP > se acobarde

Sí, vi ese mensaje y fue una de las otras razones por las que inicié anode tan rápido. Mis sistemas no están haciendo mucho más mientras están inactivos, entonces, ¿por qué no crear BitCoins? ¿Y si algún día valen algo…? ¡Bono!

> Incluso si no valen nada. t despegue de inmediato, ahora está disponible para que lo use el siguiente tipo que presente un plan que necesite algún tipo de token o moneda electrónica. Podría comenzar en un sistema cerrado o en un nicho estrecho como puntos de recompensa, tokens de donación,> moneda para un juego o micropagos para sitios para adultos. Una vez que se arranca, hay tantas aplicaciones que podrías pagar sin esfuerzo unos pocos centavos en un sitio web con la misma facilidad con que arrojas monedas en una máquina expendedora.

Puedo ver cómo varios tipos de sitios que necesitan micropagos podrían usarlos, sin embargo, también veo un impedimento para la adopción si quieren usar un grupo de pares de BitCoin existente en lugar de un sistema cerrado, ya que primero tendrían que generar suficientes monedas para respaldar lo que quieren. piensa hacer (o comprárselos a otra persona). Un sistema cerrado obviamente no tiene ese problema.

> Ya se puede utilizar para pagar por enviar correo electrónico. El cuadro de diálogo de envío es> redimensionable y puede ingresar un mensaje tan largo como desee.> Se envía directamente cuando se conecta. El destinatario hace doble clic en la transacción para ver el mensaje completo. Si alguien famoso > recibe más correos electrónicos de los que puede leer, pero aún quisiera > tener una forma para que los fanáticos se comuniquen con él, podría configurar Bitcoin y > proporcionar la dirección IP en su sitio web. «Envíe X bitcoins a mi> línea directa prioritaria en esta IP y leeré el mensaje personalmente».

Aplicación interesante (:

> Los sitios de suscripción que necesitan alguna prueba de trabajo adicional para su > prueba gratuita para que no canibalicen las suscripciones podrían cobrar > bitcoins por la prueba.

Otra buena idea.

— Dustin D. Trammell

13- 01.16 12_35 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1

> Dustin D. Trammell escribió:> > Satoshi Nakamoto escribió:> > Sabes, creo que había mucha más gente interesada en los años 90,> > pero después de más de una década de fallas en los sistemas basados en terceros confiables> > (Digicash , etc), lo ven como una causa perdida. Espero que puedan hacer la distinción de que esta es la primera vez que sé que estamos probando un sistema no basado en confianza. > > Sí, esa fue la característica principal que me llamó la atención. El verdadero truco será hacer que la gente realmente valore los BitCoins para que se conviertan en moneda.

Me sorprendería si dentro de 10 años no estemos usando la moneda electrónica de alguna manera, ahora que conocemos una forma de hacerlo que inevitablemente no se volverá tonta cuando el tercero de confianza se acobarde.

Podría comenzar en un nicho estrecho como puntos de recompensa, tokens de donación, moneda para un juego o micropagos para sitios de adultos. Inicialmente, se puede usar en aplicaciones de prueba de trabajo para servicios que casi podrían ser gratuitos, pero no del todo.

Los sitios de suscripción que necesitan una prueba de trabajo adicional para su
prueba gratuita para no canibalizar las suscripciones podrían cobrar bitcoins por la prueba.

Podría tener sentido conseguir algo en caso de que se dé cuenta. Si suficientes personas piensan de la misma manera, eso se convierte en una profecía autocumplida. Una vez que se arranca, hay tantas aplicaciones como si pudiera pagar unos centavos en un sitio web sin esfuerzo, tan fácilmente como dejar caer monedas en una máquina expendedora.

Satoshi Nakamoto
http://www.bitcoin.org

14- 01.16 12_42 – Satoshi – Re_ Algunas reflexiones…

> Una cosa que me vino a la mente sobre este tema es el potencial de pérdida de BitCoin si tiene una falla en el sistema. La aplicación no parece> almacenar ningún dato en el directorio en el que se ejecuta, por lo que asumo que está almacenado> en el registro y en otros lugares (todavía no he descifrado ProcessExplorer> para verificarlo), por lo que puede ser un Es una buena idea que la aplicación pueda exportar todo lo que necesita para la recuperación a un archivo del que se pueda hacer una copia de seguridad fuera del sistema.

Los archivos están en «%appdata%\Bitcoin», ese es el directorio para respaldar. Los datos se almacenan en una base de datos transaccional DBM, por lo que debería estar a salvo de pérdidas si se produce un bloqueo o un corte de energía.

%appdata% es un privilegio de acceso por usuario. La mayoría de los programas nuevos como Firefox almacenan sus archivos de configuración allí, a pesar de que Microsoft cambia el nombre del directorio con cada lanzamiento de Windows y está lleno de espacios y tanto tiempo que se sale de la pantalla.

> Otra cosa que noté hoy es que si cierras la aplicación,
> no parece cerrar limpiamente sus sockets de red (el inicio de TCP RST> vuela). Probablemente un elemento para la lista de tareas pendientes de baja prioridad (:

Acabo de agregar código a la próxima versión para eso.

Satoshi

15- 01.17 08_58 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1

Me sorprendería si dentro de 10 años no estemos usando
la moneda electrónica de alguna manera, ahora que conocemos una forma de hacerlo
que inevitablemente no se volverá tonta cuando el tercero de confianza se acobarde.

Ya se puede utilizar para pagar por enviar correo electrónico. El cuadro de diálogo de envío
se puede cambiar de tamaño y puede ingresar un mensaje tan largo como desee. Se envía directamente cuando se conecta. El destinatario hace doble clic en la transacción para ver el mensaje completo. Si alguien famoso está recibiendo más correos electrónicos de los que puede leer, pero aún quisiera tener una forma para que los fanáticos se comuniquen con ellos, podría configurar Bitcoin y dar la dirección IP en su sitio web. «Envíe X bitcoins a mi línea directa prioritaria en esta IP y leeré el mensaje personalmente».

Los sitios de suscripción que necesitan una prueba de trabajo adicional para su prueba gratuita para no canibalizar las suscripciones podrían cobrar bitcoins por la prueba.

Satoshi Nakamoto http://www.bitcoin.org

—————————————- ——————————————–

La lista de correo de criptografía

Darse de baja enviando «darse de baja de criptografía» a majordomo@metzdowd.com

16- 01.18 09_23 – Dustin – Transferencia de BitCoin

Hola Satoshi,

después de esa primera transferencia de 25,00, no me enviaste otros 100,00, ¿verdad? Me envié 100,00 desde mi aplicación de BitCoin en el trabajo a mi casa usando la dirección de BitCoin en lugar de IP. Mi aplicación en casa recibió una transferencia de 100.00, sin embargo, los detalles de la transacción
dicen «Recibido con: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv». Esa
no es mi dirección de BitCoin del trabajo, así que asumo que esto significa que recibí el pago codificado con un bloque que fue calculado por su cliente. Si es así, ¿cómo supo su nombre además de la dirección de BitCoin que lo generó? No recuerdo que haya un lugar en mi aplicación para poner mi nombre.

–Dustin
D. Trammell

17- 01.18 11_01 – Satoshi – Re_ Transferencia de Bitcoin

Debe ser su dirección de Bitcoin en casa con la que lo recibió. No hay forma de que sepa de quién es, por lo que lo mejor que puede hacer es saber en cuál de sus direcciones se recibió. Puede crear varias direcciones y dar una dirección diferente a cada persona y etiquetarlas para ayudar a descubrir quién le está enviando.

No conoce más nombres que los que le dices. El nombre impreso allí es lo que está asociado en su libreta de direcciones para esa dirección, ya sea bajo el botón Libreta de direcciones o el botón «Cambiar…» a la derecha de su dirección de Bitcoin.

> Hola Satoshi,> > Después de esa primera transferencia de 25,00, no me enviaste otros 100,00> ¿verdad? Me envié 100.00 desde mi aplicación de BitCoin en el trabajo a mi> una en casa usando la dirección de BitCoin en lugar de IP. Mi aplicación
> en casa tiene una transferencia de 100.00 recibida, sin embargo, son los detalles de la transacción> diga «Recibido con: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv «. Esa
> no es mi dirección de BitCoin del trabajo, así que asumo que esto significa que
> recibí el pago codificado con un bloque que fue computado por tu
> cliente? Si es así, ¿cómo supo su nombre además de la dirección BitCoin> que lo generó? No recuerdo que haya un lugar en mi aplicación para poner mi nombre.
>
> — >Dustin D. Trammell> dtrammell@dustintrammell.com> http://www.dustintrammell.com

18- 01.18 18_09 – Dustin – Re_ Transferencia de Bitcoin

El lunes, 2009-01-19 a las 00:54 +0800, Satoshi Nakamoto escribió:> Debería ser su dirección de Bitcoin en casa con la que lo recibió>. No hay forma de que sepa de quién es, por lo que lo mejor> que puede hacer es saber en cuál de sus direcciones se recibió.> Puede crear varias direcciones y dar una dirección diferente> a cada persona y etiquetarlas para ayudar a calcular saber quién está enviando > a usted.

¡Ay! Ni siquiera me di cuenta de que era mi dirección en casa, tienes razón (: tengo varias direcciones creadas en casa, así que no hice la conexión.

> No conoce ningún otro nombre que no sea el que le dices. El nombre> impreso allí está lo que está asociado en su libreta de direcciones para esa> dirección, ya sea bajo el botón Agenda o el botón «Cambiar…»> a la derecha de su dirección de Bitcoin.

Ahh, tiene razón, ‘Satoshi’ es asociado con la dirección que recibió
el pago en las direcciones del botón Cambiar. Sin embargo, no recuerdo haber establecido
ese valor, ¿es ese el valor predeterminado o algo así? (esta es la primera dirección predeterminada que la aplicación generó por sí misma cuando ejecuté por primera vez)

–Dustin D. Trammell

19- 01.19 11_02 – Satoshi – Re_ Transferencia de Bitcoin

>El lunes, 2009-01-19 a las 00:54 +0800, Satoshi Nakamoto escribió:>> Debería ser su dirección de Bitcoin en casa con la que lo recibió>>. No hay forma de que sepa de quién es, por lo que lo mejor>> que puede hacer es decir en cuál de sus direcciones se recibió.>> Puede crear varias direcciones y dar una dirección diferente>> a cada persona y etiquetarlas para ayudar a averiguar quién te está enviando>>.> > ¡Ah! Ni siquiera me di cuenta de que era mi dirección en casa, tienes razón (: Yo> tengo varias direcciones creadas en casa, así que no hice la conexión.> >> No conoce ningún otro nombre que no sea lo que le dices El nombre>> impreso allí es lo que está asociado en tu libreta de direcciones para esa>> dirección, ya sea bajo el botón Agenda o el botón «Cambiar…»>> a la derecha de tu dirección de Bitcoin.> > Ahh, tienes razón, ‘Satoshi’ está asociado con la dirección que recibió> el pago en las direcciones del botón Cambiar. Sin embargo, no recuerdo haber configurado> ese valor, ¿es ese el valor predeterminado o algo así? (este es el primero,
> predeterminado, dirección que la aplicación generó cuando la ejecuté por primera vez
)

El primer predeterminado está etiquetado como «Su dirección» cuando se crea.

Todos los lugares donde se configuran las etiquetas de la libreta de direcciones son donde el usuario lo configura manualmente. La única vez agrega automáticamente una etiqueta en blanco cuando envía a una nueva dirección. Supongo que podría haber ingresado la etiqueta en una dirección que Pensé que era mío, pero el software era confuso y lo pusiste en el lugar equivocado.

Las etiquetas de la libreta de direcciones para recibir direcciones son confusas, pero no estoy seguro de qué más hacer. Cualquiera que lo use para algo más que propósitos simples necesitaría crear diferentes direcciones de recepción para cada pagador para que puedan saber quién les está pagando. Ese concepto no tiene mucha analogía en el mundo real.

Satoshi

20- 01.19 19_58 – Dustin – Re_ Transferencia de Bitcoin

El martes, 2009-01-20 a las 00:44 +0800, Satoshi Nakamoto escribió:> El primer valor predeterminado está etiquetado como «Su dirección» cuando se crea.> > Todos los lugares donde se configuran las etiquetas de la libreta de direcciones son donde el usuario manualmente lo establece. La única vez que agrega automáticamente una etiqueta es una en blanco cuando envía a una nueva dirección. Supongo que podrías haber ingresado la etiqueta en una dirección que creías que era mía, pero el software era confuso y la pusiste en el lugar equivocado.

Eso tendría sentido, apuesto a que eso fue lo que pasó.

> Las etiquetas de la libreta de direcciones para recibir direcciones son confusas, pero no estoy seguro de qué más hacer. Cualquiera que lo use para algo más que propósitos simples necesitaría crear diferentes direcciones de recepción para cada pagador para que puedan saber quién les está pagando. Ese concepto no tiene mucha analogía en el mundo real.

Creo que si hubiera dicho «Recibido con dirección: X» en lugar de simplemente
«Recibido con: X», creo que lo habría entendido, aunque estoy seguro de que la dirección está mal etiquetada como «Satoshi» fue la razón principal de mi confusión inicial. Sin embargo, tiene razón, realmente no hay nada comparable en el sistema financiero actual a lo que la gente esté acostumbrada, aparte de tal vez poder usar múltiples direcciones de correo electrónico de destinatarios para PayPal. ¿Quizás podría decir «Pago recibido para: X»?

–Dustin D. Trammell

21- 01.25 10_03 – Satoshi – Lanzamiento de Re_ Bitcoin v0.1

Hal Finney escribió:> > * Las botnets de spammers podrían quemar los filtros de correo electrónico de pago por envío> > trivialmente> Si los tokens POW se vuelven útiles, y especialmente si se convierten en dinero,> las máquinas ya no estarán inactivas. Los usuarios esperarán que sus computadoras les hagan ganar dinero (suponiendo que la recompensa sea mayor que el costo de operar). Una computadora cuyas ganancias están siendo robadas por una red de bots será más notoria para su propietario que en la actualidad, por lo tanto, podríamos esperar que en ese mundo, los usuarios trabajen más para mantener sus computadoras y limpiarlas de infestaciones de redes de bots.

Otro factor que mitigaría el spam si los tokens POW tienen valor: habría un motivo de lucro para que las personas configuren cantidades masivas de cuentas de correo electrónico falsas para recolectar tokens POW del spam. Básicamente, estarían enviando spam inverso a los spammers con
buzones automáticos que recopilan su POW y no leen el
mensaje. La proporción entre buzones de correo falsos y personas reales podría volverse demasiado alta para que el spam sea rentable.

El proceso tiene el potencial de establecer el valor del token POW en primer lugar, ya que los spammers que no tienen una botnet podrían comprar tokens de los recolectores. Si bien la recompra dejaría pasar temporalmente más spam, solo aceleraría el ciclo contraproducente que llevaría a que demasiados recolectores se aprovecharan de los spammers.

Curiosamente, uno de los sistemas de e-gold ya tiene una forma de spam llamada «polvo». Los spammers envían una pequeña cantidad de polvo de oro para colocar un mensaje de spam en el campo de comentarios de la transacción. Si el sistema permite a los usuarios configurar el pago mínimo que están dispuestos a recibir, o al menos el mínimo que puede tener un mensaje con él, los usuarios podrían establecer cuánto están dispuestos a que les paguen por recibir spam.

Satoshi Nakamoto

Emails exchanged between Satoshi Nakamoto and Dustin D. Trammell in January 2009

01.11 23_14 – Dustin – Re_ Bitcoin v0.1 released
01.12 12_52 – Satoshi – Re_ Bitcoin v0.1 released
01.12 21_29 – Dustin – Re_ Bitcoin v0.1 released
01.12 21_40 – Dustin – Re_ Bitcoin v0.1 released
01.12 21_49 – Dustin – One Other Question
01.13 01_55 – Satoshi – Re_ Bitcoin v0.1 released
01.13 18_40 – Dustin – Re_ Bitcoin v0.1 released
01.15 00_05 – Dustin – A few thoughts…
01.15 13_15 – Satoshi – Re_ Bitcoin v0.1 released
01.15 13_46 – Satoshi – Re_ A few thoughts…
01.15 19_03 – Dustin – Re_ A few thoughts…
01.15 19_14 – Dustin – Re_ Bitcoin v0.1 released
01.16 12_35 – Satoshi – Re_ Bitcoin v0.1 released
01.16 12_42 – Satoshi – Re_ A few thoughts…
01.17 08_58 – Satoshi – Re_ Bitcoin v0.1 released
01.18 09_23 – Dustin – BitCoin Transfer
01.18 11_01 – Satoshi – Re_ Bitcoin Transfer
01.18 18_09 – Dustin – Re_ Bitcoin Transfer
01.19 11_02 – Satoshi – Re_ Bitcoin Transfer
01.19 19_58 – Dustin – Re_ Bitcoin Transfer
01.25 10_03 – Satoshi – Re_ Bitcoin v0.1 released

———————————————————————————-

01.11 23_14 – Dustin – Re_ Bitcoin v0.1 released
On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:
> Announcing the first release of Bitcoin, a new electronic cash
> system that uses a peer-to-peer network to prevent double-spending.
> It’s completely decentralized with no server or central authority.I’m currently reading through your paper. At the timestamp server
section you mention newspapers and usenet, so I thought you might be
interested in this if you have not seen it already:http://www.publictimestamp.org/
By the way, I’m also currently running the alpha code on one of my
workstations. So far it has two «Generated» messages, however the
«Credit» field for those is 0.00 and the balance hasn’t changed. Is
this due to the age/maturity requirement for a coin to be valid?

Cheers,

—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com

01.12 12_52 – Satoshi – Re_ Bitcoin v0.1 released
> I’m currently reading through your paper. At the timestamp server
> section you mention newspapers and usenet, so I thought you might be
> interested in this if you have not seen it already:
>
> http://www.publictimestamp.org/Thanks, I hadn’t seen that yet. It looks very well presented.
There was an older one that’s been running for a long time that
publishes its hashes to Usenet. I’m surprised this one isn’t
using Usenet, although it is kind of difficult to get access to
post to Usenet in an automated way these days. If they can get a
magazine or newspaper to publish their hashes, it would work a lot
easier in court for their purposes. Bitcoin and all timestamp
servers share the basic functionality of periodically collecting
things into blocks and hashing them into a chain.> By the way, I’m also currently running the alpha code on one of my
> workstations. So far it has two «Generated» messages, however the
> «Credit» field for those is 0.00 and the balance hasn’t changed. Is
> this due to the age/maturity requirement for a coin to be valid?
Right, the credit field stays 0.00 until it matures, then it’ll be
50.00. Do you think it would be clearer if I left the credit
field blank until it matures? I should put some text in the
transaction details (when you double click on it) explaining how
it works. (was it obvious you can doubleclick on a line for
details?)

Be sure to upgrade to v0.1.3 if you haven’t already. This version
has really stabilized things.

01.12 21_29 – Dustin – Re_ Bitcoin v0.1 released
On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
> Thanks, I hadn’t seen that yet. It looks very well presented.
> There was an older one that’s been running for a long time that
> publishes its hashes to Usenet. I’m surprised this one isn’t
> using Usenet, although it is kind of difficult to get access to
> post to Usenet in an automated way these days. If they can get a
> magazine or newspaper to publish their hashes, it would work a lot
> easier in court for their purposes. Bitcoin and all timestamp
> servers share the basic functionality of periodically collecting
> things into blocks and hashing them into a chain.It actually posts the hash blocks to a Google Group called
‘proof-hashes’, so similar result as if it were posting to Usenet.http://groups.google.com/group/proof-hashes
Since I run that group, and it’s sole purpose is to archive
proof-of-work hashes, feel free to join an account to have your system
post there as well if you like.

> Right, the credit field stays 0.00 until it matures, then it’ll be
> 50.00. Do you think it would be clearer if I left the credit
> field blank until it matures? I should put some text in the
> transaction details (when you double click on it) explaining how
> it works. (was it obvious you can doubleclick on a line for
> details?)

No, I think having $0.00 there is more appropriate than being blank.
The entries in my BitCoin software (4 of them now) all say ‘unconfirmed’
however, so I’m not sure what that means, but I did grok that the coins
were generated and just not ‘mature’ yet, but I had also read your
whitepaper so I may have understood that concept from there. When the
coins mature, will that generate a new ‘credit’ transaction, or will the
existing generation transaction line’s credit field be updated?

No, I was unaware that you could double-click a transaction line for
further details… I just did that and it currently just has the same
information there that is in the transaction line. Putting more
information there would definitely be useful.

> Be sure to upgrade to v0.1.3 if you haven’t already. This version
> has really stabilized things.

I was running 0.1.1… I will update now. Perhaps a new version
notification or auto-update feature is in order? (:

Electronic currency and cryptography are two things that I am very
interested in so as you would assume I was drawn to this project
immediately when I saw it posted to the Cryptography email list. Feel
free to ping me for feedback or to test out new features, I’ll be happy
to help out.

Cheers,

—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com

01.12 21_40 – Dustin – Re_ Bitcoin v0.1 released

On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
> Be sure to upgrade to v0.1.3 if you haven’t already. This version
> has really stabilized things.

Two issues with upgrading:

When closing my previous version (help said 0.1.1 but I think it was
really 0.1.0), the process did not exit. The UI exited but the process
remained. I had to manually kill the process before I was able to start
version 0.1.3.

Upon opening version 0.1.3, all four of my transaction entries still say
‘unconfirmed’, but now the Descriptions say ‘Generated (not accepted)’.
Does this mean that some other node had extended the chain first and my
coins were generated in a dead branch? If so, why did the previous
instance of the software not detect this immediately and begin
generating coins in the winning branch? Bug in 0.1.0?

I’ll watch this instance and see how it goes…

Thanks,

—
Dustin D. Trammell
dtrammell@dustintrammell

01.12 21_49 – Dustin – One Other Question
One other question I had… What prevents the single node with the most
CPU power from generating and retaining the majority of the BitCoins?
If every node is working independently of all others, if one is
significantly more powerful than the others, isn’t it probable that this
node will reach the proper conclusion before other nodes? An
underpowered node may get lucky once in a while, but if they are at a
significant horsepower advantage I would expect the majority of BitCoins
to be generated by the most powerful node.–
Dustin D. Trammell
dtrammell@dustintrammell.com

01.13 01_55 – Satoshi – Re_ Bitcoin v0.1 released
> It actually posts the hash blocks to a Google Group called
> ‘proof-hashes’, so similar result as if it were posting to Usenet.
>
> http://groups.google.com/group/proof-hashes
>
> Since I run that group, and it’s sole purpose is to archive
> proof-of-work hashes, feel free to join an account to have your system
> post there as well if you like.Sweet, I was looking for a group like that on Usenet at one point to see
what I would use if I needed, and nothing really fit. I’m sure Google
groups is a lot easier to post to.There are some scenarios where a Usenet or Google group could be used as
a supplemental defence. Bitcoin is at its most vulnerable in the
beginning when the total network CPU power is small. That’s offset by
the fact that the incentive to attack it is also low when it’s small.
Hopefully the easy solution of just growing up and getting past that
stage will work. If not, there are ways a Google group could help, if
it really came to that.
> Electronic currency and cryptography are two things that I am very
> interested in so as you would assume I was drawn to this project
> immediately when I saw it posted to the Cryptography email list. Feel
> free to ping me for feedback or to test out new features, I’ll be happy
> to help out.

We definitely have similar interests!

You know, I think there were a lot more people interested in the 90’s,
but after more than a decade of failed Trusted Third Party based systems
(Digicash, etc), they see it as a lost cause. I hope they can make the
distinction, that this is the first time I know of that we’re trying a
non-trust based system.

> When the
> coins mature, will that generate a new ‘credit’ transaction, or will the
> existing generation transaction line’s credit field be updated?

The existing transaction line will change.

> Upon opening version 0.1.3, all four of my transaction entries still say
> ‘unconfirmed’, but now the Descriptions say ‘Generated (not accepted)’.
> Does this mean that some other node had extended the chain first and my
> coins were generated in a dead branch? If so, why did the previous
> instance of the software not detect this immediately and begin
> generating coins in the winning branch? Bug in 0.1.0?

You’re right, sorry about that. It’s the bug that was fixed in 0.1.3.
The communications thread would get blocked, so you would make
connections, but they would go silent after a while. When you found a
block, you couldn’t broadcast it to the network, so it didn’t get into
the chain. You weren’t receiving anything either to know that the
network had gone on without you, until you restarted it.

The bug is also what caused bitcoin.exe to fail to exit. The
communications thread was blocked and failed to exit. Bitcoin does a
careful shutdown in case it might be in the middle of an important
transaction, but actually it’s completely safe to kill it.

This is all fixed in 0.1.3. If you give me your IP, I’ll send you some
coins.

> One other question I had… What prevents the single node with the most
> CPU power from generating and retaining the majority of the BitCoins?
> If every node is working independently of all others, if one is
> significantly more powerful than the others, isn’t it probable that this
> node will reach the proper conclusion before other nodes? An
> underpowered node may get lucky once in a while, but if they are at a
> significant horsepower advantage I would expect the majority of BitCoins
> to be generated by the most powerful node.

It’s not like a race where if one car is twice as fast, it’ll always
win. It’s an SHA-256 that takes less than a microsecond, and each guess
has an independent chance of success. Each computer’s chance of finding
a hash collision is linearly proportional to it’s CPU power. A computer
that’s half as fast would get half as many coins.

> I’ll watch this instance and see how it goes…

Let me know how it goes. If you have any trouble with it, send me your
debug.log file. I can often figure out what went wrong just from that.

01.13 18_40 – Dustin – Re_ Bitcoin v0.1 released

On Tue, 2009-01-13 at 15:39 +0800, Satoshi Nakamoto wrote:
> Sweet, I was looking for a group like that on Usenet at one point to see
> what I would use if I needed, and nothing really fit. I’m sure Google
> groups is a lot easier to post to.

Yea, that particular group is completely open, you don’t have to join to
post (in fact I think I made it difficult for people to actually join),
you just email proof-hashes@googlegroups.com and the content of the
email gets posted to the group.

> There are some scenarios where a Usenet or Google group could be used as
> a supplemental defence. Bitcoin is at its most vulnerable in the
> beginning when the total network CPU power is small. That’s offset by
> the fact that the incentive to attack it is also low when it’s small.
> Hopefully the easy solution of just growing up and getting past that
> stage will work. If not, there are ways a Google group could help, if
> it really came to that.

Yea, I was thinking you could have a client post the current block chain
every 10k blocks or something, just to occasionally document the current
winning proof-of-work chain.

> We definitely have similar interests!

Indeed.

> You know, I think there were a lot more people interested in the 90’s,
> but after more than a decade of failed Trusted Third Party based systems
> (Digicash, etc), they see it as a lost cause. I hope they can make the
> distinction, that this is the first time I know of that we’re trying a
> non-trust based system.

Yea, that was the primary feature that caught my eye. The real trick
will be to get people to actually value the BitCoins so that they become
currency. Currently, they’re just collections of bits…

> This is all fixed in 0.1.3. If you give me your IP, I’ll send you some
> coins.

I’m currently at 24.28.79.95, but that’s dynamic so it may change. I’ve
had that address for a while though so hopefully my dhcp client is being
successful at renewing and not losing my address. It does change from
time to time, but that address should be good for a while.

> It’s not like a race where if one car is twice as fast, it’ll always
> win. It’s an SHA-256 that takes less than a microsecond, and each guess
> has an independent chance of success. Each computer’s chance of finding
> a hash collision is linearly proportional to it’s CPU power. A computer
> that’s half as fast would get half as many coins.

Ahh I see… So each guess is like the spin of a roulette wheel,
completely independent from all other guesses and the extra CPU power
just translates to more successful guesses than anyone else.
Unfortunately my ability to understand complex mathematics is conversely
proportional to how interested I am in cryptography (:

> Let me know how it goes. If you have any trouble with it, send me your
> debug.log file. I can often figure out what went wrong just from that.

Will do…

—
Dustin D. Trammell
dtrammell@dustintrammell.com

01.15 00_05 – Dustin – A few thoughts…

I’m glad to see you considered the possibility of a BitCoin client
making a payment to itself and have an appropriate description in the
transaction log (:

I did this primarily so that I could get a packet capture of the network
traffic during a transaction to analyze. Without knowing your packet
structure, I only see a bit of cleartext information in the packets,
mostly just what is shown in the transaction detail such as name and
comments. There are a couple of other strings that show upon the wire
such as ‘version’ and ‘reply’, but the rest is pretty cryptic.

While pondering transactions, I realized that there is no identifiable
information involved other than an IP address or a BitCoin address. In
the case of the IP transaction, the BitCoin client seems to trust that
the IP that it has connected to really is the intended recipient of the
transaction. It is fairly trivial to launch a man-in-the-middle attack
and steal incoming transactions. Consider the scenario where a
co-worker and myself have our workstations on the same LAN. Being
nefarious, I could be ARP poisoning the local broadcast domain and
routing all traffic destined for his workstation through my workstation
as an intermediary. Both of us, not being good employees, play the
MMORPG-du-jour and like to buy and sell game items using BitCoins. I
could easily watch for incoming connections on TCP port 8333 and
terminate them at my workstation rather than passing those particular
connections on to his workstation. A bit convoluted, yes, but it
illustrates the point. This type of attack could be performed at any
hop along the route between the two transacting parties. If I were an
evil admin at Big ISP USA, well, you get the idea.

I would recommend not allowing the use of network addresses as the
address of an intended recipient. I would think it would be a bit more
secure to always require a BitCoin address and do transactions that way.
If I understand how that is done correctly, you just compute the
transaction into the block chain and let the intended recipient
‘discover’ it, correct? An alternative could be to allow the network
nodes to provide a resolution service, where they ask around for the
network address of a BitCoin address, and if that node is online, once a
consensus is agreed upon by the network for that address the sending
BitCoin application connects directly there. Because the BitCoin
addresses are tied to the keys of the node, I would think that some
method could be devised to prove ownership of that BitCoin address by
the sending node and not to proceed with the transaction if so. At the
very least I would recommend, if you intend to retain the recipient
addressing by IP method is to allow for matching a hash of a shared
secret between the parties or something that an intermediary would not
know, but since you have the crypto in place, keys generated, etc.
anyhow, using that would be a much stronger solution.

Or am I over-thinking this and the network connection is just to send
immediate notification of the transaction and context information such
as the comment? The BitCoin application mentioned getting the
recipient’s public key and a few other things, and there seems to be a
lot more going on in the network traffic than what would be required for
a simple notification.

Talk to you soon,

—
Dustin D. Trammell

01.15 13_15 – Satoshi – Re_ Bitcoin v0.1 released

> I’ve had that address for a while though so hopefully my dhcp
> client is being successful at renewing and not losing my address.
> It does change from time to time, but that address should be good
> for a while.

There’s at least one node who’s inbound IP keeps changing all the
time within the same class B. Maybe every time the program is
run. I wasn’t expecting that.

Do you mind if I CC the rest of this to bitcoin-list or
Cryptography?

BTW, bitcoin-list is:
bitcoin-list@lists.sourceforge.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

> Dustin D. Trammell wrote:
> > Satoshi Nakamoto wrote:
> > You know, I think there were a lot more people interested in the 90’s,
> > but after more than a decade of failed Trusted Third Party based systems
> > (Digicash, etc), they see it as a lost cause. I hope they can make the
> > distinction that this is the first time I know of that we’re trying a
> > non-trust-based system.
>
> Yea, that was the primary feature that caught my eye. The real trick
> will be to get people to actually value the BitCoins so that they become
> currency.

Hal sort of alluded to the possibility that it could be seen as a
long-odds investment. I would be surprised if 10 years from now
we’re not using electronic currency in some way, now that we know
a way to do it that won’t inevitably get dumbed down when the TTP
gets cold feet.

Even if it doesn’t take off straight away, it’s now available for
use by the next guy who comes up with a plan that needs some kind
of token or electronic currency. It could get started in a closed
system or narrow niche like reward points, donation tokens,
currency for a game or micropayments for adult sites. Once it
gets bootstrapped, there are so many applications if you could
effortlessly pay a few cents to a website as easily as dropping
coins in a vending machine.

It can already be used for pay-to-send e-mail. The send dialog is
resizeable and you can enter as long of a message as you like.
It’s sent directly when it connects. The recipient doubleclicks
on the transaction to see the full message. If someone famous is
getting more e-mail than they can read, but would still like to
have a way for fans to contact them, they could set up Bitcoin and
give out the IP address on their website. «Send X bitcoins to my
priority hotline at this IP and I’ll read the message personally.»

Subscription sites that need some extra proof-of-work for their
free trial so it doesn’t cannibalize subscriptions could charge
bitcoins for the trial.

Satoshi

01.15 13_46 – Satoshi – Re_ A few thoughts…

I group attacks into two classes:
1) Attacks that can only be done by someone actually in the chain
of communication
2) Attacks that can be done by anyone on the Internet from anywhere

Type 1 exposes you to people in your house or company on your
local LAN, admins at ISPs in between, and the LAN on the
recipient’s side. Type 2 exposes you to a billion people who can
self-select to be attackers and get economy of scale when they
develop one technique to attack multiple victims.

Sending by IP requests a new public key, so yes, it’s vulnerable
to type 1 man-in-the-middle. If that’s a concern, sending to a
Bitcoin address doesn’t have that vulnerability, although there’s
a small privacy tradeoff. I have a feeling most of the time
people will get Bitcoin addresses off of non-SSL websites and
unsigned cleartext e-mail, which is already vulnerable to type 1
and type 2 through DNS poisoning.

One solution would be to use both the IP and Bitcoin addresses
when sending (maybe 1.2.3.4-1Kn8iojk…), where the recipient uses
the public key of the Bitcoin address to sign the new public key
to prove that you’re sending to who you think you are. If the
system starts to be used for real business purposes, I will
certainly implement that. Another solution is to use SSL.

For now, it’s pretty obvious that if you send to an IP, you didn’t
give any other identifying information about the recipient, so
you’re blindly sending to whoever answers that IP.

Another feature for later is an option to encrypt your wallet.

> If I understand how that is done correctly, you just compute the
> transaction into the block chain and let the intended recipient
> ‘discover’ it, correct?

That’s correct.

> An alternative could be to allow the network
> nodes to provide a resolution service, where they ask around for the
> network address of a BitCoin address, and if that node is online, once a
> consensus is agreed upon by the network for that address the sending
> BitCoin application connects directly there.

It would be nice to only need the Bitcoin address and have the IP
worked out behind the scenes. Might have privacy or denial of
service issues. Certainly before another sending method is
implemented, there’s plenty of time now to fully think through the
design and make sure it’s the best way.

Satoshi

01.15 19_03 – Dustin – Re_ A few thoughts…

On Fri, 2009-01-16 at 03:42 +0800, Satoshi Nakamoto wrote:
> Sending by IP requests a new public key, so yes, it’s vulnerable
> to type 1 man-in-the-middle. If that’s a concern, sending to a
> Bitcoin address doesn’t have that vulnerability, although there’s
> a small privacy tradeoff. I have a feeling most of the time
> people will get Bitcoin addresses off of non-SSL websites and
> unsigned cleartext e-mail, which is already vulnerable to type 1
> and type 2 through DNS poisoning.

True, but the upside to using the BitCoin address is that two people can
communicate via a number of different channels to verify the address.
If my friend gets my address off my website, and thinks something fishy
is going on, he can call me, or IM me, or email me, etc. to verify the
address. An attacker would then have to basically be replacing my
address with the malicious one in every possible communications channel,
including voice, which is a difficult feat. MITMing the direct
communication via network addresses doesn’t have that benefit because
the attacker is spoofing the address or intercepting. My friend can
verify what my address is with me in the same ways, however verifying
the address doesn’t actually improve the situation.

> One solution would be to use both the IP and Bitcoin addresses
> when sending (maybe 1.2.3.4-1Kn8iojk…), where the recipient uses
> the public key of the Bitcoin address to sign the new public key
> to prove that you’re sending to who you think you are. If the
> system starts to be used for real business purposes, I will
> certainly implement that. Another solution is to use SSL.

That is a good solution. If you transact regularly you probably already
have the other person’s BitCoin address in your address book.

> Another feature for later is an option to encrypt your wallet.

One thing that came to mind on this topic is the potential for BitCoin
loss if you have a system failure. The application doesn’t seem to
store any data in the directory that it runs in, so I assume it’s stored
in the registry and other places (haven’t cracked out ProcessExplorer
yet to check myself), so it may be a good idea to have the application
be able to export everything that it needs for recovery to a file that
could be backed up off of the system.

> It would be nice to only need the Bitcoin address and have the IP
> worked out behind the scenes. Might have privacy or denial of
> service issues. Certainly before another sending method is
> implemented, there’s plenty of time now to fully think through the
> design and make sure it’s the best way.

You could always make that optional, such as a toggle that says
‘Advertise my BitCoin address to the network’ that the user could turn
on or off. If you’re not found on the network when searched for by
BitCoin address, the transaction is inserted into the block-chain as
normal. If you are, the transaction meta-data could be communicated to
the network address.

One other thing I noticed today is that if you close the application it
doesn’t appear to cleanly close it’s network sockets (TCP RST’s start
flying). Probably an item for the low-priority todo list (:

Talk to you later,

—
Dustin D. Trammell

01.15 19_14 – Dustin – Re_ Bitcoin v0.1 released

On Fri, 2009-01-16 at 03:10 +0800, Satoshi Nakamoto wrote:
> There’s at least one node who’s inbound IP keeps changing all the
> time within the same class B. Maybe every time the program is
> run. I wasn’t expecting that.

Pretty sure that’s not me. My BitCoin application at work should be
coming from our static NAT address and my connection at home has had the
IP that I gave you for at least 3 days now (that I’ve been transferring
coins between them for test purposes).

> Do you mind if I CC the rest of this to bitcoin-list or
> Cryptography?

Sure, no problem.

> BTW, bitcoin-list is:
> bitcoin-list@lists.sourceforge.net
> Subscribe/unsubscribe page:
> http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

I’ll join right now, thanks (:

> Hal sort of alluded to the possibility that it could be seen as a
> long-odds investment. I would be surprised if 10 years from now
> we’re not using electronic currency in some way, now that we know
> a way to do it that won’t inevitably get dumbed down when the TTP
> gets cold feet.

Yes, I saw that message and was one of the other reasons I started up a
node so quickly. My systems aren’t doing much of anything else while
idle, so why not create BitCoins? And if they’re worth something
someday…? Bonus!

> Even if it doesn’t take off straight away, it’s now available for
> use by the next guy who comes up with a plan that needs some kind
> of token or electronic currency. It could get started in a closed
> system or narrow niche like reward points, donation tokens,
> currency for a game or micropayments for adult sites. Once it
> gets bootstrapped, there are so many applications if you could
> effortlessly pay a few cents to a website as easily as dropping
> coins in a vending machine.

I can see how various types of sites that have a need for micropayments
could use them, however I also see an impedement to adoption if they
want to use an existing BitCoin peer group rather than a closed system
since they would first have to generate enough coins to support what
they intend to do (or buy them from someone else). A closed system
obviously doesn’t have that problem.

> It can already be used for pay-to-send e-mail. The send dialog is
> resizeable and you can enter as long of a message as you like.
> It’s sent directly when it connects. The recipient doubleclicks
> on the transaction to see the full message. If someone famous is
> getting more e-mail than they can read, but would still like to
> have a way for fans to contact them, they could set up Bitcoin and
> give out the IP address on their website. «Send X bitcoins to my
> priority hotline at this IP and I’ll read the message personally.»

Interesting application (:

> Subscription sites that need some extra proof-of-work for their
> free trial so it doesn’t cannibalize subscriptions could charge
> bitcoins for the trial.

Another good idea.

—
Dustin D. Trammell

01.16 12_35 – Satoshi – Re_ Bitcoin v0.1 released

I would be surprised if 10 years from now we’re not using
electronic currency in some way, now that we know a way to do it
that won’t inevitably get dumbed down when the trusted third party
gets cold feet.

It could get started in a narrow niche like reward points,
donation tokens, currency for a game or micropayments for adult
sites. Initially it can be used in proof-of-work applications
for services that could almost be free but not quite.

Subscription sites that need some extra proof-of-work for their
free trial so it doesn’t cannibalize subscriptions could charge
bitcoins for the trial.

It might make sense just to get some in case it catches on. If
enough people think the same way, that becomes a self fulfilling
prophecy. Once it gets bootstrapped, there are so many
applications if you could effortlessly pay a few cents to a
website as easily as dropping coins in a vending machine.

Satoshi Nakamoto
http://www.bitcoin.org

01.16 12_42 – Satoshi – Re_ A few thoughts…

> One thing that came to mind on this topic is the potential for BitCoin
> loss if you have a system failure. The application doesn’t seem to
> store any data in the directory that it runs in, so I assume it’s stored
> in the registry and other places (haven’t cracked out ProcessExplorer
> yet to check myself), so it may be a good idea to have the application
> be able to export everything that it needs for recovery to a file that
> could be backed up off of the system.

The files are in «%appdata%\Bitcoin», that’s the directory to
backup. The data is stored in a transactional database DBM, so
it should be safe from loss if there’s a crash or power failure.

%appdata% is per-user access privilege. Most new programs like
Firefox store their settings files there, despite the headwind of
Microsoft changing the directory name with every Windows release
and being full of spaces and so long it runs off the screen.

> One other thing I noticed today is that if you close the application it
> doesn’t appear to cleanly close it’s network sockets (TCP RST’s start
> flying). Probably an item for the low-priority todo list (:

Just now added code to the next release for that.

Satoshi

01.17 08_58 – Satoshi – Re_ Bitcoin v0.1 released

I would be surprised if 10 years from now we’re not using
electronic currency in some way, now that we know a way to do it
that won’t inevitably get dumbed down when the trusted third party
gets cold feet.

Subscription sites that need some extra proof-of-work for their
free trial so it doesn’t cannibalize subscriptions could charge
bitcoins for the trial.

Satoshi Nakamoto
http://www.bitcoin.org

———————————————————————
The Cryptography Mailing List
Unsubscribe by sending «unsubscribe cryptography» to majordomo@metzdowd.com

01.18 09_23 – Dustin – BitCoin Transfer

Hey Satoshi,

After that first transfer of 25.00, you didn’t send me another 100.00
did you? I sent myself 100.00 from my BitCoin application at work to my
one at home using the BitCoin address rather than by IP. My application
at home has a 100.00 transfer received, however it’s transaction details
say «Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv». That
is not my BitCoin address from work, so I assume this means that I
received the payment encoded with a block that was computed by your
client? If so, how did it know your name in addition to the BitCoin
address that generated it? I don’t recall there being a place in my
application to even put my name.

—
Dustin D. Trammell

01.18 11_01 – Satoshi – Re_ Bitcoin Transfer

It should be your Bitcoin address at home that you received it
with. There’s no way for it to know who it’s from, so the best
it can do is tell which of your addresses it was received on.
You can create multiple addresses and give a different address
to each person and label them to help figure out who’s sending
to you.

It doesn’t know any names other than what you tell it. The name
printed there is what’s associated in your address book for that
address, either under the Address Book button or the «Change…»
button to the right of your Bitcoin address.

> Hey Satoshi,
>
> After that first transfer of 25.00, you didn’t send me another 100.00
> did you? I sent myself 100.00 from my BitCoin application at work to my
> one at home using the BitCoin address rather than by IP. My application
> at home has a 100.00 transfer received, however it’s transaction details
> say «Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv«. That
> is not my BitCoin address from work, so I assume this means that I
> received the payment encoded with a block that was computed by your
> client? If so, how did it know your name in addition to the BitCoin
> address that generated it? I don’t recall there being a place in my
> application to even put my name.
>
> —
>Dustin D. Trammell
> dtrammell@dustintrammell.com
> http://www.dustintrammell.com

01.18 18_09 – Dustin – Re_ Bitcoin Transfer

On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:
> It should be your Bitcoin address at home that you received it
> with. There’s no way for it to know who it’s from, so the best
> it can do is tell which of your addresses it was received on.
> You can create multiple addresses and give a different address
> to each person and label them to help figure out who’s sending
> to you.

Ah! I didn’t even notice it was my address at home, you’re right (: I
do have multiple addresses created at home so I didn’t make the
connection.

> It doesn’t know any names other than what you tell it. The name
> printed there is what’s associated in your address book for that
> address, either under the Address Book button or the «Change…»
> button to the right of your Bitcoin address.

Ahh you’re right, ‘Satoshi’ is associated with the address that received
the payment under the Change button’s addresses. I don’t recall setting
that value though, is that the default or something? (this is the first,
default, address that the application generated itself when I first ran
it)

—
Dustin D. Trammell

01.19 11_02 – Satoshi – Re_ Bitcoin Transfer

>On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:
>> It should be your Bitcoin address at home that you received it
>> with. There’s no way for it to know who it’s from, so the best
>> it can do is tell which of your addresses it was received on.
>> You can create multiple addresses and give a different address
>> to each person and label them to help figure out who’s sending
>> to you.
>
> Ah! I didn’t even notice it was my address at home, you’re right (: I
> do have multiple addresses created at home so I didn’t make the
> connection.
>
>> It doesn’t know any names other than what you tell it. The name
>> printed there is what’s associated in your address book for that
>> address, either under the Address Book button or the «Change…»
>> button to the right of your Bitcoin address.
>
> Ahh you’re right, ‘Satoshi’ is associated with the address that received
> the payment under the Change button’s addresses. I don’t recall setting
> that value though, is that the default or something? (this is the first,
> default, address that the application generated itself when I first ran
> it)

The first default one is labelled «Your Address» when it’s created.

All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.

Address book labels for receiving addresses is confusing but I’m not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who’s paying them. That concept doesn’t have much analogy in the real world.

Satoshi

01.19 19_58 – Dustin – Re_ Bitcoin Transfer

On Tue, 2009-01-20 at 00:44 +0800, Satoshi Nakamoto wrote:
> The first default one is labelled «Your Address» when it’s created.
>
> All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.

That would make sense, I bet that’s what happened.

> Address book labels for receiving addresses is confusing but I’m not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who’s paying them. That concept doesn’t have much analogy in the real world.

I think had it said «Received with address: X» rather than just
«Received with: X» I think I would have understood, although I’m sure
that address being mislabeled ‘Satoshi’ was the primary reason for my
initial confusion. You’re right though, there’s really nothing
comparable in the current financial system that people are used to other
than maybe being able to use multiple recipient email addresses for
PayPal. Perhaps it could say «Received payment to: X»?

—
Dustin D. Trammell

01.25 10_03 – Satoshi – Re_ Bitcoin v0.1 released

Hal Finney wrote:
> > * Spammer botnets could burn through pay-per-send email filters
> > trivially
> If POW tokens do become useful, and especially if they become money,
> machines will no longer sit idle. Users will expect their computers to
> be earning them money (assuming the reward is greater than the cost to
> operate). A computer whose earnings are being stolen by a botnet will
> be more noticeable to its owner than is the case today, hence we might
> expect that in that world, users will work harder to maintain their
> computers and clean them of botnet infestations.

Another factor that would mitigate spam if POW tokens have value:
there would be a profit motive for people to set up massive
quantities of fake e-mail accounts to harvest POW tokens from
spam. They’d essentially be reverse-spamming the spammers with
automated mailboxes that collect their POW and don’t read the
message. The ratio of fake mailboxes to real people could become
too high for spam to be cost effective.

The process has the potential to establish the POW token’s value
in the first place, since spammers that don’t have a botnet could
buy tokens from harvesters. While the buying back would
temporarily let more spam through, it would only hasten the
self-defeating cycle leading to too many harvesters exploiting the
spammers.

Interestingly, one of the e-gold systems already has a form of
spam called «dusting». Spammers send a tiny amount of gold dust
in order to put a spam message in the transaction’s comment field.
If the system let users configure the minimum payment they’re
willing to receive, or at least the minimum that can have a
message with it, users could set how much they’re willing to get
paid to receive spam.

Satoshi Nakamoto

Correos intercambiados entre Satoshi Nakamoto y Dustin D. Trammell en enero del 2009

Correos intercambiados entre Satoshi Nakamoto y Dustin D. Trammell en enero del 2009

Emails exchanged between Satoshi Nakamoto and Dustin D. Trammell in January 2009

Dejar un comentario

Deja un comentario Cancelar la respuesta

Find me

Páginas

Categorías

Listado