+1 a eso!

Bitcoin actualmente está usando toda mi velocidad de carga, lo que en realidad significa que a veces ni siquiera puedo navegar. Cerrar BitCoin resuelve el problema, pero no es realmente beneficioso para la red ...

+1 también.

Tengo un límite de carga de 60 KB / s en mi ADSL, y bitcoin.exe está matando mi carga tan mal a veces que ni siquiera puedo navegar muy bien por Internet. Alguna información extra:

Normalmente tengo ~ 32 conexiones en bitcoin. Recibir parece estar bien. Después de 10 minutos, las conexiones actuales de bitcoin.exe han descargado alrededor de 100kB cada una, pero la descarga no suele estar tan limitada como la carga.

Después de aproximadamente 10 minutos, las conexiones actuales de bitcoin.exe usan aproximadamente 100 kB de carga cada una, pero hay ~ 3 que usan ~ 1 MB +. Esto llega a un promedio de más de 10kB / s (no mucho en cuanto al promedio). Pero sospecho que cuando esos tipos de 1MB + van, usa el 100% de la carga y simplemente baja a un promedio de 7.5kB / s después de que se termina esa parte.

Preferiblemente, me gustaría limitar la carga de 2kB / sa 5kB / s en mi conexión actual.

EDITAR: estoy usando bitcoin 0.3.24-beta

He alojado un nodo público de bitcoin las 24 horas del día, los 7 días de la semana durante más de un año en mi servidor Linux doméstico. Me está causando una pérdida considerable de paquetes en la línea y empeora con el tiempo, a medida que la cadena crece. Por favor, agregue limitación de ancho de banda al bitcoind. De lo contrario, tendré que apagar el nodo, porque mi conexión a Internet se vuelve inutilizable.

QoS es realmente un trabajo de enrutador, pero supongo que los enrutadores confiables no son demasiado comunes: /

