Комментарии 11
А где ты сиды пользователей хранишь, чтобы подписывать транзакции?
Все несколько проще:
1) Я не использую ни в случае с Lightning, ни в случае с on-chain платежами напрямую инструменты касающиеся криптографии — не вижу смысла, за меня это сделало много умных людей. Если это on-chain то чаще всего использую Electrum CLI с собственным Electrum сервером (можно и без второго обойтись, просто у меня был спортивный интерес). Он все делает за меня, я лишь командую — подпиши, сделай бродкаст итп. И обычно я использую один seed на приложение, а пользователя привязываю уже конкретные адреса из общего кошелька. Иногда в такой привязке есть смысл, иногда и она не нужна. В случае с Lightning по сути все так же, только в роли кошелька — lightning-cli. Но в этом случае уже логика другая — каждый платеж это свой «инвойс», которые выступают в роли адресов и они одноразовые по протоколу.
2) именно «сиды» пользователей есть смысл хранить если есть необходимость под пользователя выделить отдельный кошелек (условно бесконечное идентифицируемое множество адресов) или делать таким образом, что бы у разработчика небыло совсем доступа к средствам на балансе пользователя. Но в подавляющем большинстве случаев пользователя это не интересует, а с доступом к балансу проще решать возникшие проблемы.
1) Я не использую ни в случае с Lightning, ни в случае с on-chain платежами напрямую инструменты касающиеся криптографии — не вижу смысла, за меня это сделало много умных людей. Если это on-chain то чаще всего использую Electrum CLI с собственным Electrum сервером (можно и без второго обойтись, просто у меня был спортивный интерес). Он все делает за меня, я лишь командую — подпиши, сделай бродкаст итп. И обычно я использую один seed на приложение, а пользователя привязываю уже конкретные адреса из общего кошелька. Иногда в такой привязке есть смысл, иногда и она не нужна. В случае с Lightning по сути все так же, только в роли кошелька — lightning-cli. Но в этом случае уже логика другая — каждый платеж это свой «инвойс», которые выступают в роли адресов и они одноразовые по протоколу.
2) именно «сиды» пользователей есть смысл хранить если есть необходимость под пользователя выделить отдельный кошелек (условно бесконечное идентифицируемое множество адресов) или делать таким образом, что бы у разработчика небыло совсем доступа к средствам на балансе пользователя. Но в подавляющем большинстве случаев пользователя это не интересует, а с доступом к балансу проще решать возникшие проблемы.
Я правильно понял, что у разработчика есть доступ к балансам юзеров? И в один прекрасный день может произойти, эмммм… казус?
Да, всё верно понимаете. Казус может произойти, если разработчики раздолбаи или злодеи. Впрочем, стоит отметить, что такое возможно в любом банке, в т.ч. в том, что Вы используете, а так же с любой биржей или финансовым сервисом вроде PayPal. В отличии от упомянутых, предоставляя услугу биткойн-счёта\кошелька технически возможно (и это совсем не сложно) хранить ключи «на стороне клиента», но, к сожалению, большинство пользователей либо не умеют безопасно хранить поный доступ к «очередному кошельку» либо не хотят это делать. Поэтому приходится о сохранности их средств заботится в случаях как чат-бот разработчикам. Но неужели пользователь в здравом уме будет хранить все свои сбережения на балансе чат-бота в телеграме? Для этого есть специализированные кошельки с многослойной защитой. Тут скорее вопрос к пользователю, а не разработчику.
можно просто посмотреть в профессиональный стандарт «программист».
Что изменится с приходом внутренней валюты, грамов?
Я думаю, что «грамы» будут соего рода кошельком с глубокой интеграцией в аккаунт Телеграма, что в свою очередь сделает очень удобным использование именно этого кошелька при разработке чат-ботов вроде моего или других приложений с платежами внутри — не надо «всякие биткойны» изучать, все из коробки. И наверняка грамы легко будет обменять на биткойн и обратно.
Я правильно понимаю что в текущей реализации возможна ситуация когда к владельцу бота (или владельцу ноды Lightning Network) приходят и говорят что пользователь X — это террорист который заставляет детей сниматься в детском порно и платит им наркотой а налоги — не платит, и поэтому надо всего его деньги перевести по решению суда куда следует, и это требование технически — выполнимо, и нормально это исправлять — надо менять логику не только ботов (то же хранение ключей надежное) но и Lightning Network?(либо использовать on-chain транзакции)
Для этого нужно найти владельца бота (если мой бот был бы для криминала, я бы не писал о нём статьи, а кроме этого никаких намёков что он мой нет). А еще нужно что бы Телеграм слил данные, а он вроде как «приватный мессенджер». Что бы не узнали кто хостит Lightning ноду и кто подключается к Телеграму — есть луковички, их видно на диаграме. Но в любом случае Ваш пример из каких то страшилок и имеет почти никакое отношение к контексту чат-бота в телеграме. на мой взгляд :) А у Lightning на уровне протокола всё прекрасно (я бы сказал даже лучше чем on-chain) с приватностью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как запустить микро-платежи в своем приложении