+1 untuk itu!

Bitcoin saat ini menggunakan semua kecepatan unggah saya, yang sebenarnya berarti terkadang saya bahkan tidak dapat menjelajah! Menutup BitCoin memecahkan masalah, tetapi itu tidak terlalu bermanfaat bagi jaringan...

+1 juga.

Saya memiliki batas unggah 60KB/s pada ADSL saya, dan bitcoin.exe membunuh unggahan saya dengan sangat buruk sehingga saya bahkan tidak dapat menjelajahi internet dengan baik. Beberapa informasi tambahan:

Saya biasanya memiliki ~32 koneksi dalam bitcoin. Terima tampaknya baik-baik saja. Setelah 10 menit, koneksi bitcoin.exe saat ini masing-masing telah mengunduh sekitar 100kB, tetapi, unduhan biasanya tidak terbatas seperti mengunggah.

Setelah sekitar 10 menit, koneksi bitcoin.exe saat ini menggunakan masing-masing unggahan sekitar 100kB, tetapi, ada ~3 yang menggunakan ~1MB+. Ini mencapai rata-rata lebih dari 10kB/s (tidak terlalu rata-rata). Tapi saya menduga ketika orang-orang 1MB+ itu akan menggunakan 100% dari unggahan dan hanya turun menjadi rata-rata 7,5kB/s setelah bagian itu selesai.

Lebih disukai saya ingin membatasi unggahan ke 2kB/dtk hingga 5kB/dtk pada koneksi saya saat ini.

EDIT: Saya menggunakan bitcoin 0.3.24-beta

Saya telah meng-host node bitcoin publik 24/7 selama lebih dari setahun sekarang di server linux rumah saya. Ini menyebabkan saya kehilangan paket yang cukup besar di telepon dan semakin buruk seiring waktu, seiring dengan pertumbuhan rantai. Tolong, tambahkan batasan bandwidth ke bitcoind. Kalau tidak, saya harus mematikan node, karena koneksi internet saya tidak dapat digunakan.

QoS benar-benar pekerjaan router, tetapi saya kira router yang andal tidak terlalu umum :/