un +1 más, que también necesita esto, o una forma de que bitcoind use una cadena de bloques compartida (consulte http://bitcoin.stackexchange.com/questions/3199/read-only-blockchain-in-bitcoind-patch-ideas y https : //bitcointalk.org/index.php? topic = 71542), incluso mejor que simplemente acelerar en mi humilde opinión

Además, esperando una opción en bitcoind, puede echar un vistazo a 3 herramientas de limitación de ancho de banda del espacio de usuario: http://monkey.org/~marius/pages/?page=trickle , http://klicman.org/throttle/ y http : //stromberg.dnsalias.org/~strombrg/slowdown/

No hay +1 aquí, por favor. Creo que todos estamos de acuerdo en que es una buena idea que un programa P2P tenga límites configurables.

No es realista exigir que las personas muevan esto a un enrutador. Especialmente en un VPS, no tienes mucho control sobre el enrutamiento.

Sin embargo, esta característica actualmente no tiene prioridad para los desarrolladores principales. Si desea acelerar este problema, ayude con la implementación.

Editar: y sugiero probar clientes ligeros como Electrum, que afirman usar mucho menos ancho de banda y 'compartir' una cadena de bloques en un supernodo.

Quizás no esté relacionado, pero ustedes podrían (para Windows) probar cFosSpeed ​​si su conexión se retrasa debido a las cargas.

Para MS Windows, puedo sugerir NetLimiter como una buena pieza de software, aunque comercial. Habría pensado que Linux tiene varias opciones de QoS disponibles, ¿no es así?

Cuando utiliza una aplicación P2P (por ejemplo, un cliente torrent), siempre se le presenta algún tipo de información y / o opciones de personalización con respecto a la naturaleza de la comunicación P2P y su consumo de ancho de banda.
Con el cliente BitCoin, esto no es tan obvio y me lleva a la falsa creencia de que BitCoin no tiene mucho tráfico en la red.
Los cerdos esporádicos de Internet siempre se atribuyeron a un ISP inestable hasta que descubrí que en realidad el cliente BitCoin era el culpable (llenando todo el ancho de banda de carga).
Por el bien de los usuarios menos expertos en tecnología, haga una opción obvia y fácil para, al menos, agregar el argumento -nolisten al iniciar el cliente.

problema fue creado hace 2 malditos años. ¿Qué está pasando, chicos de desarrollo? ¿Por qué esto aún no ha sido parcheado? ¿No ven la urgente necesidad de tal característica?

es tan estúpido no implementar esto lo antes posible porque da un mal aspecto a toda la aplicación y la comunidad, ya que arruina Internet de las personas, y muchos de ellos no están metidos en cosas técnicas, lo que básicamente significa, programa malo -> desinstalar. .

No comprende cómo funciona el desarrollo de código abierto. Trabajamos en esto en nuestro
tiempo libre, así que decidimos por nosotros mismos qué es importante y qué queremos gastar.
tiempo en.

Si quieres que algo se implemente muy mal es _tu_
responsabilidad de hacer que eso suceda, no nuestra.

¿Puedes contribuir a solucionar este problema?

¿O está dispuesto a pagar para que se implemente la función? Podrías ofrecer
una recompensa.

No veo, por supuesto, una necesidad urgente de una función de este tipo, y hasta que se desarrollen algunos componentes adicionales, dicha función sería perjudicial para la red: si configuras un acelerador bajo, tus pares deben cambiar para extraer bloques de otra persona. cuando eres lento. (También es un problema en ausencia de un acelerador, pero muchas personas que ponen un acelerador lo empeorarían)

En este momento, es mejor para los nodos con tráfico restringido simplemente deshabilitar la escucha. Esto tendrá en gran medida el efecto deseado, no corre el riesgo de agregar problemas y es una opción ya disponible.

Creo que el problema aquí es mucho más que no es obvio para un nuevo usuario que, de forma predeterminada, su nodo proporcionará bloques a la red. Desactivar la escucha realmente solucionaría eso, pero está lejos de ser obvio.

Si no reenvío mi puerto, ¿otros clientes no pueden descargar de mí? El cliente realiza conexiones salientes para recibir bloques. En BitTorrent, las conexiones salientes también se usan para cargar, y tiene sentido porque esto mantiene la red mucho más viva. ¿Bitcoin hace lo mismo, sube bloques a los nodos conectados si no lo hiciste hacia adelante?

Los nodos no se anuncian a sí mismos como aceptando conexiones hasta que la mayoría de las veces se ponen al día ... por lo que solo reenviaría nuevos bloques, lo que no es una gran cantidad de datos.

Estoy atrapado con la cadena de bloques, ese no es el problema aquí. ¿Pero estaría reenviando nuevos bloques a pares conectados independientemente de si mi puerto se reenvía? Porque eso podría resultar en un trabajo de carga de 1,5 MB para un nuevo bloque, si todos los nodos conectados aún no tienen el nuevo bloque.

"Los nodos no se anuncian a sí mismos como aceptando conexiones hasta que la mayoría de las veces se ponen al día ... así que solo estarías reenviando nuevos bloques, lo cual no es una gran cantidad de datos".

Sin embargo, satura mi enlace ascendente. Estoy en DSL sin otras opciones, y es una carga sólida de 50-70 kilobytes (no kilobits), lo que hace que la conexión sea completamente inutilizable para cualquier otra cosa. Algún día, Google Fiber me traerá una pipa de grasa gigante y esto no será una preocupación, pero como vivo en un área bastante rural, es probable que no lo sea por un tiempo.

Esta falta de control de carga daña la red porque apago todo el nodo por completo a menos que realmente esté participando en una transacción. ¿No sería mejor tener un nodo lento que ningún nodo?

Parece que los desarrolladores piensan que todo el mundo tiene googlefiber, es una pena, de verdad, hay X tipos de servicios de Internet en todo el mundo con Y límites de carga / descarga. Obligar al usuario a hacer algo que dañará su propia Internet es una decisión indignante.

Sin mencionar que, una vez que el usuario se entera de lo que está martillando su internet, la decisión más común es matar al programa que está causando el problema y abandonarlo, o usarlo lo más bajo posible, se convierte en algo malo en lugar de bueno. cosa. Este es un mal marketing. Esto me decepciona de muchas maneras.

¿Cómo voy a recomendar esto a un amigo sabiendo que luego el mismo amigo vendrá y me dirá "oye, recuerdas ese programa que me dijiste que usara? Estaba jugando con mi Internet, haciéndolo muy lento, ni siquiera podía ver un video de utube en pieza, mala llamada dud ". Eso es lo mínimo que podría pasar, y este es solo un ejemplo simple.

Como acaba de señalar cjastram, es mejor TENER un nodo lento que NINGÚN nodo. Si los desarrolladores fueron lo suficientemente inteligentes como para crear un código tan avanzado y futurista, estoy seguro de que ya saben todo lo que estamos señalando aquí, no más palabras, ya terminé.

@XcaninoX , entonces, ¿estás diciendo que desactivaste la escucha según lo recomendado y estás usando 70kbytes / seg de salida?

Personalmente, creo que la aceleración de carga tal como está es una mala idea, al menos hasta que mejoremos el mecanismo de sincronización de bloques. Si golpea un nodo estrangulado durante la sincronización, la sincronización será lenta.

En cambio, creo que necesitamos un modo "sin servidor" (alguna casilla de verificación, quizás solicitada en el primer inicio), que deshabilita los bloques de servicio (históricos), deshabilita la escucha (por defecto) y deshabilita NODE_NETWORK (para que los nodos no se anuncien como llenos no). Esto significa que las personas aún pueden realizar la validación y la transmisión de parte de ser un nodo completo, pero sin las implicaciones de ancho de banda de servir la cadena completa.

Más tarde, este modo sin servidor podría convertirse en un modo de poda, donde los bloques históricos ni siquiera se guardan en el disco.

Personalmente, creo que la aceleración de carga tal como está es una mala idea, al menos hasta que mejoremos el mecanismo de sincronización de bloques. Si golpea un nodo estrangulado durante la sincronización, la sincronización será lenta.

Por supuesto, pero ¿no es lenta la sincronización si llega a un nodo que tiene un ancho de banda limitado? No obtienes mágicamente una sincronización rápida solo porque no permites que los nodos tengan la capacidad de acelerar. El problema es que si no permite la aceleración, obtiene _no_ node porque la gente simplemente lo apaga.

Después de un tiempo de que la gente simplemente lo apague, comienza a recibir una carga de sincronización masiva en el sistema porque la gente necesita sincronizar cientos (o miles) de bloques cada vez que quieren hacer una transacción BTC. En lugar de la carga de sincronización ligera que ocurre en tiempo real, tiene una cantidad pequeña (pero significativa) de personas que requieren una gran cantidad de ancho de banda a la vez.

De ahí el problema. Si pudiéramos dejar BitCoin encendido con un ancho de banda bajo, entonces no tendríamos el problema de sincronización.

En cambio, creo que necesitamos un modo "sin servidor" (alguna casilla de verificación, quizás solicitada en el primer inicio), que deshabilita los bloques de servicio (históricos), deshabilita la escucha (por defecto) y deshabilita NODE_NETWORK (para que los nodos no se anuncien como llenos no). Esto significa que las personas aún pueden realizar la validación y la transmisión de parte de ser un nodo completo, pero sin las implicaciones de ancho de banda de servir la cadena completa.

Quizás. No sé cuál es realmente la saturación de mi ancho de banda de carga, si se trata de confirmaciones de transacciones o sincronizaciones de bloque de otras personas.

Más tarde, este modo sin servidor podría convertirse en un modo de poda, donde los bloques históricos ni siquiera se guardan en el disco.

¿Tratemos de no sobre-diseñar una solución más simple?

@cjastram Ese es mi punto: creo que es mejor para las personas que no pueden o no quieren servir bloques históricos que no hagan eso en absoluto, y ni siquiera publiciten en la red lo que hacen. Si habilitamos la limitación del ancho de banda sin eso, la posibilidad de golpear accidentalmente un nodo lento aumentaría, mientras que si eliminamos esos nodos del grupo por completo, la posibilidad de que eso ocurra disminuye.

La gente que cierra completamente los nodos porque satura su enlace de datos es, por supuesto, malo. Limitar o deshabilitar el servicio mejoraría eso, pero está cerca de los recursos que está dispuesto a gastar, tal vez no debería ejecutar un nodo completo en primer lugar.

La retransmisión de nuevas transacciones y bloques suele tener un ancho de banda bastante bajo; es justo cuando un nodo que se sincroniza desde cero te golpea cuando de repente obtienes una ráfaga de carga.

Acerca de la sobreingeniería: la capacidad de ejecutar un nodo podado es una evolución inevitable en algún lugar en el futuro, en mi opinión, y también implicaría una solución a su problema de todos modos.

FWIW, respetuosamente no estoy de acuerdo, y creo que la solución más fácil es ofrecer un acelerador de carga opcional (es decir, enviar o escribir syscall). Un acelerador de descarga es menos útil: realmente no puede controlar la cantidad de datos remotos entrantes; dejar de leer (2) hará que los buenos se aceleren eventualmente, pero los malos siempre tienen una técnica o tres que inundarán la entrada de todos modos. Y en el campo, a los usuarios les importa menos limitar su velocidad de descarga que limitar su velocidad de carga.

Es una perilla común en otras aplicaciones de servicio de datos P2P, por lo que ACK un acelerador de carga correctamente implementado con perilla.

@jgarzik Mi punto es que actualmente estamos mejor con menos nodos de servicio, si eso significa que esos nodos son más rápidos. Una vez que tenemos los encabezados primero y la búsqueda en cadena paralela, las cosas son diferentes y probablemente cualquiera que esté dispuesto a contribuir con un poco de carga será útil.

OP aquí, ha pasado un tiempo desde que se creó este problema y durante los últimos 2 años mi cliente bitcoin-qt rara vez ha maximizado mi carga, así que no pensé demasiado en ello.

¡Pero recientemente, en el último mes o dos, he notado que mi carga o envío de datos a menudo está completamente al máximo! Tengo una conexión decente, algo así como 300-500KB / s de carga. Afortunadamente, he logrado atraparlo la mayoría de las veces y abro una herramienta de monitoreo de red y elimino los puertos en cuestión (siempre bitcoin-qt). Tengo que tener cuidado porque si funciona a esa velocidad durante un largo período de tiempo, mi red no solo será lenta sino que consumirá rápidamente mi cuota de datos.

Así que ahora, en lugar de ejecutar un nodo completo durante ~ 8 horas al día, dejo que se sincronice con la red y luego lo apago.

Si tuviera una opción de aceleración, la establecería en algo así como 50 KB / s de carga ... esto es más rápido de lo que nunca uso al descargar los últimos bloques (enlazados a la CPU).

Creo que esto es un problema, me gustaría ejecutar un nodo completo, pero no lo haré mientras consume el 100% de mi carga la mayor parte del tiempo.

@slothbag ¿Ha inhabilitado la escucha?

No, no lo he hecho. De hecho, me gustaría contribuir como un nodo de escucha completo.
Si voy a inhabilitar la escucha, es mejor que no me moleste y deje
sincronizar y luego apagarlo.

El miércoles 6 de marzo de 2013, Gregory Maxwell escribió:

@slothbag https://github.com/slothbag ¿Ha inhabilitado la escucha?

-
Responda a este correo electrónico directamente o véalo en Gi
.

@slothbag Como un nodo que no escucha, usted sigue contribuyendo a la red, validando y reenviando transacciones y nuevos bloques, evitando particiones ... pero no utilizará mucho ancho de banda. Un límite de velocidad mientras se sirven bloques históricos sería muy perjudicial para la red en este momento, en realidad es mejor que no ejecute un nodo que sirva bloques históricos con un límite de velocidad. ... pero mejor aún correr sin escuchar.

Entendí que si un nodo escuchaba o no no estaba relacionado con si cargaba bloques o no. Incluso un nodo que no escucha cargará bloques si un nodo conectado los solicita, ¿no es así?

En lugar de limitar la velocidad de carga de bloques, lo mejor sería que los nodos identifiquen si son proveedores de bloques o no en la primera conexión. Un limitador de velocidad no es una mala opción siempre que el límite de velocidad no sea demasiado bajo; después de todo, todavía habrá nodos en la red en redes lentas y ese siempre será el caso.

Para cualquiera que desee reducir el impacto de su cliente bitcoin-qt, he creado una solución rápida que minimiza el tráfico mientras uso una red wifi que cobra por megabyte. Este parche agrega una opción de línea de comando, para que el cliente descargue solo bloques y no transacciones, y no cargue nada más que las transacciones que usted crea. La desventaja es que esto no es saludable para la red en su conjunto, no mostrará las transacciones que está monitoreando desde otro lugar hasta que se incluyan en un bloque, y reduce el anonimato en el sentido de que solo transmitirá sus propias transacciones. y no de nadie más. Además, la función de alerta también está deshabilitada, por lo que no verá alertas para actualizaciones urgentes (¡no es que esto fuera confiable de todos modos en el caso del reciente hardfork 0.8!).

Idealmente, esto se podría alternar desde la GUI o incluso podría encenderse y apagarse automáticamente según el ISP con el que desee activarlo, en mi humilde opinión.

Oh, aquí está la rama mencionada anteriormente: https://github.com/rebroad/bitcoin/commits/MinimizeTraffic

Sigo manteniendo que debería haber una forma en que los nodos como este (que no retransmiten txs y bloques) deberían anunciarse como tales al conectarse para que otros nodos puedan tomar una decisión informada al decidir si conectarse a otros nodos o no que están retransmitiendo. Sin esta publicidad, los nodos solo pueden adivinar en función de la frecuencia de los txs y los bloques recibidos de dichos nodos.

Creo que un sistema de aceleración de carga es útil, con nodos que anuncian su ancho de banda disponible y otros nodos validan esto, y esta información se incluye en la información de la dirección que se transmite. De esta manera, los nodos pueden preferir nodos con mayor ancho de banda y el nodo puede calcular el ancho de banda disponible en función de cuántos nodos se están cargando o descargando actualmente. El ancho de banda por conexión se puede seguir controlando y las conexiones se pueden cambiar cuando sea necesario. Esto ya es algo que he estado codificando en mi rama de descarga de bloques paralelos y le permite elegir cuántos nodos descargar en función del ancho de banda que sabe que está disponible. Si encuentra que el ancho de banda de carga está saturado, simplemente dejará de enviar invs (a nuevos nodos) para que esos nodos no le soliciten datos.

Fui y probé un montón de opciones diferentes para acelerar bitcoin-qt externamente sin ningún éxito.

Intenté usar goteo en Linux, sin embargo, se produjo una falla en el inicio.

Intenté usar iptables QoS para traficar el puerto 8333 entrante y saliente y tuve un éxito limitado, a veces funcionaba y otras veces no funcionaba en absoluto.

Intenté usar NetLimiter en Windows como se mencionó anteriormente, sin embargo, no maneja muy bien bitcoin-qt, las conexiones de alto tráfico se muestran como conexiones UDP del sistema, por lo que el acelerador no se activa.

Solo sospecho un poco que las conexiones de alto tráfico son en realidad maliciosas, ya sea una simple inundación o una explotación del búfer tal vez ... ¿Al ver el tráfico en Wireshark, todos los paquetes parecían idénticos?

De todos modos, continuará investigando hasta que el tiempo lo permita.

Acabo de descubrir por qué se agota mi ancho de banda mensual de 150 GB, 85 GB eran tráfico ascendente de bitcoins. Promedio de 4 GB al día para una buena idea.

Ahora veo que no hay soporte para la limitación, por lo que no se vuelve a activar. Realmente me complace tener una tarifa limitada a 64kb durante el resto del mes y no tener que pagar tarifas.

¿Dónde crees que vive la cadena de bloques, confías en su guardián?

No aceleres la cadena de bloques, morirá.

Si lo hace, no se queje del aumento de las tarifas de las transacciones o del tiempo que tardan en confirmarse o confirmarse las transacciones.

1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB
¡Gracias!

@memetica Entiendo su punto, pero no estoy ejecutando el cliente porque no puedo permitirme que use todo mi ancho de banda.

Por tanto, ¿es mejor que algunos nodos de la red tengan una carga lenta o limitada, o que solo tengan nodos "rápidos"?

Quizás no debería ejecutar el cliente. Cuando estaba en los EE. UU. Teníamos un ancho de banda ilimitado, por lo que la carga no tenía sentido. Pero en el "resto del mundo", el ancho de banda no es gratuito, y si no tengo la capacidad de limitar mi exposición, no estoy preparado para ejecutar el cliente. Y estoy bastante seguro de que la idea es no tener todos los servidores "rápidos" en algunos países, ya que eso debilita la red.

Con solo decir: "Y estoy bastante seguro de que la idea es no tener todos los servidores" rápidos "en unos pocos países (...)"
Tú dices mi punto.

Al limitar el ancho de banda de / your /, transfieres el trabajo a otros, que también limitarán el de ellos, etc.
Hasta que termines en el escenario del que estás bastante seguro, no es la idea.
Felicitaciones a usted.

Si acelera la cadena de bloques, no confía en bitcoin. (lo piensas como robar, piénsalo)

Todo esto es bueno y tal, pero el cliente todavía está interfiriendo con su velocidad de descarga.

En respuesta al cartel original:
"Noté el otro día que Bitcoin estaba maximizando mi ancho de banda de carga en ADSL. Probablemente debido a enviar la cadena de bloques a otros usuarios de Bitcoin (tenía alrededor de 65 conexiones en ese momento) ..."

La respuesta real ya ha sido dada por "luke-jr" quien publicó:
"QoS es realmente un trabajo de enrutador, pero supongo que los enrutadores confiables no son demasiado comunes: /"

Los cínicos nunca parecen querer dar una respuesta directa: /

Quería decir, probablemente, que sería mejor quejarse de que los enrutadores no se adhieren o ni siquiera implementan los estándares de configuración del tráfico. Solo marcar una casilla y hacer clic en Aplicar no significa necesariamente que suceda, ni siquiera en / open / hard- o software. ¿Alguien bichos?
Aunque en este último caso tienen mayor probabilidad de ser encontrados y reparados.

(Me parece un tanto poético: los bitcoins están cambiando el mundo porque las personas se quejan con los creadores de redes de que sus bitcoins no se procesan lo suficientemente rápido)

Esto funciona con la premisa de que el cliente bitcoin-qt se adhiere a los estándares de QoS.
Que era el cliente de los carteles originales. (Lo confundí con un troll al principio)

Lo que parece hacer durante mucho tiempo.
A pesar de que el tráfico ha aumentado recientemente, mi enrutador al menos, amablemente, me permite ver mi "ted talk" a toda velocidad. ¿Limitando el tráfico de bitcoins? ¡Sí! Pero de acuerdo con el bit QoS, es decir. mi ancho de banda es mío.

En lugar de señalar a los desarrolladores que por una razón u otra su tráfico de bitcoins había aumentado (un acto en línea, supongo, ya lo saben, o él no pudo verificar) y proporcionarles al menos los detalles del sistema operativo y la versión del cliente. usado ... Nooooo ....

La funcionalidad inmediata ofrecida: estrangulamiento, asfixia. ¡Qué humano!

Esta "solución" ya se ha aplicado a clientes bittorrent.
utorrent (por nombrar uno) implementó su propio modelador de tráfico.
En lugar de quejarse a los fabricantes de enrutadores.

Si no hay, o solo unos pocos sembradores para esta "charla ted" que sólo desea ver en este momento (o dentro de ciertos límites), no hay "charla ted" para usted en este momento (o dentro de ciertos límites). O quizás nunca, la semilla está muerta.

Ahora sea honesto, ¿cuál es / su / proporción de participación general? ¿Limitó la carga? ¿Todavía siembras la "charla ted"?
¿Ciclas puertos? ¿Acepta solo conexiones cifradas, para que su proveedor no pueda rastrear el protocolo bittorent para mantener el ancho de banda alto? ¿Ha utilizado TOR? (aunque eso es ridículo: torrents sobre tor)

Esa es la consecuencia.
Bittorrent, lo hermoso que es, está lisiado solo por eso. No porque esté censurado.
(Estoy en Holanda y no puedo acceder a piratebay.com, pero DHT parece funcionar muy bien, pero recibo muchas "charlas ted" falsas).

Cada bitcoin es rastreable, hasta los primeros 50 (solo busque el bloque 0) y todos los demás bitcoins después de eso. (si tienes tiempo; las computadoras tienen)
No hay derechos de copia u otros derechos sobre el protocolo o los números que se envían.
Además, el tráfico BTC no puede, no puede ser limitado o bloqueado. Es legal o no ilegal.

No puedo dejar de admirar la estrofa de los desarrolladores de btc-core diciendo todo Douglas Adams-y: "Es el problema de otra persona".

Ok, y ahora el problema real:
¡Nadie te ha obligado a mantener el cliente en funcionamiento!
¿Acapara tu ancho de banda? ¡Para! Sin embargo, espere un retraso para verificar las transacciones recientes, para que sepa de dónde provienen sus monedas y, por lo tanto, pueda confiar en ellas.

No andas con la billetera abierta todo el día, ¿verdad? ¿Registrarte de dónde viene todo tu dinero?

Ah, y hágase esta pregunta "¿bitcoins a dinero o viceversa?"
De cualquier manera, deje de quejarse, aprenda a programar, implemente esta función en su bifurcación de bitcoin-qt.
Siéntese y vea cómo se implementa ... o no.

Entonces, y solo entonces, tienes derecho a quejarte, pero prepárate para la batalla. Tendrá que ser realmente convincente y capaz de explicar / por qué / estrangulamiento es bueno.

Como "nadrimajstor" optó: "(...) agregar argumento -nolisten"

Si no escuchas, no hay diálogo. Por lo tanto, sus transacciones son nulas.

: /

Einstein podría haber dicho:

• "Si puedes explicarle el problema a tu abuela, lo entenderás",

Si cree que ha aprendido algo:
1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB

Si crees que debería callarme:
15B4oqE6e2skviM67kSmAB3yp77GChjPnL

¡Gracias!

simeón peregrino dijo:
"en los EE. UU. teníamos un ancho de banda ilimitado, por lo que la carga no tenía sentido. Pero en el" resto del mundo "el ancho de banda no es gratuito",

Los bitcoins no son gratuitos ni carecen de sentido. Lee las noticias.

¿Por qué pones comillas alrededor de "resto del mundo"?

citando medio punto ["Con solo decir:" Y estoy bastante seguro de que la idea es no tener todos los servidores "rápidos" en unos pocos países (...) "
Tú dices mi punto.

Al limitar el ancho de banda de / your /, transfieres el trabajo a otros, que también limitarán el de ellos, etc.
Hasta que termines en el escenario del que estás bastante seguro, no es la idea.
Felicitaciones a usted."]

Usted hace un punto con perder mi punto, que si no estoy ejecutando un servidor, está en la misma posición. Repetí tu aumento para ayudar a aclarar mi punto, y acabas de ver tu aumento y pareces dejar de leer para comprender ...

Entonces, ¿es mejor tener servidores rápidos y más lentos, o solo rápidos?

Estoy de acuerdo en que QOS es la solución. El hecho de que el enrutador proporcionado por mi ISP no haga QOS y no quiero comprar un segundo enrutador para anidar detrás de él para hacer el QOS es mi problema.

Quizás la verdadera pregunta es: ¿Quiere que muchas personas ejecuten el cliente?

Si es así, hágales las cosas más fáciles. Si no, continúa.

Detuve al cliente porque a) no tengo QOS, b) estoy ocupado con mis propios proyectos de sistema operativo, yc) no me importa mucho, pero este proyecto, la relación entre el interés y el costo se ha vuelto demasiado alta.

