+1 para isso!

Bitcoin está usando toda a minha velocidade de upload, o que na verdade significa que às vezes nem consigo navegar! Fechar o BitCoin resolve o problema, mas não é muito benéfico para a rede ...

+1 também.

Tenho um limite de upload de 60 KB / s em meu ADSL e o bitcoin.exe está matando tanto meu upload que às vezes não consigo navegar muito bem na Internet. Algumas informações extras:

Normalmente tenho cerca de 32 conexões em bitcoin. Receber parece estar bem. Após 10 minutos, as conexões bitcoin.exe atuais baixaram cerca de 100kB cada, mas o download geralmente não é tão limitado quanto o upload.

Após cerca de 10 minutos, as conexões bitcoin.exe atuais usam cerca de 100kB de upload cada, mas existem ~ 3 que usam ~ 1 MB +. Isso chega a mais de 10kB / s em média (não muito na média). Mas eu suspeito que quando esses caras de 1 MB + estão indo, ele usa 100% do upload e cai para a média de 7,5kB / s depois que essa parte é feita.

De preferência, gostaria de limitar o upload de 2kB / sa 5kB / s na minha conexão atual.

EDIT: Estou usando bitcoin 0.3.24-beta

Hospedei um nó bitcoin público 24 horas por dia, 7 dias por semana, por mais de um ano, no meu servidor Linux doméstico. Isso está me causando uma perda considerável de pacotes na linha e está piorando com o tempo, conforme a cadeia aumenta. Por favor, adicione limitação de largura de banda ao bitcoind. Caso contrário, terei que desligar o nó, porque minha conexão com a Internet está ficando inutilizável.

QoS é realmente um trabalho de roteador, mas acho que roteadores confiáveis ​​não são muito comuns: /

