Correspondencia entre Mike Hearn y Satoshi
Mike Hearn
Correspondencia de Hearn y Satoshi, parte 5
https://nakamotostudies.org/uncategorized/hearn-and-satoshi-correspondence-part-5/
De: Mike Hearn <mike@plan99.net>
Fecha: lunes 18 de abril de 2011 a las 23:14
Para: Satoshi Nakamoto <satoshin@gmx.com>Hola Satoshi,
Espero que este correo te encuentre bien. Recientemente he estado pensando en cómo
BitCoin puede ayudar a manejar el abuso de Internet y agradecería su
pensamientos.
Mi «trabajo diario» es en el equipo de abuso de Google. Hacemos un uso extensivo de
verificación telefónica para controlar el spam saliente de nuestra red. Facebook
y Craigslist hacen lo mismo. La verificación telefónica funciona bien porque
Los números de teléfono son algo a lo que la mayoría de la gente tiene acceso al menos uno o
dos de, pero rara vez más. Sin embargo, tiene importantes desventajas: es
caro (para nosotros), inestable, a algunas personas no les gusta la privacidad
implicaciones, y parte del spam es lo suficientemente rentable como para comprar muchos
Las tarjetas SIM valen la pena.
Sería ideal si los BitCoins pudieran ofrecerse como garantía contra un
cuenta. La cantidad aportada ayudaría a determinar los límites que el sistema
colocado en su comportamiento (por ejemplo, cuánto correo puede enviar), en un
forma anónima y privada. ¿Pero cómo implementar esto?
Quemar monedas para siempre es fácil, simplemente configure la única salida como OP_FALSE. Ahora puedes firmar algún desafío proporcionado por el servidor con eso.
clave y demuestra que realmente quemaste esas monedas. Una clave sólo sería
utilizable con una cuenta para que los spammers no puedan simplemente poner una enorme
garantía y luego revender firmas generadas con esa clave. Si el
Se descubrió que se había abusado de la cuenta y se cancelaría como hoy, y el
las monedas desaparecerían.
Pero la gente va y viene de estas grandes redes y la idea de
perder las monedas si sales de Google para ejecutar tu propio correo es
poco atractivo. Sería ideal si las monedas pudieran guardarse bajo llave durante un tiempo.
período de tiempo tal que no se pueden gastar hasta el momento X, donde X
puede ser empujado constantemente hacia el futuro si el propietario así lo desea, pero
de lo contrario, las monedas eventualmente volverán a poder gastarse. Para verificar su
cuenta de Google, tomarías una cierta cantidad de monedas (digamos 10) y establecerías
póngalo arriba para que no pueda gastarlos durante 6 meses.
El lenguaje escrito no tiene concepto de tiempo. OP_BLOCKNUMBER fue descartado
porque las reorganizaciones podrían potencialmente invalidar cadenas enteras de
actas. ¿Pero es factible un OP_DAY? Estoy pensando en un código de operación.
que devuelve la marca de tiempo del encabezado del bloque, pero redondeada al
día más cercano para manejar la desviación natural del reloj observada en la cadena de bloques.
Si pudiera funcionar, entonces un TX que inmoviliza las monedas hasta pasado un día determinado.
es fácil de construir. Actualizarlo para que la fecha límite cambie constantemente.
es más difícil. Una solución simple de fuerza bruta es exigir al usuario que coloque
hasta el doble de las monedas, de modo que en el momento en que el primer tx esté a punto de expirar
y se puede gastar nuevamente, se crea el segundo tx. De esta manera tu
siempre tener al menos un tx de fecha límite suficientemente distante para actuar como
colateral. Pero esto es poco elegante. Una mejor manera sería presentar
una nueva regla que permite que un tx se conecte a dicha salida antes de que
La fecha límite ha pasado, siempre y cuando la salida de ese tx sea una vez más un
Salida en plazo del mismo formulario. Sin embargo, esto es menos general que
el lenguaje de programación también es algo poco elegante.
¿Qué opinas?
———-
De: Satoshi Nakamoto <satoshin@gmx.com>
Fecha: miércoles 20 de abril de 2011 a las 11:39 a.m.
Para: Mike Hearn <mike@plan99.net>
Si el lenguaje de secuencia de comandos no es apátrida, si tiene acceso a información externa que cambia o varía entre los nodos, los atacantes pueden usarlo para bifurcar la cadena. La única excepción es si siempre es falso antes de cierto tiempo y permanentemente verdadero después, lo cual se implementa con nLockTime.
Dado que se confía en Google, ¿no podrían los usuarios pagar un depósito simbólico a Google y Google les reembolsará cuando cierren la cuenta?
Sin embargo, para responder a su pregunta, sí, se puede hacer sin utilizar la confianza:
Tx 1 del Usuario paga a un script que requiere la firma tanto de Google como del Usuario para gastar.
Tx 2 (el contrato) gasta Tx 1 y se lo paga al Usuario. nLockTime es el momento de liberar el dinero.
Pasos:
1) Google le da al Usuario una clave pública para usar en la creación de Tx 1.
2) El usuario crea de forma privada Tx 1, no lo transmite todavía.
3) El usuario entrega el hash de Tx 1 a Google.
4) Google firma su parte de Tx 2, con nLockTime configurado, y se la entrega al Usuario.
5) El usuario transmite Tx 1.
6) El usuario firma su mitad de Tx 2 y la transmite.
Con estos pasos, el usuario ya tiene en la mano la mitad de Tx 2 firmada por Google antes de transmitir Tx 1, por lo que tiene la seguridad de en qué trato está firmando el dinero.
Este es el patrón general para firmar contratos de forma segura. Tx 2 se prepara primero para que las partes sepan en qué están pagando. Se transmite Tx 1 para bloquear el dinero y asignarlo a Tx 2. En otras palabras, todas las partes asignan su dinero a un fondo que está controlado por el acuerdo unánime del grupo, pero primero el grupo ya ha firmado un acuerdo por defecto. acción a tomar con el dinero, o múltiples opciones disponibles parcialmente firmadas que una parte puede completar agregando la última firma.
De común acuerdo, las partes siempre pueden escribir otra versión de Tx 2 que libere el dinero inmediatamente.
———-
De: Mike Hearn <mike@plan99.net>
Fecha: miércoles 20 de abril de 2011 a las 13:55
Para: Satoshi Nakamoto <satoshin@gmx.com>
Gracias, eso es útil. Ahora entiendo mejor los contratos.
Entonces, el problema de tener un código de operación OP_TIME/OP_BLOCKNUMBER no es solo que los resultados pueden cambiar después de una reorganización (lo dijiste anteriormente), sino también que la gente podría usarlo para producir transacciones que dejan de ser válidas por completo después de un cierto tiempo. y provocar una bifurcación. Algo obvio en retrospectiva.
Dado que se confía en Google, ¿no podrían los usuarios pagar un depósito simbólico a Google y Google les reembolsará cuando cierren la cuenta?
Google y la confianza es un tema complicado. Mucha gente utiliza nuestros servicios a pesar de tener poca confianza en nosotros. Algunas personas empiezan confiando en nosotros pero luego leen historias (a menudo sensacionalistas o erróneas) en los medios que les hacen cambiar de opinión, y así sucesivamente. Este es uno de los problemas que tenemos con la verificación telefónica… algunas personas no quieren darnos su número de teléfono.
En este caso, probablemente estaría bien porque la confianza en torno a la privacidad de los datos es diferente a la confianza en el cumplimiento de los contratos. Estoy seguro de que nadie dudaría de que Google les devolverá el dinero; apuesto a que tendríamos una calificación crediticia incluso mejor que la del gobierno de EE. UU. en ese sentido 🙂 Pero tenemos una tasa bastante alta de falsos positivos en nuestras verificaciones y algunas personas Sospecho que estábamos verificando usuarios accidentalmente para acumular grandes cantidades de monedas con las que ganar intereses. He visto teorías de conspiración mucho más tontas ganar fuerza.
Además, evitar la necesidad de confiar en instituciones grandes y complejas es mucho más parecido a BitCoin. Y sospeché correctamente que había una manera de hacerlo que aún no entendía, por lo que es una buena oportunidad para aprender más sobre BitCoin.
Sin embargo, para responder a su pregunta, sí, se puede hacer sin utilizar la confianza.
Si escribiera una página wiki sobre cómo crear contratos con BitCoin, ¿te importaría revisarla?
Creo que podría ser una buena idea volver a habilitar el reemplazo de transacciones pronto porque a medida que la red crezca, será cada vez más difícil actualizarla. En cierto sentido, esto es bueno porque dificulta cambiar las reglas fundamentales del sistema. Por otro lado, corremos el riesgo de tener un protocolo que tenga muchas funciones no utilizadas porque no cuentan con el soporte suficiente. HTTP sufrió este destino con muchos de sus verbos, así como con características como la canalización.
¿Tenías alguna lista de tareas para reactivación, algún tipo de auditoría o terminar algún código?
Tenía algunas otras cosas en mente (como siempre). Una es: ¿planea volver a unirse a la comunidad en algún momento (por ejemplo, para revisiones de código) o planea alejarse permanentemente del centro de atención? Una de las razones por las que los estoy acosando con preguntas es que me preocupa que gran parte del potencial de BitCoins resida en el uso cuidadoso de funciones actualmente inactivas, pero hay poca orientación sobre cómo hacerlo. Y, francamente, no creo que sea lo suficientemente inteligente como para resolverlo todo por mi cuenta. Quizás Theymos lo sea, parece entenderlo bien. Pero si algún día se abandona por completo, algunas partes del protocolo podrían caer en desuso, lo cual sería una lástima.
Otro es la economía de la minería después de la transición a un sistema totalmente basado en tarifas. En este momento, la dificultad es aproximadamente una función del tipo de cambio USD/BTC y la inflación por bloque. Cuando la recompensa minera la establece el mercado, es posible que se produzca una “tragedia de los comunes” en la que todos se beneficien de una gran dificultad, pero nadie específicamente quiera pagar tarifas para obtenerla. Además, valorar la dificultad es bastante difícil ya que nunca se sabe cuáles son las capacidades de los atacantes hasta que es demasiado tarde. ¿Sería posible que las tarifas tiendan a cero con el tiempo, ya que algún minero siempre está dispuesto a aceptar transacciones más baratas y, a medida que los mineros abandonan, la dificultad se ajusta para que los retrasos nunca sean tan graves como para tolerarlos?
Como siempre gracias por tus ideas.
———-
De: Satoshi Nakamoto <satoshin@gmx.com>
Fecha: sábado 23 de abril de 2011 a las 15:40
Para: Mike Hearn <mike@plan99.net>
Tenía algunas otras cosas en mente (como siempre). Una es: ¿planea volver a unirse a la comunidad en algún momento (por ejemplo, para revisiones de código) o planea alejarse permanentemente del centro de atención?
He pasado a otras cosas. Está en buenas manos con Gavin y todos.
Espero que su BitcoinJ continúe desarrollándose hasta convertirse en un cliente alternativo. Les da a los desarrolladores de Java algo en lo que trabajar y es más fácil con una base más simple que no tiene que hacerlo todo. Obtendrá una masa crítica cuando nuevos usuarios impacientes puedan comenzar a usarlo mientras el otro todavía está descargando la cadena de bloques.
Archivado en: Sin categoría
————————————————————–
Mike Hearn
Hearn and Satoshi Correspondence Part 5
https://nakamotostudies.org/uncategorized/hearn-and-satoshi-correspondence-part-5/
Date: Mon, Apr 18, 2011 at 11:14 PM
BitCoin can help handle internet abuse and would appreciate your
thoughts.
My “day job” is on the Google abuse team. We make extensive use of
phone verification to control outbound spam from our network. Facebook
and Craigslist do the same. Phone verification works well because
phone numbers are something most people have access to at least one or
two of, but rarely more. Yet it has significant downsides – it’s
expensive (for us), flaky, some people don’t like the privacy
implications, and some spam is profitable enough that buying lots of
SIM cards is worth it.
It would be ideal if BitCoins could be put up as collateral against an
account. The amount put up would help determine the limits the system
placed on your behavior (eg how much mail you can send), in an
anonymous and private way. But how to implement this?
Burning coins forever is easy, just set the only output to be OP_FALSE. Now you can sign some server-provided challenge with that
key and prove you did indeed burn those coins. A key would only be
usable with one account so spammers cannot simply put up a huge
collateral and then resell signatures generated with that key. If the
account was found to be abused it’d be terminated like today, and the
coins would be “gone”.
But people do come and go from these big networks and the thought of
losing the coins if you quit Google to run your own mail is
unappealing. It would be ideal if coins could be locked up for a
period of time such that they cannot be spent until time X, where X
can be constantly pushed into the future if the owner desires it but
otherwise the coins eventually become spendable again. To verify your
Google account, you would take some amount of coins (say 10) and set
it up so you cannot spend them for 6 months.
The script language has no concept of time. OP_BLOCKNUMBER was ruled
out because re-orgs could potentially invalidate entire chains of
transactions. But is an OP_DAY feasible? I’m thinking of an opcode
that returns the timestamp from the block header, but rounded to the
nearest day to handle the natural clock drift seen in the block chain.
If it could work then a TX that ties up coins until past a certain day
is easy to construct. Updating it so the deadline is constantly moving
is harder. A simple brute force solution is to require the user to put
up 2x the coins such that at the point the first tx is about to expire
and become spendable again, the second tx is created. In this way you
always have at least one tx of sufficiently distant deadline to act as
collateral. But this is inelegant. A better way would be to introduce
a new rule allowing a tx to connect to such an output before the
deadline has passed, as long as the output of that tx is once again a
deadlined output of the same form. However this is less general than
the scripting language so is also somewhat inelegant.
What do you think?
———-
From: Satoshi Nakamoto <satoshin@gmx.com>
Date: Wed, Apr 20, 2011 at 11:39 AM
To: Mike Hearn <mike@plan99.net>
If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.
Since Google is trusted, couldn’t users pay a token deposit to Google and Google pays them back when they close the account?
To answer your question though, yes it can be done without using trust:
Tx 1 from User pays to a script that requires the signature of both Google and User to spend.
Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money.
Steps:
1) Google gives User a pubkey to use in creating Tx 1.
2) User privately creates Tx 1, does not broadcast it yet.
3) User gives the hash of Tx 1 to Google.
4) Google signs its part of Tx 2, with nLockTime set, and gives it to User.
5) User broadcasts Tx 1.
6) User signs his half of Tx 2 and broadcasts it.
With these steps, the user already has Google’s signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to.
This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they’re paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature.
By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately.
———-
From: Mike Hearn <mike@plan99.net>
Date: Wed, Apr 20, 2011 at 1:55 PM
To: Satoshi Nakamoto <satoshin@gmx.com>
Thanks, that’s helpful. I’m understanding contracts better now.
So the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight.
Since Google is trusted, couldn’t users pay a token deposit to Google and Google pays them back when they close the account?
Google and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification … a few people don’t want to give us their phone number.
For this case it’d probably be OK because trust around data privacy is different to trust around obeying contracts. I’m sure nobody would doubt that Google will pay them back – I bet we’d have an even better credit rating than the US Government in that sense 🙂 But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I’ve seen much sillier conspiracy theories gain traction.
Besides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn’t understand yet so it’s a good chance to learn more about BitCoin.
To answer your question though, yes it can be done without using trust
If I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?
I’m thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren’t widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining.
Did you have any list of tasks for re-activation, some kind of audit or finishing off some code?
I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I’m peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there’s little guidance on how to do it. And frankly, I don’t think I’m smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame.
Another is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a “Tragedy of the commons” to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it’s too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?
As always thanks for your insights.
———-
From: Satoshi Nakamoto <satoshin@gmx.com>
Date: Sat, Apr 23, 2011 at 3:40 PM
To: Mike Hearn <mike@plan99.net>
I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?
I’ve moved on to other things. It’s in good hands with Gavin and everyone.
I do hope your BitcoinJ continues to be developed into an alternative client. It gives Java devs something to work on, and it’s easier with a simpler foundation that doesn’t have to do everything. It’ll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain.
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!