Consigo que todo el sistema operativo resuelva sus propios problemas, o sea bastante. Supuse que Bitcoin quería un efecto de red, por lo que se podrían necesitar comentarios.

Lamento que no entendiste mi punto.

Pero aquí tienes una respuesta a la tuya.

Aunque no estoy seguro de si estas discusiones están permitidas en un hilo como este.

No importa si ejecuta el cliente o no.
Si desea intercambiar bitcoins, debe ejecutar el cliente.
Si no desea intercambiar bitcoins, no ejecute el cliente.

Usted pregunta:
"Quizás la verdadera pregunta es: ¿Quieres que muchas personas ejecuten el cliente?"

¿Qué no entiendes? Quiero que todos ejecuten el cliente, incluso más, ¡quiero que todo ejecute el cliente!
Quiero poder pagar con bitcoins y quiero una confirmación inmediata de mis pagos.

Sea o no el cliente, quiero que confirme mi transacción, como si estuviera allí. ¿Qué tiene eso de difícil?

Al ver el aumento de bitcoin, mucha gente parece querer eso también. Entonces, ¿por qué pospones o incluso niegas (no escuchas) eso?

Usted pregunta:
"Entonces, ¿es mejor tener servidores rápidos y más lentos, o solo rápidos?

Y he explicado repetidamente que no hay diferencia, que parece que no captas el concepto.