mais um +1, também precisando disso, ou uma maneira de fazer com que o bitcoind use um blockchain compartilhado (consulte http://bitcoin.stackexchange.com/questions/3199/read-only-blockchain-in-bitcoind-patch-ideas e https : //bitcointalk.org/index.php? topic = 71542), ainda melhor do que apenas acelerar imho

Além disso, esperando por uma opção no bitcoind, você pode dar uma olhada em 3 ferramentas de limitação de largura de banda do espaço do usuário: http://monkey.org/~marius/pages/?page=trickle , http://klicman.org/throttle/ e http : //stromberg.dnsalias.org/~strombrg/slowdown/

Não há + 1s aqui, por favor. Acho que todos concordamos que é uma boa ideia que um programa P2P tenha limites configuráveis.

Não é realista exigir que as pessoas movam isso para um roteador. Especialmente em um VPS, você não tem muito controle sobre o roteamento.

No entanto, esse recurso atualmente não tem prioridade para os desenvolvedores principais. Se você quiser acelerar esse problema, ajude na implementação.

Edit: e eu sugiro experimentar thin clients como Electrum, que afirmam usar muito menos largura de banda e 'compartilhar' uma cadeia de blocos em um supernó.

Talvez não relacionado, mas vocês podem (para Windows) experimentar o cFosSpeed ​​se sua conexão ficar lenta por causa de uploads.

Para o MS Windows, posso sugerir o NetLimiter como um bom software, embora comercial. Eu teria pensado que o Linux tem várias opções de QoS disponíveis, não é?

Quando você usa um aplicativo P2P (por exemplo, cliente de torrent), sempre é apresentado algum tipo de informação e / ou opções de personalização em relação à natureza da comunicação P2P e seu consumo de largura de banda.
Com o cliente BitCoin, isso não é tão óbvio e me leva a uma falsa crença de que o BitCoin não é pesado no tráfego de rede.
O consumo esporádico de internet sempre foi atribuído a um ISP instável, até que descobri que o culpado era o cliente BitCoin (preenchendo toda a largura de banda de upload).
Para o benefício de usuários menos experientes em tecnologia, faça uma opção óbvia e fácil de, pelo menos, adicionar o argumento -nolisten ao iniciar o cliente.

problema foi criado 2 malditos anos atrás. O que está acontecendo, pessoal de desenvolvimento? Por que isso ainda não foi corrigido? Vocês não veem a necessidade urgente desse recurso?

é tão estúpido não implementar isso o mais rápido possível porque dá uma má aparência a todo o aplicativo e à comunidade, já que estraga a internet das pessoas, e muitas delas não gostam de coisas técnicas, o que basicamente significa programa ruim -> desinstalação. .

Você não entende como o desenvolvimento de código aberto funciona. Trabalhamos nisso em nosso
tempo livre, então decidimos por nós mesmos o que é importante e queremos gastar
tempo ligado.

Se você quer que algo seja mal implementado, é _seu_
responsabilidade de fazer isso acontecer, não nossa.

Você pode contribuir para resolver esse problema?

Ou você está disposto a pagar para ter o recurso implementado? Você poderia oferecer
uma recompensa.

Não vejo, fwiw, uma necessidade urgente de tal recurso - e até que alguns componentes extras sejam desenvolvidos, tal recurso seria prejudicial para a rede: se você definir um acelerador baixo, seus colegas precisam mudar para puxar blocos de outra pessoa quando você é lento. (Também um problema de ausência do acelerador, mas muitas pessoas ajustando o acelerador o tornariam pior)

No momento, é melhor para nós de tráfego restrito apenas desabilitar a escuta. Isso terá em grande parte o efeito desejado, não corre o risco de adicionar problemas e é uma opção já disponível.

Acho que o problema aqui é muito mais do que não ser óbvio para um novo usuário que, por padrão, seu nó fornecerá blocos para a rede. Desativar a escuta realmente resolveria isso, mas está longe de ser óbvio.

Se eu não encaminhar minha porta, os outros clientes não poderão fazer download de mim? O cliente faz conexões de saída para receber blocos. No BitTorrent, as conexões de saída também são usadas para upload, ao que parece, e faz sentido porque mantém a rede muito mais ativa. O Bitcoin faz o mesmo, carrega blocos para nós conectados se você não fez o portforward?

Os nós não se anunciam como aceitando conexões até que sejam quase todos capturados ... então, você só estaria encaminhando em novos blocos, o que não é uma quantidade enorme de dados.

Estou preso à cadeia de blocos, esse não é o problema aqui. Mas eu estaria encaminhando novos blocos para pares conectados, independentemente de minha porta ser encaminhada. Porque isso pode resultar em um trabalho de upload de 1,5 MB para um novo bloco, se todos os nós conectados ainda não tiverem o novo bloco.

"Os nós não se anunciam como aceitando conexões até que sejam quase todos capturados ... então, você só estaria encaminhando em novos blocos, o que não é uma quantidade enorme de dados."

No entanto, satura meu uplink. Estou usando DSL sem outras opções e é um upload sólido de 50-70 kilobytes (não kilobit), tornando a conexão completamente inutilizável para qualquer outra coisa. Algum dia, o Google Fiber me trará um cachimbo gordo gigante e isso não será uma preocupação, mas como moro em uma área bastante rural, isso não será provável por um tempo.

Essa falta de controle de upload prejudica a rede porque eu desligo todo o nó completamente, a menos que esteja realmente envolvido em uma transação. Não seria melhor ter um nó lento do que nenhum nó?

Parece que os desenvolvedores acham que todo mundo tem googlefiber, isso é uma pena, realmente, existem X tipos de serviços de internet ao redor do mundo com Y limites de upload / download. Forçar o usuário a fazer algo que irá prejudicar sua própria internet é uma decisão ultrajante.

Sem falar que, uma vez que o usuário descobre o que está martelando sua internet, a decisão mais comum é matar o programa que está causando o problema e abandoná-lo, ou usá-lo o mais baixo possível, torna-se uma coisa ruim ao invés de uma boa coisa. Este é um marketing ruim. Isso me decepciona de muitas maneiras.

Como vou recomendar isso a um amigo sabendo que mais tarde o mesmo amigo virá até mim e dirá "ei lembra daquele programa que você me disse para usar? Estava bagunçando a minha internet, tornando-a muito lenta, não conseguia nem veja um vídeo utube em partes, bad call dud ". Isso é o mínimo que poderia acontecer, e este é apenas um exemplo simples.

Como o cjastram acabou de apontar, é melhor TER um nó lento do que NENHUM nó. Se os desenvolvedores fossem inteligentes o suficiente para criar um código tão futurístico e avançado, tenho certeza de que eles já sabem tudo o que estamos apontando aqui, sem mais palavras, acabou.

@XcaninoX então, você está dizendo que desligou a escuta conforme recomendado e está usando saída de 70kbytes / s?

Pessoalmente, acho que a limitação de upload no estado em que se encontra é uma má ideia, pelo menos até melhorarmos o mecanismo de sincronização de bloqueio. Se acontecer de você atingir um nó regulado durante a sincronização, a sincronização será lenta.

Em vez disso, acho que precisamos de um modo "não servidor" (alguma caixa de seleção, talvez solicitada na primeira inicialização), que desativa os blocos de veiculação (históricos), desativa a escuta (por padrão) e desativa NODE_NETWORK (para que os nós não se anunciem como completos não). Isso significa que as pessoas ainda podem fazer a parte de validação e retransmissão de ser um nó completo, mas sem as implicações de largura de banda de servir a cadeia completa.

Posteriormente, esse modo não servidor pode ser transformado em um modo de poda, onde os blocos históricos nem mesmo são mantidos no disco.

Pessoalmente, acho que a limitação de upload no estado em que se encontra é uma má ideia, pelo menos até melhorarmos o mecanismo de sincronização de bloqueio. Se acontecer de você atingir um nó regulado durante a sincronização, a sincronização será lenta.

Claro, mas a sincronização não é lenta se você atinge um nó com largura de banda limitada? Você não consegue magicamente uma sincronização rápida só porque não permite que os nós tenham a capacidade de aceleração. O problema é que se você não permitir a limitação, você receberá _nenhum_ nó porque as pessoas simplesmente o desligam.

Depois de um tempo com as pessoas simplesmente desligando-o, você começa a obter uma carga de sincronização massiva no sistema porque as pessoas precisam sincronizar centenas (ou milhares) de blocos sempre que desejam fazer uma transação BTC. Em vez da carga de sincronização leve que acontece em tempo real, você tem um número pequeno (mas significativo) de pessoas que exigem muita largura de banda de uma vez.

Daí o problema. Se pudéssemos apenas deixar o BitCoin ligado com largura de banda baixa, não teríamos o problema de sincronização.

Em vez disso, acho que precisamos de um modo "não servidor" (alguma caixa de seleção, talvez solicitada na primeira inicialização), que desativa os blocos de veiculação (históricos), desativa a escuta (por padrão) e desativa NODE_NETWORK (para que os nós não se anunciem como completos não). Isso significa que as pessoas ainda podem fazer a parte de validação e retransmissão de ser um nó completo, mas sem as implicações de largura de banda de servir a cadeia completa.

Pode ser. Eu não sei qual é a saturação da minha largura de banda de upload, se são confirmações de transações ou sincronizações de bloco de outras pessoas.

Posteriormente, esse modo não servidor pode ser transformado em um modo de poda, onde os blocos históricos nem mesmo são mantidos no disco.

Vamos tentar não exagerar na engenharia de uma solução mais simples?

@cjastram Esse é realmente o meu ponto: eu acho que é melhor para as pessoas que não podem ou não querem servir blocos históricos não fazer isso de forma alguma, e nem mesmo anunciar na rede que fazem. Se habilitarmos a aceleração da largura de banda sem isso, a chance de atingir acidentalmente um nó lento aumentará, ao passo que, se removermos esses nós do pool, a chance disso diminuirá.

As pessoas fecham totalmente os nós porque isso satura o link de dados, é claro que é ruim. Limitar ou desabilitar a veiculação melhoraria isso, mas você está perto dos recursos que deseja gastar, talvez não deva executar um nó completo em primeiro lugar.

Apenas a retransmissão de novas transações e blocos costuma ter uma largura de banda bem baixa - é apenas quando você é atingido por um nó que está sincronizando do zero que de repente ocorre uma explosão de upload.

Sobre engenharia excessiva: a capacidade de executar um nó podado é uma evolução inevitável em algum lugar no futuro, na minha opinião, e também implicaria em uma solução para o seu problema de qualquer maneira.

FWIW, eu discordo respeitosamente, e acho que a solução mais fácil é oferecer um acelerador de upload opcional (ou seja, enviar ou gravar syscall). Um acelerador de download é menos útil: você não pode realmente controlar a quantidade de dados remotos de entrada; interromper a leitura (2) fará com que os mocinhos acelerem eventualmente, mas os bandidos sempre têm uma ou três técnicas que inundam o que está entrando de qualquer maneira. E em campo, os usuários se preocupam menos em limitar a velocidade de download do que em limitar a velocidade de upload.

É um botão comum em outros aplicativos de serviço de dados P2P, então eu ACK um acelerador de upload implementado corretamente com botão.

@jgarzik Meu ponto é que atualmente estamos melhor com menos nós de serviço, se isso significar que esses nós são mais rápidos. Uma vez que temos os cabeçalhos primeiro e a busca em cadeia paralela, as coisas são diferentes e, provavelmente, qualquer pessoa que queira contribuir com um pouco de upload é útil.

OP aqui, já faz um tempo desde a criação deste problema e nos últimos 2 anos meu cliente bitcoin-qt raramente maximizou meu upload, então não pensei muito sobre isso.

Mas recentemente, no último mês ou dois, percebi que meu upload ou envio de dados costuma estar completamente no máximo! Eu tenho uma conexão decente, algo como upload de 300-500 KB / s. Felizmente, consegui detectá-lo na maioria das vezes e abri uma ferramenta de monitoramento de rede e matei as portas em questão (sempre bitcoin-qt). Eu tenho que ter cuidado porque se ele rodasse nessa velocidade por um longo período de tempo, não apenas minha rede ficaria lenta, mas rapidamente consumirá minha cota de dados.

Portanto, agora, em vez de executar um nó completo por ~ 8 horas por dia, deixo-o sincronizar com a rede e, em seguida, desligue-o.

Se eu tivesse uma opção de aceleração, eu definiria algo como 50 KB / s de upload .. isso é mais rápido do que eu já usei ao baixar os blocos mais recentes (limite da CPU).

Acho que isso é um problema, gostaria de executar um nó completo, mas não o farei enquanto ele consome 100% do meu upload na maior parte do tempo.

@slothbag Você desabilitou a escuta?

Não, não tenho. Na verdade, gostaria de contribuir como um nó de escuta completo.
Se vou desativar a escuta, é melhor não me incomodar e deixar
ele sincroniza e, em seguida, fecha-o.

Na quarta-feira, 6 de março de 2013, Gregory Maxwell escreveu:

@slothbag https://github.com/slothbag Você desabilitou a escuta?

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/bitcoin/bitcoin/issues/273#issuecomment -14491575
.

@slothbag Como um nó que não escuta, você ainda contribui com a rede - validando e encaminhando transações e novos blocos, evitando o particionamento ... mas não usará muita largura de banda. Um limite de taxa ao servir blocos históricos seria muito prejudicial para a rede agora; na verdade, é melhor que você não execute um nó do que servir blocos históricos com um limite de taxa. ... mas melhor ainda correr sem ouvir.

Eu tinha entendido que o fato de um nó ouvir ou não não estava relacionado ao fato de carregar blocos ou não. Mesmo um nó que não está escutando carregará blocos se um nó conectado os solicitar, não é?

Em vez de limitar a velocidade de upload do bloco, o que poderia ser melhor seria que os nós identificassem se são provedores de bloco ou não na primeira conexão. Um limitador de velocidade não é uma opção ruim, desde que o limite de velocidade não seja muito baixo - afinal, ainda haverá nós na rede em redes lentas e sempre será o caso.

Para quem deseja reduzir o impacto de seu cliente bitcoin-qt, criei uma correção rápida, que minimiza o tráfego enquanto estou usando uma rede wi-fi que cobra por megabyte. Este patch adiciona uma opção de linha de comando, para que o cliente baixe apenas blocos e não transações, e não carregue nada além das transações que você criar. A desvantagem é que isso não é saudável para a rede como um todo, não exibirá transações que você está monitorando de outro lugar até que sejam incluídas em um bloco e reduz o anonimato, pois você só transmitirá suas próprias transações e não de mais ninguém. Além disso, o recurso de alerta também está desabilitado, então você não verá alertas para atualizações urgentes (não que isso fosse confiável de qualquer maneira no caso do recente hardfork 0.8!).

Idealmente, isso seria alternável de dentro da GUI ou até mesmo capaz de ligar e desligar automaticamente, dependendo de qual ISP você deseja ativar, IMHO.

Oh, aqui está o branch mencionado acima: https://github.com/rebroad/bitcoin/commits/MinimizeTraffic

Eu ainda sustento que deve haver uma maneira de nós como este (que não retransmitem txs e blocos) se anunciarem como tal durante a conexão para que outros nós possam tomar uma decisão informada sobre a decisão de se conectar a outros nós ou não que estão retransmitindo. Sem essa publicidade, os nós podem apenas adivinhar com base na frequência de txs e blocos recebidos de tais nós.

Eu acho que um sistema de aceleração de upload é útil, com nós anunciando sua largura de banda disponível e outros nós validando isso, e essas informações incluídas nas informações de endereço que são retransmitidas. Dessa forma, os nós podem preferir nós com largura de banda maior, e o nó pode calcular a largura de banda disponível com base em quantos nós estão fazendo upload ou download no momento. A largura de banda por conexão pode continuar a ser monitorada e as conexões alteradas conforme e quando necessário. Isso já é algo que tenho codificado em meu branch de download de parallelblocks e permite escolher de quantos nós fazer o download com base na largura de banda que sabe que está disponível. Se ele descobrir que a largura de banda de upload está saturada, ele simplesmente parará de enviar invs (para novos nós) para que esses nós não solicitem dados dele.

Eu tentei um monte de opções diferentes para controlar bitcoin-qt externamente, sem sucesso.

Eu tentei usar trickle no linux, porém falhou na inicialização

Eu tentei usar o QoS do iptables para trafegar a porta 8333 de entrada e saída e tive sucesso limitado, às vezes funcionava e outras vezes não.

Tentei usar o NetLimiter no Windows como mencionei acima, porém ele não lida muito bem com bitcoin-qt, as conexões de alto tráfego são mostradas como conexões UDP do sistema, então o acelerador não ativa.

Eu só estou um pouco desconfiado de que as conexões de alto tráfego são na verdade maliciosas, seja uma simples inundação ou exploração de buffer, talvez. Ao visualizar o tráfego no Wireshark, todos os pacotes pareciam idênticos ??

De qualquer forma, continuaremos investigando conforme o tempo permitir.

Acabei de descobrir por que minha largura de banda mensal de 150 GB é usada, 85 GB era o tráfego upstream de bitcoin. Média de 4 GB por dia para uma ideia legal.

Agora vejo que não há suporte para limitação, então ela não está sendo ativada novamente. Eu realmente gosto de ter uma taxa limitada a 64 KB pelo resto do mês e não ter que pagar taxas.

Onde você acha que vive o blockchain, você confia em seu guardião?

Não estrangule o blockchain, ele morrerá.

Se você fizer isso, não reclame do aumento das taxas sobre as transações ou do tempo que leva para as transações serem confirmadas ou confirmadas.

1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB
Obrigada!

@memetica Eu entendo seu ponto, mas não estou executando o cliente porque não posso permitir que ele use toda a minha largura de banda.

Portanto, é melhor ter alguns nós na rede com upload lento ou limitado ou ter apenas nós "rápidos"?

Talvez eu não devesse estar executando o cliente. Quando eu estava nos EUA, tínhamos largura de banda ilimitada, então a carga não fazia sentido. Mas, no "resto do mundo", a largura de banda não é gratuita e, se eu não tiver a capacidade de limitar minha exposição, não estou preparado para executar o cliente. E tenho certeza que a ideia é não ter todos os servidores "rápidos" em alguns países, pois isso enfraquece a rede.

Só dizendo: "E tenho certeza que a ideia é não ter todos os servidores" rápidos "em alguns países (...)"
Você faz o meu ponto.

Ao limitar / sua / largura de banda, você transfere o trabalho para outros, que também limitarão o deles, etc.
Até que você termine no cenário do qual você tem certeza, não é a ideia.
Parabéns para você.

Se você restringir o blockchain, não confia no bitcoin. (você pensa nisso como roubo, pense nisso)

Tudo isso é bom e tal, mas o cliente ainda está interferindo na velocidade de download.

Em resposta ao autor original:
"Notei outro dia que o Bitcoin estava maximizando minha largura de banda de upload em ADSL. Provavelmente devido ao envio da cadeia de bloqueio para outros usuários de bitcoin (eu tinha cerca de 65 conexões na época)."

A verdadeira resposta já foi dada por "luke-jr" que postou:
"QoS é realmente um trabalho de roteador, mas acho que roteadores confiáveis ​​não são muito comuns: /"

Os cínicos parecem nunca querer dar uma resposta direta: /

Ele quis dizer, provavelmente, que é melhor reclamar sobre roteadores que não aderem ou mesmo implementam os padrões de modelagem de tráfego. Apenas marcar uma caixa e clicar em aplicar não significa necessariamente que isso aconteça, nem mesmo em / open / hard- ou software. Bugs alguém?
Embora, no último caso, eles tenham uma chance maior de serem encontrados e corrigidos.

(methinks um tanto poéticos: bitcoins mudando o mundo por pessoas reclamando para os criadores de redes que seus bitcoins não estão passando rápido o suficiente)

Isso funciona com a premissa de que o cliente bitcoin-qt adere aos padrões de QoS.
Qual era o cliente dos pôsteres originais. (Eu o confundi com um troll no começo)

O que parece acontecer há muito tempo.
Embora o tráfego tenha aumentado recentemente, meu roteador, pelo menos, graciosamente, me permite ver minha "conversa tediosa" a toda velocidade. Limitando o tráfego de bitcoin? Sim! Mas de acordo com o bit QoS, ou seja. minha largura de banda é minha.

Em vez de apontar para os desenvolvedores que por algum motivo ou outro seu bitcointraffic havia aumentado (um ato na veia, eu suponho, eles já sabem, ou ele falhou em verificar) e fornecer a eles, no mínimo, detalhes do sistema operacional e versão do cliente usado ... Nãããão ....

A funcionalidade imediata oferecida: estrangulamento, estrangulamento. Tão humano.

Esta "solução" já foi aplicada a clientes bittorrent.
utorrent (para citar um) implementou seu próprio modelador de tráfego.
Em vez de reclamar com os fabricantes de roteadores.

Se não houver nenhum, ou apenas alguns propagadores para esta "conversa ted" que você apenas deseja ver agora (ou dentro de certos limites), nenhuma "conversa ted" para você agora (ou dentro de certos limites). Ou talvez nunca, a semente está morta.

Agora seja honesto, qual é / sua proporção de compartilhamento geral, você limitou o upload? Você ainda semeia a "conversa ted"?
Você dá um ciclo nas portas? Aceita apenas conexões criptografadas, para que seu provedor não consiga detectar o protocolo bittorent, para manter a largura de banda alta? Já usou o TOR? (embora isso seja ridículo: torrents over tor)

Essa é a consequência.
Bittorrent, como é lindo, está aleijado só por causa disso. Não porque é censurado.
(Estou na Holanda e não consigo acessar o piratebay.com, mas o DHT parece funcionar muito bem, mas recebo muitas "conversas ted" falsas.)

Cada bitcoin é recuperável, até os primeiros 50 (basta olhar para o bloco 0) e todos os outros bitcoins depois disso. (se você tiver tempo; os computadores têm)
Não há direitos de cópia ou outros sobre o protocolo ou os números que são enviados.
Além disso, o tráfego BTC não pode, não pode ser limitado ou bloqueado. É legal ou não ilegal.

Eu não posso deixar de admirar a estrofe dos desenvolvedores do núcleo-btc indo todo Douglas Adams: "É problema de outra pessoa".

Ok, e agora o problema real:
Ninguém o / a obrigou a manter o cliente a funcionar!
Consome sua largura de banda? Pare com isso! Mas espere um atraso para verificar as transações recentes, para saber de onde vêm suas moedas e, portanto, confiar nelas.

Você não anda por aí com a carteira aberta o dia todo, não é? Registrando de onde vem todo o seu dinheiro?

Ah, e pergunte a si mesmo "bitcoins em dinheiro ou vice-versa?"
De qualquer forma, pare de reclamar, aprenda a programar, implemente esse recurso em seu fork do bitcoin-qt.
Sente-se e veja como é implementado ... ou não.

Então, e só então, você tem o direito de reclamar, mas esteja pronto para a batalha. Você terá que ser realmente convincente e capaz de explicar / por que / limitação é bom.

Como "nadrimajstor" optou: "(...) add -nolisten argument"

Se você não ouvir, não haverá diálogo. Portanto, suas transações são anuladas.

: /

Einstein poderia ter dito:

• "Se você pode explicar o problema para sua avó, você entende o problema,"

Se você acha que aprendeu algo:
1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB

Se você acha que devo calar a boca:
15B4oqE6e2skviM67kSmAB3yp77GChjPnL

Obrigada!

simeonpilgrim quoth:
"nos EUA tínhamos largura de banda ilimitada, portanto a carga não fazia sentido. Mas no" resto do mundo "a largura de banda não é gratuita",

Os bitcoins não são gratuitos nem insignificantes. Leia as notícias.

Por que você coloca aspas no "resto do mundo"?

por citação de meio ponto ["Só por dizer:" E tenho certeza que a ideia é não ter todos os servidores "rápidos" em alguns países (...) "
Você faz o meu ponto.

Ao limitar / sua / largura de banda, você transfere o trabalho para outros, que também limitarão o deles, etc.
Até que você termine no cenário do qual você tem certeza, não é a ideia.
Parabéns para você. "]

Você faz questão de não entender meu ponto, que se eu não estiver executando um servidor, você está na mesma posição. Repeti seu acréscimo para ajudar a demonstrar meu ponto de vista, e você acabou de ver o acréscimo e pareceu parar de ler para compreender.

Portanto, é melhor ter servidores rápidos e mais lentos ou apenas rápidos?

Eu concordo que QOS é a solução. O fato de que meu roteador fornecido pelo ISP não faz QOS e eu não quero comprar um segundo roteador para aninhar atrás dele para fazer QOS é meu problema.

Talvez a verdadeira questão seja: você quer muitas pessoas administrando o cliente?

Se assim for, torne isso mais fácil para eles. Se não, continue.

Interrompi o cliente porque a) não tenho QOS, b) estou ocupado com meus próprios projetos de SO ec) Não me importo muito, mas com este projeto, a relação entre juros e custo tornou-se muito alta.

