Comments 23
как по мне — существенный минус данного решения — необходимость доверять сторонним ресурсам.
альтернатива:
1. ставим локальную ноду.
2. работаем с ней по json-rpc и вовремя бэкапим. можно обойтись просто requests в случае питона, или разнообразными curl.
минус: большой объем требуемого дискового пространства, 200 Гб в случае bitcoin.
альтернатива:
1. ставим локальную ноду.
2. работаем с ней по json-rpc и вовремя бэкапим. можно обойтись просто requests в случае питона, или разнообразными curl.
минус: большой объем требуемого дискового пространства, 200 Гб в случае bitcoin.
Если полный блокчейн — то уже за 300 с лишним, но можно и урезать начальные блоки.
"Bytes: 385 611 696 957" если точнее.
Не нужно хранить 300 ГБ, есть же легкие клиенты. Тот же electrum можно использовать
electrum.readthedocs.io/en/latest/merchant.html
electrum.readthedocs.io/en/latest/merchant.html
Бекапить не надо. Можно подключиться еще одной нодой и тогда транзакции будут на обеих нодах автоматом из-за бродкаста.
Блокчейн можно урезать до любого удобного размера (у меня 4гб например).
Можно вообще бекапить только мастер ключ (не путать с ключом к кошельку!!!). Напечатайте на бумажке, заламинируйте и положите в сейф.
Потом от мастер ключа определять подключи по номерам не проблема главное пути запомнить.
Блокчейн бекапить вообще жесть несусветная…
Блокчейн можно урезать до любого удобного размера (у меня 4гб например).
Можно вообще бекапить только мастер ключ (не путать с ключом к кошельку!!!). Напечатайте на бумажке, заламинируйте и положите в сейф.
Потом от мастер ключа определять подключи по номерам не проблема главное пути запомнить.
Блокчейн бекапить вообще жесть несусветная…
Страшно было использовать сторонние библиотеки, потому что не знаешь пройдет ли операция, и в любой момент может что-то там сломаться. Этот вариант максимально простой, поэтому доверия к такому решению больше, понятно что доверяться сервису blockchain.com не самый лучший вариант, но и хранить 300 гб на сервере для меня непозволительная роскошь.
Спасибо, мне статья понравилась
Возникают вопросы по безопасности. Если кто-то узнает SEED, то смогут увести все деньги со всех адресов. Как она будет защищаться? Где хранится?
Это в любом случае "горячий" кошелёк, на нем не стоит хранить средства, а сразу переводить на холодный. Так что если и украдут, то немного. Но доверять третьей стороне проверку транзакции я бы не стал...
Seed фраза хранится и используется на сервере, так что если получается взломать сам сервер, то мы теряем все, бдшку, seed фразу, токены qiwi и тд. Можно зашифровать seed фразу и использовать в коде, но это не сильно поможет. Возможно лучше сделать упор на защиту сервера. Так что ответа я незнаю, может кто предложит получше варианты)
Надо защищать сервер разумеется.
В принципе когда речь идет о бюджетном решении — используем достаточно стандартный прием.
Ставится отдельный сервак (1) любой степени дохлости непосредственно для проведения операций и хранения данных, в идеале в защищенном месте (хотя при определённых танцах с бубном можно и в ДЦ поставить). Это дешево. На серваке запрещаются ВСЕ входящие коннекты в принципе, если нет физ.доступа — можно оставить конечно какой-то сильно урезанный и защищенный вход, но лучше не надо.
Сервак с сайтом (2) абсолютно отдельный. Когда он хочет что бы какая-то операция выполнилась, он выкладывает файлик зашифрованный ключом со своими «пожеланиями».
Первый сервак раз с хорошей частотой опрашивает второй сервак на предмет новых заданий, расшифровывает ключом, независимо! проверяет их на легальность (сверяет балансы, логи операций) и проводит только если все ок и соответственно отчитывается второму по завершении.
Первый раз такой схематоз использовали когда была необходимость хранить пароли в открытом виде (дада, мы знаем что нельзя, но тут было очень надо:)), на (1) сервак вынесли тупо БД с паролями и он занимался проверкой.
Вытащить пароли в такой схеме достаточно тяжело (ломануть один сервак, что бы понять где находится другой, потом ломануть другой к которому запрещены все внешние коннекты… не для ньюбов в общем).
Поэтому когда занялись криптопроектами — пошли по той же схеме.
Основное преимущество схемы — отличное соотношение «затраты/безопасность». Да, на проектах где «денег куры не клюют» такой колхоз так себе идея, но когда бюджет ограничен — все затраты тут это доп. сервак, который вообще может стоять хоть у заказчика в кладовке (траффик на проведение операций небольшой, хватает и резервного 4г модема если что с резервным дизель-генератором:) для обеспечения неплохой отказоустойчивости).
p.s.: Автору респект, разобрался, сделал, описал. Но нас «терзают смутные сомнения» по поводу безопасности скармливания пасс-фразы на blockchain.com. У этого blockchain.com и так уже потенциально доступов к крипто-средствам больше чем у бинанса пожалуй:)
В принципе когда речь идет о бюджетном решении — используем достаточно стандартный прием.
Ставится отдельный сервак (1) любой степени дохлости непосредственно для проведения операций и хранения данных, в идеале в защищенном месте (хотя при определённых танцах с бубном можно и в ДЦ поставить). Это дешево. На серваке запрещаются ВСЕ входящие коннекты в принципе, если нет физ.доступа — можно оставить конечно какой-то сильно урезанный и защищенный вход, но лучше не надо.
Сервак с сайтом (2) абсолютно отдельный. Когда он хочет что бы какая-то операция выполнилась, он выкладывает файлик зашифрованный ключом со своими «пожеланиями».
Первый сервак раз с хорошей частотой опрашивает второй сервак на предмет новых заданий, расшифровывает ключом, независимо! проверяет их на легальность (сверяет балансы, логи операций) и проводит только если все ок и соответственно отчитывается второму по завершении.
Первый раз такой схематоз использовали когда была необходимость хранить пароли в открытом виде (дада, мы знаем что нельзя, но тут было очень надо:)), на (1) сервак вынесли тупо БД с паролями и он занимался проверкой.
Вытащить пароли в такой схеме достаточно тяжело (ломануть один сервак, что бы понять где находится другой, потом ломануть другой к которому запрещены все внешние коннекты… не для ньюбов в общем).
Поэтому когда занялись криптопроектами — пошли по той же схеме.
Основное преимущество схемы — отличное соотношение «затраты/безопасность». Да, на проектах где «денег куры не клюют» такой колхоз так себе идея, но когда бюджет ограничен — все затраты тут это доп. сервак, который вообще может стоять хоть у заказчика в кладовке (траффик на проведение операций небольшой, хватает и резервного 4г модема если что с резервным дизель-генератором:) для обеспечения неплохой отказоустойчивости).
p.s.: Автору респект, разобрался, сделал, описал. Но нас «терзают смутные сомнения» по поводу безопасности скармливания пасс-фразы на blockchain.com. У этого blockchain.com и так уже потенциально доступов к крипто-средствам больше чем у бинанса пожалуй:)
А почему файлик, а не какой-нибудь RabbitMQ?
Меньше сущностей && больше простоты => выше безопасность.
На сервере (1) все по абсолютной минималке стоит, а добавлено только строго необходимое.
При этом файлы вполне закрывают функциональные нужды, т.к. сервер обрабатывает только операции реального ввода-вывода из системы, а их обычно сравнительно немного.
На сервере (1) все по абсолютной минималке стоит, а добавлено только строго необходимое.
При этом файлы вполне закрывают функциональные нужды, т.к. сервер обрабатывает только операции реального ввода-вывода из системы, а их обычно сравнительно немного.
Вы хранили пароли в открытом виде, но охотно раздаёте советы по безопасности?
Хороший вариант, но что делать если сервера в облаке и не физического доступа к серверу? Нужно как минимум открывать SSH порт на ноде, чтобы иметь возможность подключиться и настроить что-нибудь.
А как вы решили проблему с «Gap Limit»?
Я, к сожалению или к счастью, не встречался с данной проблемой, но думаю это легко решается следующим вариантом:
Затем запоминаем в бд seed фразу, адрес и wif. В итоге у каждого пользователя свой кошелек, а не адрес общего кошелька. И при получении оплаты, мы переведем бтс на свой кошелек. Просто этот вариант с лишней комиссией, а хотелось бы без нее.
def gen_address(index):
# Наша seed фраза
seed = wallet.generate_mnemonic()
# Мастер ключ из seed фразы
master_key = HDPrivateKey.master_key_from_mnemonic(seed)
...
return seed, address, str(wif, 'utf-8')
Затем запоминаем в бд seed фразу, адрес и wif. В итоге у каждого пользователя свой кошелек, а не адрес общего кошелька. И при получении оплаты, мы переведем бтс на свой кошелек. Просто этот вариант с лишней комиссией, а хотелось бы без нее.
https://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System
Ключевые слова в данном случае p2p. Использование двух (!) сторонних сервисов для перевода денег (бот + api blockchain.com) это противоречит самой изначальной идее создателя биткоин.
На самом деле все же уже давно придумано, надо просто использовать SPV wallet, работает быстро, весь блокчейн не хранит, хранится только несколько десятков мегабайт, соединяется непосредственно с сетью bitcoin, не требует сторонних api. Для Java есть прекрасная библиотека bitcoinj, которая реализует этот функционал, от одного из разработчиков bitcoin (Mike Hearn). Для Go есть библиотека SPVWallet. Наверняка, и для python что-то есть.
Если платежей действительно много (больше примерно 144 в сутки, все равно SPV реализация будет запрашивать merkle subtree для каждого блока фактически), можно использовать полную реализацию с pruned форматом хранения. Точно также, не требует дополнительных API, работает быстро, места на диске требует не 300G
Блин, сколько хайпа было о свободе децентрализации, исключения посредников, избавление от необходимости доверять третьей стороне, а куда не плюнь, все кому не лень предлагают посреднические услуги в обеспечении этого самого избавления от посредников ))
Ну прям ни как нам без этих двойных стандартов )
Вот, на секундочку, кейс для размышления, как думаете, нафига Ян Колеман, сделал свою тулзу по работе с BIP39, что бы её можно было юзать локально на кампе, даже в оффлайне?
Мышление менять не просто, понимаю, но начните уже разрабатывать приложухи, которые работают ТОЛЬКО на стороне юзера.
Да, ещё, понимаю, всех пугает необходимость подымать полную ноду, так оно сформулировано, подозреваю что сознательно с целью мотивации развивать сеть, но Вы же IT-шники, не ужели не ясно, что Ваша полная нода как то должна взаимодействовать с другими нодами? Уметь там транзу в мемпул анонсировать ВСЕЙ сети, от других нод принимать данные и тд
Я может в этом посте немного косноязычен — тема не простая для среднего, пока что, ума, тоже понимаю, но блин, давайте уже направлять наш креатив на РЕАЛЬНЫЙ p2p
Вам полная нода нужна ТОЛЬКО для майнинга, ну и в целом если Вы энтузиаст и хотите сеть поддержать, но для взаимодействия с сетью, Вам надо просто взаимодействовать с другими нодами.
Меня уже достали заказчики, которым нужен кошелёк и они все как один начинают, вот те камп со 100500 гигов на борту.
Чую в один прекрасный момент, много много непокоя прочуют кинутые юзеры, ведь любой такой бот/сайт/сервис, в любой момент, может кинуть всех юзающих его лохов и элементарно уйти от ответственности, если правильно запускались и не спалили личность.
А хакнут Вас господа хорошие, че делать будете? это другая сторона медали.
В общем статью рекомендую воспринимать, как поле для экспериментов, но в прод с таким лучше выходить, только если готовы взять на себя полную ответственность за чужие деньги, или если реально есть желание всех своих клиентов на битки опустить не слабо, так, как опция, когда нибудь, но в этом случае помните про силу анонимности )
Ну прям ни как нам без этих двойных стандартов )
Вот, на секундочку, кейс для размышления, как думаете, нафига Ян Колеман, сделал свою тулзу по работе с BIP39, что бы её можно было юзать локально на кампе, даже в оффлайне?
Мышление менять не просто, понимаю, но начните уже разрабатывать приложухи, которые работают ТОЛЬКО на стороне юзера.
Да, ещё, понимаю, всех пугает необходимость подымать полную ноду, так оно сформулировано, подозреваю что сознательно с целью мотивации развивать сеть, но Вы же IT-шники, не ужели не ясно, что Ваша полная нода как то должна взаимодействовать с другими нодами? Уметь там транзу в мемпул анонсировать ВСЕЙ сети, от других нод принимать данные и тд
Я может в этом посте немного косноязычен — тема не простая для среднего, пока что, ума, тоже понимаю, но блин, давайте уже направлять наш креатив на РЕАЛЬНЫЙ p2p
Вам полная нода нужна ТОЛЬКО для майнинга, ну и в целом если Вы энтузиаст и хотите сеть поддержать, но для взаимодействия с сетью, Вам надо просто взаимодействовать с другими нодами.
Меня уже достали заказчики, которым нужен кошелёк и они все как один начинают, вот те камп со 100500 гигов на борту.
Чую в один прекрасный момент, много много непокоя прочуют кинутые юзеры, ведь любой такой бот/сайт/сервис, в любой момент, может кинуть всех юзающих его лохов и элементарно уйти от ответственности, если правильно запускались и не спалили личность.
А хакнут Вас господа хорошие, че делать будете? это другая сторона медали.
В общем статью рекомендую воспринимать, как поле для экспериментов, но в прод с таким лучше выходить, только если готовы взять на себя полную ответственность за чужие деньги, или если реально есть желание всех своих клиентов на битки опустить не слабо, так, как опция, когда нибудь, но в этом случае помните про силу анонимности )
Ммм, а документация bipwallet молвит, что можно без всяких лишних действий в ней же сгенерировать BTC-адрес и WIF по seed и index.
pypi.org/project/bipwallet
И вообще данная библиотека похоже не поддерживает версию Python более 3.6
pypi.org/project/bipwallet
И вообще данная библиотека похоже не поддерживает версию Python более 3.6
Как то не пахнет надёжностью. Лет семь назад ставил году и по json-rpc слушал нужный адрес, клал транзакцию в бд и ждал ее подтверждения. Работало безотказно. Сейчас я бы сделал вообще без ноды напрямую, имхо не вижу смысла ее держать для приема платежей.
Sign up to leave a comment.
Внедряем оплату BTC куда угодно (Python)