A veces se produce congestión, cuando hay muchas transacciones en curso.
¿Por qué las carreteras solo están congestionadas entre las 9 y las 5 (bueno, solo puedo hablar en nombre de Holanda, por supuesto)
La solución habitual son carreteras más grandes, pero eso no funciona, también se llenan.
Aquí la solución es ahogar la entrada de vehículos, pero eso solo desplaza el problema a las entradas.
Entonces ahora la congestión está en los pueblos (donde no debería estar, niños y todo eso). Y se tarda una eternidad en llegar a la autopista ... para usar un coloquialismo americano "¿Sabes a qué me refiero?")

Estoy seguro de que has notado el absurdo aumento en el valor de bitcoin.

Solo hay alrededor de 21.000.000 bitcoins

El problema del ancho de banda se resuelve solo. después de 2020, solo se está extrayendo billeteras perdidas.

No, la verdadera pelea es el tamaño de los bloques ...

Si todavía no me entiendes, explícame por qué quieres tu billetera en línea 24/24 sin pagar por ella.

Pero ten esto en cuenta.

Los bitcoins cuestan dinero, ¿alguna vez has intercambiado un bitcoin?

No creo que esta discusión sea productiva en este momento. Las mejores soluciones técnicas encuentran la manera de abordar las _necesidades_ de todos y, incluso si a veces me siento culpable por ello, es difícil llegar allí con un argumento de que sus deseos son estúpidos o incorrectos. Lo que se necesita aquí no es más debate, lo que se necesita es más implementación y pruebas, incluso si parte de la "implementación" es solo una buena copia para ayudar a las personas a comprender cómo pueden desempeñar un papel importante para mantener la red sana.

(Editar: eliminé una publicación de mimetica pidiendo fondos para callar)

Esto realmente no se puede resolver hasta que se solucione el sistema de descarga del historial, por lo que
que un solo cliente puede descargar de varios pares, estilo bittorrent. O
al menos permitiéndole detectar pares lentos y buscar mejores.

Quizás un método simple es evitar que un cliente cargue a más de
un par en cualquier momento de forma predeterminada puede hacer que las cosas sean menos problemáticas.

Todo el esfuerzo mental en este hilo debe cambiar para desarrollar un verdadero
Extensión del protocolo de descarga P2P.

El 11 de abril de 2013 a las 13:29, Gregory Maxwell [email protected] escribió:

No creo que esta discusión sea productiva en este momento. El mejor
Las soluciones técnicas encuentran la manera de abordar las _necesidades_ de todos y, incluso si
A veces me siento culpable por ello, es difícil llegar allí con un
argumento de que sus deseos son estúpidos o incorrectos. Lo que se necesita aquí no es más
debate, lo que se necesita es más implementación y pruebas, incluso si algunos de los
"implementación" es simplemente una buena copia para ayudar a las personas a comprender cómo pueden
juegan un papel importante en mantener la red sana.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Oh, ¿me enamoré del troll o no entiendes bitcoin en absoluto?

Quizás un método simple es evitar que un cliente cargue a más de un par en cualquier momento de manera predeterminada, lo que podría hacer que las cosas sean menos problemáticas.

....
No tengo nada mas que decir a tanta estupidez

Estás en un prado, las salidas son n, e, s, w
Hay mago, dice: "Ve al norte"

(su movimiento)

No soy estadounidense, pero sé que Jefferson dijo: El que sacrifica la libertad por la seguridad, no se merece ninguna de las dos.
¡Y estoy de acuerdo con eso!

perdón por gritar (fuera del tema)

(Editar: eliminé una publicación de mimetica pidiendo fondos para callar)

¡Mi palabra! ¡PUEDES LEER INCLUSO!

mEmetica

(Editar: eliminé una publicación de mimetica pidiendo fondos para callar)