Eu consigo que todo o sistema operacional resolva seus próprios problemas, ou fique quieto. Presumi que o Bitcoin queria um efeito de rede, portanto, o feedback pode ser necessário.

Sinto muito que você não entendeu meu ponto.

Mas aqui está, uma resposta para a sua.

Embora eu não tenha certeza se essas discussões são permitidas em um tópico como este.

Não importa se você executa o cliente ou não.
Se você deseja negociar bitcoins, deve executar o cliente.
Se você não quiser negociar bitcoins, não execute o cliente.

Você pergunta:
"Talvez a verdadeira questão seja: você quer muitas pessoas administrando o cliente?"

O que você não entendeu? Quero todo mundo rodando o cliente, ainda mais, quero tudo rodando o cliente!
Quero poder pagar com bitcoins e quero a confirmação imediata dos meus pagamentos.

Seja você o cliente ou não, quero que confirme minha transação, como se você estivesse lá. O que há de tão difícil nisso?

Vendo a ascensão do bitcoin, muitas pessoas parecem querer isso também. Então, por que você está adiando ou mesmo negando (--nolisten) isso?

Você pergunta:
"Então, é melhor ter servidores rápidos e mais lentos ou apenas rápidos?

E eu já expliquei várias vezes que não há diferença, você não parece entender o conceito.