satu lagi +1, juga membutuhkan ini, atau cara agar bitcoind menggunakan blockchain bersama (lihat http://bitcoin.stackexchange.com/questions/3199/read-only-blockchain-in-bitcoind-patch-ideas dan https ://bitcointalk.org/index.php?topic=71542 ), bahkan lebih baik dari sekedar mencekik imho

juga, menunggu opsi di bitcoind, Anda dapat melihat 3 alat pembatas bandwidth ruang pengguna: http://monkey.org/~marius/pages/?page=trickle , http://klicman.org/throttle/ dan http ://stromberg.dnsalias.org/~strombrg/slowdown/

Tolong jangan ada +1 di sini. Saya pikir kita semua setuju bahwa program P2P adalah ide yang bagus untuk memiliki batasan yang dapat dikonfigurasi.

Tidak realistis untuk meminta orang memindahkan ini ke router. Terutama pada VPS Anda tidak memiliki banyak kendali atas perutean.

Namun, fitur ini saat ini tidak memiliki prioritas untuk pengembang inti. Jika Anda ingin mempercepat masalah ini, bantu implementasinya.

Sunting: dan saya sarankan mencoba klien tipis seperti Electrum, yang mengklaim menggunakan bandwidth jauh lebih sedikit dan 'berbagi' rantai blok di supernode.

Mungkin tidak ada hubungannya, tapi kalian bisa (untuk Windows) mencoba cFosSpeed ​​jika koneksi Anda lambat karena upload.

Untuk MS Windows, saya dapat menyarankan NetLimiter sebagai perangkat lunak yang bagus, meskipun komersial. Saya mengira linux memiliki berbagai pilihan QoS yang tersedia, bukan?

Saat Anda menggunakan aplikasi P2P (misalnya klien torrent), Anda selalu disajikan dengan beberapa bentuk informasi dan/atau opsi penyesuaian mengenai sifat komunikasi P2P dan konsumsi bandwidthnya.
Dengan klien BitCoin, ini tidak begitu jelas dan membawa saya ke keyakinan yang salah bahwa BitCoin tidak berat pada lalu lintas jaringan.
Babi internet sporadis selalu dikaitkan dengan ISP yang tidak stabil sampai saya menemukan bahwa sebenarnya klien BitCoin adalah pelakunya (mengisi semua bandwidth unggahan).
Demi pengguna yang kurang paham teknologi, harap buat opsi yang jelas dan mudah untuk, setidaknya, menambahkan argumen -nolisten saat memulai klien.

masalah dibuat 2 tahun yang lalu. Apa yang terjadi guys dev? Ini kok belum di patch ya? Tidakkah kalian melihat kebutuhan mendesak dari fitur tersebut?

sangat bodoh untuk tidak menerapkan ASAP ini karena itu memberikan tampilan yang buruk ke seluruh aplikasi dan komunitas, karena itu mengacaukan internet orang, dan banyak dari mereka tidak menyukai hal-hal teknis, yang pada dasarnya berarti, program yang buruk -> uninstall. .

Anda salah memahami cara kerja pengembangan sumber terbuka. Kami mengerjakan ini di
waktu luang jadi kita putuskan sendiri apa yang penting dan ingin dihabiskan
waktu aktif.

Jika Anda ingin sesuatu diimplementasikan dengan sangat buruk, itu adalah _your_
tanggung jawab untuk mewujudkannya, bukan tanggung jawab kita.

Bisakah Anda berkontribusi untuk memecahkan masalah ini?

Atau apakah Anda bersedia membayar untuk mengimplementasikan fitur tersebut? Anda bisa menawarkan
sebuah karunia.

Saya tidak, fwiw, melihat kebutuhan mendesak untuk fitur semacam itu— dan sampai beberapa komponen tambahan dikembangkan, fitur tersebut akan berbahaya bagi jaringan: jika Anda menyetel kecepatan rendah, rekan-rekan Anda perlu beralih ke blok penarik dari orang lain ketika Anda lambat. (Juga masalah tidak adanya throttle tetapi banyak orang yang menyetel throttle akan membuatnya lebih buruk)

Saat ini lebih baik untuk node yang dibatasi lalu lintas untuk menonaktifkan mendengarkan saja. Ini sebagian besar akan memiliki efek yang diinginkan, tidak berisiko menambah masalah, dan merupakan opsi yang sudah tersedia.

Saya pikir masalahnya di sini jauh lebih banyak sehingga tidak jelas bagi pengguna baru bahwa secara default node Anda akan menyediakan blok ke jaringan. Menonaktifkan mendengarkan memang sebagian besar akan memperbaikinya, tetapi itu jauh dari jelas.

Jika saya tidak meneruskan port saya, tidak dapatkah klien lain mengunduh dari saya? Klien membuat koneksi keluar untuk menerima blok. Di BitTorrent koneksi keluar juga digunakan untuk mengunggah, dan itu masuk akal karena ini membuat jaringan lebih hidup. Apakah Bitcoin melakukan hal yang sama, mengunggah blok ke node yang terhubung jika Anda tidak melakukan portforward?

Node tidak mengumumkan dirinya sebagai menerima koneksi sampai mereka sebagian besar terjebak ... jadi Anda hanya akan meneruskan blok baru, yang bukan merupakan jumlah data yang luar biasa.

Saya terjebak dengan rantai blok, bukan itu masalahnya di sini. Tetapi saya akan meneruskan blok baru ke rekan yang terhubung terlepas dari apakah port saya diteruskan? Karena itu mungkin menghasilkan tugas unggah 1,5 MB untuk blok baru, jika semua node yang terhubung belum memiliki blok baru.

"Node tidak mengumumkan dirinya sebagai menerima koneksi sampai mereka sebagian besar terjebak ... jadi Anda hanya akan meneruskan blok baru, yang bukan jumlah data yang luar biasa."

Namun demikian, itu menjenuhkan uplink saya. Saya menggunakan DSL tanpa opsi lain, dan ini adalah unggahan 50-70 kilobyte (bukan kilobit) yang solid, membuat koneksi sama sekali tidak dapat digunakan untuk hal lain. Suatu hari nanti, Google Fiber akan membawakan saya pipa lemak raksasa dan ini tidak akan menjadi masalah, tetapi karena saya tinggal di daerah yang cukup pedesaan, itu tidak mungkin untuk sementara waktu.

Kurangnya kontrol unggahan ini merusak jaringan karena saya mematikan seluruh node sepenuhnya kecuali saya benar-benar terlibat dalam suatu transaksi. Bukankah lebih baik memiliki simpul yang lambat daripada tidak ada simpul?

sepertinya para pengembang berpikir semua orang memiliki googlefiber, ini memalukan, sungguh, ada X jenis layanan internet di seluruh dunia dengan batas unggah/unduh Y. Memaksa pengguna untuk melakukan sesuatu yang akan membahayakan internetnya sendiri adalah keputusan yang keterlaluan.

Belum lagi, begitu pengguna mengetahui apa yang memalu internetnya, keputusan paling umum adalah mematikan program yang menyebabkan masalah dan mengabaikannya, atau menggunakannya serendah mungkin, itu menjadi hal yang buruk alih-alih baik. hal. Ini adalah pemasaran yang buruk. Ini mengecewakan saya dalam banyak hal.

Bagaimana saya akan merekomendasikan ini kepada seorang teman mengetahui bahwa nanti teman yang sama akan datang kepada saya dan berkata "hei ingat program yang Anda suruh saya gunakan? Itu mengacaukan internet saya, membuatnya sangat lambat, saya bahkan tidak bisa lihat video utube dalam potongan, panggilan buruk tidak berguna". Setidaknya itu yang bisa terjadi, dan ini hanya contoh sederhana.

Seperti yang baru saja ditunjukkan cjastram, lebih baik MEMILIKI simpul yang lambat daripada TIDAK ADA simpul sama sekali. Jika para pengembang cukup cerdas untuk membuat kode yang futuristik dan canggih, saya yakin mereka sudah tahu semua yang kami tunjukkan di sini, tidak ada kata-kata lagi, saya sudah selesai.

@XcaninoX jadi, Anda mengatakan Anda mematikan mendengarkan seperti yang disarankan dan menggunakan 70kbytes/dtk keluar?

Secara pribadi, saya pikir pelambatan mengunggah apa adanya adalah ide yang buruk, setidaknya sampai kami meningkatkan mekanisme sinkronisasi blok. Jika Anda menabrak node yang terhambat saat menyinkronkan, sinkronisasi akan lambat.

Sebagai gantinya, saya pikir kita memerlukan mode "non server" (beberapa kotak centang, mungkin ditanyakan pada startup pertama), yang menonaktifkan blok penyajian (historis), menonaktifkan mendengarkan (secara default) dan menonaktifkan NODE_NETWORK (sehingga node tidak mengumumkan dirinya sebagai penuh tidak). Ini berarti orang masih dapat melakukan validasi dan menyampaikan bagian sebagai simpul penuh, tetapi tanpa implikasi bandwidth untuk melayani rantai penuh.

Kemudian, mode non-server seperti itu dapat diubah menjadi mode pemangkasan, di mana blok historis bahkan tidak disimpan di disk.

Secara pribadi, saya pikir pelambatan mengunggah apa adanya adalah ide yang buruk, setidaknya sampai kami meningkatkan mekanisme sinkronisasi blok. Jika Anda menabrak node yang terhambat saat menyinkronkan, sinkronisasi akan lambat.

Tentu saja, tetapi bukankah sinkronisasi lambat jika Anda menekan node yang memiliki bandwidth terbatas? Anda tidak secara ajaib mendapatkan sinkronisasi cepat hanya karena Anda tidak mengizinkan node kemampuan untuk mencekik. Masalahnya adalah jika Anda tidak mengizinkan pelambatan, maka Anda mendapatkan simpul _no_ karena orang hanya mematikannya.

Setelah beberapa saat orang hanya mematikannya, maka Anda mulai mendapatkan beban sinkronisasi besar-besaran pada sistem karena orang perlu menyinkronkan ratusan (atau ribuan) blok kapan pun mereka ingin melakukan transaksi BTC. Alih-alih beban sinkronisasi ringan yang terjadi secara realtime, Anda memiliki sejumlah kecil (tetapi signifikan) orang yang memerlukan banyak bandwidth sekaligus.

Oleh karena itu masalahnya. Jika kita bisa membiarkan BitCoin dihidupkan pada bandwidth rendah, maka kita tidak akan memiliki masalah sinkronisasi.

Sebagai gantinya, saya pikir kita memerlukan mode "non server" (beberapa kotak centang, mungkin ditanyakan pada startup pertama), yang menonaktifkan blok penyajian (historis), menonaktifkan mendengarkan (secara default) dan menonaktifkan NODE_NETWORK (sehingga node tidak mengumumkan dirinya sebagai penuh tidak). Ini berarti orang masih dapat melakukan validasi dan menyampaikan bagian sebagai simpul penuh, tetapi tanpa implikasi bandwidth untuk melayani rantai penuh.

Mungkin. Saya tidak tahu apa sebenarnya kejenuhan bandwidth unggahan saya, apakah itu konfirmasi transaksi atau sinkronisasi blok orang lain.

Kemudian, mode non-server seperti itu dapat diubah menjadi mode pemangkasan, di mana blok historis bahkan tidak disimpan di disk.

Mari kita mencoba untuk tidak merekayasa solusi yang lebih sederhana?

@cjastram Itu sebenarnya poin saya: Saya pikir lebih baik bagi orang yang tidak bisa atau tidak ingin melayani blok bersejarah untuk tidak melakukan itu sama sekali, dan bahkan tidak beriklan di jaringan yang mereka lakukan. Jika kita mengaktifkan pembatasan bandwidth tanpa itu, kemungkinan mengenai node yang lambat secara tidak sengaja akan meningkat, sementara jika kita menghapus node tersebut dari kumpulan sama sekali, kemungkinannya akan berkurang.

Orang-orang yang sepenuhnya mematikan node karena menjenuhkan tautan data mereka tentu saja buruk. Pembatasan atau penonaktifan penayangan akan meningkatkannya, tetapi Anda mendekati sumber daya yang ingin Anda belanjakan, mungkin Anda tidak harus menjalankan node penuh sejak awal.

Hanya menyampaikan transaksi dan blok baru biasanya bandwidthnya cukup rendah - hanya saja ketika Anda terkena node yang sedang menyinkronkan dari awal, Anda tiba-tiba mendapatkan ledakan unggahan.

Tentang over-engineering: kemampuan untuk menjalankan node yang dipangkas adalah evolusi yang tak terhindarkan di suatu tempat di masa depan, menurut pendapat saya, dan itu juga akan menyiratkan solusi untuk masalah Anda.

FWIW, saya dengan hormat tidak setuju, dan menurut saya solusi termudah adalah dengan menawarkan throttle unggahan opsional (yaitu mengirim atau menulis syscall). Sebuah throttle download kurang berguna: Anda tidak dapat benar-benar mengontrol jumlah data jarak jauh yang masuk; berhenti membaca(2) akan menyebabkan orang baik pada akhirnya mencekik, tetapi orang jahat selalu memiliki satu atau tiga teknik yang akan tetap membanjiri yang masuk. Dan di lapangan, pengguna tidak terlalu peduli untuk membatasi kecepatan unduh mereka daripada membatasi kecepatan unggah mereka.

Ini adalah kenop umum pada aplikasi penyajian data P2P lainnya, jadi saya akan ACK throttle unggah yang diimplementasikan dengan benar dengan kenop.

@jgarzik Maksud saya adalah bahwa saat ini kami lebih baik dengan node yang melayani lebih sedikit, jika itu berarti node tersebut lebih cepat. Setelah kami memiliki header-first, dan pengambilan rantai paralel, semuanya berbeda, dan mungkin siapa pun yang mau berkontribusi sedikit pengunggahan berguna.

OP di sini, sudah lama sejak membuat masalah ini dan selama 2 tahun terakhir klien bitcoin-qt saya sangat jarang memaksimalkan unggahan saya jadi saya tidak terlalu memikirkannya.

Namun baru-baru ini, dalam satu atau dua bulan terakhir saya perhatikan bahwa unggahan atau pengiriman data saya sering kali benar-benar maksimal! Saya memiliki koneksi yang layak, seperti unggahan 300-500KB/s. Untungnya saya berhasil menangkapnya berkali-kali dan saya membuka alat pemantauan jaringan dan mematikan port yang dimaksud (selalu bitcoin-qt). Saya harus berhati-hati karena jika berjalan pada kecepatan itu untuk jangka waktu yang lama, tidak hanya jaringan saya menjadi lambat tetapi juga akan menghabiskan kuota data saya dengan cepat.

Jadi sekarang alih-alih menjalankan simpul penuh selama ~8 jam sehari, saya membiarkannya menyinkronkan dengan jaringan dan kemudian mematikannya.

Jika saya memiliki opsi throttle, saya akan mengaturnya pada sesuatu seperti unggahan 50KB/s.. ini lebih cepat daripada yang pernah saya gunakan saat mengunduh blok terbaru (terikat CPU).

Saya pikir ini adalah masalah, saya ingin menjalankan node penuh, tetapi tidak akan menghabiskan 100% dari sebagian besar waktu unggahan saya.

@slothbag Sudahkah Anda menonaktifkan mendengarkan?

Tidak, saya belum. Saya sebenarnya ingin berkontribusi sebagai simpul mendengarkan penuh.
Jika saya akan menonaktifkan mendengarkan maka saya mungkin juga tidak repot dan biarkan saja
itu disinkronkan dan kemudian dimatikan.

Pada hari Rabu, 6 Maret 2013, Gregory Maxwell menulis:

@slothbag https://github.com/slothbag Sudahkah Anda menonaktifkan mendengarkan?

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/bitcoin/bitcoin/issues/273#issuecomment -14491575
.

@slothbag Sebagai node yang tidak mendengarkan, Anda masih menjadi kontributor jaringan— memvalidasi dan meneruskan transaksi dan blok baru, mencegah partisi... tetapi Anda tidak akan menggunakan banyak bandwidth. Batas kecepatan saat melayani blok historis akan sangat merusak jaringan saat ini, sebenarnya lebih baik Anda tidak menjalankan node daripada melayani blok historis dengan batas kecepatan. ... tapi lebih baik tetap berlari tanpa mendengarkan.

Saya mengerti bahwa apakah sebuah node mendengarkan atau tidak, tidak terkait dengan apakah node tersebut mengunggah blok atau tidak. Bahkan node yang tidak mendengarkan akan mengunggah blok jika node yang terhubung memintanya, bukan?

Daripada membatasi kecepatan unggah blok, apa yang mungkin lebih baik bagi node untuk mengidentifikasi apakah mereka adalah penyedia blok atau bukan pada koneksi pertama. Pembatas kecepatan bukanlah pilihan yang buruk selama batas kecepatannya tidak terlalu rendah - lagi pula, masih akan ada node di jaringan pada jaringan yang lambat dan itu akan selalu terjadi.

Bagi siapa pun yang ingin mengurangi dampak klien bitcoin-qt mereka, saya telah membuat perbaikan cepat, yang meminimalkan lalu lintas saat saya menggunakan jaringan wifi yang dikenakan biaya per megabita. Patch ini menambahkan opsi baris perintah, sehingga klien hanya mengunduh blok dan bukan transaksi, dan tidak mengunggah apa pun selain transaksi yang Anda buat. Kelemahannya adalah ini tidak sehat untuk jaringan secara keseluruhan, tidak akan menampilkan transaksi yang Anda pantau dari tempat lain sampai dimasukkan dalam blok, dan mengurangi anonimitas karena Anda hanya akan menyiarkan transaksi Anda sendiri. dan bukan milik orang lain. Selain itu, fitur peringatan juga dinonaktifkan, jadi Anda tidak akan melihat peringatan untuk peningkatan yang mendesak (bukan berarti ini dapat diandalkan dalam kasus hardfork 0,8 baru-baru ini!).

Idealnya ini akan dapat dialihkan dari dalam GUI atau bahkan dapat secara otomatis menghidupkan dan mematikan tergantung pada ISP yang Anda inginkan untuk mengaktifkannya, IMHO.

Oh, ini cabang yang disebutkan di atas: https://github.com/rebroad/bitcoin/commits/MinimizeTraffic

Saya masih berpendapat bahwa seharusnya ada cara agar node seperti ini (yang tidak menyampaikan txs dan blok) harus mengiklankan diri mereka sendiri seperti itu pada koneksi sehingga node lain dapat membuat keputusan yang tepat untuk memutuskan apakah akan terhubung ke node lain atau tidak yang menyampaikan. Tanpa iklan ini, node hanya bisa menebak berdasarkan frekuensi txs dan blok yang diterima dari node tersebut.

Saya pikir sistem throttle unggah berguna, dengan node mengiklankan bandwidth yang tersedia, dan node lain memvalidasi ini, dan informasi ini termasuk dalam informasi alamat yang diteruskan. Dengan cara ini, node dapat memilih node dengan bandwidth yang lebih besar, dan node dapat menghitung bandwidth yang tersedia berdasarkan berapa banyak node yang sedang diunggah atau diunduh. Bandwidth per koneksi dapat terus dipantau, dan koneksi berubah sesuai kebutuhan. Ini sudah menjadi sesuatu yang telah saya kodekan di cabang paralelblocksdownload saya, dan memungkinkannya untuk memilih berapa banyak node yang akan diunduh berdasarkan bandwidth yang diketahui tersedia. Jika menemukan bandwidth unggahan jenuh, itu hanya akan berhenti mengirim invs (ke node baru) sehingga node tersebut tidak meminta data darinya.

Saya pergi dan mencoba banyak opsi berbeda untuk mencekik bitcoin-qt secara eksternal tanpa hasil.

Saya mencoba menggunakan trickle di linux, namun seg-fault saat startup

Saya mencoba menggunakan iptables QoS untuk membentuk lalu lintas port 8333 inbound & outbound dan memiliki keberhasilan yang terbatas, kadang-kadang akan berhasil dan di lain waktu tidak sama sekali.

Saya mencoba menggunakan NetLimiter di Windows seperti yang disebutkan di atas, namun tidak menangani bitcoin-qt dengan baik, koneksi lalu lintas tinggi ditampilkan sebagai koneksi sistem UDP sehingga throttle tidak aktif.

Saya hanya sedikit curiga bahwa koneksi lalu lintas tinggi sebenarnya berbahaya, baik banjir sederhana atau eksploitasi buffer mungkin.. Saat melihat lalu lintas di Wireshark semua paket tampak identik??

Bagaimanapun, akan terus menyelidiki jika waktu memungkinkan.

Saya baru mengetahui mengapa bandwidth bulanan 150GB saya habis, 85gb adalah lalu lintas bitcoin upstream. Rata-rata 4gb sehari untuk ide yang rapi.

Sekarang saya melihat tidak ada dukungan untuk membatasi, jadi itu tidak diaktifkan kembali. Saya hanya benar-benar ingin tarif dibatasi hingga 64kb untuk sisa bulan ini dan tidak membayar lebih dari biaya.

Menurut Anda di mana blockchain itu hidup, apakah Anda mempercayai penjaganya?

Jangan mencekik blockchain, itu akan mati.

Jika ya, jangan mengeluh tentang kenaikan biaya transaksi, atau waktu yang diperlukan untuk konfirmasi atau konfirmasi transaksi sama sekali.

1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB
Terima kasih!

@memetica Saya mengerti maksud Anda, tetapi saya tidak menjalankan klien karena saya tidak mampu membuatnya menggunakan semua bandwidth saya.

Jadi apakah lebih baik memiliki beberapa node di jaringan yang lambat atau upload terbatas, atau hanya memiliki node "cepat"?

Mungkin saya seharusnya tidak menjalankan klien. Ketika saya berada di AS, kami memiliki bandwidth tidak terbatas sehingga bebannya tidak berarti. Tapi di "seluruh dunia" bandwidth tidak gratis, dan jika saya tidak memiliki kemampuan untuk membatasi eksposur saya, saya tidak siap untuk menjalankan klien. Dan saya cukup yakin idenya adalah untuk tidak memiliki semua server "cepat" di beberapa negara, karena itu membuat jaringan lebih lemah.

Hanya dengan mengatakan: "Dan saya yakin idenya adalah tidak memiliki semua server "cepat" di beberapa negara (...)"
Anda membuat poin saya.

Dengan membatasi /your/ bandwidth Anda membagikan pekerjaan kepada orang lain, yang juga akan membatasi mereka, &c.
Sampai Anda berakhir dalam skenario yang Anda yakini, bukan itu idenya.
Salut untuk Anda.

Jika Anda mencekik blockchain, Anda tidak mempercayai bitcoin. (Anda menganggapnya sebagai mencuri, pikirkanlah)

Semua ini bagus dan semacamnya, tetapi klien masih mengganggu kecepatan unduhan Anda.

Sebagai jawaban atas poster asli:
"Saya perhatikan suatu hari Bitcoin sedang memaksimalkan bandwidth unggahan saya di ADSL. Mungkin karena mengirim rantai blok ke sesama pengguna bitcoin (saya memiliki sekitar 65 koneksi saat itu)."

Jawaban sebenarnya telah diberikan oleh "luke-jr" yang memposting:
"QoS benar-benar pekerjaan router, tetapi saya kira router yang andal tidak terlalu umum :/"

Orang sinis sepertinya tidak pernah mau memberikan jawaban langsung :/

Dia bermaksud mengatakan, mungkin, bahwa seseorang sebaiknya mengeluh tentang router yang tidak mengikuti atau bahkan menerapkan standar pembentukan lalu lintas. Hanya mencentang kotak dan mengklik terapkan tidak berarti itu terjadi, bahkan pada /open/ hard- atau software. Bug siapa saja?
Meskipun dalam kasus terakhir mereka memiliki peluang lebih tinggi untuk ditemukan dan diperbaiki.

(pikiran saya agak puitis: bitcoin mengubah dunia oleh orang-orang yang mengeluh kepada pembuat jaringan bahwa bitcoin mereka tidak melalui cukup cepat)

Ini bekerja pada premis bahwa klien bitcoin-qt mematuhi standar QoS.
Yang merupakan klien poster asli. (Saya mengira dia troll pada awalnya)

Yang tampaknya dilakukan untuk waktu yang lama.
Meskipun lalu lintas baru-baru ini meningkat, setidaknya router saya, dengan ramah, memungkinkan saya melihat "bicara ted" saya dengan kecepatan penuh. Membatasi lalu lintas bitcoin? Ya! Tapi menurut bit QoS, yaitu. bandwidth saya adalah milik saya.

Alih-alih menunjukkan kepada pengembang bahwa untuk beberapa alasan atau lainnya lalu lintas bitcoin-nya telah meningkat (tindakan yang saya kira, mereka sudah tahu, atau dia gagal untuk memeriksa) dan memberi mereka setidaknya rincian sistem operasi dan versi klien digunakan... tidaaaak....

Fungsionalitas langsung ditawarkan: mencekik, tersedak. Bagaimana manusia.

"Solusi" ini telah diterapkan ke klien bittorrent.
utorrent (untuk menyebutkan satu) mengimplementasikan pembentuk lalu lintasnya sendiri.
Alih-alih mengeluh kepada pembuat router.

Jika tidak ada, atau hanya beberapa seeder untuk "pembicaraan ted" ini yang hanya ingin Anda lihat sekarang (atau dalam batas-batas tertentu), tidak ada "pembicaraan ted" untuk Anda saat ini (atau dalam batas-batas tertentu). Atau mungkin tidak pernah, benihnya sudah mati.

Sekarang jujur, berapa rasio share /your/ secara keseluruhan, apakah Anda membatasi unggahan? Apakah Anda masih menyemai "pembicaraan ted"?
Apakah Anda siklus port? Terima hanya koneksi terenkripsi, sehingga penyedia Anda tidak dapat mengendus protokol bittorent, untuk menjaga bandwidth tetap tinggi? Sudah menggunakan TOR? (walaupun, itu konyol: torrents over tor)

Itulah konsekuensinya.
Bittorrent, betapa indahnya, lumpuh hanya karena itu. Bukan karena disensor.
(Saya di Belanda dan tidak dapat mengakses bajak laut.com, tetapi DHT tampaknya bekerja dengan sangat baik, tetapi saya mendapatkan banyak "pembicaraan ted" palsu.)

Setiap bitcoin dapat dilacak, hingga 50 pertama (cukup cari blok 0) dan setiap bitcoin lainnya setelah itu. (jika Anda punya waktu; komputer punya)
Tidak ada hak cipta atau hak lain pada protokol atau nomor yang dikirim.
Selanjutnya lalu lintas BTC mungkin tidak, tidak dapat dibatasi atau diblokir. Itu legal, atau, tidak ilegal.

Saya tidak bisa tidak mengagumi bait dari para pengembang btc-core dengan mengucapkan semua Douglas Adams-y: "Ini adalah masalah orang lain".

Oke, dan sekarang untuk masalah sebenarnya:
Tidak ada yang /mewajibkan/ Anda untuk menjaga klien tetap berjalan!
Hog bandwidth Anda? Hentikan! Namun, perkirakan penundaan untuk memeriksa transaksi terbaru, jadi Anda tahu dari mana koin Anda berasal, dan dengan demikian dapat mempercayainya.

Anda tidak berjalan-jalan dengan dompet terbuka sepanjang hari bukan? Mendaftar dari mana semua uang Anda berasal?

Oh, dan tanyakan pada diri Anda pertanyaan ini "bitcoin menjadi uang atau sebaliknya?"
Apa pun itu, berhentilah mengeluh, pelajari cara memprogram, terapkan fitur ini di fork bitcoin-qt Anda.
Duduklah, dan lihat penerapannya ... atau tidak.

Kemudian dan baru setelah itu Anda memiliki hak untuk mengeluh, bersiaplah untuk pertempuran sekalipun. Anda harus benar-benar meyakinkan dan mampu menjelaskan /mengapa/ pelambatan itu bagus.

Saat "nadrimajstor" memilih: " (...) tambahkan argumen -nolisten"

Jika Anda tidak mendengarkan, tidak ada dialog. Maka transaksi anda batal..

:/

Einstein bisa saja berkata:

• "Jika kamu bisa menjelaskan masalahnya kepada nenekmu, kamu mengerti masalahnya,"

Jika Anda merasa telah mempelajari sesuatu:
1LwRoFi19fUWw4jtxEuQVXFNr29kd4mjmB

Jika Anda pikir saya harus diam:
15B4oqE6e2skviM67kSmAB3yp77GChjPnL

Terima kasih!

kutipan simeonpilgrim:
"di AS kami memiliki bandwidth tidak terbatas sehingga bebannya tidak berarti. Tapi di "seluruh dunia" bandwidth tidak gratis,"

Bitcoin tidak gratis, juga tidak berarti. Baca berita.

Mengapa Anda menempatkan tanda kutip di "seluruh dunia"?

dengan kutipan setengah poin ["Hanya dengan mengatakan: "Dan saya cukup yakin idenya adalah tidak memiliki semua server "cepat" di beberapa negara (...)"
Anda membuat poin saya.

Dengan membatasi /your/ bandwidth Anda membagikan pekerjaan kepada orang lain, yang juga akan membatasi mereka, &c.
Sampai Anda berakhir dalam skenario yang Anda yakini, bukan itu idenya.
Salut buat kamu."]

Anda membuat poin dengan kehilangan poin saya, bahwa jika saya tidak menjalankan server Anda di posisi yang sama. Saya mengulangi augment Anda untuk membantu menjelaskan maksud saya, dan Anda baru saja melihat augment Anda dan tampaknya berhenti membaca untuk pemahaman..

Jadi apakah lebih baik memiliki server yang cepat dan lambat, atau hanya cepat?

Saya setuju QOS adalah solusinya. Fakta bahwa router yang disediakan ISP saya tidak melakukan QOS dan saya tidak ingin membeli router kedua untuk bersarang di belakangnya untuk melakukan QOS adalah masalah saya.

Mungkin pertanyaan sebenarnya adalah: Apakah Anda ingin banyak orang menjalankan klien?

Jika demikian, buatlah mereka lebih mudah. Jika tidak, lanjutkan.

Saya telah menghentikan klien karena a) Saya tidak memiliki QOS, b) Saya sibuk dengan proyek OS saya sendiri, dan c) Saya tidak terlalu peduli tetapi proyek ini, rasio bunga terhadap biaya menjadi tinggi.