Como es:
Si te gustan mis argumentos:
12345554335

difiere de
1dice9wVtrKZTBbAZqz1XiTmboYyvpD3t

Acabo de publicar un número, ¿cuándo estaba solicitando fondos?

Una respuesta podría ser "sí hombre, acabo de enviar trillones a eso".

¿Ver? grupo equivocado, gente equivocada.

¡Vosotros que no comprendéis la verdadera libertad si se les pega en la cara!

¡Bien! fornicarte!

(Editar: eliminé una publicación de mimetica pidiendo fondos para callar)

Whoohooo

Entonces, ¿qué es, no hay fondos para mí, cállate?
En la misma publicación pedí fondos si aprendiste algo,

Supongo que no lo hiciste

Todo el esfuerzo mental en este hilo debe cambiar para desarrollar una verdadera extensión de protocolo de descarga P2P.

¡Gracias robbak!

Pero, ¿a qué te refieres exactamente?

¿Qué es una "verdadera extensión de protocolo de descarga p2p"?

¿El que intimidas a los demás? MS lo ha estado haciendo durante años y, en cierto modo, parece funcionar.
Conoces las palabras de moda, pero lamentablemente no entiendes su significado.

¡Todos los esfuerzos mentales en este hilo deben detener este hilo!
No más aumento repentino en el tráfico saliente, ¡son solo bitcoins!
¡Déjalos ir!

Es curioso ... Entré en este hilo porque noté que mi nodo está usando _mucho_ ancho de banda de carga ... Entiendo que p2p tiende a hacer eso, especialmente porque más personas "necesitan" la información de la red ... pero esto también sucede cuando tienes _menos_ personas en la red (porque hay menos lugares desde donde descargar). Tengo una cuota de peso corporal mensual en la máquina en la que estoy ejecutando bitcoind.

Según tengo entendido, cuantos más nodos, más confiable es esta red (o es menos probable que algún individuo o institución pueda hacerse cargo de la red bitcoin controlando la mayoría de los nodos), puedo agregar QoS para limitar bitcoind (y lo haré , puedes apostar que lo haré), sin embargo, el usuario promedio simplemente no sabe cómo hacerlo. Agregar una configuración simple que limite el uso de bitcoind bw solo alentará a las personas a ejecutar el cliente ... por ahora, el demonio deja de funcionar hasta que tenga tiempo para configurar QoS, sin embargo, si tuviera una forma más simple de acelerarlo _ahora_, continuaría funcionando, 24 horas al día, 7 días a la semana.

No estoy muy interesado en las monedas en absoluto (escuché por primera vez sobre este proyecto hace varios años), simplemente encontré la idea interesante y asumí que agregar más nodos "honestos" a la red sería bueno ... aparentemente no te importa eso, solo quieres "unos pocos nodos rápidos" en lugar de _muchos_ nodos no tan rápidos. Creo que "cuanto más mejor" para este tipo de sistema ... pero tal vez me equivoque.

@soulhunter Parece haber un poco de confusión aquí.

Por supuesto que necesitamos muchos nodos si queremos un sistema descentralizado. Pero principalmente queremos muchos nodos que validen: la principal ventaja de Bitcoin sobre otras monedas (en mi opinión) es que no necesito confiar en nadie para saber que nadie está haciendo trampa. Si es más fácil ejecutar un nodo de este tipo, menos personas tendrán que hacerlo.

Sin embargo, para iniciar un nuevo nodo, se debe mostrar el historial del estado actual, de modo que también pueda evaluar de forma independiente que nada en el pasado haya sido fraudulento. Por lo tanto, necesitamos una forma de alimentarlos con este historial, y lo proporcionan otros nodos en la red que también en algunos tuvieron que descargar ese historial de todos modos. Idealmente, también tenemos tantos de estos como sea posible. Pero la realidad no es perfecta. No todo el mundo quiere sacrificar su upstream para hacer esto, mientras que otros tienen un montón de upstream de sobra. Y, con la implementación actual con errores, si accidentalmente está golpeando a un par lento para descargar, tendrá una descarga lenta. No tenemos un mecanismo para buscar buenos pares o paralelizar la descarga. Por lo tanto, siempre que no se mejore el mecanismo de sincronización, sí, todos están mejor con pocos cargadores más rápidos que muchos más lentos. Tenga en cuenta que se trata solo de proporcionar bloques históricos a otros: puede validar perfectamente todos los bloques y transacciones, y participar de otra manera en la red sin proporcionar ese servicio.

¿Entiendo correctamente que el historial NO se descarga de igual a igual? ¿Leí correctamente que se descargó de UN par? Si es así, eso explica todo el problema. Realmente necesita descargarse de igual a igual: ¿qué importa si solo tiene una carga de 10 kbit si hay otros 100 dentro de un radio de red razonable para extraer?

¿Estoy entendiendo correctamente? Porque eso marca la diferencia en el mundo.

@cjastram No estoy seguro de que lo entiendas correctamente. Si es así, está utilizando una definición muy extraña de peer to peer. Los bloques se descargan de un par al azar, pero actualmente todos se descargan de un par. (porque la forma en que funciona el proceso es básicamente un "dime lo que no tengo" en lugar de un "esto es lo que me falta").

Y sí, absolutamente esto debe mejorarse y es por eso que Pieter y yo decimos que si bien apoyamos tener todo tipo de perillas para controlar el uso de recursos, el comportamiento de búsqueda debe cambiar primero.

@gmaxwell Ya veo, supongo que lo leí correctamente. ¿Hay alguna forma de agregar ese problema como un bloqueo para este problema, por lo que es más claro que el otro debe hacerse primero?

+1 para agregar estrangulamiento. Bitcoin-qt acaba de apagar la red wifi de mi hogar y me tomó 20 minutos descubrir qué estaba pasando. El cliente estaba usando todo mi ancho de banda de carga disponible (1mb / s) y no pude usar la web. Eso es plátanos. Estoy feliz de contribuir con parte de mi ancho de banda, pero no con todo. No hay razón para que tenga que ser todo o nada.

Ya no puedo ejecutar el cliente completo excepto unas pocas horas a la semana debido a este problema. Este problema evitará que los usuarios domésticos o novatos ejecuten un cliente completo. Algo tan simple como (límite de carga de X kb / seg) debería ser suficiente.

@soundasleep ¿Ha desactivado la escucha de conexiones entrantes? De lo contrario, eso debería permitirle ejecutarlo con menos impacto hasta que haya otras instalaciones disponibles.

@gmaxwell, por lo que entiendo, eso solo reducirá la probabilidad de que mi conexión se sature, y con solo 0.8 Mbps de carga (que está mal formada, mal aprovisionada y estrangulada también) dudo que resuelva algo ya que un par podría fácilmente saturar eso . Lo intentaré, pero todavía no puedo ejecutar el cliente a tiempo completo.

luke-jr tiene toda la razón cuando dice "QoS es realmente un trabajo de enrutador, pero supongo que los enrutadores confiables no son demasiado comunes", esto es simplemente un hecho.

Los desarrolladores deben darse cuenta y corregir el problema lo antes posible para que todos los tipos de usuarios (muy bajos ~ muy altos) puedan seguir utilizando el programa sin salir de su zona de confort. Durante al menos 20 años, tal vez para entonces, todos en la Tierra tendrán un enrutador con un código QoS decente incorporado y también Internet de fibra para manejar todos los datos de rendimiento.

Pero en este momento, tal como está, es como una misión suicida en mi humilde opinión, esto me entristece, enoja y decepciona tanto al mismo tiempo que ni siquiera puedo explicar con palabras cómo me siento al respecto. Todo lo que sé es que la decisión de no parchearlo y dejarlo como está, es una decisión indignante.

El 02/05/13 23:42, soundasleep escribió:

Ya no puedo ejecutar el cliente completo excepto unas pocas horas a la semana porque
de este problema. Este problema evitará que los usuarios domésticos o novatos nunca
ejecutando un cliente completo. Algo tan simple como (límite de carga de X
kb / seg) debería ser suficiente.

Bueno, en realidad no tengo problemas para ejecutarlo en casa, algo de QoS es
suficiente ... sin embargo, mi problema está en el servidor, tengo un BW mensual
límite allí, y el cliente solo usará la velocidad de carga completa de 100 Mbps
siempre que quiera (!), estaría feliz de darle de 3 a 7 Mbps de carga
(de esa manera no puedo superar la cuota).