Às vezes, você obtém congestionamento, quando há muitas transações em andamento.
Por que as estradas estão congestionadas apenas entre 9 e 5 (bem, só posso falar pela Holanda, é claro)
A solução usual são estradas maiores, mas isso não funciona, elas enchem também.
Por aqui a solução é engasgar a entrada de veículos, mas isso só desloca o problema para as entradas.
Então agora o congestionamento está nas aldeias (onde não deveria estar, crianças e tudo mais). E demora uma eternidade para pegar a rodovia ... para usar um coloquialismo americano "Você sabe o que quero dizer?")

Tenho certeza que você notou o aumento absurdo no valor do bitcoin?

Existem apenas cerca de 21.000.000 bitcoins

A questão da largura de banda se resolve sozinha. depois de 2020, é apenas garimpar carteiras perdidas.

Não, a verdadeira luta é o tamanho dos blocos ....

Se ainda não me entendeu, explique por que quer sua carteira online 24 horas por dia, 24 horas por dia, sem pagar por ela.

Mas leve isso em mente.

Bitcoins custam dinheiro, você já trocou um bitcoin?

Não acho que essa discussão seja produtiva neste momento. As melhores soluções técnicas encontram uma maneira de atender às _necessidades_ de todos e, mesmo que às vezes eu mesmo seja culpado disso, é difícil chegar lá com um argumento de que seus desejos são estúpidos ou errados. O que é necessário aqui não é mais debate, o que é necessário é mais implementação e testes, mesmo que parte da "implementação" seja apenas uma boa cópia para ajudar as pessoas a entender como podem desempenhar um papel importante em manter a rede saudável.

(Editar: excluí uma postagem da mimetica pedindo dinheiro para calar a boca)

Isso realmente não pode ser resolvido até que o sistema de download de histórico seja corrigido, então
que um único cliente pode baixar de vários pares, estilo bittorrent. Ou
pelo menos permitindo que ele detecte pares lentos e busque os melhores.

Talvez um método simples esteja impedindo um cliente de enviar para mais de
um par a qualquer momento por padrão pode tornar as coisas menos problemáticas.

Todo o esforço mental neste segmento precisa mudar para o desenvolvimento de um verdadeiro
Extensão do protocolo de download P2P.

Em 11 de abril de 2013 13:29, Gregory Maxwell [email protected] escreveu:

Não acho que essa discussão seja produtiva neste momento. Ao melhor
soluções técnicas encontram uma maneira de atender às _necessidades_ de todos e, mesmo que
Às vezes sou culpado por isso mesmo, é difícil chegar lá com um
argumento de que seus desejos são estúpidos ou errados. O que é necessário aqui não é mais
debate, o que é necessário é mais implementação e testes, mesmo que alguns dos
"implementação" é apenas uma boa cópia para ajudar as pessoas a entender como podem
desempenham um papel importante em manter a rede saudável.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/bitcoin/bitcoin/issues/273#issuecomment -16215243
.

Oh, eu me apaixonei pelo troll, ou você não entende bitcoin tudo?

Talvez um método simples evite que um cliente faça upload para mais de um par a qualquer momento por padrão, o que pode tornar as coisas menos problemáticas.

....
Não tenho mais nada a dizer sobre tamanha estupidez

Você está em um prado, as saídas são n, e, s, w
Não é feiticeiro, ele diz: "Vá para o norte"

(sua vez)

Não sou americano, mas sei que Jefferson disse: quem sacrifica a liberdade pela segurança não merece nenhuma.
E eu concordo com isso!

desculpe por gritar (fora do tópico)

(Editar: excluí uma postagem da mimetica pedindo dinheiro para calar a boca)

Minha palavra! VOCÊ PODE MESMO LER!

mEmetica

(Editar: excluí uma postagem da mimetica pedindo dinheiro para calar a boca)

Como é:
Se você gosta de meus argumentos:
12345554335

difere da
1dice9wVtrKZTBbAZqz1XiTmboYyvpD3t

Acabei de postar um número, quando estava pedindo fundos?