Saya mendapatkan seluruh OS memecahkan masalah Anda sendiri, atau cukup. Saya berasumsi Bitcoin menginginkan efek jaringan, sehingga umpan balik mungkin diinginkan.

Maaf Anda melewatkan poin saya.

Tapi ini, jawaban untuk Anda.

Meskipun saya tidak yakin apakah diskusi ini diizinkan di utas seperti ini.

Tidak masalah jika Anda menjalankan klien atau tidak.
Jika Anda ingin berdagang bitcoin, Anda harus menjalankan klien.
Jika Anda tidak ingin memperdagangkan bitcoin, jangan jalankan klien.

Anda bertanya:
"Mungkin pertanyaan sebenarnya adalah: Apakah Anda ingin banyak orang menjalankan klien?"

Apa yang tidak kamu mengerti? Saya ingin semua orang menjalankan klien, terlebih lagi, saya ingin semuanya menjalankan klien!
Saya ingin dapat membayar dengan bitcoin, dan ingin konfirmasi pembayaran saya segera.

Apakah Anda klien atau bukan, saya ingin Anda mengkonfirmasi transaksi saya, seolah-olah Anda ada di sana. Apa yang begitu sulit tentang itu?

Melihat maraknya bitcoin, sepertinya banyak orang juga menginginkannya. Jadi mengapa Anda menunda atau bahkan menyangkal (--nolisten) itu?