Ildefonso.

@XcaninoX tu respuesta es confusa e increíblemente irrespetuosa. No soy tu esclavo. Tener más opciones para esto en el futuro es bueno y está planeado, como se ha explicado una y otra vez pero no es baladí de implementar y por lo tanto esperará a alguien que tenga tiempo para trabajar en ello.

@soulhunter casi todo el ancho de banda se utiliza alimentando los datos históricos a los nodos recién iniciados. Por lo tanto, el consejo de desactivar la escucha si tiene limitaciones de ancho de banda para no hacer esto. Sin alimentar nuevos nodos, la utilización media máxima es del orden de 100 kbit / seg más o menos.

@gmaxwell Lo siento si te

@XcaninoX OK . No sé qué más se necesita abordar, básicamente todos están de acuerdo en que debería haber mejores controles de recursos. Pero estar de acuerdo en que deberían estar allí no hace que sucedan instantáneamente.

El 03/05/13 00:13, Gregory Maxwell escribió:

@soulhunter https://github.com/soulhunter casi todo el ancho de banda
se utiliza alimentando los datos históricos a los nodos recién iniciados. Por lo tanto
el consejo de deshabilitar la escucha si tiene limitaciones de ancho de banda, por lo que
que no harás esto. Sin alimentar nuevos nodos el promedio máximo
la utilización es del orden de 100 kbit / seg. más o menos.

Sí, pero aún así es necesario alimentar datos históricos, porque de lo contrario
¿Cómo se agregarían nuevos nodos? (esta es parte de la razón por la que estoy
ejecutar un cliente en un servidor, para mantenerlo activo las 24 horas del día, los 7 días de la semana y ayudar a la red).
Además, deshabilitar "entrante" no soluciona mágicamente eso, porque puede
todavía entrar en un nodo incompleto a través de una conexión saliente (aunque
la probabilidad se reduce considerablemente). De todos modos, hasta ahora, la cantidad de
BW que ha comido no es _ tan_ enorme (solo "puntiagudo"). Lo mantendré funcionando
durante unas semanas más y veamos (parece que usará
~ 500GB / mes, me lo puedo permitir, por ahora).

¿Por qué no implementar algo simple?

1. Agregue la opción de límite de BW de carga básica (hay varias formas de hacerlo)
   esto, no voy a dar más detalles ahora).
2. Cuando un cliente está descargando y tiene más de un par, debería
   descargar de un par determinado durante N segundos (digamos: N = 300), y luego pasar a
   el siguiente en un esquema por turnos (o incluso aleatorio). De esta manera un dado
   el cliente no se "atascará" en un único par lento, sino que probablemente se moverá
   de pares rápidos a lentos mientras se descarga y distribuye la carga de descarga.

¿Qué piensas?

Ildefonso.

Si uno imagina la cadena de bloques como un archivo torrent de más de 7GB, ¿hay algo que nos impida usar ideas de arquitectura bittorrent para arrancar clientes? @jgarzik ya implementó esta idea independientemente del cliente aquí . Supongo que inflar al cliente mediante la vinculación a libtransmission o similar no es aceptable (¿o lo sería?). Puede que tampoco sea seguro. Probablemente resuelva varios problemas asociados con el ancho de banda y la gestión del límite de datos.

Quizás, como experimento independiente, alguien (¿yo?) Debería intentar implementar un parche para responder solo a solicitudes de datos históricos más allá de una determinada fecha o número de bloque. Supongo que la mayoría de los compañeros están totalmente desactualizados (requieren el historial completo) o solo una semana o dos desactualizados. Absolutamente me lo estoy inventando, así que podría estar muy equivocado, pero parece una suposición razonable. Suponiendo que esto sea cierto, la mayoría de los pares podrían beneficiarse estableciendo un filtro de fecha hace un par de semanas y requerir que los nuevos pares recurran al torrente de Jeff Garzik o cualquier otro mecanismo que pueda estar disponible. No es útil para los nuevos clientes, pero podría facilitar el uso del ancho de banda.

En mi humilde opinión, esta debería ser una opción de configuración de GUI simple similar a las opciones para configurar tor, es decir, decidir si proporcionar una funcionalidad de red completa o una funcionalidad limitada. Si no se convierte en parte del cliente "principal", es probable que alguien proporcione una bifurcación que sí lo haga, y luego el cliente "principal" deberá atender la existencia de estos clientes alternativos, por ejemplo, atender a getblocks / getheaders ignorados. peticiones.

Yo tambien Estoy Teniendo Este Problema. Personalmente, no me importa en absoluto usar el manejo de esto por mi parte en lugar de que sea parte del protocolo bitcoin. Si alguien sabe qué puerto usa bitcoin, felizmente lo regularé. Utilizo Tomato como mi enrutador WiFi y estoy seguro de que tiene las funciones suficientes para proporcionar la funcionalidad para hacer esto, siempre que el puerto no sea el puerto 80, por supuesto, porque no voy a limitar el tráfico web estándar. solo por el bien de bitcoin, pero me sorprendería si ese fuera el caso.

No importa, simplemente busqué en Google y encontré la respuesta a mi propia pregunta en las preguntas frecuentes de bitcoin. Para cualquier otra persona que esté interesada, el puerto que usa Bitcoin es el puerto 8333. Si hay alguien más aquí usando Tomato, felizmente publicaré instrucciones para limitar este puerto una vez que averigüe cómo hacerlo. Avísame si hay algún interés.

El problema es que bitcoin hará conexiones salientes a cualquier puerto que un par pueda decir que está usando, por lo que 8333 captará la mayor parte del tráfico, pero no todo.

Podría ser posible detectar los puertos usando uPnP o algo ... Demasiado difícil, estoy esperando la funcionalidad del acelerador :)

bitcoin hará conexiones salientes a cualquier puerto que un par pueda decir que está usando

No, no lo hará. Solo probará pares que no sean 8333 si no tiene suerte al conectarse en 8333.

bitcoin will make outgoing connections to any port that a peer may say its using

No it won't. It will only try non 8333 peers if its having no luck connecting on 8333.

No he leído el código, así que no puedo comentar sobre lo que hace el cliente central de bitcoin, pero esto tendría más sentido que lo que dijo Slothbag. Especialmente porque el puerto que se está usando es lo que obtuve directamente de la wiki de bitcoin, creo que habrían dicho un poco más si quisieran decir "usa el puerto 8333 la mayor parte del tiempo".

Acelerar la velocidad de carga de bitcoind

Es gracioso y triste que no entiendan que ejecutar un nodo con un límite de ancho de banda de carga es mejor que no ejecutar un nodo. No ejecutar un nodo de Bitcoin parece ser la alternativa que prefieren los desarrolladores y estoy de acuerdo con no hacerlo.

Considere esto: tiene una fibra y ADSL y ejecuta tor, i2p, un cliente bittorrent y quizás algunas otras cosas. Todas estas cosas, básicamente todo el software SANE P2P, le permiten establecer un límite de ancho de banda de carga para que pueda navegar por la web y hacer otras cosas con su conexión normalmente. Luego tienes bitcoind que básicamente intenta usar el 100% de tu conexión y hace que todo lo demás se detenga. La mayoría de la gente simplemente verá bitcoind como algo que carece de las características más básicas que tiene el resto del software P2P (capacidad para configurar el puerto, limitar el número de conexiones, ancho de banda, etc.) y no ejecutarlo.

Veo que este error tiene 3 años. Volveré a verificar en 3 años para ver si los desarrolladores que argumentan en contra de la limitación del ancho de banda han descubierto que tener muchos nodos con un límite de ancho de banda es mejor que tener solo unos pocos nodos de alto ancho de banda con conexiones dedicadas para entonces. Supongo que no lo harán, pero uno puede esperar.

@oyvinds Parece que he

@gmaxwell Snark no es productivo. Pero me ha inspirado a responder.

No entiendo por qué esto es tan difícil de parchear. Permítanme intentar ser útil y pragmático.

No se necesitan controles detallados sobre el ancho de banda de carga. Solo un control deslizante que nos permitiría agregar un "sueño" entre cada envío de un paquete. El control deslizante nos permitiría aumentar la duración del sueño. Esto proporcionaría una limitación de velocidad burda pero eficaz sin requerir mucho tiempo de desarrollo. ¿Qué es eso, como una hora de desarrollo para solucionar el problema n. ° 1 que impide que las personas ejecuten bitcoind?