Uma resposta poderia ser "sim cara, acabei de enviar zilhões para isso".

Ver? grupo errado, pessoas erradas.

Vocês que não entendem a verdadeira liberdade se isso os atingir na cara!

Nós vamos! fornicar você!

(Editar: excluí uma postagem da mimetica pedindo dinheiro para calar a boca)

Uauuuuuuuuuuuuuuuuuuuuuuuu

Então o que é, sem fundos para mim, cale a boca?
Na mesma postagem, perguntei se você aprendeu alguma coisa,

Eu acho que você não

Todo o esforço mental neste segmento precisa mudar para o desenvolvimento de uma verdadeira extensão de protocolo de download P2P.

Obrigado robbak!

Mas o que exatamente você quer dizer?

O que é uma "verdadeira extensão de protocolo de download P2P"

Aquele que você intimida com os outros? MS tem feito isso há anos e parece funcionar, de certa forma.
Você conhece os chavões, mas infelizmente não consegue entender seu significado.

Todos os esforços mentais neste tópico precisam parar este tópico!
Chega de aumento repentino no tráfego de saída, são apenas bitcoins!
Deixa eles irem!

Engraçado ... Eu entrei neste tópico porque notei que meu nó está usando _muito_ largura de banda de upload ... Eu entendo que o p2p tende a fazer isso, especialmente porque mais pessoas "precisam" das informações da rede ... mas isso também acontece quando você tem _menos_ pessoas na rede (porque há menos lugares de onde fazer download). Tenho uma cota mensal de bw na máquina em que estou executando o bitcoind.

Do meu entendimento, quanto mais nós, mais confiável esta rede é (ou menos provável é que algum indivíduo ou instituição possa assumir a rede bitcoin controlando a maioria dos nós), posso adicionar QoS para limitar o bitcoind (e irei , pode apostar que sim), no entanto, o usuário comum simplesmente não sabe fazer isso. Adicionar uma configuração simples que limita o uso de bitcoind bw apenas encorajará as pessoas a executar o cliente ... por enquanto, o daemon ficará inativo até que eu tenha tempo de configurar o QoS, no entanto, se houvesse uma maneira mais simples de regulá-lo _agora_, ele continuaria a funcionar 24 horas por dia, 7 dias por semana.

Não estou muito interessado em moedas (ouvi falar desse projeto há vários anos), apenas achei a ideia interessante e presumi que seria bom adicionar mais nós "honestos" à rede ... aparentemente você não se importa realmente com isso, você só quer "alguns nós rápidos" em vez de _muitos_ nós não tão rápidos. Acho que "quanto mais melhor" para esse tipo de sistema ... mas talvez eu esteja errado.

@soulhunter Parece haver um pouco de confusão aqui.

Claro, precisamos de muitos nós se quisermos um sistema descentralizado. Mas queremos principalmente muitos nós que validem - a principal vantagem do Bitcoin sobre outras moedas (na minha opinião) é que não preciso confiar em ninguém para saber que ninguém está trapaceando. Se for mais fácil executar esse nó, menos pessoas terão que não fazer isso.

No entanto, para inicializar um novo nó, é necessário mostrar o histórico do estado atual, para que também possa avaliar de forma independente que nada no passado foi fraudulento. Assim, precisamos de uma maneira de alimentá-los com esse histórico, e é fornecido por outros nós da rede que também em alguns tiveram que baixar esse histórico de qualquer maneira. Idealmente, também temos o maior número possível. Mas a realidade não é perfeita. Nem todo mundo quer sacrificar seu upstream para fazer isso, enquanto outros têm muito upstream de sobra. E, com a implementação atual com bugs, se você estiver acidentalmente atingindo um ponto lento para fazer o download, o download será lento. Não temos um mecanismo para procurar bons pares ou paralelizar o download. Assim, desde que o mecanismo de sincronização não seja aprimorado, sim, todos ficam melhor com poucos uploaders mais rápidos do que muitos mais lentos. Observe que se trata apenas de servir blocos históricos a terceiros - você pode validar perfeitamente todos os blocos e transações e participar de outra forma na rede sem fornecer esse serviço.

Eu entendi corretamente que o histórico NÃO é baixado ponto a ponto? Eu li corretamente que ele foi baixado de UM ponto? Nesse caso, isso explica todo o problema. Realmente precisa ser baixado ponto a ponto: o que importa se você só tem 10kbit de upload se houver 100 outros dentro de um raio de rede razoável para puxar?

Estou entendendo corretamente? Porque isso faz toda a diferença do mundo.

@cjastram Não tenho certeza se você está entendendo corretamente. Se você estiver usando uma definição muito estranha de ponto a ponto. Os blocos são baixados de um par aleatório, mas atualmente todos são baixados de um par. (porque a forma como o processo funciona é basicamente um "diga-me o que não tenho" em vez de um "aqui está o que estou perdendo").

E sim, absolutamente isso precisa ser melhorado e é por isso que Pieter e eu afirmamos que, embora apoiemos todos os tipos de botões para controlar o uso de recursos, o comportamento de busca precisa mudar primeiro.

@gmaxwell entendo, acho que li corretamente. Existe alguma maneira de adicionar esse problema como um bloco para este problema, de forma que seja mais claro que o outro deve ser feito primeiro?

1 para adicionar estrangulamento. Bitcoin-qt acabou de desligar minha rede wi-fi doméstica e demorei 20 minutos para descobrir o que estava acontecendo. O cliente estava usando toda a minha largura de banda de upload disponível (1 MB / s) e eu não conseguia usar a web. Isso são bananas. Estou feliz em contribuir com minha largura de banda, mas não toda ela. Não há razão para ser tudo ou nada.

Não consigo mais executar o cliente completo, exceto algumas horas por semana, devido a esse problema. Esse problema impedirá que usuários domésticos ou novatos executem um cliente completo. Algo tão simples como (limite de upload de X kb / s) deve ser suficiente.

@soundasleep Você desligou a escuta de conexões de entrada? Do contrário, isso deve permitir que você o execute com menos impacto até que haja outras instalações disponíveis.

@gmaxwell, pelo que entendi, isso apenas reduzirá a probabilidade de minha conexão ficar saturada, e com upload de apenas 0,8 Mbps (que é malformado, mal provisionado e regulado também), duvido que vá resolver qualquer coisa, já que um par poderia facilmente saturar isso . Vou tentar, mas ainda não consigo executar o cliente em tempo integral.

luke-jr está absolutamente certo ao dizer "QoS é realmente um trabalho de roteador, mas acho que roteadores confiáveis ​​não são muito comuns", isso é simplesmente um fato.

Os desenvolvedores devem perceber isso e corrigir o problema o mais rápido possível para que todos os tipos de usuários (muito low-end ~ very high-end) ainda possam usar o programa sem sair de sua zona de conforto. Por pelo menos 20 anos, então talvez até lá, todos na Terra terão um roteador com um código QoS decente embutido e também Internet de fibra para lidar com todos os dados de transferência.

Mas agora, do jeito que está, é como uma missão suicida IMHO, isso me deixa tão triste, louco e desapontado ao mesmo tempo que não consigo nem explicar em palavras como me sinto sobre isso. Tudo o que sei é que a decisão de não remendar e deixar do jeito que está é uma decisão ultrajante.

Em 02/05/13 23:42, dormindo profundamente escreveu:

Não consigo mais executar o cliente completo, exceto algumas horas por semana, porque
desta questão. Este problema impedirá que usuários domésticos ou novatos nunca
executando um cliente completo. Algo tão simples como (limite de upload de X
kb / seg) deve ser suficiente.

Bem, na verdade não tenho problemas para executá-lo em casa, algum QoS é
chega .... porém, meu problema é no servidor, eu tenho um BW mensal
limite lá, e o cliente usará apenas a velocidade total de upload de 100 Mbps
sempre que quiser (!), ficarei feliz em dar um upload de 3 a 7 Mbps
(dessa forma, não pode me fazer overquota).

Ildefonso.

@XcaninoX sua resposta é confusa e insanamente desrespeitosa. Eu não sou seu escravo. Ter mais opções para isso no futuro é bom e planejado, como foi explicado várias vezes, mas não é algo trivial de implementar e, portanto, vai esperar por alguém que tenha tempo para trabalhar nisso.