Anda bertanya:
"Jadi lebih baik memiliki server yang cepat dan lambat, atau hanya cepat?

Dan saya telah berulang kali menjelaskan tidak ada perbedaan, Anda tampaknya tidak mengambil konsepnya.

Terkadang Anda mengalami kemacetan, ketika banyak transaksi terjadi.
Mengapa jalan-jalan hanya macet antara jam 9 dan 5 (yah saya hanya bisa berbicara untuk holland tentu saja)
Solusi yang biasa adalah jalan yang lebih besar, tetapi itu tidak berhasil, mereka juga penuh.
Di sini solusinya adalah mencekik saluran masuk kendaraan, tetapi itu hanya memindahkan masalah ke saluran masuk.
Jadi sekarang kemacetan di desa-desa (Di mana tidak boleh, anak-anak dan sebagainya). Dan butuh selamanya untuk mendapatkan di jalan bebas hambatan ... menggunakan bahasa sehari-hari Amerika "Anda tahu apa yang saya maksud?")

Saya yakin Anda telah memperhatikan kenaikan nilai bitcoin yang tidak masuk akal?

Hanya ada sekitar 21.000.000 bitcoin

Masalah bandwidth teratasi dengan sendirinya. setelah 2020 itu hanya menambang dompet yang hilang.

Tidak, pertarungan sebenarnya adalah ukuran balok....

Jika Anda masih tidak mengerti saya, maka jelaskan kepada saya mengapa Anda ingin dompet Anda online 24/24 tanpa membayarnya.

Tapi ingat ini.

Bitcoin membutuhkan uang, apakah Anda pernah memperdagangkan bitcoin?

Saya tidak berpikir diskusi ini produktif pada saat ini. Solusi teknis terbaik menemukan cara untuk mengatasi _kebutuhan_ semua orang dan, bahkan jika saya sendiri terkadang merasa bersalah, sulit untuk mencapainya dengan argumen bahwa keinginan mereka bodoh atau salah. Apa yang dibutuhkan di sini bukanlah perdebatan lagi, yang dibutuhkan adalah lebih banyak implementasi dan pengujian bahkan jika beberapa "implementasi" hanyalah salinan yang bagus untuk membantu orang memahami bagaimana mereka dapat memainkan peran penting dalam menjaga jaringan tetap sehat.

(Sunting: Saya menghapus posting oleh mimetica meminta dana untuk tutup mulut)

Ini benar-benar tidak dapat diselesaikan sampai sistem unduhan riwayat diperbaiki, jadi
bahwa satu klien dapat mengunduh dari beberapa rekan, gaya bittorrent. Atau
setidaknya memungkinkannya untuk mendeteksi rekan yang lambat dan mencari yang lebih baik.

Mungkin metode sederhana mencegah klien mengunggah ke lebih dari
satu rekan setiap saat secara default mungkin membuat hal-hal kurang dari masalah.

Semua upaya mental di utas ini perlu beralih ke pengembangan yang benar
Ekstensi protokol unduhan P2P.

Pada 11 April 2013 13:29, Gregory Maxwell [email protected] menulis:

Saya tidak berpikir diskusi ini produktif pada saat ini. Terbaik
solusi teknis menemukan cara untuk mengatasi _kebutuhan_ semua orang dan, bahkan jika
Saya sendiri terkadang merasa bersalah, sulit untuk mencapainya dengan
argumen bahwa keinginan mereka bodoh atau salah. Yang dibutuhkan di sini tidak lebih
perdebatan, yang dibutuhkan adalah lebih banyak implementasi dan pengujian bahkan jika beberapa dari
"implementasi" hanyalah salinan yang bagus untuk membantu orang memahami bagaimana mereka bisa
memainkan peran penting dalam menjaga jaringan tetap sehat.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/bitcoin/bitcoin/issues/273#issuecomment -16215243
.

Oh, apakah saya jatuh cinta pada troll, atau apakah Anda tidak mengerti semua tentang bitcoin?

Mungkin metode sederhana mencegah klien mengunggah ke lebih dari satu rekan kapan saja secara default dapat membuat masalah menjadi lebih ringan.

....
Saya tidak punya apa-apa lagi untuk dikatakan pada kebodohan seperti itu

Anda berada di padang rumput, pintu keluarnya adalah n,e,s,w
Ada penyihir, dia berkata: "Pergilah ke Utara"

(langkahmu)

Saya bukan orang Amerika, tetapi saya tahu bahwa Jefferson berkata: Dia yang mengorbankan kebebasan demi keamanan, tidak pantas mendapatkan keduanya.
Dan saya setuju dengan itu!

maaf untuk berteriak (di luar topik)

(Sunting: Saya menghapus posting oleh mimetica meminta dana untuk tutup mulut)

Kata saya! BISAKAH ANDA MEMBACA!

mEmetica

(Sunting: Saya menghapus posting oleh mimetica meminta dana untuk tutup mulut)

Bagaimana:
Jika Anda menyukai argumen saya:
123456554335

berbeda dari
1dice9wVtrKZTBbAZqz1XiTmboYyvpD3t

Saya baru saja memposting nomor, kapan saya meminta dana?

Sebuah balasan bisa menjadi "yeah man, saya baru saja mengirim zillions untuk itu".

Melihat? kelompok yang salah, orang yang salah.

Kamu yang tidak mengerti kebebasan sejati jika itu menghantam wajah mereka!