@ dwest-trulia Por favor lea los mensajes de mí y de otras personas experimentadas con el protocolo Bitcoin en el hilo, esto se ha cubierto anteriormente. Gracias.

@gmaxwell Busqué en el hilo la palabra "dormir" y no

Apagar la escucha es bastante confiable, ya que los nodos a los que nos estamos conectando ya tienen la cadena de bloques. No hubo ningún argumento filosófico en absoluto, nadie se opone a la limitación de tasas sobre una base filosófica. Pero debido a la forma en que funciona actualmente el protocolo Bitcoin, el DOS ataca severamente a sus pares. Es mejor que no se conecten contigo en este momento, aunque eso se está arreglando.

@gmaxwell No sabía que había un problema potencial de DOS. Interesante.

Nadie está en contra de las conexiones que limitan la velocidad como tales.

El problema es que el mecanismo de búsqueda actual es bastante estúpido y, por lo general, se ocupa muy mal de la limitación. Entonces, hasta que se solucione, sí, creo que no ejecutar un nodo (accesible) es mejor que ejecutar uno acelerado.

Cuando hayamos arreglado el algoritmo de sincronización (ver # 3077, # 3083, # 3087, # 3276, # 3370, # 3514, # 3884 para trabajar en eso, así como la versión anterior # 2964), con gusto ACK cualquier parche para mejorar la configuración del ancho de banda en bitcoind.

@gmaxwell

Si tiene problemas con el uso de inmediato, puede establecer listen = 0

No ayuda. En una conexión de 8/1 Mbps (abajo / arriba), bitcoin-qt haría el DoS al cargar tantas cosas que el sistema ya no tenía Internet. Ninguno en absoluto. Los pings no se retrasarían; simplemente se agotó el tiempo. Servicios como LogMeIn informaron que ya no había conectividad a Internet y la navegación se volvió básicamente imposible.

En este momento, un año después de mis comentarios anteriores aquí, tengo una conexión de fibra e incluso con listen = 1 todo funciona bien, pero no fue agradable tener que ejecutar bitcoin-qt (para ponerse al día con la cadena) exclusivamente mientras el resto de mi familia dormía.

@ lucb1e Es lamentable que no ofreciera esa observación mientras aún tenía la configuración para reproducirla. No puedo reproducir y tengo varios nodos listen = 0 para realizar pruebas y ninguno ve un uso elevado de ancho de banda.

@gmaxwell Sí, debería haberlo señalado antes. Pensé que recordaba haber comentado que bitcoin-qt mató su propia conexión, pero parece que no lo recuerdo. Lo siento por eso. Sin embargo, lo que dije sigue siendo válido: incluso distribuir bloques a medida que avanzan a través de la red es una gran cantidad de datos.

Mirando blockchain.info en este momento, hace 20 minutos había un bloque de 0.9MB. Times 7 (un compañero ya debe tenerlo) realiza una carga de 6 MB. En mi conexión anterior, eso causaría poco más de 1 minuto sin Internet.

Al repasar estos números, está bastante claro que ejecutar un nodo bitcoin completo en una conexión de este tipo simplemente no ayudará a nadie. Pero no necesito ser un nodo completo, solo quiero ejecutar el cliente de bitcoin oficial (o quizás debería decir "líder en general") con mi propia cadena de bloques. Sería útil tener un interruptor para no cargar bloques y / o no cargar transacciones. Se dice que esto causa problemas de DoS, pero yo diría que es un problema en este cliente y no un problema de red: cualquiera puede configurar y anunciar muchos nodos deshonestos que nunca hacen nada. Los nodos que no escuchan deben desconectar a los pares que parecen estar solo chupando porque podrían estar tratando de ralentizar o perturbar la red.

En lugar de limitar la velocidad de las conexiones entrantes (lo que generaría una mala experiencia de sincronización para otros usuarios), ¿sería factible establecer un límite diario y no aceptar más conexiones una vez que se alcanza el límite? Esto me permitiría ser un nodo totalmente participante algunas veces y evitaría activar la política de limitación de "uso justo" de mi ISP.

Mi preferencia sería algo como esto:

Nodo completo: sirve a todos los bloques históricos
Nodo abierto: sirve los últimos 1008 bloques
Nodo cerrado: No sirve bloques.

Me cansé de superar mi límite de datos de 300 GB por mes que sirven bloques de bitcoind, por lo que busqué una forma de limitar la tasa de bitcoind. Nunca encontré una buena solución.

Dado que los desarrolladores aún no nos han dado la capacidad de limitar la tasa en el demonio, decidí usar iptables para imponer un límite. En caso de que ayude a alguien más, las reglas a continuación son las que utilicé. Es muy doloroso actualizar después de estar desconectado por un tiempo, pero funciona bien una vez que está sincronizado.

// Límite de tasa de bitcoind saliente (tenemos que obtener los puertos de origen y destino 8333)
-A SALIDA -p tcp --sport 8333 -m state --state ESTABLISHED -m limit --limit 30 / sec --limit-burst 150 -j ACEPTAR
-A SALIDA -p tcp --sport 8333 -m estado --estado ESTABLECIDO -j CAÍDA
-A SALIDA -p tcp --dport 8333 -m estado --estado ESTABLECIDO -m límite - límite 30 / seg - límite-ráfaga 150 -j ACEPTAR
-A SALIDA -p tcp --dport 8333 -m estado --estado ESTABLECIDO -j CAÍDA

Estás causando ese mismo rendimiento doloroso a cualquier otro usuario que se sincronice contigo, así que asegúrate de establecer listen = 0 cuando ejecutes de esa manera.

@Ratief Estás reinventando la rueda, ya tenemos un script para eso en contrib / qos / tc.sh durante un año.

Si hubiera una palanca para deshabilitar los bloques de servicio a cualquier persona> 20 atrás, ¿no funcionaría? Entonces, los pares nunca intentarían sincronizarse con un nodo lento y un nodo lento no saturaría su flujo ascendente.

@darkhosis En este momento, si alguien elige un nodo de sincronización que se niega a servir bloques, el nodo que intenta sincronizar no se sincronizará por completo. Necesitamos algo de código escrito que pasará al siguiente par para sincronizar. Creo que @sipa está trabajando en eso primero en los encabezados (pero podría estar equivocado).

Quizás sería bueno que los compañeros con aceleradores configurados informaran eso, y los que no lo tienen para medir su velocidad efectiva para informar. Luego, los pares obtienen un poco más de información para usar al elegir un nodo de sincronización ...

@ luke-jr headersfirst solo busca desde donde puede y debería lidiar relativamente bien con los pares que se estancan, por lo que después de implementar HF, estoy bien con una función como esta.

@sipa La idea de enviar bloques no considerados "históricos" parece una buena solución. Los llamaré servidores de luz. Quizás en función de los límites de ancho de banda deseados de los servidores ligeros, se podría establecer la distancia hacia atrás en el tiempo de bloqueo que se cargará a los pares sincronizados

Por ejemplo:
El usuario A con 'servidor ligero' seleccionado que quiera dedicar una cantidad mínima de su ancho de banda ascendente retrocederá solo al bloque que tiene un tiempo de bloqueo 7 días antes de su último bloque.

El usuario B con 'servidor ligero' también habilitado, pero dispuesto a donar un poco más de ancho de banda (pero no sincronizar toda la cadena de bloques) puede sincronizar bloques hasta un tiempo de bloqueo de 30 días antes del tiempo de bloqueo actual.

De esa manera, no hay una velocidad límite de conexión real que haga que un nodo se bloquee al sincronizarse desde un nodo lento.

Actualización: esto requeriría la capacidad de los nodos para cambiar a otro nodo de sincronización sin fallar

El problema es que el mecanismo de búsqueda actual es bastante estúpido y, por lo general, se ocupa muy mal de la limitación. Entonces, hasta que se solucione, sí, creo que no ejecutar un nodo (accesible) es mejor que ejecutar uno acelerado.

-

Estás causando ese mismo rendimiento doloroso a cualquier otro usuario que se sincronice contigo, así que asegúrate de establecer listen = 0 cuando ejecutes de esa manera.

¿No se ejecuta un nodo en una conexión lenta como una "estrangulada"?
Digamos que tenemos 2 nodos: A ejecutándose en una conexión de 1 Mbps y B en una de 1 Gbps. Incluso con un límite de ancho de banda en B (como 100 Mbps), ¡es mejor sincronizar desde B que desde A!
Además, ¿no sería mejor para un nodo limitar su carga al 90% para evitar la saturación? (paquetes de reconocimiento, etc.). ¿Quizás el nodo A funcionaría mejor con un acelerador de 900 Kbps (y otro usuario sería capaz de navegar por la web)?

Por último, tener este tipo de visualización sería una forma de "anunciar" la velocidad de su nodo a otros y dejar que decidan sincronizarse (o no) con usted.

La limitación en un nivel muy básico de comandos de red probablemente sería una mala idea y ya se puede hacer con software y hardware (enrutador / iptables, etc.).
El estrangulamiento también resultaría incómodo para el nodo del otro extremo.

Lo que la mayoría de los operadores de nodos completos deberían hacer feliz sería una forma de no servir bloques históricos cuando se alcanzan ciertas condiciones previas. Estoy bastante seguro de que las quejas en las que los usuarios obtuvieron un tráfico saliente muy alto se debieron a que sus nodos servían muchos bloques históricos a los nodos en la sincronización inicial.

Me gustaría implementar una función que permita establecer un límite total por día y, si se alcanza, ya no serviría a los nodos que soliciten bloques <self.height-100 (TBD). El nodo conectado podría entonces cambiar a un nodo diferente. Limitar las respuestas block sería una mala idea, en mi opinión.

También estoy buscando una buena forma de limitar las respuestas de merkleblock .

El primer paso hacia esto fue implementado por @jonasschnelli en # 6622, que establece un límite de carga por período de tiempo.
Una vez que el nuevo código P2P de @theuni esté terminado, se puede comenzar a trabajar hacia la

@laanwj Un límite de carga por ASN también podría ser una característica útil: ayudaría a distribuir la cadena de bloques de manera más justa en lugar de permitir que un ASN agote toda la asignación. Además, el uso de ASN para calcular el desalojo de pares sería un buen paso hacia la protección contra los pantanos.

Sí, el uso de ASN tiene sentido para algunas cosas, incluidos los desalojos y la limitación. Aunque el problema práctico que surgió la última vez es que la base de datos ASN es demasiado grande para incluirla tal cual. Sin embargo, tal vez podría aproximarse / codificarse de alguna manera eficiente para realizar consultas. O tal vez dejar que el usuario lo descargue y hacerlo opcional.

@laanwj oh, había pensado que la lógica de selección de nodos de salida ya estaba usando ASN, pero tal vez no; sin embargo, hay algo allí para "extender" la red más ampliamente, tal vez valga la pena mirar más de cerca la lógica para ver si es adecuado para ser usado en ausencia de una base de datos ASN real.

Creo que el nuevo código de sincronización hace un mejor trabajo al distribuir la carga entre pares. El estrangulamiento debería ser un problema menor ahora.

@earonesty parece que todavía lo es.

Técnicamente, este problema se ha solucionado con la adición del parámetro de configuración "maxuploadtarget". Sin embargo, no estoy seguro de si ese parámetro se ha expuesto en la GUI.

maxuploadtarget aún no ha sido expuesto a la GUI.
Además, una vez que tengamos libevent para la capa p2p, la limitación de la red debería ser una fruta madura.
Aunque, personalmente, creo que la regulación de la red debe hacerse a una capa más profunda que la capa de la aplicación (nivel de enrutador), ya que la aplicación no sabe qué más, ejecutarse en la misma red, requiere ancho de banda.

Estoy usando la v5.9.6 todavía sin control de pares, como alguien dijo que hay software y enrutadores que pueden controlar el tráfico en una red, pero descubrí que la cantidad de conexiones parece ser el problema, Bitcoin parece abrirse a muchas conexiones, por lo que ni siquiera Internet Explorer puede mostrar una página web,
Buscando en las pestañas, encontré Vista general, Enviar, Recibir y Transacciones. ¿Existe una amenaza de vincular el programa con el torrent del cliente, integrarlo o algo así? en otro para controlar este tipo de cosas que realmente no son del interés de bitcoin?

@jlopp maxuploadtarget no resuelve el problema del pico de ancho de banda. Ya existen soluciones para este problema, por ejemplo, NAFC , que cuenta con el apoyo de eMule hace años. Pero claro, NAFC tiene sus propias limitaciones, no puede saber qué están haciendo otros dispositivos que comparten la misma conexión a Internet.

Hace mucho tiempo comencé a ver este hilo con la esperanza de que algún día alguien agregara opciones para esto. Mientras tanto, encontré mi propia solución. Utilizo iptables y limito la velocidad de las conexiones. Esto funciona bien para mi.

Estoy en Ubuntu. Agregué esto a /etc/ufw/before.rules. Ajústelo como mejor le parezca.

Límite de tasa de bitcoin

-A ufw-before-output -p tcp --sport 8333 -m state --state ESTABLISHED -m limit --limit 30 / sec --limit-burst 150 -j ACCEPT
-A ufw-before-output -p tcp --sport 8333 -m state --state ESTABLISHED -j DROP
-A ufw-before-output -p tcp --dport 8333 -m state --state ESTABLISHED -m limit --limit 30 / sec --limit-burst 150 -j ACCEPT
-A ufw-before-output -p tcp --dport 8333 -m state --state ESTABLISHED -j DROP

(Desafortunadamente, sin poder comprender el contexto completo de lo que había escrito, y sin poder verificar las contribuciones significativas que hice y sigo haciendo a los proyectos de código abierto, mi nombre de usuario está etiquetado como exigente, de carga gratuita, y grosero en la siguiente publicación. Un intento de usar el humor para disipar la incomodidad de recibir una reprimenda personal a una investigación no personal no logró ganarse los corazones de los controladores de este problema abierto de github de ocho años. Me pregunto si esta actualización que estoy haciendo actualmente también será condenada o censurada. Hay muchos ejemplos estelares para ser considerados de desarrolladores que responden con elegancia y sin presunción a las consultas humildes y mal escritas de nuevos usuarios que no tienen publicaciones registradas con un proyecto determinado. ; del cual he sido el beneficiario personal, y por lo tanto me queda la opción a) exponer, b) responder adecuadamente oc) retirarme sin sentirme atacado personalmente)