@soulhunter quase toda a largura de banda é usada alimentando os dados históricos para nós recém-iniciados. Portanto, o conselho para desabilitar a escuta se sua largura de banda estiver restrita, para que você não faça isso. Sem alimentar novos nós, a utilização média máxima é da ordem de 100kbit / s ou mais.

@gmaxwell Me desculpe se eu o insultei de alguma forma, definitivamente não era nem é minha intenção, embora eu nunca tenha realmente visto ou tratado você como meu escravo, peço desculpas se você pensou assim .. Minha opinião sobre este assunto se mantém , para ser mais claro, estou apenas expressando meus pontos de vista, apenas dizendo o que tenho em mente, compartilhando como vejo as coisas agora e como acho que deveriam ser em vez disso, apenas colocando as cartas na mesa e discutindo eles, é isso.

@XcaninoX OKAY. Não sei o que mais precisa ser abordado, basicamente todos concordam que deveria haver melhores controles de recursos. Mas concordar que eles deveriam estar presentes não os faz acontecer instantaneamente.

Em 03/05/13 00:13, Gregory Maxwell escreveu:

@soulhunter https://github.com/soulhunter quase toda a largura de banda
é usado alimentando os dados históricos para nós recém-iniciados. Por isso
o conselho para desabilitar a escuta se sua largura de banda for restrita,
que você não vai fazer isso. Sem alimentar novos nós a média máxima
a utilização é da ordem de 100 kbit / s ou mais.

Sim, mas ainda é necessário alimentar dados históricos, porque caso contrário
como novos nós seriam adicionados? (esta é parte da razão pela qual eu sou
rodar um cliente em um servidor, para mantê-lo funcionando 24 horas por dia, 7 dias por semana e ajudar a rede).
Além disso, desabilitar "entrada" não corrige isso magicamente, porque você pode
ainda entrar em um nó incompleto por meio de uma conexão de saída (embora
a probabilidade fica bastante reduzida). Enfim, até agora, a quantidade de
BW que comeu não é _tão_ enorme (apenas "espetado"). Vou mantê-lo funcionando
por mais algumas semanas e vamos ver (parece que vai usar
~ 500 GB / mês, posso pagar por isso, por enquanto).

Por que não implementar algo simples?

1. Adicionar opção de limite de BW de upload básico (há várias maneiras de fazer
   isso, não vou elaborar agora).
2. Quando um cliente está baixando e tem mais de 1 par, ele deve
   baixar de um determinado par por N segundos (digamos: N = 300) e, em seguida, mover para
   o próximo em um esquema round-robin (ou mesmo aleatório). Desta forma, um dado
   o cliente não ficará "preso" em um único par lento, mas provavelmente se moverá
   de pares rápidos para lentos durante o download e distribuir a carga de download.

O que você acha?

Ildefonso.

Se alguém imaginar o blockchain como um arquivo torrent de 7 GB +, há algo que nos impeça de usar idéias de arquitetura bittorrent para inicializar clientes? @jgarzik já implementou essa ideia independente do cliente aqui . Estou supondo que inchar o cliente com um link para libtransmission ou algo semelhante não é aceitável (ou seria?). Também pode não ser seguro. Provavelmente resolve vários problemas associados ao gerenciamento de largura de banda e limite de dados.

Talvez, como um experimento independente, alguém (eu?) Deva tentar implementar um patch para responder apenas às solicitações de dados históricos além de uma determinada data ou número de bloco. Estou supondo que a maioria dos pares está totalmente desatualizada (exigindo todo o histórico) ou então apenas uma ou duas semanas desatualizados. Estou absolutamente inventando isso, então posso estar totalmente errado, mas parece um palpite razoável. Assumindo que isso seja verdade, a maioria dos pares poderia ser servida definindo um filtro de data algumas semanas atrás e exigir que novos pares recorressem ao torrent de Jeff Garzik ou qualquer outro mecanismo disponível. Não é útil para novos clientes, mas pode facilitar o uso da largura de banda.

IMHO, esta deve ser uma opção de configuração GUI simples semelhante às opções para configurar tor - ou seja, decidir se deve fornecer funcionalidade de rede completa ou funcionalidade limitada. Se não se tornar parte do cliente "principal", então alguém provavelmente fornecerá um fork que o faça, e então o cliente "principal" precisará atender à existência desses clientes alternativos - por exemplo, atendendo a getblocks / getheaders ignorados solicitações de.

Eu também estou tendo este problema. Eu, pessoalmente, não me importo em usar isso do meu lado, em vez de fazer com que seja parte do protocolo bitcoin. Se alguém souber o que o bitcoin de porta usa, ficarei feliz em estrangulá-lo. Eu uso o Tomato como meu roteador WiFi e tenho certeza de que ele é completo o suficiente para fornecer a funcionalidade para fazer isso - contanto que a porta não seja a porta 80, é claro, porque não vou limitar o tráfego da web padrão apenas por causa do bitcoin, mas ficaria surpreso se for esse o caso.

Não se preocupe, apenas pesquisei no Google e encontrei a resposta para minha própria pergunta no FAQ do bitcoin. Para qualquer pessoa interessada, a porta que Bitcoin usa é a porta 8333. Se houver mais alguém aqui usando o Tomato, ficarei feliz em postar instruções para controlar essa porta assim que descobrir como fazer isso. Deixe-me saber se houver algum interesse.

O problema é que o bitcoin fará conexões de saída para qualquer porta que um par possa dizer que está usando, então 8333 capturará a maior parte do tráfego, mas não todo.

Pode ser possível detectar as portas usando uPnP ou algo assim ... Muito difícil, estou esperando a funcionalidade do acelerador :)

bitcoin fará conexões de saída para qualquer porta que um par possa dizer que está usando

Não, não vai. Ele só tentará pares não 8333 se não tiver sorte ao conectar-se no 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.

Eu não li o código, então não posso comentar sobre o que o cliente bitcoin principal faz, mas isso faria muito mais sentido do que o que o preguiçoso disse. Especialmente porque a porta que está sendo usada é o que obtive diretamente do wiki do bitcoin, acho que eles teriam falado um pouco mais se quisessem dizer "usa a porta 8333 na maioria das vezes".

Acelerar a velocidade de upload do bitcoind

Engraçado e triste que vocês não entendam que executar um nó com um limite de largura de banda de upload é melhor do que não executar um nó. Não executar um nó Bitcoin parece ser a alternativa que os desenvolvedores preferem e estou bem em não fazer isso.

Considere o seguinte: você tem uma fibra e ADSL e executa para, i2p, um cliente bittorrent e talvez algumas outras coisas. Todas essas coisas - basicamente todos os softwares SANE P2P - permitem definir um limite de largura de banda de upload para que você possa navegar na web e fazer outras coisas com sua conexão normalmente. Então você tem o bitcoind que basicamente tenta usar 100% da sua conexão e faz todo o resto parar. A maioria das pessoas simplesmente verá o bitcoind como algo que não possui os recursos mais básicos que todos os outros softwares P2P possuem (capacidade de definir a porta, limitar o número de conexões, largura de banda, etc.) e não executá-lo.

Vejo que esse bug tem 3 anos. Vou verificar novamente em 3 anos para ver se os desenvolvedores que argumentam contra a limitação de largura de banda descobriram que ter muitos nós com um limite de largura de banda é melhor do que ter apenas alguns nós de alta largura de banda com conexões dedicadas até então. Eu estou supondo que eles não vão, mas pode-se esperar.

@oyvinds Parece que

@gmaxwell Snark não é produtivo. Mas me inspirou a responder.

Não entendo por que isso é tão difícil de corrigir. Aqui, deixe-me tentar ser útil e pragmático.

Não são necessários controles detalhados sobre a largura de banda de upload. Apenas um controle deslizante que nos permitiria adicionar um "sono" entre cada envio de um pacote. O controle deslizante nos permitiria aumentar a duração do sono. Isso forneceria uma limitação de taxa bruta, mas eficaz, sem exigir muito tempo de desenvolvimento. O que é isso, como uma hora de desenvolvimento para corrigir o problema nº 1 que impede as pessoas de executar o bitcoind?