Sehat! berzina Anda!

(Sunting: Saya menghapus posting oleh mimetica meminta dana untuk tutup mulut)

Whoohoo

Jadi apa, tidak ada dana untuk saya tutup mulut?
Di pos yang sama saya meminta dana apakah Anda belajar sesuatu,

Saya kira Anda tidak

Semua upaya mental di utas ini perlu dialihkan untuk mengembangkan ekstensi protokol unduhan P2P yang sebenarnya.

Terima kasih robbak!

Tapi apa sebenarnya yang Anda maksud?

Apa itu "ekstensi protokol unduhan p2p sejati"

Orang yang kamu bully ke orang lain? MS telah melakukan itu selama bertahun-tahun, dan tampaknya berhasil.
Anda tahu kata kuncinya, tapi sayangnya gagal memahami artinya.

Semua upaya mental di utas ini harus menghentikan utas ini!
Tidak ada lagi kenaikan lalu lintas keluar yang tiba-tiba, ini hanya bitcoin!
Biarkan mereka pergi!

Lucu... Saya masuk ke utas ini karena saya mencatat bahwa simpul saya menggunakan _banyak_ bandwidth unggahan.... Saya mengerti p2p cenderung melakukan itu, khususnya karena lebih banyak orang "membutuhkan" informasi dari jaringan... tapi ini juga terjadi ketika Anda memiliki _kurang_ orang dalam jaringan (karena ada lebih sedikit tempat untuk mengunduh). Saya memiliki kuota bw bulanan di mesin tempat saya menjalankan bitcoind.

Dari pemahaman saya, semakin banyak node, semakin andal jaringan ini (atau semakin kecil kemungkinan bahwa beberapa individu atau institusi dapat mengambil alih jaringan bitcoin dengan mengendalikan sebagian besar node), saya dapat menambahkan QoS untuk membatasi bitcoind (dan saya akan , Anda yakin saya akan melakukannya), namun, rata-rata pengguna tidak tahu bagaimana melakukannya. Menambahkan pengaturan sederhana yang membatasi penggunaan bitcoind bw hanya akan mendorong orang untuk menjalankan klien.... untuk saat ini, daemon turun sampai saya mendapatkan waktu untuk mengkonfigurasi QoS, namun, jika ada cara yang lebih sederhana untuk mencekiknya _now_, itu akan terus berjalan, 24/7.

Saya sama sekali tidak tertarik dengan koin (saya pertama kali mendengar tentang proyek ini beberapa tahun yang lalu), saya baru saja menemukan idenya menarik, dan berasumsi bahwa menambahkan lebih banyak node "jujur" ke jaringan akan bagus.... tampaknya Anda tidak terlalu peduli tentang itu, Anda hanya ingin "beberapa node cepat" alih-alih _banyak_ node yang tidak terlalu cepat. Saya pikir "semakin banyak yang terbaik" untuk sistem semacam ini ... tapi mungkin saya salah.

@soulhunter Tampaknya ada sedikit kebingungan di sini.

Tentu saja kita membutuhkan banyak node jika kita menginginkan sistem yang terdesentralisasi. Tapi kami terutama ingin banyak node yang memvalidasi - keuntungan utama Bitcoin dibandingkan mata uang lain (menurut saya) adalah bahwa saya tidak perlu mempercayai siapa pun untuk mengetahui bahwa tidak ada yang curang. Jika lebih mudah untuk menjalankan simpul seperti itu, semakin sedikit orang yang tidak perlu melakukannya.

Namun, untuk mem-bootstrap node baru, perlu ditunjukkan riwayat status saat ini, sehingga node tersebut juga dapat menilai secara independen bahwa tidak ada yang curang di masa lalu. Jadi, kita membutuhkan cara untuk memberi mereka riwayat ini, dan itu disediakan oleh node lain di jaringan yang juga pada beberapa harus mengunduh riwayat itu. Idealnya, kami juga memiliki ini sebanyak mungkin. Tapi kenyataan tidak sempurna. Tidak semua orang ingin mengorbankan hulu mereka untuk melakukan ini, sementara yang lain memiliki banyak cadangan. Dan, dengan penerapan buggy saat ini, jika Anda secara tidak sengaja menekan rekan yang lambat untuk mengunduh, Anda akan mengalami unduhan yang lambat. Kami tidak memiliki mekanisme untuk mencari rekan yang baik atau memparalelkan unduhan. Jadi, selama mekanisme sinkronisasi tidak ditingkatkan, ya semua orang lebih baik dengan sedikit pengunggah yang lebih cepat daripada banyak pengunggah yang lebih lambat. Perhatikan bahwa ini hanya tentang menyajikan blok historis kepada orang lain - Anda dapat dengan sempurna memvalidasi semua blok dan transaksi, dan berpartisipasi sebaliknya dalam jaringan tanpa menyediakan layanan itu.

Apakah saya memahami dengan benar bahwa riwayat TIDAK diunduh peer-to-peer? Apakah saya membaca dengan benar bahwa itu diunduh dari SATU rekan? Jika demikian, itu menjelaskan seluruh masalah. Itu benar-benar perlu diunduh peer-to-peer: apa yang penting jika Anda hanya memiliki unggahan 10kbit jika ada 100 lainnya di dalam radius jaringan yang masuk akal untuk ditarik?

Apakah saya memahami dengan benar? Karena itu membuat semua perbedaan di dunia.

@cjastram Saya tidak yakin apakah Anda mengerti dengan benar. Jika ya, Anda menggunakan definisi peer to peer yang sangat aneh. Blok diunduh dari rekan acak, tetapi saat ini semuanya diunduh dari satu rekan. (karena cara kerja proses pada dasarnya adalah "beri tahu saya apa yang tidak saya miliki" daripada "inilah yang saya lewatkan").

Dan ya, ini benar-benar perlu ditingkatkan dan itulah mengapa Anda memiliki Pieter dan saya mengatakan bahwa sementara kami mendukung memiliki semua jenis kenop untuk mengontrol penggunaan sumber daya, perilaku pengambilan perlu diubah terlebih dahulu.

@gmaxwell saya mengerti, saya kira saya membacanya dengan benar. Apakah ada cara untuk menambahkan masalah itu sebagai blok untuk masalah ini, jadi lebih jelas bahwa yang lain harus dilakukan terlebih dahulu?

+1 untuk menambahkan pelambatan. Bitcoin-qt baru saja mematikan jaringan wifi rumah saya dan saya butuh 20 menit untuk mencari tahu apa yang sedang terjadi. Klien menggunakan semua bandwidth unggahan saya yang tersedia (1mb/s) dan saya tidak dapat menggunakan web. Yaitu pisang. Saya senang untuk menyumbangkan sebagian dari bandwidth saya, tetapi tidak semuanya. Tidak ada alasan harus semuanya atau tidak sama sekali.

Saya tidak dapat lagi menjalankan klien penuh kecuali beberapa jam seminggu karena masalah ini. Masalah ini akan mencegah pengguna rumahan atau pemula menjalankan klien penuh. Sesuatu yang sederhana seperti (batas unggahan X kb/dtk) sudah cukup.

@soundasleep Sudahkah Anda mematikan mendengarkan koneksi masuk? Jika tidak, itu akan memungkinkan Anda untuk menjalankannya dengan dampak yang lebih kecil sampai ada fasilitas lain yang tersedia.

@gmaxwell dari apa yang saya mengerti itu hanya akan mengurangi kemungkinan koneksi saya menjadi jenuh, dan dengan hanya 0,8 Mbps unggahan (yang bentuknya buruk, tidak disediakan dengan baik dan juga dibatasi) saya ragu itu akan menyelesaikan apa pun karena satu rekan dapat dengan mudah menjenuhkan itu . Saya akan mencobanya tetapi saya masih tidak dapat menjalankan klien secara penuh.

luke-jr benar sekali ketika mengatakan "QoS benar-benar pekerjaan router, tapi saya kira router yang andal tidak terlalu umum", ini hanyalah fakta.

Pengembang harus menyadarinya dan memperbaiki masalah ini secepatnya sehingga semua jenis pengguna (sangat kelas bawah ~ sangat kelas atas) masih dapat menggunakan program tanpa keluar dari zona nyaman mereka. Setidaknya selama 20 tahun, jadi mungkin saat itu, semua orang di Bumi akan memiliki router dengan kode QoS bawaan yang layak dan juga internet fiber untuk menangani semua data throughput.

Tapi sekarang, apa adanya, ini seperti misi bunuh diri IMHO, ini membuat saya sangat sedih dan marah dan kecewa secara bersamaan sehingga saya bahkan tidak bisa menjelaskan dengan kata-kata bagaimana perasaan saya tentang ini. Yang saya tahu adalah keputusan untuk tidak menambalnya dan membiarkannya apa adanya, adalah keputusan yang keterlaluan.

Pada 02/05/13 23:42, soundasleep menulis:

Saya tidak bisa lagi menjalankan klien penuh kecuali beberapa jam seminggu karena
dari masalah ini. Masalah ini akan mencegah pengguna rumahan atau pemula dari selamanya
menjalankan klien penuh. Sesuatu yang sederhana seperti (batas upload X
kb/sec) sudah cukup.

Yah, saya sebenarnya tidak punya masalah menjalankannya di rumah, beberapa QoS adalah
cukup .... namun, masalah saya ada di server, saya memiliki BW bulanan
batasi di sana, dan klien hanya akan menggunakan kecepatan unggah 100Mbps penuh
kapan pun dia mau (!), saya akan dengan senang hati memberikannya unggahan 3 hingga 7Mbps
(dengan begitu saya tidak bisa kelebihan kuota).

Ildefonso.

@XcaninoX tanggapan Anda bingung dan sangat tidak sopan. Aku bukan budakmu. Memiliki lebih banyak opsi untuk ini di masa depan adalah baik, dan terencana, seperti yang telah dijelaskan berulang kali tetapi tidak sepele untuk diterapkan dan karenanya akan menunggu seseorang yang punya waktu untuk mengerjakannya.