@Hypocritus No se ha implementado porque nadie hizo el trabajo de implementación, así de simple, así es como funciona en proyectos de código abierto. Simplemente no puede exigir que otros dediquen tiempo a implementar las cosas que desea de forma gratuita. Es increíblemente grosero.

wow, un hilo de este tipo y antiguo se siente un poco estúpido incluso para publicar, pero sigue siendo el mismo problema aquí, mi Internet se ve perturbado al ejecutar un nodo de bitcoin. Me siento muy convencido de contribuir de nuevo a bitcoin pero al mismo tiempo no quiero renunciar a un rendimiento significativo de mi conexión a Internet, por lo que, con desgana, otro ha establecido el listen = 0, desearía que hubiera opciones.
:(

Acordado. Un problema clave es que en el proceso de un nodo completo sin restricciones, hay algunas llamadas diferentes que realizan el cliente y sus pares al sistema o la red bitcoin, cualquiera de las cuales o una serie de las cuales podría estar causando un problema. el rendimiento disminuye, se atasca o se bloquea en una variedad casi infinita de formas en la máquina host.

¿Debería encontrarse una solución generalmente discreta e intuitiva para este problema? Sería bueno si a) este problema se cerrara (en beneficio de los laicos más densos que no podemos leer entre líneas), yb) esa solución se citara regularmente para aliviar a aquellos de nosotros que genuinamente y aprecian con entusiasmo poder dedicar más tiempo a construir o crear, en lugar de reducir, buscar o defender (aunque sean pobres) los intentos de llamar la atención sobre un problema persistente e impactante.

Y si hubiera una razón sólida para mantener esta característica como "necesaria", como argumentos sólidos sobre la integridad o seguridad de bitcoin, entonces nos beneficiaría que esas razones se citen, publiquen o vinculen regularmente, y que este problema se cierre.