@ dwest-trulia Por favor, leia as mensagens minhas e de outras pessoas que tiveram experiência com o protocolo Bitcoin no tópico. Isso foi abordado anteriormente. Obrigado.

@gmaxwell Procurei no tópico a palavra "sono" e não consegui encontrar minha ideia ou sua refutação. Eu encontrei alguns argumentos filosóficos contra a limitação de taxa em geral e a ideia malfeita de desligar a escuta (que não é confiável o suficiente para que as pessoas habilitem o bitcoind com segurança). Perfeito é inimigo do bom. Continuarei sem rodar o bitcoind até que esteja bom ou perfeito.

Desligar a escuta é bastante confiável, pois os nós que estamos conectando já têm o blockchain. Não houve nenhum argumento filosófico em tudo, _nenhum_ se opõe à limitação de taxa em uma base filosófica. Mas, devido à forma como o protocolo Bitcoin funciona atualmente, o DOS ataca severamente seus pares. É melhor simplesmente não ter eles se conectando a você agora, embora isso esteja sendo corrigido.

@gmaxwell Eu não sabia que havia um possível problema com o DOS. Interessante.

Ninguém é contra conexões limitadoras de taxa como tais.

O problema é que o mecanismo de busca atual é bastante estúpido e geralmente lida muito mal quando está estrangulado. Então, até que isso seja corrigido, sim, eu acredito que não executar um nó (alcançável) é melhor do que executar um limitado.

Quando tivermos corrigido o algoritmo de sincronização (consulte # 3077, # 3083, # 3087, # 3276, # 3370, # 3514, # 3884 para trabalhar nesse sentido, bem como a versão antiga # 2964), terei prazer em ACK qualquer patch para melhorar a modelagem de largura de banda em bitcoind.

@gmaxwell

Se você estiver tendo problemas com o uso imediatamente, pode definir listen = 0

Não ajuda. Em uma conexão de 8 / 1mbps (down / up), o bitcoin-qt faria o próprio DoS enviando tantas coisas que o sistema não teria mais internet. Nenhum mesmo. Os pings não seriam atrasados; eles apenas expiraram. Serviços como o LogMeIn relataram que não havia mais conectividade com a Internet e a navegação tornou-se basicamente impossível.

Agora, um ano depois de meus comentários anteriores aqui, eu tenho uma conexão de fibra e mesmo com listen = 1 tudo funciona bem, mas não foi legal precisar rodar bitcoin-qt (para alcançar a cadeia) exclusivamente enquanto o resto da minha família dormia.

@ lucb1e É uma pena que você não ofereceu essa observação enquanto ainda tinha a configuração para reproduzi-la. Não consigo reproduzir e tenho vários nós de escuta = 0 para teste e nenhum vê alto uso de largura de banda.

@gmaxwell Sim, eu deveria ter apontado antes. Eu pensei ter lembrado de comentar que o bitcoin-qt acabou com sua própria conexão, mas parece que não me lembro. Desculpe por isso. O que eu disse ainda se mantém: mesmo distribuir blocos conforme eles passam pela rede são muitos dados.

Olhando para blockchain.info agora, 20 minutos atrás havia um bloqueio de 0,9 MB. Times 7 (um par já deve tê-lo) faz um upload de 6 MB. Na minha conexão anterior, isso causaria pouco mais de 1 minuto de falta de internet.

Examinando esses números, fica bem claro que executar um nó bitcoin completo em tal conexão não vai ajudar ninguém. Mas não preciso ser um nó completo, só quero executar o cliente bitcoin oficial (ou talvez deva dizer "geralmente líder") com minha própria cadeia de blocos. Ter uma opção para não enviar blocos e / ou não enviar transações seria útil. Diz-se que isso causa problemas de DoS, mas eu diria que é um problema neste cliente e não um problema de rede: qualquer um pode configurar e anunciar muitos nós desonestos que nunca fazem nada. Os nós que não escutam devem desconectar os pares que parecem estar apenas fazendo leeching porque podem estar tentando desacelerar ou perturbar a rede.

Em vez de limitar a taxa de conexões de entrada (o que tornaria a experiência de sincronização ruim para outros usuários), seria viável definir um limite diário e não aceitar mais conexões quando o limite for atingido? Isso me deixaria ser um nó totalmente participante algumas vezes e evitaria o acionamento da política de limitação de "uso justo" dos meus ISPs.

Minha preferência seria algo assim:

Nó completo: atende todos os blocos históricos
Nó aberto: atende os últimos 1008 blocos
Nó fechado: não atende blocos

Cansei de ultrapassar meu limite de dados de 300 GB por mês atendendo a blocos de bitcoind, então procurei uma maneira de limitar a taxa de bitcoind. Nunca encontrei uma boa solução.

Como os desenvolvedores ainda não nos deram a capacidade de limitar a taxa no daemon, decidi usar o iptables para impor um limite. Caso ajude mais alguém, as regras abaixo são as que usei. É muito doloroso atualizar depois de ficar off-line por um tempo, mas funciona bem depois de sincronizado.

// Limite de taxa de saída de bitcoind (temos que obter as portas de origem e destino 8333)
-A SAÍDA -p tcp --sport 8333 -m estado --estado ESTABELECIDO -m limite --limit 30 / seg --limit-burst 150 -j ACEITAR
-A SAÍDA -p tcp --esporte 8333 -m estado --estado ESTABELECIDO -j DROP
-A SAÍDA -p tcp --dport 8333 -m estado --estado ESTABELECIDO -m limite --limit 30 / seg --limit-burst 150 -j ACEITAR
-A SAÍDA -p tcp --dport 8333 -m estado --estado ESTABELECIDO -j DROP

Você está causando o mesmo desempenho doloroso para qualquer outro usuário que por acaso sincronize com você, portanto, certifique-se de definir listen = 0 ao executar dessa forma.

@Ratief Você está reinventando a roda, já temos um script para isso em contrib / qos / tc.sh por um ano.

Se houvesse um botão para desativar os bloqueios de serviço para qualquer pessoa> 20 atrás, não funcionaria? Assim, os pares nunca tentariam sincronizar com um nó lento e um nó lento não ficaria saturado de envio.

@darkhosis No momento, se alguém escolher um nó de sincronização que se recusa a servir blocos, o nó que está tentando sincronizar falhará totalmente. Precisamos de algum código escrito que passará para o próximo par para sincronização. Acho que @sipa está trabalhando nisso nos cabeçalhos primeiro (mas posso estar errado).

Talvez seja bom ter pares com reguladores definidos para relatar isso, e outros sem isso para medir sua velocidade efetiva para relatar. Em seguida, os pares obtêm um pouco mais de informações para usar ao escolher um nó de sincronização ...

@ luke-jr headersfirst apenas busca em qualquer lugar que possa e deve lidar relativamente bem com pares que travam, então, depois que o HF é implantado, estou bem com um recurso como este.

@sipa A ideia de enviar blocos não considerados "históricos" parece uma boa solução. Vou chamá-los de servidores de luz. Talvez com base nos limites de largura de banda desejados dos servidores de luz, a distância para trás no tempo de bloqueio que será carregada para sincronizar os pares pode ser definida

Por exemplo:
O usuário A com 'servidor leve' selecionado que deseja dedicar uma quantidade mínima de sua largura de banda upstream irá retroceder apenas para o bloco que tem um tempo de bloqueio 7 dias antes de seu último bloco.

O usuário B com 'light-server' também habilitado, mas disposto a doar um pouco mais de largura de banda (mas não sincronizar todo o blockchain) pode sincronizar blocos até um tempo de bloqueio de 30 dias antes do tempo de bloqueio atual.

Dessa forma, não há limite de velocidade de conexão real, fazendo com que um nó travar na sincronização de um nó lento.

Atualização: isso exigiria a capacidade dos nós de alternar para outro nó de sincronização sem falhar

O problema é que o mecanismo de busca atual é bastante estúpido e geralmente lida muito mal quando está estrangulado. Então, até que isso seja corrigido, sim, eu acredito que não executar um nó (alcançável) é melhor do que executar um limitado.

-

Você está causando o mesmo desempenho doloroso para qualquer outro usuário que por acaso sincronize com você, portanto, certifique-se de definir listen = 0 ao executar dessa forma.

Não é um nó rodando em uma conexão lenta como um "estrangulado"?
Digamos que temos 2 nós: A rodando em uma conexão de 1 Mbps e B em uma de 1 Gbps. Mesmo com um limite de largura de banda em B (como 100 Mbps), é melhor sincronizar de B do que de A!
Além disso, não seria melhor para um nó limitar seu upload a 90% dele, a fim de evitar a saturação? (pacotes de confirmação, etc.). Talvez o nó A funcionasse melhor com um acelerador de 900 Kbps (e outro usuário seria capaz de navegar na web)?

Por último, ter esse tipo de rede seria uma maneira de "anunciar" a velocidade do seu nó para outros e deixá-los decidir se sincronizar (ou não) de você.

A limitação em um nível muito básico de comandos de rede provavelmente seria uma má ideia e já pode ser feita com software e hardware (roteador / iptables, etc.).
A limitação também seria desconfortável para o nó na outra extremidade.

O que a maioria dos operadores de nó completo deveria alegrar seria uma maneira de não servir blocos históricos quando certas pré-condições são alcançadas. Tenho certeza de que a reclamação de que os usuários obtiveram um tráfego de saída muito alto foi porque seus nós serviram muitos blocos históricos para nós na sincronização inicial.

Eu gostaria de implementar um recurso que permitiria definir um limite total por dia e, se alcançado, não serviria mais nós que pedem blocos <self.height-100 (TBD). O nó conectado pode então mudar para um nó diferente. Limitar block respostas seria uma má ideia, IMO.

Também estou procurando uma boa maneira de limitar merkleblock respostas.

O primeiro passo para isso foi implementado por @jonasschnelli no # 6622, que impõe um limite de upload por intervalo de tempo.
Assim que o novo código P2P de @theuni for concluído, o trabalho de limitação pode ser iniciado.

@laanwj Um limite de upload por ASN também pode ser um recurso útil - ajudaria a distribuir o blockchain de forma mais justa, em vez de permitir que um ASN use toda a permissão. Além disso, usar ASNs para calcular o despejo de pares seria um bom passo para se proteger contra bogons.

Sim, usar os ASNs faz sentido para algumas coisas, incluindo despejos e restrições. Embora o problema prático que surgiu da última vez é que o banco de dados ASN é muito grande para incluir no estado em que se encontra. Talvez ele possa ser aproximado / codificado de alguma forma eficiente para consulta. Ou talvez deixe o download para o usuário e torne-o opcional.

@laanwj oh, pensei que a lógica de seleção de nó de saída já estava usando ASNs, mas talvez não - há algo lá para "espalhar" mais a rede - talvez valha a pena olhar mais de perto a lógica para ver se ela é adequada para ser usada na ausência de um banco de dados ASN real.

Acho que o novo código de sincronização faz um trabalho melhor de distribuir a carga entre os pares. A limitação deve ser um problema menor agora.

@earonesty parece que ainda é.

Tecnicamente, esse problema foi resolvido com a adição do parâmetro de configuração "maxuploadtarget". Não tenho certeza se esse parâmetro foi exposto na GUI, no entanto.

maxuploadtarget ainda não foi exposto à GUI.
Além disso, uma vez que temos o libevent para a camada p2p, a limitação da rede deve ser um fruto fácil.
Porém, eu pessoalmente acho que a aceleração da rede deve ser feita em uma camada mais profunda do que a camada do aplicativo (nível do roteador), uma vez que o aplicativo não sabe o que mais - rodando na mesma rede - requer largura de banda.

Estou usando a v5.9.6 ainda sem controle de pares, como alguém disse que existem softwares e roteadores que podem controlar o tráfego em uma rede, mas descobri que o número de conexões parece ser o problema, o Bitcoin parece abrir para muitas conexões, então nem mesmo o Internet Explorer pode exibir uma página da web,
Olhando nas guias, encontrei Visão Geral, Enviar, Receber e Transações. Existe uma ameaça de vincular o programa com o torrent do cliente, integrando-o ou algo parecido? em outro para controlar esse tipo de coisas que realmente não interessam ao bitcoin?

@jlopp maxuploadtarget não resolve o problema de pico de largura de banda. Já existem soluções para este problema, por exemplo, NAFC , que é apoiado pelo eMule anos atrás. Mas com certeza, o NAFC tem sua própria limitação, ele não pode saber o que outros dispositivos que compartilham a mesma conexão de Internet estão fazendo.

Há muito tempo comecei a assistir este tópico esperando que algum dia alguém adicionasse opções para isso. Nesse ínterim, encontrei minha própria solução. Eu uso iptables e limite de taxa as conexões. Isto funciona bem para mim.

Estou no Ubuntu. Eu adicionei isso a /etc/ufw/before.rules. Ajuste como achar melhor.

Bitcoin de limite de taxa

-A ufw-before-output -p tcp --sport 8333 -m state --state ESTABELECIDO -m limit --limit 30 / seg --limit-burst 150 -j ACEITAR
-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 ESTABELECIDO -m limit --limit 30 / seg --limit-burst 150 -j ACEITAR
-A ufw-before-output -p tcp --dport 8333 -m state --state ESTABLISHED -j DROP

(Infelizmente, sem ser capaz de entender todo o contexto do que escrevi, e sem ser capaz de verificar as contribuições significativas que fiz e continuo a fazer para projetos de código aberto, meu nome de usuário é rotulado como exigente, de carregamento gratuito, e rude no seguinte post. Uma tentativa de usar o humor para dissipar a estranheza de receber uma repreensão pessoal a uma investigação não pessoal não conseguiu conquistar os corações dos over-controllers desta edição aberta do github de oito anos. Eu agora me pergunto se esta atualização que estou fazendo agora também será condenada ou censurada. Existem muitos exemplos estelares a serem considerados de desenvolvedores respondendo com elegância e sem presunção às consultas humildes e mal escritas de novos usuários que não têm nenhuma postagem registrada em um determinado projeto ; do qual eu fui o beneficiário pessoal e, portanto, deixei com a opção de a) expor, b) responder apropriadamente ou c) retirar-se sem me sentir pessoalmente atacado)