@soulhunter hampir semua bandwidth digunakan dengan memasukkan data historis ke node yang baru dimulai. Demikian saran untuk menonaktifkan mendengarkan jika bandwidth Anda terbatas sehingga Anda tidak akan melakukan ini. Tanpa memberi makan node baru, pemanfaatan rata-rata maksimum berada di urutan 100kbit/sec atau lebih.

@gmaxwell Saya minta maaf jika saya menghina Anda dengan cara apa pun, itu pasti bukan dan bukan niat saya, meskipun saya tidak pernah benar-benar melihat atau memperlakukan Anda sebagai budak saya, saya minta maaf jika Anda berpikir begitu.. Pendapat saya tentang masalah ini berlaku , untuk lebih jelasnya, saya hanya mengungkapkan sudut pandang saya, hanya mengatakan apa yang ada dalam pikiran saya, berbagi bagaimana saya melihat segala sesuatunya sekarang dan bagaimana menurut saya seharusnya, hanya meletakkan kartu di atas meja dan berdiskusi mereka, itu saja.

@XcaninoX OKE. Saya tidak tahu apa lagi yang perlu ditangani pada dasarnya semua orang setuju bahwa harus ada kontrol sumber daya yang lebih baik. Tetapi menyetujui bahwa mereka harus ada tidak membuat mereka terjadi secara instan.

Pada 03/05/13 00:13, Gregory Maxwell menulis:

@soulhunter https://github.com/soulhunter hampir semua bandwidth
digunakan dengan memasukkan data historis ke node yang baru dimulai. Jadi
saran untuk menonaktifkan mendengarkan jika bandwidth Anda terbatas
bahwa Anda tidak akan melakukan ini. Tanpa memberi makan node baru rata-rata maksimum
pemanfaatan berada di urutan 100kbit/sec atau lebih.

Ya, tetapi tetap memberi makan data historis diperlukan, karena jika tidak
bagaimana node baru akan ditambahkan? (ini adalah bagian dari alasan mengapa saya
menjalankan klien di server, untuk menjaganya 24/7 dan membantu jaringan).
Juga, menonaktifkan "masuk" tidak secara ajaib memperbaikinya, karena Anda bisa
masih masuk ke node yang tidak lengkap melalui koneksi keluar (walaupun
kemungkinannya akan sangat berkurang). Bagaimanapun, sejauh ini, jumlah
BW yang dimakannya tidak _itu_ besar (hanya "berduri"). Saya akan tetap menjalankannya
selama beberapa minggu lagi dan mari kita lihat (sepertinya akan menggunakan
~500GB/bln, saya mampu membelinya, untuk saat ini).

Mengapa tidak menerapkan sesuatu yang sederhana?

1. Tambahkan opsi batas unggah BW dasar (ada beberapa cara melakukannya
   ini, saya tidak akan menguraikannya sekarang).
2. Saat klien mengunduh, dan memiliki lebih dari 1 rekan, seharusnya
   unduh dari rekan yang diberikan selama N detik (katakanlah: N=300), lalu pindah ke
   yang berikutnya dalam skema round-robin (atau bahkan acak). Cara ini diberikan
   klien tidak akan "terjebak" pada satu rekan lambat, tetapi kemungkinan akan bergerak
   dari rekan cepat ke lambat saat mengunduh, dan menyebarkan beban unduhan.

Bagaimana menurut anda?

Ildefonso.

Jika seseorang membayangkan blockchain sebagai file torrent 7GB+, apakah ada yang menghentikan kita dari menggunakan ide arsitektur bittorrent untuk mem-bootstrap klien? @jgarzik sudah menerapkan ide ini terlepas dari klien di sini . Saya menduga bahwa membuat klien membengkak dengan menautkan ke libtransmission atau sejenisnya tidak dapat diterima (atau akankah?). Mungkin juga tidak aman. Ini mungkin memecahkan beberapa masalah yang terkait dengan bandwidth dan manajemen batas data.

Mungkin sebagai eksperimen independen, seseorang (saya?) harus mencoba menerapkan tambalan untuk menanggapi hanya permintaan data historis di luar tanggal atau nomor blok tertentu. Saya kira sebagian besar teman sebaya benar-benar ketinggalan zaman (memerlukan seluruh riwayat) atau hanya satu atau dua minggu kedaluwarsa. Saya benar-benar mengada-ada, jadi saya bisa sangat salah, tetapi sepertinya tebakan yang masuk akal. Dengan asumsi ini benar, sebagian besar rekan dapat dilayani dengan menetapkan filter tanggal beberapa minggu yang lalu, dan mengharuskan rekan baru untuk menggunakan torrent Jeff Garzik atau mekanisme lain apa pun yang mungkin tersedia. Ini tidak membantu klien baru, tetapi mungkin penggunaan bandwidth yang mudah.

IMHO, ini harus menjadi opsi konfigurasi GUI sederhana yang mirip dengan opsi untuk mengonfigurasi tor - yaitu memutuskan apakah akan menyediakan fungsionalitas jaringan penuh, atau fungsionalitas terbatas. Jika itu tidak menjadi bagian dari klien "utama", maka seseorang kemungkinan akan menyediakan garpu yang melakukannya, dan kemudian klien "utama" perlu memenuhi keberadaan klien alternatif ini - mis. melayani getblock/getheader yang diabaikan permintaan.

Saya juga sedang mengalami masalah ini. Saya pribadi sama sekali tidak keberatan menggunakan penanganan ini di pihak saya daripada menjadikannya bagian dari protokol bitcoin. Jika ada yang tahu port bitcoin apa yang digunakan, saya akan dengan senang hati mencekiknya. Saya menggunakan Tomat sebagai router WiFi saya dan saya yakin itu cukup berfitur lengkap untuk menyediakan fungsionalitas untuk melakukan ini - asalkan portnya bukan port 80, tentu saja, karena saya tidak akan membatasi lalu lintas web standar hanya demi bitcoin, tapi saya akan terkejut jika itu masalahnya.

Sudahlah, cukup googling dan temukan jawaban untuk pertanyaan saya sendiri di FAQ bitcoin. Bagi siapa saja yang tertarik, port yang digunakan Bitcoin adalah port 8333. Jika ada orang lain di sini yang menggunakan Tomat, saya akan dengan senang hati memposting instruksi untuk membatasi port ini setelah saya mengetahui cara melakukannya. Beri tahu saya jika ada minat.

Masalahnya adalah bitcoin akan membuat koneksi keluar ke port mana pun yang mungkin dikatakan oleh rekan penggunaannya, jadi 8333 akan menangkap sebagian besar lalu lintas tetapi tidak semua.

Mungkin mendeteksi port menggunakan uPnP atau sesuatu ... Terlalu sulit, saya menunggu fungsi throttle :)

bitcoin akan membuat koneksi keluar ke port mana pun yang mungkin dikatakan oleh rekan penggunaannya

Tidak. Itu hanya akan mencoba rekan-rekan non 8333 jika tidak berhasil terhubung pada 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.

Saya belum membaca kodenya, jadi saya tidak bisa mengomentari apa yang klien bitcoin inti lakukan sendiri, tapi ini akan lebih masuk akal daripada apa yang dikatakan slothbag. Terutama karena port yang digunakan adalah apa yang saya dapatkan langsung dari wiki bitcoin, saya pikir mereka akan mengatakan lebih banyak jika yang mereka maksud adalah "sebagian besar menggunakan port 8333."

Batasi kecepatan unggah bitcoind

Lucu dan menyedihkan bahwa kalian tidak mengerti bahwa menjalankan node dengan batas bandwidth upload lebih baik daripada tidak menjalankan node. Tidak menjalankan node Bitcoin tampaknya menjadi alternatif yang disukai para pengembang dan saya baik-baik saja dengan tidak melakukan itu.

Pertimbangkan ini: Anda memiliki serat dan ADSL dan Anda menjalankan tor, i2p, klien bittorrent dan mungkin beberapa hal lainnya. Semua hal ini - pada dasarnya semua perangkat lunak SANE P2P - memungkinkan Anda menetapkan batas bandwidth unggahan sehingga Anda dapat menjelajahi web dan melakukan hal lain dengan koneksi Anda secara normal. Kemudian Anda memiliki bitcoind yang pada dasarnya mencoba menggunakan 100% koneksi Anda dan membuat segala sesuatunya terhenti. Kebanyakan orang hanya akan melihat bitcoind sebagai sesuatu yang tidak memiliki fitur paling dasar yang dimiliki semua perangkat lunak P2P lainnya (kemampuan untuk mengatur port port, membatasi jumlah koneksi, bandwidth dll) dan tidak menjalankannya.

Saya melihat bug ini berumur 3 tahun. Saya akan memeriksa kembali dalam 3 tahun untuk melihat apakah para pengembang yang menentang pembatasan bandwidth telah mengetahui bahwa memiliki banyak node dengan batas bandwidth lebih baik daripada hanya memiliki beberapa node bandwidth tinggi dengan koneksi khusus saat itu. Saya kira mereka tidak akan tetapi orang bisa berharap.

@oyvinds sepertinya saya salah menempatkan tambalan Anda. Bisakah Anda mengirim ulang? FWIW, (dan saya tidak tahu apakah Anda benar-benar peduli dengan teknologi atau hanya di sini untuk mengeluh) tidak ada yang menentang batasan. Ada perubahan yang diperlukan sebagai prasyarat untuk memiliki batas dan sekarang hampir selesai (tajuk pertama memiliki beberapa perubahan persiapan di 0.9 dan harus diselesaikan di versi berikutnya). Jika Anda mengalami masalah dengan penggunaan dengan segera, Anda dapat menyetel listen=0 di bitcoin.conf dan menghentikan 95% lalu lintas keluar yang meledak segera tanpa dampak buruk pada jaringan, ini adalah rekomendasi untuk solusi jangka pendek— tidak gagal untuk menjalankan sebuah simpul.

