Может ли исходный биткойн-клиент содержать миллионы адресов?

Мы используем стандартный клиент в нашем бизнесе. Кошелек уже содержит около 25 тысяч адресов. Будет ли кошелек оставаться стабильным после того, как количество адресов достигнет 100 тысяч или миллиона? Мне сказали, что у всех крупных бизнесов есть форк клиента. Должны ли мы также разветвлять и кодировать наш собственный кошелек?

Ответы (4)

Я уже проводил тесты на 0,5 миллионах адресов, сгенерированных за один день. Он срабатывал walletnotify в течение миллисекунд, без заметной задержки, когда я отправлял сумму на случайный адрес. Единственная заметная вещь заключалась в том, что запуск клиента занял 30 минут, что, я думаю, нормально, если вы запускаете более крупный сервис. Единственное, что может вас беспокоить, это медленное время создания транзакции, но кто-то здесь посоветовал мне просто ежемесячно переводить средства на новый адрес.

Как он будет себя вести, если у вас будет несколько транзакций, включающих все эти адреса? Я предполагаю, что совет ежемесячно переводить все средства на новый адрес должен решить эту проблему?
Размер транзакции и, следовательно, комиссия будут тем больше, чем шире будут ваши средства. Хотя я предполагаю, что перемещение их на центральный адрес должно решить эту проблему, поскольку из многих создается один неизрасходованный вывод.

Обычный клиент BitcoinQT не подходит для работы с огромным количеством адресов/транзакций. База данных легко за месяц уходит на крышу с IO-операциями, если делать, скажем, 1 транзакцию в минуту. Пожалуйста, рассмотрите возможность чтения блокчейна напрямую или используйте внешний сервис, который возьмет на себя накладные расходы, т.е. Blockchain.info

Предположим, что мы используем сторонние службы для уведомления о кошельке и уведомления о блокировке адресов, которые мы храним в нашем кошельке. (Например, добавление их в качестве адреса только для просмотра) Не будет ли клиент по-прежнему извлекать данные транзакций, связанные с нашими адресами, из сети? И поэтому бд опять на крышу?

Я проверил это, программно добавив 1 миллион адресов клиенту QT через интерфейс JSON-RPC из программы Java. Повторное сканирование было отключено, поэтому все, что он делал, это добавляло адреса, а не подтверждало баланс. Потребовалось около 24 часов, чтобы добавить 1 миллион адресов, а затем потребовалось еще 4 часа или около того, чтобы перезапустить клиент и просканировать 1 миллион адресов. Я использовал MacBook Air, поэтому не очень мощное оборудование. Тем не менее, учитывая количество времени, которое потребовалось для повторного сканирования, я бы не рекомендовал использовать клиент QT с таким количеством адресов в производственных условиях. Удачи.

Возможно, вашего теста недостаточно, чтобы предсказать, что произойдет в реальных сценариях, включающих миллионы транзакций и, возможно, сотни учетных записей в кошельке.

Все упирается в исторические данные. Вы извлекаете исторические данные, запрашивая блокчейн, или полагаетесь на свои собственные транзакционные данные в локальной базе данных? Если вы сделаете последнее и вас беспокоит стабильность вашего перегруженного кошелька, вы всегда можете переключиться на совершенно новый, чистый кошелек только с предварительно загруженными 100 адресами и быть уверенным, что до отметки 25 000 все будет работать гладко.