@Hypocritus Não foi implementado porque ninguém fez o trabalho de implementação, simples assim, é assim que funciona em projetos open source. Você simplesmente não pode exigir que outros gastem tempo implementando as coisas que você deseja gratuitamente. É incrivelmente rude.

wow tal e velho tópico meio que parece estúpido até mesmo postar, mas ainda assim o mesmo problema aqui minha internet está sendo perturbada ao rodar um nó de bitcoin. Sinto que devo contribuir de volta para o bitcoin, mas ao mesmo tempo não quero perder o desempenho significativo da minha conexão com a Internet, então, com relutância, outro configurou o listen = 0, gostaria que houvesse opções
:(

Acordado. Uma questão importante é que no processo de um nó completo sendo totalmente irrestrito, existem algumas chamadas diferentes que são feitas pelo cliente e seus pares para o sistema ou a rede bitcoin, qualquer um ou uma série das quais poderia estar causando um diminuição de desempenho, travamento ou travamento de uma variedade quase infinita de maneiras na máquina host.

Caso seja encontrada uma solução geralmente discreta e intuitiva para esse problema. seria bom se a) este problema fosse resolvido (para o benefício dos leigos mais densos que não conseguem ler nas entrelinhas), eb) essa solução fosse regularmente citada para o bem daqueles de nós que genuinamente e aprecio com entusiasmo poder gastar mais tempo construindo ou criando, em vez de diminuir, pesquisar ou defender tentativas (embora ruins) de chamar a atenção para um problema persistente e impactante.

E se houver um motivo forte para manter esse recurso como "necessário", como argumentos sólidos sobre a integridade ou segurança do bitcoin, seria benéfico para nós ter esses motivos regularmente citados, postados ou vinculados, e para que este problema fosse encerrado.