@gmaxwell Snark tidak produktif. Tapi itu telah mengilhami saya untuk menjawab.

Saya tidak mengerti mengapa ini sangat sulit untuk ditambal. Di sini, izinkan saya mencoba membantu dan pragmatis.

Kontrol berbutir halus pada bandwidth unggahan tidak diperlukan. Hanya penggeser yang memungkinkan kita menambahkan "tidur" di antara setiap pengiriman paket. Slider akan memungkinkan kita menambah panjang tidur. Ini akan memberikan pembatasan laju yang kasar tetapi efektif tanpa memerlukan banyak waktu pengembangan. Apa itu, seperti satu jam pengembangan untuk memperbaiki masalah #1 yang mencegah orang menjalankan bitcoind?

@dwest-trulia Silakan baca pesan saya sendiri dan orang lain yang berpengalaman dengan protokol Bitcoin di utas, ini telah dibahas sebelumnya. Terima kasih.

@gmaxwell Saya mencari utas untuk kata "tidur" dan tidak dapat menemukan ide saya atau sanggahannya. Saya memang menemukan beberapa argumen filosofis yang menentang pembatasan tarif secara umum dan gagasan setengah matang untuk mematikan mendengarkan (yang tidak cukup andal bagi orang untuk mengaktifkan bitcoind dengan percaya diri). Sempurna adalah musuh kebaikan. Saya akan terus tidak menjalankan bitcoind sampai baik atau sempurna.

Mematikan mendengarkan cukup andal, karena node yang kami hubungkan sudah memiliki blockchain. Tidak ada argumen filosofis sama sekali, _tidak ada yang menentang pembatasan nilai secara filosofis. Tetapi karena cara protokol Bitcoin saat ini bekerja, batas kecepatan sangat parah menyerang rekan-rekan DOS. Lebih baik untuk tidak menghubungkannya dengan Anda sekarang, meskipun itu sedang diperbaiki.

@gmaxwell Saya tidak menyadari ada potensi masalah DOS. Menarik.

Tidak ada yang menentang koneksi pembatas kecepatan seperti itu.

Masalahnya adalah mekanisme pengambilan saat ini cukup bodoh, dan umumnya berurusan dengan sangat buruk dengan dicekik. Jadi sampai itu diperbaiki, ya, saya percaya tidak menjalankan simpul (yang dapat dijangkau) lebih baik daripada menjalankan simpul yang dibatasi.

