diff --git a/_posts/2015-02-28-test-markdown.md b/_posts/2015-02-28-test-markdown.md index f76feaa..f8587d3 100644 --- a/_posts/2015-02-28-test-markdown.md +++ b/_posts/2015-02-28-test-markdown.md @@ -1,76 +1,74 @@ --- layout: post title: Test markdown subtitle: Each post also has a subtitle gh-repo: daattali/beautiful-jekyll gh-badge: [star, fork, follow] tags: [test] published: false multiLangId: 2015-02-28-test-markdown lang: en --- You can write regular [markdown](http://markdowntutorial.com/) here and Jekyll will automatically convert it to a nice webpage. I strongly encourage you to [take 5 minutes to learn how to write in markdown](http://markdowntutorial.com/) - it'll teach you how to transform regular text into bold/italics/headings/tables/etc. **Here is some bold text** ## Here is a secondary heading Here's a useless table: | Number | Next number | Previous number | | :------ |:--- | :--- | | Five | Six | Four | | Ten | Eleven | Nine | | Seven | Eight | Six | | Two | Three | One | How about a yummy crepe? ![Crepe](http://s3-media3.fl.yelpcdn.com/bphoto/cQ1Yoa75m2yUFFbY2xwuqw/348s.jpg) Here's a code chunk: - -~~~ +``` var foo = function(x) { return(x + 5); } foo(3) -~~~ +``` And here is the same code with syntax highlighting: - ```javascript var foo = function(x) { return(x + 5); } foo(3) ``` And here is the same code yet again but with line numbers: {% highlight javascript linenos %} var foo = function(x) { return(x + 5); } foo(3) {% endhighlight %} ## Boxes You can add notification, warning and error boxes like this: ### Notification {: .box-note} **Note:** This is a notification box. ### Warning {: .box-warning} **Warning:** This is a warning box. ### Error {: .box-error} **Error:** This is an error box. diff --git a/_posts/2017-11-01-DAA-es.md b/_posts/2017-11-01-DAA-es.md index 10fc8e0..aa4a303 100644 --- a/_posts/2017-11-01-DAA-es.md +++ b/_posts/2017-11-01-DAA-es.md @@ -1,75 +1,74 @@ --- layout: post title: Actualización del algoritmo de ajuste de dificultad (DAA) subtitle: Bitcoin ABC ha publicado la versión 0.16.0 que contiene el algoritmo de ajuste de dificultad (DAA) actualizado. multiLangId: 2017-11-01-DAA lang: es --- ## Bitcoin ABC ha publicado la versión 0.16.0 que contiene el algoritmo de ajuste de dificultad (*Difficulty Adjustment Algorithm*) (DAA) actualizado. Este es un cambio de las reglas de consenso de Bitcoin Cash. El cambio se activa el 13 de Noviembre. Este es un *hardfork*, por lo que los sitios de cambio, carteras y otros software necesitan actualizar antes del 13 de Noviembre. Se cuenta con un *testnet* disponible. Hemos estado en comunicación con los mineros de Bitcoin Cash y ellos están esperando esta actualización. El *’EDA’* (*Emergency Difficulty Adjustment*) original de Bitcoin Cash permitió que Bitcoin Cash sobreviviera como una cadena minoritaria, pero produce fluctuaciones descontroladas de *hashrate*. Esto es problemático porque evita rápidas confirmaciones consistentes para los usuarios y cambia radicalmente el programa de emisión de monedas. Se presentaron varias propuestas para mejorar el DAA. Hemos revisado todas ellas y las agradecemos. Después de una cuidadosa consideración, tomamos la decisión de implementar la propuesta del desarrollador líder de Bitcoin ABC, Amaury Sechet (más detalles sobre esta propuesta a continuación). Nuestra decisión de elegir una propuesta específica no fue fácil, porque Bitcoin Cash cuenta con varios equipos de desarrollo independientes, y hubo una gran deliberación entre los desarrolladores de estos grupos. Tenemos el máximo respeto por todos los desarrolladores involucrados en las discusiones, pero dado que una decisión en tiempo era requerida solo se podía elegir un algoritmo. Por lo tanto, decidimos adoptar un enfoque científico y utilizamos dos equipos de prueba imparciales y desconectados: Bitprim y nChain. Estos equipos realizaron sus pruebas por separado y llegaron a la misma conclusión de cuál algoritmo era el más apropiado. En el futuro, los cambios a nivel de consenso deben tener mayor planificación, así como un proceso para facilitar la comunicación entre los equipos. Esperamos trabajar con otros equipos para definir y perfeccionar ese proceso en los próximos meses y años. Los tres algoritmos principales que se probaron son ‘D578’ de Neil Booth, ‘D601’ de Amaury Sechet y ‘D622’ de Tom Harding. En nuestras propias pruebas los 3 produjeron resultados similares y tiempos medios de bloque (*mean block time*) de aproximadamente 600 segundos, una mejora colosal con respecto al código actual. Las sinopsis de Bitprim y nChain siguen a continuación: BitPrim: *’Las propuestas de Tom y Amaury son muy similares en rendimiento. La propuesta de Amaury tiene mejores posibilidades de obtener consenso de red’* nChain: *‘D601 es la elección lógica. D622 es 3.1% (+/- 1.2% a 95% CI) mejor en la mayoría de los casos, pero presenta algunos casos límite (*edge cases*) en su contra. Por ejemplo, un gran minero puede establecer fluctuaciones en el tiempo’* Reconocemos que D601 (propuesta de Amaury Sechet) puede no tener necesariamente el rendimiento más alto, pero dado que los 3 tuvieron un rendimiento similar, se seleccionó D601 porque parece presentar el menor riesgo. ## Algoritmo El nuevo algoritmo DAA busca lograr los siguientes objetivos: * Ajustar la dificultad del *hashrate* apuntando a un intervalo de bloque promedio de 600 segundos. * Evitar cambios repentinos en la dificultad cuando el *hashrate* sea relativamente estable. * Ajustar la dificultad rápidamente cuando el *hashrate* cambie rápidamente. * Evitar las oscilaciones de respuesta entre el *hashrate* y la dificultad. * Ser resistente a los ataques como la manipulación de marca-de-tiempo (*timestamp*). Este algoritmo está basado en un promedio móvil simple de 144 períodos. La dificultad se ajusta a cada bloque, según la cantidad de trabajo realizado y el tiempo transcurrido entre los 144 bloques anteriores. Para calcular la dificultad, comenzamos con los tres bloques recientes y elegimos el que tiene la marca-de-tiempo (*timestamp*) mediana a los tres. A continuación, el proceso se repite con los bloques 144, 145 y 146 (bloques con una altura de 144-146 menor al bloque actual) y se selecciona nuevamente una marca-de-tiempo (*timestamp*) de bloque mediana a esos 3. A partir de estos 2 bloques elegidos separados aproximadamente 144 bloques, se define W como la cantidad de trabajo realizado entre los bloques, y T como el tiempo transcurrido entre los bloques. Se aplica un filtro de paso alto-bajo para que T tenga un valor máximo de 2 días y un valor mínimo de 0.5 días. Esto evita que la dificultad cambie abruptamente. (Normalmente 144 bloques toman aproximadamente 1 día). Entonces podemos calcular: +``` +Wn = W * Tiempo de Bloque Esperado / T. -~~~ - Wn = W * Tiempo de Bloque Esperado / T. - - G = (2^256 / Wn) - 1 -~~~ +G = (2^256 / Wn) - 1 +``` Este es nuestro objetivo de dificultad. Por último, se aplica un filtro final para imponer un objetivo máximo. La activación de las nuevas reglas de consenso se realizarán sobre la base de la marca-de-tiempo (*timestamp*) mediana en bloques que se produzcan después de la marca-de-tiempo (*timestamp*) 1510600000, que corresponde al 13 de Noviembre a las 7:06 PM GMT. Este código de activación ha sido consolidado. La hora exacta de la actualización dependerá de la marca-de-tiempo (*timestamp*) de los bloques minados después de la marca-de-tiempo (*timestamp*) límite. ## Actualizando la red Bitcoin ABC tomará medidas para ponerse en contacto con los principales proveedores de cambio y carteras. Toda ayuda en este esfuerzo es bienvenida. Podés ayudar poniéndote en contacto con los sitios de cambio, los proveedores de carteras y otros participantes del ecosistema, y haciéndoles saber que deben actualizar su software o ejecutar una versión actualizada de Bitcoin ABC u otro software compatible. Como nota final, Bitcoin ABC está comprometido con los valores del desarrollo descentralizado. Nos esforzamos por ser una implementación líder e impulsar la innovación y el progreso, pero no deseamos ser EL LÍDER, ya que creemos que nunca debería existir una autoridad única. Aunque esta vez es la propuesta de Bitcoin ABC la que se presenta a los mineros, confiamos en que con el tiempo, otros equipos de desarrollo también verán sus ideas implementadas a medida que avancemos juntos como una comunidad unida. diff --git a/_posts/2017-11-01-DAA.md b/_posts/2017-11-01-DAA.md index 9dfe995..aa5c79e 100644 --- a/_posts/2017-11-01-DAA.md +++ b/_posts/2017-11-01-DAA.md @@ -1,75 +1,74 @@ --- layout: post title: Difficulty Adjustment Algorithm Update subtitle: Bitcoin ABC has published version 0.16.0 which contains an updated Difficulty Adjustment Algorithm (DAA). multiLangId: 2017-11-01-DAA lang: en --- ## Bitcoin ABC has published version 0.16.0 which contains an updated Difficulty Adjustment Algorithm (DAA). This is a change to the Bitcoin Cash consensus rules. The change activates on November 13th. This is a hard fork, so exchanges, wallets, and other software need to upgrade before November 13th. There is a testnet available. We have been in communication with Bitcoin Cash miners and they are expecting this upgrade. The original Bitcoin Cash “EDA” allowed Bitcoin Cash to survive as a minority chain but produces wild fluctuations of hashrate. This is problematic because it prevents consistently fast confirmations for users, and radically shifts the coin issuance schedule. Several proposals to improve the DAA were put forth We appreciate these proposals and have reviewed them all. After careful consideration, we have made the decision to implement a proposal from Bitcoin ABC lead developer Amaury Sechet (more details on this proposal below). Our decision to choose one specific proposal was not easy, because Bitcoin Cash has several independent development teams, and there was a great deal of deliberation between developers from the different groups. We have the utmost respect for the all developers involved in the discussions, but only one algorithm could be chosen, and a timely decision was required. Therefore, we decided to take a scientific approach and utilized two impartial and unconnected testing teams: Bitprim and nChain. These teams conducted their tests separately and came to the same conclusion of which algorithm was most appropriate. In the future, consensus level changes should have more planning, as well as a process to facilitate cross-team communication. We look forward to working with other teams to define and hone that process in the months and years to come. The top three algorithms that were tested include "D578" from Neil Booth, "D601" from Amaury Sechet, and "D622" from Tom Harding. All 3 produced similar results in our own testing, and all 3 produced mean block times of approximately 600 seconds, a colossal improvement over the current code. Synopses from Bitprim and nChain are as follows: BitPrim: *“Tom and Amaury’s proposals are very similar in performance. Amaury’s proposal has better chances to get network consensus”* nChain: *“D601 is the logical choice. D622 is 3.1% (+/- 1.2% at 95% CI) better in most instances, but there are edge cases against it. For example a large miner can set fluctuations into the timing”* We acknowledge that D601 (proposal from Amaury Sechet) may not necessarily have the highest performance, but since all 3 had similar performance, D601 was selected because it appears to have the least risk. ## Algorithm The new DAA algorithm seeks to accomplish the following objectives: * Adjust difficulty to hash rate to target a mean block interval of 600 seconds. * Avoid sudden changes in difficulty when hash rate is fairly stable. * Adjust difficulty rapidly when hash rate changes rapidly. * Avoid oscillations from feedback between hash rate and difficulty. * Be resilient to attacks such as timestamp manipulation. This algorithm is based on a 144-period simple moving average. The difficulty is adjusted each block, based on the amount of work done and the elapsed time of the previous 144 blocks. To compute the difficulty, we begin with the three topmost blocks, and choose the one with the median timestamp of the three. Next, the process is repeated with blocks 144, 145, and 146 (blocks of 144-146 height less than the current) and a median timestamp block is again chosen from those 3. From these 2 blocks roughly 144 blocks apart, we define W as the amount of work done between the blocks, and T as the elapsed time between the blocks. A high-low filter is applied so that T has maximum value of 2 days and a minimum value of .5 days. This prevents difficulty from changing too abruptly. (Normally 144 blocks takes approximately 1 day). We can then compute: +``` +Wn = W * ExpectedBlockTime / T . -~~~ - Wn = W * ExpectedBlockTime / T . - - G = (2^256 / Wn) - 1 -~~~ +G = (2^256 / Wn) - 1 +``` This is our difficulty target. Lastly, a final filter is applied to enforce a maximal target. Activation of the new consensus rules will be done on a median time stamp basis on blocks that occur after timestamp 1510600000, which corresponds to November 13th, 7:06 PM GMT. This activation code has been merged. The exact time of upgrade will depend on the timestamp of the blocks mined after this timestamp. ## Upgrading the Network Bitcoin ABC will take steps to contact major exchanges and wallet providers. All assistance in this effort is welcome. You can help by contacting exchanges, wallet providers, and other ecosystem participants, and letting them know they should upgrade their software or run an updated version of Bitcoin ABC or other compatible software. On a final note, Bitcoin ABC is committed to the values of decentralized development. We strive to be a leading implementation and drive innovation and progress, but we do not wish to be THE leader, as we believe there should never be one singular authority. Although this time it is Bitcoin ABC’s proposal that is being put forth to the miners, we are confident that in time, other development teams will also see their ideas implemented as we move forward together as a united community. diff --git a/_posts/2018-01-14-CashAddr-es.md b/_posts/2018-01-14-CashAddr-es.md index f91b196..616e60f 100644 --- a/_posts/2018-01-14-CashAddr-es.md +++ b/_posts/2018-01-14-CashAddr-es.md @@ -1,82 +1,82 @@ --- layout: post title: Las direcciones CashAddr están aquí subtitle: La versión 0.16.2 soporta el nuevo formato de dirección Bitcoin Cash CashAddr. multiLangId: 2018-01-14-CashAddr lang: es --- **Qué es *CashAddr*?** *CashAddr* es un nuevo formato de dirección para Bitcoin Cash. Si alguna vez viste una dirección de Bitcoin o una dirección de Bitcoin Cash, estás al menos relativamente familiarizado con la apariencia de las direcciones --básicamente un montón de letras y números. Esto es lo que está obteniendo un nuevo formato. Técnicamente, es una nueva ‘codificación’ y visualmente aparecerá de manera diferente. **Cómo son las nuevas direcciones?** Sigue un ejemplo: -~~~ - bitcoincash:qqeht8vnwag20yv8dvtcrd4ujx09fwxwsqqqw93w88 -~~~ +``` +bitcoincash:qqeht8vnwag20yv8dvtcrd4ujx09fwxwsqqqw93w88 +``` Tené en cuenta el prefijo "bitcoincash:", que técnicamente es siempre parte de la dirección, aunque el mismo puede ser opcional o faltar por completo, dependiendo de la cartera o de la implementación. **Cómo esto me afecta? Qué necesito hacer?** Te recomendamos utilizar las direcciones nuevas, aunque no sea obligatorio. Podrías experimentar ‘incompatibilidad de cartera’ y necesitar usar una herramienta de conversión de dirección (más sobre esto a continuación). Si observás que tu cartera o servicio elegido aún no ha sido actualizado para admitir *CashAddr*, sería útil informarles sobre el nuevo formato. **Puedo seguir usando las antiguas direcciones ‘heredadas’?** Técnicamente sí, pero te recomendamos actualizar. Si tenés una dirección heredada que se encuentra actualmente en uso, la misma continuará funcionando. Sin embargo, la mayoría de los usuarios deberían actualizar porque las nuevas direcciones son más seguras. Además, la experiencia de usuario mejorará cuando todos utilicen el mismo formato. **Puedo enviar desde una dirección antigua a una dirección nueva o viceversa?** Sí. El formato de dirección es solo una codificación. Para usar una analogía, pensá en la codificación como un envoltorio, o ‘vestimenta’. Considerá el hecho de que siempre podés hablar con tus amigos, independientemente de la vestimenta que estés usando. En esta analogía, lo que está por debajo de la vestimenta es el hash de la clave pública (*pubkeyHash*). **Puedo comenzar a usar las nuevas direcciones inmediatamente?** Sí. Por favor, hacelo. **Intenté enviar a una de estas nuevas direcciones y mi cartera no me lo permitió. Por qué?** Si la cartera no ha sido actualizada, la misma todavía no conoce el nuevo formato. Pero no te preocupes, hay una fácil solución al problema. Es posible convertir formatos antiguos a formatos nuevos, o formatos nuevos a formatos antiguos. Existen varias herramientas de conversión disponibles. Recomendamos: [https://cashaddr.bitcoincash.org/](https://cashaddr.bitcoincash.org/). Otra herramienta de conversión está disponible en [Electron Cash 3.1.](Https://electroncash.org). Si vas a utilizar alguna herramienta de conversión, es muy importante utilizar solo las confiables, ya que existe la posibilidad de que una herramienta malintencionada te proporcione una dirección falsa. **Existe un ‘mapeo’ uno-a-uno de formatos antiguos a formatos nuevos?** Sí. Cualquier formato de dirección Bitcoin heredado se convertirá en uno y solo un formato de *CashAddr*, y lo mismo se aplica a la inversa. Por lo tanto, siempre habrá 2 versiones (heredada y *CashAddr*) de cualquier dirección dada, y son intercambiables porque corresponden al mismo conjunto de claves privadas y públicas. **Qué sucede si convierto una dirección antigua al nuevo formato y le envío algunas monedas a un amigo pero su cartera no admite el nuevo formato?** No hay problema. El dinero aparecerá en la dirección antigua de tu amigo (ya que es realmente la misma dirección, solo codificada de manera diferente). **Por qué la comunidad de desarrollo de Bitcoin Cash decidió crear un nuevo formato de dirección?** Como un libro mayor y criptomoneda diferente, Bitcoin Cash debería tener su propio formato de dirección, lo que reducirá posibles errores y confusión en los usuarios. **Cuáles son los beneficios de este formato de dirección en particular?** Además de ofrecer un formato de dirección distintivo, el nuevo formato no diferencia entre letras mayúsculas y minúsculas, lo que hace que las direcciones sean más fáciles de escribir y de comunicar entre humanos. Es también extensible, por lo que no será necesario cambiarlo en el futuro a medida que nuevas funcionalidades de Bitcoin Cash sean agregadas. **Pueden explicar lo que significa, técnicamente, contar con un nuevo formato?** Cuando realizás una transacción para ‘enviar’ Bitcoins a una dirección, lo que realmente estás haciendo es desbloquear salidas (*outputs*) no gastadas y volverlas a bloquear para que solo alguien con la capacidad de firmar la clave pública (con su clave privada) pueda controlarlos. El nuevo formato de dirección no cambia el formato de estas transacciones en el blockchain, sino más bien: simplemente la representación visual que es presentada al usuario. **Es esto un cambio de protocolo, un *softfork*, o un *hardfork*?** No, no es ninguno de estos. **Alguna de mis claves privadas o públicas cambia?** No. **Existe alguna especificación *CashAddr* oficial para desarrolladores?** Sí, [aquí.](Https://github.com/bitcoincashorg/spec/blob/master/cashaddr.md) diff --git a/_posts/2018-01-14-CashAddr.md b/_posts/2018-01-14-CashAddr.md index 42946c5..2c0b989 100644 --- a/_posts/2018-01-14-CashAddr.md +++ b/_posts/2018-01-14-CashAddr.md @@ -1,86 +1,86 @@ --- layout: post title: CashAddr Addresses Are Here subtitle: Version 0.16.2 Supports the new CashAddr Bitcoin Cash Address Format. multiLangId: 2018-01-14-CashAddr lang: en permalink: cashaddr/ --- ## Bitcoin ABC Releases Software Version 0.16.2 Featuring the new CashAddr Address Format **What is CashAddr?** CashAddr is a new Bitcoin Cash address format. If you've ever seen a Bitcoin address or a Bitcoin Cash address, then you're at least somewhat familiar with what addresses look like -- basically a whole bunch of letters and numbers. This is what is getting a new format. Technically, it’s a new 'encoding' and visually, it will appear differently. **What do the new addresses look like?** Here's an example: -~~~ - bitcoincash:qqeht8vnwag20yv8dvtcrd4ujx09fwxwsqqqw93w88 -~~~ +``` +bitcoincash:qqeht8vnwag20yv8dvtcrd4ujx09fwxwsqqqw93w88 +``` Note the prefix "bitcoincash:", which is technically always part of the address, although the prefix may be optional or missing entirely, depending on the wallet or the implementation. **How does all this affect me? What do I need to do?** We encourage you to use the new addresses, but this is not mandatory. You may experience "wallet incompatibility" and need to use an address converter tool (more on this in a moment). If you notice that your favorite wallet or service is not yet upgraded to support CashAddr, it is helpful to make them aware of the new format. **Can I still use the old 'legacy' addresses?** Technically yes, but we strongly encourage you to upgrade. If you have a legacy address that is currently being used, it will continue working. However, most users should upgrade because the new addresses are safer. Moreover, the user experience will be enhanced when everyone is using the same format. **Can I send from an old address to a new address or vice-versa?** Yes. The address format is just an encoding. To use an analogy, think of the encoding as just a wrapper, or "clothing". Consider the fact that you can always talk to your friends, regardless of what clothes either of you happen to be wearing. In this analogy, what's underneath the clothes is the raw public key hash (pubkeyHash). **Can I start using the new addresses immediately?** Yes. Please do. **I tried sending to one of these new addresses and my wallet won't let me. Why?** If a wallet hasn't been upgraded, it doesn't know about the new format yet. But don't worry, there's an easy workaround to this problem. You can convert from the old format to the new format, or from the new format to the old format. There's several converter tools available. We recommend: [https://cashaddr.bitcoincash.org/](https://cashaddr.bitcoincash.org/) Another converter tool is available in [Electron Cash 3.1.](https://electroncash.org) If you are going to use any converter tools, it is very important to only use trusted ones, as there exists the possibility for a malicious tool to give you a fake address. **Is there a one-to-one "mapping" from an old format to a new format?** Yes. Any legacy Bitcoin address format will convert to one and only one CashAddr format, and the same is true in reverse. So there will always be 2 versions (legacy and CashAddr) of any given address, and they are interchangeable because they correspond to the same set of private and public keys. **What happens if I convert an old address to the new format and have sent the coins to my friend, but his wallet doesn't support the new format?** That's ok. The money will still show up at his old address (since its really the same address, just encoded differently) **Why did the Bitcoin Cash development community decide to create a new address format?** As a distinct ledger and cryptocurrency, Bitcoin Cash should have its own address format, which will reduce errors and confusion for users. **What are the benefits of this particular address format?** Aside from offering a distinct address format, the new format is case-insensitive, which makes addresses easier to type and communicate between humans. It is also extensible, so that the format would not need to be changed in the future as new Bitcoin Cash functionality is added. **Can you explain what it means, technically, to have a new format?** When you conduct a transaction to "send" Bitcoins to an address, what you're really doing is unlocking unspent outputs and then locking them again so that only someone who can sign for the public key (with their private key) can control them. The new address format does not change the format of these transactions on the blockchain, but rather: only the visual representation which is presented to the user. **Is this a protocol change, soft-fork, or hard-fork?** No, it's none of those things. **Do any of my private or public keys change?** No. **Is there an official CashAddr specification for developers?** Yes, [here.](https://github.com/bitcoincashorg/spec/blob/master/cashaddr.md)