Notas de la reunión
Fecha: September 5, 2017
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
https://twitter.com/kanzure/status/907233490919464960
((Como siempre, cualquier error es probablemente mío, etc.))
Introducción
Existe una gran preocupación sobre si BlueMatt se ha convertido en un nombre erróneo.
Presentación del lunes por la noche: https://btctranscripts.com/sf-bitcoin-meetup/2017-09-04-jonas-schnelli-bip150-bip151/
Creo que deberíamos seguir usando #bitcoin-core-dev para cualquier cosa relacionada con el cambio de Bitcoin Core y tratar de mantener las cosas abiertas aunque estemos juntos aquí hoy y mañana y el siguiente.
Carteras y poda de bloques y rescates
Nadie produce un cambio P2SH cuando tiene una salida nativa. Y la producción de un conjunto mixto de salidas le dirá cuál es. Así que esto no es ideal desde el punto de vista de la privacidad.
Si escaneas una transacción… así que, todavía está esta cuestión de si tienes… …P2SH incrustado o no. Y necesitaremos otros, para otras versiones de script también. ….
En algún momento, no se puede esperar que todos los nodos tengan el blockchain completo. Así que deberíamos tener prácticas de gestión de carteras que no requieran tanto gratuitamente, y tales rescates. Podrías tener un filtro Bloom, escanearlo, y luego determinar si vas a recuperar el bloque o no, como si sabes que tienes cosas correlacionadas que quieres recuperar de ese bloque. Puedes añadir ruido, seguro, eso ayudará.
Sospecho que la forma en que funcionará ese reescaneo dentro de un año es implementar la propuesta de Laolu. Así que diríamos que el … filtro Bloom para cada bloque, y luego un rescan escaneará los filtros, y luego irá a por él. No debemos limitarnos a… allí, sólo porque podríamos… Esto es básicamente como cuando generamos claves para P2SH incrustadas.
¿Tengo la llave pública? Bueno, si no, entonces nunca la consideres mía. Ahora mismo no aceptarás un P2SH que esté pagando… el hash de la llave. Lo harás. Si tienes la P2SH, sí. Ah creo que tengo una solución. Si tienes un redeemScript entonces tratará de recurrir a él. Hay más posibilidades… el pubkeyhash frente al scripthash, … quizás dos cadenas.
Sólo debe aceptar las cosas que emitió. Es importante tener esta discusión. Bryan había planteado previamente una preocupación de que parecía que aceptaríamos a la gente de IsMine() convirtiendo su… para aceptar cualquier cosa testigo, el redeemScript equivalente debe estar en tu almacén de claves, lo que significa que debes haberlo añadido explícitamente.
Hay todo tipo de otros scripts que puedes tener que utilizan las mismas claves. Sólo quieres aceptar pagos a esos si has añadido ese script. Esa plantilla se aplica a esa llave. El problema con esa regla es que la situación no es robusta… respaldo. Esto se remonta a una preocupación anterior … cada vez que se utiliza la cartera, usted tiene que hacer una copia de seguridad ahora. Me gustaría pensar, a medida que avanzamos, que la lógica para determinar si esto es un pago para mí se convierte en una lógica completamente separada de la lógica de cómo firmo por esto. Ahora mismo están entrelazados de múltiples maneras. Si tenemos una clave privada para algo, entonces aceptamos la … para la forma en que esto fue … pero no para un 1-de-2 multisig. Aceptamos cosas P2SH– el respaldo— P2SH es … soportado en Bitcoin Core, es como un calce para pruebas.
Si ves un pago a una dirección multisig– tienes que recordar… rehacer el añadir multisig y volver a escanear lo relevante. Como vas a …. tu plan de rescaneo debe ser almacenado en la cartera. Entonces, ¿lo recibes cuando haces la copia de seguridad, en la blockchain o cuando vuelves a escanear? No debemos continuar con la lógica de intentar habilitar automáticamente las cosas de IsMine.
IsMine es básicamente una copia a medias de la lógica de firma que intenta determinar si puedo firmar por esto, y si puedo firmar por ello, IsMine es verdadero. Esto es hostil a las copias de seguridad si se añaden más formas de firmar. En el lado de la firma, esto está bien, su código debe ser capaz de firmar por todo lo que pueda, pero eso no significa que deba ser tratado como pagos. Qué pasa si añadimos al almacén de claves, un conjunto de scripts, o scripthashes o incluso, no es un mapa de scripts que conozcas, pero estas son las cosas que considero mías, y si está ahí, es mío. Si no está ahí, seguiremos haciendo la búsqueda de legado para pagar a pubkey, pero no intentamos nada con el P2SH o lo que sea. Y esto significa que si usted tiene una cadena de testigo habilitado, a continuación, la re-exploración automática y añadir cosas a ese mapa. El legado se resuelve de la misma manera haciendo que la cadena de legado añada las dos cosas al mapa. Esto es cierto. En cuanto a la reserva de los redeemScripts, el fondo de recompensas coinjoin cuando se anunció - para ir a recuperar estas monedas, sólo tienes que ir al anuncio y el multisig actual se enumeran.
Cuando tenemos estas cosas como las llamadas RPC de createmultisig, debería venir con una advertencia de que necesitas hacer una copia de seguridad. createmultisig[address] debería ser crear una cartera multisig, debería crear una cadena para eso, y tú haces una copia de seguridad de eso. Así que si estamos hablando de la generalización de la cosa de la cadena, entonces para una cadena en particular tiene algunos metadatos que dice cómo las claves de esta cadena se traducen a las direcciones. Y entonces necesitas un nuevo inglés para describir esto a un usuario. Es más complejo porque si estás hablando de multisig puede ser 2-de-2 junto con otra cadena. Creo que todo esto está fuera del alcance de la v0.15.1… Creo que no tenemos que soportar todas esas cosas, pero debemos configurar el diseño para que evolucione en lo que creemos que es una buena dirección.
Me gusta la idea de añadir al keystore un conjunto de direcciones o scripthashes… deberían ser scriptpubkeys. Sí. Datos de tamaño variable. siphash de los… bueno, ¿de los bits? Bueno, está bien. La cuestión es que ya no debería haber una comprobación secundaria. Eso es lo que decide… podría ser un hash de 256 bits del… o un 128 bits es probablemente suficiente. Es efectivamente una tabla hash de sus scriptpubkeys. No es una tabla hash, es sólo un conjunto. No mapea a nada. Independientemente tienes la lógica de… ¿no tenemos ya eso como lo de watchonly?
Necesitamos un mapa. …. que se necesita para firmar cosas que tienen redeemScripts. Eso se utiliza en la lógica de la firma y que también se utiliza actualmente para recurrir en la lógica de IsMine, y estoy argumentando que no se debe hacer. Sin embargo, creo que esto ya existe, en las cosas de watchonlys. Esto parece conceptualmente tener más sentido. Entiendo por qué la cartera funciona así y cuál es su objetivo. Si no miro la cartera durante un año, empiezo a pensar que lo hace… no hay un conjunto de IsMine, actualmente.
Tenemos un conjunto de CScripts en el conjunto watchonly. Eso es conceptualmente lo que necesitamos. Creo que deberían ser scripts completos y también hashes de los mismos. Ignoremos esa distinción por ahora. Creo que es fácil de arreglar. Imaginemos scripts completos por un segundo. Cuando creas un… digamos un coinjoin… digamos que quieres crear una nueva dirección de 1-off a la que quieres aceptar pagos, tu copia de seguridad.. no tienes que invalidar la copia de seguridad de las claves privadas, podrías tener una copia de seguridad adicional de los scripts y quizás hace referencia a la ruta o ubicación de la otra cosa. Pero de esta manera puedes desde el punto de vista del usuario puedes en lugar de invalidar la copia de seguridad … es menos menos. Así que hay dos copias de seguridad, hay una que es material clave, que podría ser de 32 bytes.
Deberíamos reescribir las cosas de IsMine. El material de la clave puede estar separado, lo que coincidiría con la separación para la firma frente a la coincidencia de todos modos.
Opciones anidadas vs nativas. ¿Tiene alguna relación esta discusión? Nativo versus anidado. Apoyar lo que antes era addwitnessaddress sería difícil en este modelo. Son importaciones. No. El script está en la cartera… pero eso es lo que quiero eliminar. Si todavía está ahí, entonces agrégalo al conjunto. IsMine sólo mirará el conjunto, cuando la cartera se inicie, irá a través de la cartera y construirá el conjunto, el conjunto no se guarda en la cartera pero se construye, camina a través del keypool, camina… No, tiene que estar en la cartera. ¿Por qué? No has resuelto nada de lo contrario- estás determinando IsMine en base a lo que puedes firmar. Obtienes los beneficios de rendimiento de añadirlo a un conjunto, pero no obtienes más. Deberíamos dejar la lógica existente en su lugar, que utiliza la capacidad de firma como un indicador de si es nuestro. Se ha perdido la oportunidad de limpiar el código de IsMine. Bueno, tal vez la limpieza de IsMine se puede hacer más tarde.
Usted puede tener una operación de conversión de una sola vez donde se inicia, usted no tiene un conjunto todavía, usted está pasando por todas las claves, guardarlas, hecho, entonces en adelante voy a añadir cosas al conjunto.
Por lo tanto, estamos hablando de las ideas de añadir al keystore un conjunto de salidas vigiladas, scripts o scripthashes y luego, eventualmente, dejar de usar la capacidad de firmar como un proxy para que lo consideres parte de tu cartera. La observación es que quieres ser capaz de firmar para cualquier combinación extraña que tu cartera sea técnicamente capaz de firmar, pero eso no significa que cualquier cosa que puedas firmar vaya a ser de pago. Hay, supongo, una especie de razones ideológicas por las que no deberías tratar de aceptar cosas que no has dado, pero también hay otras razones como que si das una dirección bech32 entonces no quieres aceptar a una versión P2SH porque es más caro para ti gastar desde un P2SH y así sucesivamente. Así que creo que esto tiene sentido como una evolución, pero no creo que seamos capaces de hacer todo eso en la v0.15.1. Tenemos 3 días, así que tal vez. ¿Hace un momento eran 5 días?
Entonces la pregunta es, cómo hacemos… asumiendo que es así como lo hacemos: simplemente usamos la mac existente de watchonly como lo único para determinar si una salida es suya. Creo que eso sería una simplificación impresionante del código. No podemos hacerlo por razones de incompatibilidad hacia atrás… pero esto es sólo una idea que estamos pensando; ves una salida, compruebas si está en el conjunto, si es tuya, si no, no es tuya. Si es tuyo, entonces podemos usar una operación DummySign para determinar si es firmable, la lógica de la firma desaparece; sólo va a buscar en el conjunto, y si es así ¿puedo firmar por él?
¿Podemos hacerlo ahora? Olvidémonos de addwitness por ahora… simplemente, hay cadenas separadas en la cartera, IsMine no las mira por alguna razón… y entonces esas se añaden a este nuevo mapa. Así que revisa IsMine y revisa este conjunto. No puede ser sólo un conjunto, por cierto. ¿Por qué no? Necesitas avanzar en el pool para recargar. Eso es una cartera… el set está en el keystore y es lo único que le importa a IsMine. Pero una vez que el monedero lo detecta, todavía tiene que resolverlo.
Tienes que asegurarte de que, o bien no nos importa o hay un caso en el que el tenedor es o…. por sí mismos no son IsMine legado en un sentido. Sí, eso está bien. Lo de la multisig es que, en el futuro, e incluso hoy en día 1-de-1, se añadiría una plantilla multisig a la cartera, generan cadenas, y luego generan las direcciones. Esto es una especie de peso pesado. Esta es una dirección de importación. Trata de firmarlo, trata de firmarlo, pero no deberíamos hacer eso. Si insertas una cosa, ejecuta el comando, insértalo en ese conjunto, no intentes firmar cosas.
¿Podría ser este conjunto sólo para cosas de SegWit? Sí, eso es lo que espero. Pero no estoy seguro. Creo que implicará que dejemos toda la lógica existente en su lugar, pero hay una comprobación frontal está en mi conjunto, y entonces dejamos de apoyar la cosa de la recursión para los testigos por lo que toda la lógica de los testigos se elimina de la existente IsMine y se sustituye por esta nueva cosa … Rompemos la compatibilidad… Puedes dejar ese asunto histórico. Pero entonces seguirás aceptando… no, no se ven nuevas cadenas en esa lógica. No, no hay un concepto de cadenas en el almacén de claves. Pero podrías añadir un concepto de cadenas. Pero no deberías. Podría ser una bandera en su lugar. Esta es una nueva clave, no deberías tratarla como algo que es parte de tu antiguo código de búsqueda. Vale, sí. Esto debería ser implementable. Genial, pero ¿es comprobable?
Podríamos deshacernos de la cosa de la recursión, y luego durante la carga añadimos la versión p2pkh y p2pk, pero perdemos… ¿Multisigencia 1-de-1? Habría que poder… todos los scripts de vigilancia actuales tendrían que ser añadidos también, pero eso se podría hacer más tarde. Creo que es trivial. Creo que es trivial. Consigues que la cartera te diga todo el conjunto de cosas que consideras IsMine. Va a ser grande. Tener una ruta de actualización que sople la lógica de IsMine… no, esto es sólo en la memoria. Quiere salvar el conjunto. Creo que la raíz de todos estos problemas es que usamos la señalización como un proxy para IsMine. Si estás haciendo algo en la memoria entonces no estás cambiando eso. Hacemos IsMine para watchonly… deberíamos guardar eso… …. viejos contraejemplos históricos que necesitas guardar en el disco. Lo nuevo, generado a partir de la nueva cadena es determinista. Estoy diciendo que es una optimización para decir que cuando estamos cargando la billetera, si vemos una clave privada que está marcada como uso de SegWit, entonces la agregamos al conjunto donde sabemos que está agregada. Es una forma diferente de almacenar en el disco. Usando cadenas en la cartera como medio para determinar cómo almacenar en el disco. Anteriormente decidimos usar cadenas separadas.
Creo que es lo que la gente quiere hacer, pero una vez implementado, tal vez resulte ser una mala idea. ¿Cuál es el impulso? En media hora serán menos 2 días. Lógica de banderas, así que tendrás que aceptar cualquier cosa que te envíen, 1-de-1 multisig, si tienes 1 cadena que nunca puedes distinguir… hay problemas raros de downgrade desde v0.15.1… así que tienes esta llave… y luego hay problemas de privacidad, aceptando transacciones a una dirección rara, … es una buena idea tratar de soportar el downgrade por una versión. cartera v0.15, y código v0.15.1, y no actualizar la cartera. Y luego si actualizas la billetera entonces lamentablemente tienes que usar el nuevo código. Haga una copia de seguridad de su cartera antes de actualizar de todos modos, que es lo que debería estar haciendo en primer lugar.
Lógicamente, queremos ser capaces de apoyar a las personas que utilizan bech32 desde el día 1. La otra cuestión es, desde la reunión del IRC, el método de actualización de la cartera para cambiar a SegWit. Hay que añadir banderas o algo similar, o utilizar el monedero de actualización que tenemos. Me inclino por la segunda, pero significa que tenemos que apoyar la actualización a HD como parte de ella. La próxima versión es la de HD y no tenemos buenas cosas de actualización. Hay un pull request de dooglus sobre eso. ¿Alguien ha revisado eso? El problema de añadir una nueva bandera es que tenemos que hacerlo para que… soporte con carteras no HD. No tengo muchas ganas de que hagamos eso… Son básicamente la misma cosa, la cartera HD es un montón de llaves importadas. La cuestión es que si tienes un monedero y quieres generar una nueva clave…. La verdadera pregunta es si queremos tomar el retraso en la v0.15.1 para actualizarhd? Pero si quieres hacer la actualización para SegWit… necesitamos una actualización explícita. ¿Un nuevo mecanismo de actualización? No lo sé. La pregunta es si necesitamos un nuevo mecanismo de actualización. Si coges un monedero antiguo y empiezas a usar SegWit, necesitas actualizarlo. ¿Requiere esto una actualización del HD? Sí. Es una cuestión de seguridad porque de repente tienes una cartera mixta. Cada vez que importas, tienes un monedero mixto. Tal vez la gente espera tener… una sola semilla. Probablemente ignoran el hecho de que… bueno, deberíamos abordar esto con una nueva advertencia cada vez que hagamos copias de seguridad y decir que su cartera tiene claves importadas en una advertencia.
La actualización en sí requiere una nueva copia de seguridad. Eso está bien, no rompe ningún tipo de compatibilidad. Hay usuarios que usarán dumpwallet y luego escribirán la semilla maestra y creo que eso es todo lo que necesitan… pero en esa salida de texto, debería haber advertencias, y en la GUI para la cartera de copia de seguridad, para decir que su cartera ha importado claves. Con un monedero hd puro donde solo se hace eso, estaría bien.
Este es un retraso potencialmente importante para la v0.15.1… ya tenemos este problema, ¿los avisos? Ya lo necesitamos. Sería muy bueno si tuviéramos el RPC para rotar la llave maestra del HD. No estamos haciendo eso ahora. Sólo tenemos 1 día… ¿5 horas? El problema ya existe, puedes hacer carteras mixtas ya, los chicos en línea le dicen a la gente que haga esto, … lo de la rotación, probablemente quieras continuar antes de que… al menos para el… y encriptar la cartera no te sirve. Siempre y cuando tengas un keypool lo suficientemente largo. Bueno, haz el keypool más grande ((risas)). El monedero por defecto de una instalación ahora es como un megabyte. En el monedero usamos una entrada de un kilobyte… usamos registros más pequeños en el monedero encriptado. Así que guardamos una dirección en la cartera y la guardamos en este formato de clave privada DER, incluyendo los parámetros de la curva, son 270 bytes. Son 270 bytes para una clave. Y empezamos con 2000 claves ahora. Así que esa es la cartera por defecto. Esto es cuando no estás usando encriptación. Así que gzipéalo cuando termines ((risas)). Usas una codificación más eficiente en el caso de la cartera encriptada. Aunque también estamos codificando el nonce.
Cuando codificas tu cartera ahora mismo, ¿qué pasa? Con HD haces… para … y luego tienes una clave de respaldo, se encripta, sigue ahí, no continuará explorando esa cadena. Continuará generando nuevos futuros… y encriptando un monedero pre-HD, sólo lo desencripta… Vuelca la… y cualquier clave en ella marca como usada… Si empiezas con un monedero encriptado, ¿la restauración del HD comprueba la clave antigua que tenías antes de la encriptación para buscarla? Eso no es necesario porque tu nueva copia de seguridad ya incluirá esas claves. Ya no sigue explorando eso. Tienes que volver a explorar, encriptar, volver a explorar, etc. Pero el monedero necesita entrar en un caso donde.. y estamos tan cerca.. estamos tan cerca de poder no generar el monedero hasta que ejecutes un comando que necesite un monedero. Había un caso de esquina que impedía esto. Pero si tuviéramos esto, entonces podríamos hacer que la billetera naciera encriptada. … hasta que pulses recibir, en la GUI, podría incluso pedirte que la encriptes, pedirte que hagas una copia de seguridad, etc. Me he encontrado con usuarios que generaron un monedero en 0.9 pero recién ahora lo están usando. achow trató de hacer esto y hubo algún caso de esquina. La implementación es fácil pero había un caso de esquina… algo más que lo hacía difícil.
Alguien pregunta qué pasa con importprivkey con respecto al soporte de SegWit. ¿Se va a añadir en 3 copias diferentes en el… enumerado en todas ellas? Podemos añadir un argumento a importprivkey donde se diga que es una privkey para este tipo de dirección. Entonces, ¿nuevos comandos rpc? importmulti. ¿Podemos actualizar a bech32? No es posible para la v0.15.1… bueno eso tendría que pasar por la revisión por pares, así que no.
Para asegurarnos de que todo el mundo está en la misma página, hablamos de cambiar a la propuesta de Pieter de un saco de llaves y solucionador, cambiaríamos por completo en la v0.15.1 a usar un conjunto de scripts y el almacenamiento en disco permitiría convertirlo eficientemente a un conjunto de scripts. Hablamos de usar el mecanismo de la cartera de actualización para actualizar a SegWit, lo que significa que deberíamos dar soporte en la v0.15.1 para la actualización a hd, lo que esperamos que sea un pequeño parche, y usar el mismo mecanismo para la actualización a SegWit, que usa una ruta de actualización separada? No es necesario borrar la cartera o reescribir la cartera. Es un subconjunto estricto de lo que … como en términos de generación de una nueva clave maestra y mantiene todas las viejas claves alrededor. Parece un montón de trabajo, especialmente el keypool, ¿qué pasa con la división del keypool. Se convertirá en una lista de conjuntos de todos modos … lista de conjuntos. ¿3 conjuntos? Interno, externo, no 4 conjuntos. IsMine sólo necesita saber… ¿sólo el keypool? Keypool es un concepto separado. Pero ahora van a ser 4 conjuntos. 6 de hecho, debido a bech32. ¿Estamos haciendo una ruta de derivación separada para bech32? Sí, debería serlo. Estoy convencido. Es necesario para, entre otras cosas, ….
Para las versiones de direcciones SegWit posteriores, cuántos… keypools van a ser. ¿Multiíndice? Habrá un conjunto para la comprobación de IsMine. Pero entonces tienes keypools separados para cada una de las cadenas que estés usando. Si haces un nuevo monedero, sólo tendrá el… Decir que las carteras antiguas… Ya no las uso, ni las saco de la memoria ni nada, caducan la cadena. Enviar los fondos a una nueva cartera, y archivar. Hacer una nueva cartera nunca debería ser un requisito.
Aquí hay una idea loca. Cuánto más simple sería añadir soporte para SegWit si tuviéramos una cartera que sólo hiciera SegWit y no soportara ninguna de las cosas heredadas. Lo cual estamos haciendo con el asunto de la multicarpeta. Pero puede que no sea más sencillo… tenemos que soportar llaves importadas. No soportamos el gasto de monedas de múltiples carteras… no puedes seleccionar monedas a través de carteras. De acuerdo, es justo. Y tal vez ese es el punto de los monederos múltiples, no seleccionar monedas a través de los monederos. Reduce el problema de contabilidad. Es un coinjoin.
Creo que deberíamos tomarnos el tiempo para ir por este camino aunque signifique que vamos a tardar en hacerlo, quizás tengamos que llamarlo v0.16 o algo así. Son parches sencillos pero son invasivos. Deshacerse de las cosas de IsMine va a ser meses, aquí. No. El parche más grande va a ser los cambios de la GUI. Podríamos hacerlo dos veces. Hacerlo prioritario es importante, pero ponerle una fecha límite… bueno, no vamos a ponerle una fecha límite. La gente necesita no perder fondos. Es perjudicial para el ecosistema que la gente no pueda usar SegWit. No queremos que prolifere una situación en la que la gente use SegWit. Estamos recibiendo pull requests como “añadir soporte de cuentas a addwitness”. “Añadir característica obsoleta a la característica obsoleta”, en otras palabras. Esto es lo de bech32, lo de IsMine, la actualización de hd, la lista de conjuntos, …. Esto corre el riesgo de abarcar el rehacer de la cartera que necesitamos. Hay muchas otras cosas en la cartera que necesitan ser rehechas.
Creo que son sólo las cosas que acabamos de enumerar. Bueno, eso podría llevar meses. ¿Podemos dividir el trabajo en secciones? ¿Cuál es la forma más rápida de hacer esto, no separar los cambios. Deberíamos saber qué es esto. ¿Cuál es nuestra siguiente opción? Si queremos esto para mañana, mi enfoque sería no distinguir bech32 de P2SH embedded witness, siempre apoyas p2pkh para cualquier cosa para la que hayas dado una dirección SegWit, eliminamos el requisito de tener el redeemScript en tu cartera para los testigos y en su lugar lo sustituimos por una comprobación de si tengo la pubkey y si está descomprimida y te quedas con la otra también, y te relajas, y entonces tienes una bandera en tu cartera y dices que así es como se habilita SegWit aquí, y entonces tienes dirección de testigo para cualquier cosa que añadas a la cartera. Y esto funcionará. Esto es probablemente 100 líneas de parche. ¿Y cómo interfiere esto con futuros cambios? ¿Cuánta compatibilidad queremos en el futuro? Bueno, tal vez las futuras carteras sean incompatibles con las cosas viejas.
Si queremos tener soporte para el caso en que alguien en v0.14.2 para utilizar addwitnessaddress y luego se actualiza a lo que pensamos que va a hacer, creo que esto hace que no sea más difícil, sólo lo hace un poco más hinchado cuando lo hace. Si se dice que no vamos a avanzar en el soporte de addwitness, no sé cómo, algunas cosas se vuelven mucho más fáciles aquí sin embargo. En el resumen anterior, no hay nuevas cadenas allí. Si tienes la dirección del testigo P2SH dado, automáticamente también soportas el nativo, y si tienes el testigo nativo entonces también soportas automáticamente el p2pkh. Tienes la clave, esto es que tienes la clave y el redeemScript e incluso son equivalentes.
¿Cómo funciona addwitnessaddress? Busca la dirección en tu cartera, intenta resolverla, averigua si es un P2PKH, busca la pubkey, si es un P2SH entonces busca el redeemScript, entonces si es una pubkey entonces crea un P2SH-P2WPKH… luego intenta firmar con ella, con un pool de claves ficticias que es un cambio que hizo muy recientemente, hace eso para ambos, y luego lo convierte en una dirección P2SH y luego lo devuelve, y luego agrega un redeemScript para esa dirección P2SH como un CScript para la billetera, y luego IsMine y la lógica de firma pueden recurrir a ella. Así que esto implica que, si no nos deshacemos de la lógica recursiva de IsMine, esto implica que el testigo P2SH y el testigo no P2SH son equivalentes porque ambos requieren que redeemScript esté presente en la cartera, y entonces implica que estás viendo esas claves como claves normales.
Así que tengo dos preguntas… tenías un ?? en tu cartera… y entonces tienes que volver a escanear desde el punto desde el que se activa SegWit, lo cual es imposible para los nodos podados. Si hacemos lo que acabas de decir, ¿hace que hacer lo que alguien expuso hace un minuto sea más difícil para, digamos, la v0.16, y no, no lo creo. De todos modos, tenemos que dar soporte a todas las necesidades de esas cosas. Tenemos que apoyar la importación de esos. Pero no nos hemos encerrado en siempre.. pagar el P2SH o el regular.. addwitness ya lo estamos haciendo. Asegurémonos de no encerrarnos en eso. En este punto desearía que nunca tuviéramos addwitness. En este punto la gente está diciendo a otros que usen addwitness. Tenemos que apoyar esas carteras de todos modos. En 6 meses si tenemos una forma de… no te has encerrado en un paradigma de que si das un testigo desnudo tienes que apoyar el P2SH incrustado, no creo que nos encerremos en eso. Podemos bajar las probabilidades comunicando eso. Probablemente muchos otros monederos van a tener un enfoque de ahora en adelante sólo SegWit. Ledger tiene una ‘cadena separada’ que probablemente no acepte pagos a la no-…. Bueno es nativo versus no nativo. No son equivalentes por las tarifas. No sé qué va a pasar.
Si la gente empieza a hacer esto, no es el fin del mundo porque son casi equivalentes. Deberíamos abordarlo con la comunicación. Lo que hagamos no decide el resultado, sino lo que hagan los demás. Apoyar tanto a los nativos como a SegWit es añadirlos en paralelo; es lo que nos resulta más fácil de hacer.
¿Cuál era el requisito que les relajaba a la hora de buscar el redeemScript? No necesitamos hacer eso para un producto mínimo viable. En realidad, tal vez eso sea algo a cambiar cuando introduzcamos la nueva cadena… casi es mejor no relajar eso. El cambio se ha reducido a 12 líneas de código. Es la entrada a cuando deberíamos empezar a añadir esto… el cambio del MVP también incluye el cambio para enviar a bech32. Bueno, eso es aparte.
Dame una nueva dirección y escupe un SegWit nativo, pero almacena ambos, el nativo y el… ¿estás hablando del enfoque mínimo viable o del enfoque correcto a largo plazo? Uh, mínimo. No se almacenan ambos porque no es necesario. Ya tratamos asumiendo que tan pronto como se añade un redeemScript para un p2pk, que es actualmente el requisito para ver o tratar como IsMine una salida de testigo es que usted tiene el redeemScript en su cartera. Este es el único cambio de estado que causa addwitness– añade el redeemScript para la versión P2PK a tu cartera. Bueno vale, la razón por la que pregunto es porque estaría bien a nivel de GUI o cliente que .. He recibido estos fondos pero no a la dirección donde los esperaba…. Bueno….. ((gemidos)). No se puede saber cuál es la que has entregado. Ya tenemos ese problema, por lo que el MVP no aborda ese problema. Si queremos decir que estamos desaprovechando el addwitnessaddress a partir de ahora, o queremos que la gente no lo use, sería bueno señalar esto a la gente. Podemos solucionarlo a los metadatos de la clave que dice como hemos mantenido o generado la dirección. Eso parece poco común porque nadie va a hacer addwitness …..
Estaría bien crear una dirección Bech32 que no soporte el P2SH correspondiente. Podemos relajar este requisito. La versión P2SH siempre requerirá conocer el redeemScript. Para la salida nativa del testigo, esto no es un requisito. Esta relajación será de 5-10 líneas de código. Y ninguna de estas cosas tiene pruebas. Si hacemos una relajación que si quisiéramos y fuera lo correcto, entonces automáticamente tiene la capacidad de crear una salida de testigo nativo que sólo se acepta como una salida de testigo nativo o un p2pk pero no como un P2SH … Si al final hacemos lo de la multicadena, entonces esto es un trabajo de oficina, estoy de acuerdo.
Users explicitly asked for Bech32 getnewaddress. Or a command line flag that tells you what your change is. Maybe for MVP you can spend to bech32 but not give out your own address. I think we have to do that, I don’t think the other thing is going to get done. Creating bech32… No he meant the bigger re-design. It’s important for us to have something. I don’t think it makes it worse, but we should clean it up for v0.16. It would need wallet upgrade option. It needs to store or hides… the height is when. The problem is that if you mark the height when SegWit activates. You don’t need that either. You need to know where to rescan. If it’s going to do it automatically then maybe you need to rescan for it. It might be a separate field.
Su cartera o nodo podría ser un nodo diferente… mover la cartera. No es la activación de SegWit, es la activación de SegWit en la cartera. Por qué no usar la activación antes de SegWit. Los nodos podados no pueden actualizar entonces. Ya ha pasado ese punto. Ya está roto en este sentido. Addwitness está roto de la misma manera que addmultisig está roto. Así que al menos lo activas implícitamente cada vez. Si no tienes esta bandera, entonces podrías … Sin embargo, no sé cómo eso te estropea. Necesitas una bandera, pero no necesita interactuar con la actualización de la cartera. Cuando lo ejecutas por primera vez, añade ese campo si no está ya ahí.
Estoy empezando a dudar de nuevo de esto. Haces una operación de actualización explícita para soportar las operaciones de SegWit… tu cartera dice que necesitas una nueva copia de seguridad ahora. ¿Cuál es el problema? No tenemos la altura para… bueno la única cosa que podría ser un problema es si usted estaba tratando de recuperarse de alguna copia de seguridad anterior, pero entonces usted vuelve a escanear, y ya perdió la altura de todos modos. Tiene la altura para hasta la que volvió a escanear. Si se requiere para estar en la copia de seguridad, entonces usted es bueno. Así que ahora sólo necesitamos dos horas para implementar esto. ¿Así que estamos haciendo el MVP? Pull request en 30 minutos.
Creo que alguien debería dibujar esto. Creo que el punto aquí es que… si no hacemos el MVP entonces estaremos bajo presión para sacar SegWit. Lo bueno de hacer un MVP es que también podemos decir que … ¿no preguntó Harding esta mañana no podemos decirle a la gente que use addwitnessaddress, ahora podemos decirle a la gente que es genial? ((risas)) Todos los RPCs de añadir algo deberían tener una advertencia de que necesitan una nueva copia de seguridad de la cartera, incluyendo addwitnessaddress, si hacemos esto entonces podemos decir que está soportado pero probablemente no quieras hacerlo. Bueno, nunca asumas que los usuarios leen el texto de ayuda. Cuando SegWit activado, añadiendo todos los … cada vez que se obtiene una dirección sólo añade la cosa. Añadir a la cartera, añadir la clave a la función de la cartera sólo hace la cosa. Llama a la dirección de addwitness, incluso en tiempo de carga, sí. Pero no hay peligro de que alguien con pago a la dirección testigo de la suya antes de SegWit se activa. Lo sabemos porque Suhas fue a comprobarlo… pero puede que haya pagos, pero al menos son tuyos ahora. No se han gastado. Hay un error de off-by-6 en mi código en el que accidentalmente activé SegWit 6 bloques después… pero aunque sea una fantástica metedura de pata, en el peor de los casos habría un pago a la cartera que no hizo, causaría confusión en el peor de los casos. Pero si durante el rescaneo lo hacemos desde el principio no desde la activación de SegWit, pillaríamos esos casos. Pero lo que decimos es que sabemos… ignorando el off-by-6, sabemos que no ha habido gastos de SegWit antes de la activación.
¿Cómo se comunica a los usuarios que se puede enviar a SegWit nativo pero no recibir? ¿No vamos a generar la dirección Bech32? Así que a un usuario no puede recibir SegWit. Desde la perspectiva del usuario, esto es confuso. Puedes enviar a este formato de dirección pero no generar para ti. No, probablemente apoyaremos eso. Un usuario verá salir una dirección P2SH y dirá oh, no apoyo SegWit porque estoy recibiendo una dirección P2SH. Creo que verán una dirección P2SH y dirán “oh apoyo SegWit”. Si alguien les da Bech32, pueden pagar eso, pero mientras tanto no saben si hay un apoyo generalizado. Hay locos que los están dando ahora, como Armory(risas).
En el protocolo de pago de bitcoin, añadir SegWit a eso… ¿podemos hacer un fallback? Bueno, entonces la gente necesitará código extra en el manejo de URI para soportar esto. Bueno, ya tenemos código ahí. Dale a alguien una dirección, y si no puede pagar, entonces le das otra. Coinbase te da una dirección mediante un código qr o un enlace… demos un ejemplo para otros monederos. El soporte para Bech32 probablemente irá muy rápido, y debemos planear para el éxito, asumir que va bien, y si no va rápido entonces debemos tratar de ayudarlo, y entonces hemos aprendido una lección que necesitamos saber para otras actualizaciones futuras.
Bueno, lightning va a utilizar el esquema BIP70 URI, y el cliente puede elegir opcionalmente utilizar las cosas de lightning que son datos extra en el URI. Pero también puede simplemente retroceder a eso. Los rayos oxidados deberían ser realmente BIPs.
Firmas una transacción, es testigo maleado, y la versión maleada es minada, puede que no te des cuenta, unas semanas más tarde estás mirando tu cartera, no puedes correlacionar eso con lo que hay en la blockchain. El txid será confirmado. La transacción en la GUI será como el tamaño equivocado…. El monedero se comporta correctamente, pero ¿qué espera el usuario? Es una buena cosa para arreglar, pero podría no ser crítico. gettxoutproof podría no… salidas no afectadas por los testigos. ¿Funciona gettxoproof con los testigos y punto? Da una rama Merkle entre el bloque y la transacción. Tienes un usuario arbitrario, y verifytxout que te mostrará el testigo, y que podría ser basura. Eso no es bueno. BlueMatt abrirá el tema. También el tema para requerir algún mensaje sobre todos los RPC de adición requiere copia de seguridad.
Así que en términos de romper la cartera, sólo not…. Creo que llegamos demasiado tarde. Además 0.12 está a punto de ser el final de lifed de todos modos.
salvagewallet tomará un … en el primero … se pierde una tonelada de otros. Incluyendo que esta es una cartera HD… ¿Podemos arreglar esto? La división de la cadena es básicamente el número de versión. Podríamos decir que Salvagewallet está prohibido. No, podemos cambiarle el nombre a savagewallet. Bueno, eso va a ser golpeado por los errores tipográficos … sí en realidad eso me pasó una vez, pensé hey que podría ser un mejor nombre.
En términos de paralelismo, así, algunas de estas cosas pueden, creo que, va a ser pequeño, va a tomar un montón de pruebas. Tengo dos PRs abiertos. Uno para añadir soporte para.. uno para deshacerse de.. esos pueden ser revisados. Necesitamos un issue o milestone para la v0.15.1. Necesitamos esos 2 PRs, y esto que acabamos de discutir, ¿algo más que necesitemos? Hay como si su cambio va a la … así que tal vez deberíamos traer esa discusión de nuevo porque somos un grupo más amplio ahora.
Así que la cuestión del cambio… debería ser P2PKH, debería ser P2SH-P2WPKH, o debería ser nativo. Una idea que se sugirió antes es que se use lo mismo que se usaría para una nueva dirección propia que es… Yo preferiría un …. por defecto lo que estás haciendo por ti mismo es una pregunta por defecto. ¿Cuál es la configuración? Si se obtiene una dirección y una dirección Bech32, tal vez eso es lo que hace cada vez. Me parece que la forma de hacer esto es hacer el cambio por defecto sea este.. Realmente me parece bien cualquier cosa. Aparte de la privacidad… No, la privacidad es la única razón. La privacidad en el núcleo es una especie de basura con el cambio .. y tal vez no en el futuro. No es siempre basura, sólo es mayormente basura. Mira a lo que estás pagando, y si estamos pagando a Bech32 entonces tiene que ser Bech32. sendmany- realmente no generaliza. Si alguno de ellos es Bech32, entonces haz tu cambio Bech32. Así que esto podría ser una mejora temporal de la privacidad. Bueno, tal vez aumente la puntuación del “proyecto de privacidad”.
Similar a la forma en que las direcciones regulares trabajarán, generará las 3 cosas para todas las… cosas de cambio. Sí. De lo contrario, sería demasiado extraño. Esto es algo que hay que arreglar al mismo tiempo que cambiamos a cadenas separadas. Esto es directo- tener una opción de control de monedas que diga para mi cambio usa este, usa este tipo. ¿Cuál sería el valor por defecto? Creo que el valor por defecto debería ser el testigo P2SH al menos durante un tiempo. Por la privacidad. Quieres que coincida con lo que estás enviando… bueno no necesariamente. Si sólo eres la persona que gasta a Bech32, entonces no quieres que tu cambio sea también Bech32, creo.
No debería discriminar a los usuarios menos sofisticados: digamos que su transacción puede ser más barata a cambio de algo de privacidad; tenemos esta mejora masiva de rendimiento con dbcache que sólo los usuarios sofisticados conocen. Este es un argumento en contra de tener configuraciones. Bueno, hay una opción de GUI para el tamaño de dbcache, pero está escondida en los menús.
Entonces, ¿vamos a añadir una opción GUI para qué tipo de dirección de cambio?
P2SH … testigo. Por defecto para el cambio a partir de uno es testigo desnudo, pero eso todavía está abierto a debate. Si nadie lo debate, entonces no cambia. Bueno, depende de quien lo implemente. Joinmarket quiere usar Bech32, openbazaar lo está usando, … Muy bien, a comer.
Adopción de P2SH
¿Cuánto tiempo pasó con P2SH antes de que se pudiera asumir en general que se podía enviar? Bueno, bastante tiempo. No se puede… tardó años, pero blockchain.info tiene soporte para P2SH ahora, sí. Todavía lo tienen. Así que ahora mismo si envías a un… no lo indexan, no puedes ver las transacciones de una determinada dirección, aparece como… ¿así que todo el mundo los usa porque son “privados”? Llevó años… quizás más rápido por estas fechas, pero aún así algún tiempo.
blockchain.info no mantuvo su sitio durante unos 2 años. Armory tampoco lo implementó durante mucho tiempo. También hay casos especiales, como decir que tienes una cartera de Bitcoin Core. Coinbase era… bech32… digamos que tengo un exchange… el caso particular de enviarse a uno mismo desde un servicio es un caso que la gente utilizará rápidamente. Nadie quiere hacer un viaje de ida y vuelta extra. Si me pago a mí mismo, lo acepto. Alguien me ha preguntado si podemos tener el URI del bip.. y le he dicho que el problema es que son más cosas de las que preocuparse.
Algoritmo de ajuste de la dificultad de testnet
El algoritmo de ajuste de la dificultad de testnet es la razón por la que la altura del bloque es alta en testnet3.
bumpfee y retransmisión
¿Los monederos suelen retransmitir si la transacción no está en la blockchain después de unos días? Anyonecanspend covenant utxo que necesita para crear uno nuevo de sí mismo en su salida. Si tuvieras covenants, podrías de alguna manera …. oh podríamos hacerlo de esa otra manera, pero no es tan genial como los covenants. La protección de repetición con pactos sería un buen uso de los pactos en lugar de algunos otros usos de los pactos. Segwit2x debería añadir una fuerte protección de repetición bidireccional.
libevent
https://github.com/bitcoin/bitcoin/pull/11227
Hay tres capas en libevent. Está la base que se ocupa de los eventos de lectura/escritura de los sockets, luego una capa encima que son sus arrays o sus buffers, como sea que los llamen, que tienen callbacks, y luego los eventos de los buffers encima de eso como cuando obtengo datos entonces hago esto, etc. Empecé en el nivel más abstracto porque supuse que sería agradable y limpio. Empecé con los eventos de búfer porque eran los más abstractos y pensé que conducirían al código más limpio. Hay algunas pequeñas cosas molestas que no funcionan del todo como queríamos, así que añadí un montón de hacks que arruinaron la abstracción de todos modos. Así que bajé un nivel y encontré el mismo problema. Y luego bajé a los eventos más básicos, y terminó siendo la menor cantidad de cambios en el código. Después de reescribirlo tantas veces, nunca estuve contento con la diferencia y la legibilidad. Es algo que era sencillo, y ahora es una especie de… está volviendo. Cuando se basa en la devolución de llamada, el código es difícil de leer. Estoy satisfecho ahora que es razonablemente fácil de seguir y ver lo que está pasando. “Si esto está establecido, ponlo a cero”. No hice eso porque empujé esto el domingo por la noche y quería discutirlo aquí.
La implementación anterior era un solo hilo para la red y los compañeros se conectaron a la secuencia con una pausa en el medio. Pero ahora con el bucle de eventos podemos hacer múltiples intentos de conexión simultáneos y hacerlo todo a la vez de forma asíncrona.
El nuevo plan para Cory es que fusionaremos su trabajo inmediatamente, luego sólo haremos que Cory arregle los problemas a medida que aparezcan, y cambiaremos el nombre de Bitcoin Core a Bitcoin Cory.
Construcción de la cadena de herramientas
¿Cuántas tortugas debemos bajar? ¿Debería este sistema intentar ser autodeterminista, o todavía lo ejecutas dentro de gitian para hacer builds? Usted tiene algo que se parece a depende, construye la cadena de herramientas para su sistema, construye cualquier utilidad que usted necesita, debe esa cosa en sí mismo tratar de ser producir una construcción determinista entre las personas? Sería bonito, pero podría no ser realista. Sólo sería realista si usted tipo de real de la explosión de lo que se construye. Tal vez construir su propio shell, su propio… Debería construir un compilador, un enlazador y binutils. No todas las utilidades de Unix.
El sistema de archivos puede impactar en los resultados de la compilación, aunque creemos que lo hemos arreglado. Hay bit rot, y trabajo determinista hecho en upstreams, pero mucho de ello no podemos usarlo porque estamos…. pero si asumiéramos que estamos usando una versión mucho más nueva de estas herramientas, entonces podemos eliminar un montón de esas herramientas, pero estamos confiando en esas herramientas. Hacer una construcción de su propio shell y busybox y la construcción de esas cosas es un poco más de la parte superior. ¿Cuáles son los requisitos mínimos para construir? Tal vez no son tantos. Se necesita un shell. Necesita las utilidades de construcción. Busybox sería la forma más fácil de hacerlo.
Compilador, enlazador, ensamblador son absolutamente necesarios. Deberíamos asumir un sistema linux para las construcciones. Desde linux, construir un entorno de host para OSX. Tener una construcción determinista desde gitian que es la misma, incluso si se construye en OSX. Es empujar, lo reconozco. La mayoría de las veces se asume que el build y el host son iguales. Pero tal vez usted construye el toolchain en linux, y luego lo ejecuta en osx. Es casi el mismo esfuerzo que soportar una nueva plataforma. wumpus hace builds (no deterministas) en openbsd y freebsd.
otros
Si cambias todas las transacciones del historial para usar índices, es un 30% más de reducción en el tamaño de la cadena. Así que obtienes una reducción del 20% usando… pero si cambias todas las… es otro 30% de reducción. Es un ahorro realmente bueno. Tienes que tener un índice de…
otro otro
http://bitcoin.sipa.be/bech32/demo/demo.html
Agregación de firmas
Trasladado a http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/
Selección de monedas
La primera vez utiliza el método “branch-and-bound”. Y luego vuelve al otro método si falla. Es una sola vez. El branch-and-bound, la primera vez que se ejecuta, ve si puede construir… utiliza valores efectivos para las entradas. El argumento que tenía para no usar valores efectivos es que hace que se muela el cambio más a menudo. Así que la preocupación por el valor efectivo es que.. [cosas malas pero como el BnB no crea cambios no es un problema]
Usar la tasa de descarte para decidir el cambio. Calcular el coste del cambio y utilizar la tasa de descarte, en lugar de la estimación de 1008 bloques Digamos que tienes una entrada de 1k sat y te costaría 999 sat gastarlo. Te alegras de elegirlo, aunque la tasa que pagas es alta. Se ordena por… dada una lista de entradas, la ordenamos primero, de mayor a menor, y luego elegimos bajando por ahí. La ventana que tiene que golpear se basa en la tasa de descarte. La tasa de descarte es pequeña comparada con la tasa total. El coste de crear un cambio es nuestra tasa actual, así que 34x. Eso son varios miles. Es poco probable que elija algo más pequeño que eso. Elige primero las tasas efectivas más grandes. Así que no entra en la ventana.
El valor efectivo es … tamaño serializado o virtual de la entrada (vsize), … 148 bytes para no-SegWit, con su tasa actual, se utiliza para calcular la tasa efectiva. Tal vez excluir las cosas que son más pequeños que el 50% de su valor efectivo. Ya está pasando por cero y el valor negativo. Podría tomar múltiples pases… hecho experimentos donde cuanto más pequeña es la ventana… En lugar de detenerse en la primera, encontrar como muchos que encajan como sea posible, de la misma rama hacia abajo, y luego utilizar algún otro restringir para encontrar el “mejor”. Si tomas la primera solución, vete a buscar la que tenga la tasa de descarte más alta pero que tenga el mayor número de entradas.
Cambio * tasa de descarte es lo que nos ahorramos si no creamos una salida. Estamos utilizando la tasa de descarte que se basa en la estimación a largo plazo a menos que el usuario anula. Si la estimación de la tasa es alta, nunca creará nada más que la tasa de descarte. Tal vez esté dispuesto a descartar mucho más, pero incluso sin descartar mucho más, seguiría produciendo salidas sin cambios con bastante frecuencia.
Se implementó branch-and-bound para un monedero trezor bitcoinjs. Lo redujo a sólo la salida de cambio más óptima creo que era una décima parte del costo de entrada.
Este es un problema de suma de subconjuntos: debería haber soluciones una vez que el número de posibles subconjuntos que puede seleccionar es similar al tamaño del valor que está apuntando. Una vez que el número de soluciones es mucho mayor, entonces usted podría tener muchas soluciones al tamaño del número que usted está apuntando.
discardrate es un parámetro que es lo mucho que está dispuesto a tirar la cuota extra para evitar hacer la salida de cambio. También se utiliza ahora en branch-and-bound. El rango está entre la cantidad de polvo y la tasa de descarte, en algún lugar dentro de ese rango.
Evitar una salida de cambio mejora la privacidad. Ningún cambio es mejor para la privacidad. Así que usted tiene un costo que está dispuesto a pagar por la privacidad adicional. Añadiendo esta otra métrica de residuos .. y minimizar eso. Lo que significará que nosotros, en vez de descartar más, en vez de tener menos aciertos, tenemos el mismo número, y simplemente desperdiciamos menos dinero.
Con branch-and-bound, la primera solución es poco probable que sea la óptima incluso con el mismo número de entradas. Simplemente combino sistemáticamente y en algún momento encuentro algo que está en algún lugar en el rango de las cantidades, porque está en algún lugar menos que cualquiera que sea la métrica de desperdicio. Si seguimos buscando, incluso si permitimos el mismo número de entradas, es casi seguro que vamos a encontrar el mismo número de entradas que tiene una menor cantidad de residuos. En la ramificación, esto se autorregula. Si tienes una tasa mayor, puedes conseguir pocas entradas para encontrar un conjunto de entradas que llegue a esta zona permitida. En la situación de tarifa alta, tienes un conjunto de entradas pequeño, que a la gente le debería gustar porque gastar entradas aumenta el coste de la transacción. Es probable que se necesiten más entradas en combinación para alcanzar el objetivo exacto cuando las tasas son bajas. Podríamos modificar el tamaño de la ventana dispuesta a tolerar en función de nuestra visión de la relación entre la tasa de honorarios actual y la tasa de honorarios a largo plazo. Cuando pensamos que la tasa de honorarios es baja, estamos dispuestos a tener un valor efectivo que sea un porcentaje menor del valor inicial. Podríamos hacer con esto con una entrada de preprocesamiento, qué porcentaje de su valor para cada entrada es su valor efectivo, podríamos hacer eso. Si la relación entre el actual y el largo plazo, por la entrada, y ordenar por eso. También podríamos ser estrictos y decir que nunca considerar cualquier entrada que está gastando más del 10% de sí mismo en los honorarios, y luego volver a la antigua algoritmo.
El retroceso… bueno, esto parece que se optimiza sólo para algunos usuarios. ¿Qué tenemos que hacer para hacer branch-and-bound en la aproximación de la suma de subconjuntos? No es un mal algoritmo. ¿Cuáles son los objetivos? ¿Qué estamos tratando de optimizar? Si tuviéramos una función objetivo, el tipo de solucionador de mochila que estamos utilizando actualmente no es un mal enfoque. No hay realmente buenos algoritmos genéricos para resolver este tipo de problemas de suma de subconjuntos.
Los cambios pequeños pueden ser malos. Pero, ¿por qué los cambios grandes son malos? Si tienes demasiados cambios grandes, pierdes privacidad. Optimizar para muchos cambios pequeños es una tontería. Optimizar para muchas entradas, es bueno.
Digamos que no puedes encontrar la coincidencia exacta. Sólo escoge entradas al azar hasta que encuentres la cantidad hasta que termines. Bueno, eso es ramificar. No quiero crear polvo, … cualquier cosa por encima de un centavo para el cambio está bien. Tal vez un directorio de objetivos. Quieres gastar todos los insumos en la cartera y dejarlos con una salida de la que están atascados encadenando, y ahora esa salida no está confirmada, pero con la maleabilidad arreglada es mejor ahora. Digamos que tienen unos pocos insumos grandes que tratas de pagar 20 BTC, tienes como, algunos insumos de tamaño medio y algunos insumos grandes, escoge los insumos de tamaño medio y los obtiene todos. En general, deberías ser avaricioso a la hora de gastar insumos, porque las tarifas van a ser más altas en el futuro. Ignorando lo que sabemos sobre los periodos de tasas altas y bajas, etc. Pero las tasas en bitcoin probablemente deberían ser menores en el futuro, así que si el usuario no va a comprar más bitcoin en cantidades iguales a sus tasas, entonces debería minimizar las tasas que está pagando actualmente. Digamos que el bitcoin va a ser de 1 millón de dólares, entonces las tasas en bitcoin deberían bajar… o no… en las tasas en bitcoin?
¿Puede un nuevo algoritmo utilizar el valor efectivo? Claro, absolutamente. Pero lo que preocupa es que si se introduce el valor efectivo en la aproximación actual de la suma de subconjuntos, es que con el algoritmo actual que tenemos, se tendería a no gastar polvo, y se triturarían las salidas en cositas y se haría un lío. No estoy seguro de eso, pero creo que mi respuesta de eso es mostrar que no hace esto mediante la ejecución de una simulación. Escoger al azar parece menos probable que lo muela en polvo. Mientras el algoritmo no esté súper predispuesto a elegir entradas de baja cuota, probablemente esté bien. Y puede cambiar en base a lo que pensamos que es nuestra tasa de honorarios relativa. No queremos estar en una situación en la que la cartera… no crea salidas que estaríamos sesgados en contra de elegir para gastar más tarde. Esto es lo que hace branch-and-bound, evita crear cambios que ew no gastaría. El algoritmo existente sólo limpia cosas a un costo económico para usted, a veces. Intenta producir una pequeña cantidad de cambio por encima del objetivo de cambio, que no está relacionado con nada.
Si tienes muchas salidas de cambio, entonces puedes dividirlo en dos salidas de cambio, o bien gastar tu cambio en una mitad 50/50, lo cual no es bueno para el branch-and-bound, o si tu moneda sale cara, entonces haces una que es igual al pago que estás haciendo, y la otra es el resto. Así que tienes una transacción con tres salidas, dos que son iguales, y una podría ser un pago o podría ser el cambio. Y la mitad de las veces esto creará una salida que va a ser un pago del tamaño del pago que estás haciendo de todos modos, por lo que las futuras transacciones serán más baratas. Si algún servicio está flipando con el número de salidas, …. bitpay se romperá si les pagas con dos salidas, pero me refiero sólo al cambio.
¿Cuáles son los objetivos? Si se paga una cantidad grande se paga una cantidad más grande, que podría ser un esquema viable. Cuando el cambio es grande, necesita crear múltiples salidas. Nunca cree salidas mayores a 50 BTC, no hay ganancia para nadie en hacer salidas grandes. Te ahorras un par de dólares en honorarios en el futuro, y te destacas como un loco, y pones todos los huevos en una sola canasta.
Podemos elegir las cosas por lo que es socialmente favorable a la red en términos de privacidad general, la utilización general, el tamaño del conjunto utxo. Y luego, en segundo lugar, hay diferentes perfiles o modos que un usuario puede utilizar para los usuarios.
Las tarifas constantes facilitan la comparación de los algoritmos. Pero en la realidad tenemos variación de tarifas, y esto hace que la selección de monedas sea más interesante. Las empresas están consolidando utxos en el fin de semana. Hacen primero lo más grande, y luego consolidan en el fin de semana. Ya vemos este comportamiento.
En realidad, cierta empresa (no una de las que podrías esperar) está realmente interesada en que les ayudemos a resolver la selección de monedas para ellos. Están dispuestos a configurar una API para que los desarrolladores de bitcoin envíen el código de selección de monedas y ellos devolverán los resultados, pero no darán los datos de las transacciones. Así que están pidiendo ayuda activamente.
No deberíamos detectar, basándonos en la tasa de las tarifas, si hay que agregar entradas. Mirando las estimaciones de las tasas y tratando de averiguar qué … con la selección aleatoria, está sesgada hacia la agregación.
Ordenar por valor efectivo, seguir añadiéndolos de arriba a abajo, y si no hemos llegado a ese punto entonces literalmente no podemos hacer el pago. Litecoin añadió 800 MB a su conjunto de utxos al principio porque alguien envió 1 sat a todo el mundo. Y tenías como un millón de utxos pequeños y el algoritmo de selección de monedas fallaba porque no podía encontrar tus salidas reales.
Si vas por encima del objetivo, cortas esa rama. Esto te da un pequeño corredor en el árbol binario donde realmente tienes que explorar para encontrar todas las soluciones posibles. Por lo general, probablemente se encuentra ampliamente en el rango de esas cantidades tal vez en la parte superior de la misma, y usted está tirando un montón de dinero que no quiere hacer eso - queremos minimizar el desperdicio. ¿Cuál podría ser la métrica para medir el desperdicio? La idea de esto en este momento sólo tomar la primera y seguiríamos buscando y, a continuación, en función de la cantidad de insumos que nuestra solución más pequeña tiene, calcularíamos la cantidad de honorarios que pagamos por los insumos que no necesariamente necesitaríamos en comparación con la expectativa a largo plazo de lo que costaría un insumo, más el subsidio. Así que tenemos dos entradas, encontramos una solución que llega a la ventana de asignación en la zona inferior, por lo que es menos dar a las tasas, pero si añadimos dos entradas más a 100 sat/byte, entonces el usuario está perdiendo dinero porque podría enviar más a las tasas pero más tarde cuando es más barato. Pues no sabemos si va a ser más barato.
Tenemos muchas cosas diferentes en la métrica. Ahora mismo sólo priorizamos estrictamente las cosas. Ya tenemos 6 cosas de confirmación, luego 1 cosa de confirmación, luego 0 cosas de confirmación, y tal vez queremos tratar cada dirección como una unidad, entonces vas a …. No estoy seguro de que discardfee. Tal vez minimizar discardfee. No, sólo lo que sea. Podríamos minimizar el número de entradas, minimizar la cantidad de cuota que descartamos….
Liberación de la validación
Tengo una pubkey en el binario. Una herramienta de descarga para comprobar el binario que has descargado, como alternativa a pedir al usuario que compruebe manualmente que la liberación ha sido firmada por los desarrolladores de bitcoin. verifysignature no sirve para esto. sha256. Sólo digo que el trabajo mínimo. Eso sería un pequeño número de líneas.
jenkins
jenkins tiene una integración estándar con IRC y podríamos usarlo para activar las construcciones. También tiene alguna interacción con github pull requests. La ventaja de ejecutar cosas en no travis-ci es que podríamos ejecutar un conjunto completo de pruebas porque no estaríamos limitados a las mismas máquinas que travis-ci proporciona. También podrías garantizar que no hay nada más ejecutando concurrentemente. Puedes construir en paralelo, todavía.
Transacciones conflictivas para las retiradas
Intentamos evitar que las transacciones caduquen. Tratamos nuestras salidas de cambio como si fueran gastables inmediatamente. Con SegWit podemos evitar la maleabilidad. Podemos gastar inmediatamente la salida de la última ronda en nuestra transacción. Y entonces tenemos una larga cadena de transacciones no confirmadas. Entonces tenemos que calcular la tasa para golpear toda la cadena.
Tomas todas las transacciones no confirmadas en el gráfico y calculas su tamaño, miras las tasas, y luego dices cuál es el tamaño de todo el paquete, y cuál es la tasa para todo el paquete que hay que añadir. Así que para cada retirada, se actualiza el objetivo de la tasa actual. En Core, sería bueno hacer cosas de reemplazo.
Tratar sus propias salidas no confirmadas como de confianza, y los depósitos mantener el requisito de profundidad de la confirmación. Otras personas pueden encadenar sus cosas y estropearlas, en lugar de ….
Hacer que el hijo pague por el padre en lugar de la sustitución. CPFP para cadenas de 25 transacciones. En algún momento tienes que dejar de hacer retiros. Un intercambio estaba anclando sus reemplazos, lo que causó problemas. El reemplazo es mucho más eficiente.
Transacción de 200 bytes que paga 30 sat/byte. Se gasta por una transacción de 1 sat/byte de 100 kb, pero mi bump para reemplazarla tiene que pagar una cantidad enorme de sat/byte para poder pagar lo que sacó. No tiene que ser la tarifa, tiene que ser lo que ha eliminado.
Árboles de Merkle y MASTs
Trasaladado a http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-07-merkleized-abstract-syntax-trees/