Ketika kami telah memperbaiki algoritme sinkronisasi (lihat #3077, #3083, #3087, #3276, #3370, #3514, #3884 untuk pekerjaan ke arah itu, serta versi lama #2964), saya akan dengan senang hati ACK setiap patch untuk meningkatkan pembentukan bandwidth di bitcoind.

@gmaxwell

Jika Anda mengalami masalah dengan penggunaan segera, Anda dapat mengatur listen=0

Tidak membantu. Pada koneksi 8/1mbps (turun/naik) bitcoin-qt akan melakukan DoS sendiri dengan mengunggah begitu banyak hal sehingga sistem tidak memiliki internet lagi. Tidak sama sekali. Ping tidak akan tertunda; mereka baru saja kehabisan waktu. Layanan seperti LogMeIn melaporkan tidak ada lagi konektivitas internet dan penjelajahan pada dasarnya menjadi tidak mungkin.

Saat ini, setahun kemudian setelah komentar saya sebelumnya di sini, saya memiliki koneksi serat dan bahkan dengan listen=1 semuanya berfungsi dengan baik, tetapi tidak menyenangkan harus menjalankan bitcoin-qt (untuk mengejar rantai) secara eksklusif sementara keluarga saya yang lain sedang tidur.

@lucb1e Sangat disayangkan bahwa Anda tidak menawarkan pengamatan itu saat Anda masih memiliki pengaturan untuk mereproduksinya. Saya tidak dapat mereproduksi dan memiliki beberapa node listen=0 untuk pengujian dan tidak ada yang melihat penggunaan bandwidth tinggi.

@gmaxwell Ya, saya seharusnya menunjukkannya sebelumnya. Saya pikir saya ingat berkomentar bahwa bitcoin-qt mematikan koneksinya sendiri, tetapi sepertinya saya salah ingat. Maaf tentang itu. Apa yang saya katakan masih berlaku: bahkan mendistribusikan blok saat mereka melintasi jaringan adalah banyak data.

Melihat blockchain.info sekarang, 20 menit yang lalu ada blok 0,9MB. Times 7 (satu rekan harus sudah memilikinya) membuat unggahan 6MB. Pada koneksi saya sebelumnya yang menyebabkan lebih dari 1 menit tidak ada internet.

Melihat angka-angka ini, cukup jelas bahwa menjalankan node bitcoin penuh pada koneksi seperti itu tidak akan membantu siapa pun. Tapi saya tidak perlu menjadi full node, saya hanya ingin menjalankan klien bitcoin resmi (atau mungkin saya harus mengatakan "umumnya memimpin") dengan rantai blok saya sendiri. Memiliki tombol untuk tidak mengunggah blok dan/atau tidak mengunggah transaksi akan sangat membantu. Ini dikatakan menyebabkan masalah DoS, tetapi menurut saya itu masalah di klien ini dan bukan masalah jaringan: siapa pun dapat mengatur dan mengiklankan banyak node jahat yang tidak pernah melakukan apa pun. Node yang tidak mendengarkan harus memutuskan rekan yang tampaknya hanya lintah karena mereka mungkin mencoba memperlambat atau mengganggu jaringan.

Alih-alih menilai membatasi koneksi masuk (yang akan membuat pengalaman sinkronisasi yang buruk bagi pengguna lain), apakah layak untuk menetapkan batas harian, dan tidak menerima lebih banyak koneksi setelah batas tercapai? Ini akan membuat saya menjadi node yang berpartisipasi penuh beberapa waktu, dan menghindari memicu kebijakan pembatasan "penggunaan wajar" ISP saya.

Preferensi saya akan menjadi seperti ini:

Node penuh: Melayani semua blok bersejarah
Node terbuka: Melayani 1008 blok terakhir
Node tertutup: Tidak melayani blok

Saya bosan melampaui batas data 300 GB per bulan yang melayani blok bitcoind dan jadi saya mencari cara untuk menilai batas bitcoind. Saya tidak pernah menemukan solusi yang baik.

Karena para pengembang belum memberi kami kemampuan untuk menilai batas dalam daemon, saya memutuskan untuk menggunakan iptables untuk menegakkan batas. Jika itu membantu orang lain, aturan di bawah ini adalah yang saya gunakan. Sangat menyakitkan untuk memperbarui setelah offline untuk sementara waktu, tetapi berfungsi dengan baik setelah Anda disinkronkan.

// Nilai batas outbound bitcoind (kita harus mendapatkan port sumber dan tujuan 8333)
-A OUTPUT -p tcp --sport 8333 -m state --state ESTABLISHED -m limit --limit 30/sec --limit-burst 150 -j ACCEPT
-A OUTPUT -p tcp --sport 8333 -m state --state ESTABLISHED -j DROP
-A OUTPUT -p tcp --dport 8333 -m state --state ESTABLISHED -m limit --limit 30/sec --limit-burst 150 -j ACCEPT
-A OUTPUT -p tcp --dport 8333 -m state --state ESTABLISHED -j DROP

Anda menyebabkan kinerja menyakitkan yang sama kepada pengguna lain yang kebetulan menyinkronkan dari Anda, jadi pastikan untuk menyetel listen=0 saat menjalankannya.

@Ratief Anda menemukan kembali roda, kami sudah memiliki skrip untuk itu di contrib/qos/tc.sh selama setahun.

Jika ada tombol untuk menonaktifkan blok penayangan kepada siapa pun > 20 di belakang, bukankah itu akan berhasil? Kemudian rekan-rekan tidak akan pernah mencoba menyinkronkan dengan simpul yang lambat dan simpul yang lambat tidak akan jenuh hulunya.

@darkhosis Saat ini, jika seseorang memilih simpul sinkronisasi yang menolak melayani blok, simpul yang mencoba menyinkronkan akan gagal menyinkronkan seluruhnya. Kami membutuhkan beberapa kode tertulis yang akan pindah ke rekan berikutnya untuk sinkronisasi. Saya pikir @sipa sedang mengerjakannya di header terlebih dahulu (tapi saya bisa saja salah).

Mungkin akan lebih baik untuk memiliki rekan-rekan dengan throttle set melaporkan itu, dan yang tanpa itu mengukur kecepatan efektif mereka untuk melaporkan. Kemudian rekan-rekan mendapatkan sedikit lebih banyak info untuk digunakan saat memilih simpul sinkronisasi...

@luke-jr headersfirst hanya mengambil dari mana pun ia dapat dan harus berurusan dengan relatif baik dengan rekan-rekan yang macet, jadi setelah HF digunakan, saya baik-baik saja dengan fitur seperti ini.

@sipa Ide mengirim blok yang tidak dianggap "bersejarah" sepertinya solusi yang bagus. Saya akan menyebutnya light-server. Mungkin berdasarkan batas bandwidth yang diinginkan dari server cahaya, jarak mundur dalam waktu blok yang akan diunggah ke rekan sinkronisasi dapat diatur

Sebagai contoh:
Pengguna A dengan 'light-server' dipilih yang ingin mendedikasikan jumlah minimal bandwidth upstream mereka akan mundur hanya ke blok yang memiliki waktu blokir 7 hari sebelum blok terbaru mereka.

Pengguna B dengan 'light-server' juga diaktifkan, tetapi bersedia menyumbangkan sedikit lebih banyak bandwidth (tetapi tidak menyinkronkan seluruh blockchain) dapat menyinkronkan blok hingga waktu pemblokiran 30 hari sebelum waktu pemblokiran saat ini.

Dengan begitu tidak ada kecepatan batas koneksi aktual yang menyebabkan sebuah node macet saat menyinkronkan dari node yang lambat.

Pembaruan: Ini akan membutuhkan kemampuan node untuk beralih ke node sinkronisasi lain tanpa gagal

Masalahnya adalah mekanisme pengambilan saat ini cukup bodoh, dan umumnya berurusan dengan sangat buruk dengan dicekik. Jadi sampai itu diperbaiki, ya, saya percaya tidak menjalankan simpul (yang dapat dijangkau) lebih baik daripada menjalankan simpul yang dibatasi.

-

Anda menyebabkan kinerja menyakitkan yang sama kepada pengguna lain yang kebetulan menyinkronkan dari Anda, jadi pastikan untuk menyetel listen=0 saat menjalankannya.

Bukankah node yang berjalan pada koneksi yang lambat seperti node yang "dibatasi"?
Katakanlah kita memiliki 2 node: A berjalan pada koneksi 1 Mbps dan B pada koneksi 1 Gbps. Bahkan dengan batas bandwidth di B (seperti 100 Mbps), lebih baik menyinkronkan dari B daripada A!
Juga bukankah lebih baik bagi sebuah simpul untuk membatasi unggahannya hingga 90% untuk menghindari kejenuhan? (paket ack dll). Mungkin node A akan berjalan lebih baik dengan kecepatan 900 Kbps (dan pengguna lain akan dapat menjelajahi web)?

Terakhir, memiliki tampilan seperti ini akan menjadi cara untuk "mengumumkan" kecepatan simpul Anda ke orang lain dan membiarkan mereka memutuskan untuk menyinkronkan (atau tidak) dari Anda.

Pelambatan pada tingkat yang sangat dasar dari perintah jaringan mungkin merupakan ide yang buruk dan sudah dapat dilakukan dengan perangkat lunak dan perangkat keras (router / iptables, dll.).
Throttling juga tidak nyaman untuk node di ujung yang lain.

Apa yang sebagian besar operator simpul penuh harus membuat senang adalah cara untuk tidak melayani blok historis ketika prasyarat tertentu tercapai. Saya cukup yakin keluhan di mana pengguna mendapatkan lalu lintas keluar yang sangat tinggi adalah karena simpul mereka yang menyajikan banyak blok historis ke simpul dalam sinkronisasi awal.

Saya ingin menerapkan fitur yang memungkinkan untuk menetapkan batas total per hari, dan jika tercapai, itu tidak akan lagi melayani node yang meminta blok < self.height-100(TBD). Node yang terhubung kemudian dapat beralih ke node yang berbeda. Membatasi respons block akan menjadi ide yang buruk IMO.

Saya juga mencari cara yang baik untuk membatasi tanggapan merkleblock .

Langkah pertama menuju ini diterapkan oleh @jonasschnelli di #6622, yang memasang batas unggahan per rentang waktu.
Setelah kode P2P baru oleh @theuni selesai, pekerjaan menuju pelambatan dapat dimulai.

@laanwj Batas unggahan per ASN mungkin juga merupakan fitur yang berguna - akan membantu mendistribusikan blockchain lebih adil daripada membiarkan satu ASN menggunakan semua tunjangan. Juga, menggunakan ASN untuk menghitung pengusiran rekan-rekan akan menjadi langkah yang baik untuk melindungi dari tipuan.

Ya menggunakan ASN masuk akal untuk beberapa hal, termasuk penggusuran dan pelambatan. Meskipun masalah praktis yang muncul terakhir kali adalah bahwa database ASN terlalu besar untuk dimasukkan apa adanya. Mungkin itu bisa diperkirakan/dikodekan dengan cara yang efisien untuk kueri. Atau mungkin menyerahkan pengunduhan kepada pengguna dan menjadikannya opsional.

@laanwj oh, saya mengira logika pemilihan simpul keluar sudah menggunakan ASN, tapi mungkin tidak - ada sesuatu di sana untuk "menyebarkan" jaring lebih luas - mungkin layak untuk melihat lebih dekat pada logika untuk melihat apakah itu cocok untuk digunakan dengan tidak adanya database ASN yang sebenarnya.

Saya pikir kode sinkronisasi baru melakukan pekerjaan yang lebih baik dalam mendistribusikan beban di antara rekan-rekan. Throttling seharusnya tidak menjadi masalah sekarang.

@earonesty sepertinya masih.

Secara teknis, masalah ini telah diatasi dengan penambahan parameter konfigurasi "maxuploadtarget". Tidak yakin apakah parameter itu telah diekspos di GUI.

maxuploadtarget belum diekspos ke GUI.
Juga, setelah kita memiliki libevent untuk lapisan p2p, pelambatan jaringan harus menjadi buah yang menggantung rendah.
Padahal, menurut saya pribadi, pembatasan jaringan harus dilakukan lebih dalam dari lapisan aplikasi (tingkat router), karena aplikasi tidak tahu apa lagi – berjalan di jaringan yang sama – membutuhkan bandwidth.

Saya menggunakan v5.9.6 masih tidak ada kontrol rekan, seperti yang dikatakan seseorang ada perangkat lunak dan router yang dapat mengontrol lalu lintas di jaringan tetapi saya menemukan bahwa jumlah koneksi tampaknya menjadi masalah, Bitcoin tampaknya membuka banyak koneksi jadi bahkan penjelajah internet tidak dapat menampilkan halaman web,
Melihat di tab, saya menemukan Tampilan Umum, Kirim, Terima, dan Transaksi. Apakah ada ancaman untuk menautkan program dengan torrent klien, mengintegrasikannya atau semacamnya? di lain untuk mengontrol hal-hal semacam ini yang tidak terlalu menarik dari bitcoin?

@jlopp maxuploadtarget tidak menyelesaikan masalah lonjakan bandwidth. Solusi untuk masalah ini sudah ada, misalnya NAFC , yang didukung oleh eMule beberapa tahun lalu. Tapi tentu saja, NAFC memiliki batasannya sendiri, ia tidak dapat mengetahui apa yang dilakukan perangkat lain yang berbagi koneksi Internet yang sama.

Dulu saya mulai menonton utas ini berharap suatu hari seseorang akan menambahkan opsi untuk ini. Sementara itu saya menemukan solusi saya sendiri. Saya menggunakan iptables dan membatasi kecepatan koneksi. Ini bekerja dengan baik untuk saya.

Saya di Ubuntu. Saya menambahkan ini ke /etc/ufw/before.rules. Tweak sesuai keinginan Anda.

Batas nilai 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-sebelum-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-sebelum-output -p tcp --dport 8333 -m state --state ESTABLISHED -j DROP

(Sayangnya, tanpa dapat memahami konteks penuh dari apa yang telah saya tulis, dan tanpa dapat memverifikasi kontribusi signifikan yang telah saya buat dan terus berikan untuk proyek sumber terbuka, nama pengguna saya diberi label sebagai menuntut, memuat gratis, dan kasar di pos berikut. Upaya menggunakan humor untuk menghilangkan kecanggungan menerima teguran pribadi untuk penyelidikan non-pribadi gagal memenangkan hati para pengontrol berlebihan dari masalah github terbuka berusia delapan tahun ini. Saya sekarang bertanya-tanya apakah pembaruan yang saya buat saat ini juga akan dikutuk atau disensor. Ada banyak contoh luar biasa yang harus dipertimbangkan dari pengembang yang merespons dengan anggun dan tanpa praduga terhadap pertanyaan rendah dan ditulis dengan buruk dari pengguna baru yang tidak memiliki posting yang dicatat dengan proyek tertentu ; di mana saya telah menjadi penerima manfaat pribadi, dan karena itu dibiarkan dengan pilihan a) untuk menjelaskan, b) untuk menanggapi dengan tepat atau c) untuk mundur tanpa merasa diserang secara pribadi)

@Hypocritus Ini belum diimplementasikan karena tidak ada yang melakukan implementasi, sesederhana itu, begitulah cara kerjanya di proyek open source. Anda tidak bisa menuntut orang lain menghabiskan waktu untuk menerapkan hal-hal yang Anda inginkan secara gratis. Ini sangat kasar.

wow utas lama dan seperti itu terasa bodoh bahkan untuk memposting, tetapi masalah yang sama masih di sini internet saya sedang terganggu dengan menjalankan node bitcoin. saya merasa cukup kuat untuk berkontribusi kembali ke bitcoin tetapi pada saat yang sama tidak ingin melepaskan kinerja signifikan dari koneksi internet saya, jadi dengan keengganan yang lain telah mengatur mendengarkan = 0, saya berharap ada opsi
:(

Sepakat. Masalah utama adalah bahwa dalam proses node penuh yang sepenuhnya tidak dibatasi, ada beberapa panggilan berbeda yang dilakukan oleh klien dan rekan-rekannya ke sistem atau jaringan bitcoin, salah satu dari atau serangkaian yang dapat menyebabkan penurunan kinerja, macet, atau macet dalam berbagai cara yang hampir tak ada habisnya di mesin host.

Haruskah solusi yang umumnya tidak mengganggu dan intuitif untuk masalah ini ditemukan. alangkah baiknya jika a) masalah ini ditutup (demi kepentingan kita orang awam yang lebih padat yang tidak bisa membaca yang tersirat), dan b) solusi itu secara teratur dikutip demi meringankan kita yang akan benar-benar dan dengan antusias menghargai kemampuan untuk menghabiskan lebih banyak waktu untuk membangun atau menciptakan, dibandingkan dengan mengurangi, mencari, atau mempertahankan (walaupun buruk) upaya untuk menarik perhatian pada masalah yang berdampak lama.

Dan jika ada alasan kuat untuk mempertahankan fitur ini sebagai "perlu", seperti argumen yang masuk akal tentang integritas atau keamanan bitcoin, maka akan bermanfaat jika alasan tersebut dikutip, diposting, atau ditautkan secara teratur, dan agar masalah ini ditutup.