В настоящее время я столкнулся с проблемой обновления Bitcoin Core. Как вы, возможно, знаете, в недавнем обновлении Bitcoin Core устарела концепция учетной записи, принадлежащей каждому узлу. Следовательно, я больше не могу устанавливать параметр «от учетной записи» или «от адреса» для отслеживания потока монет, когда я использую методы Bitcoin Core API (например, sendmany, sendfrom, sendtoaddress) для управления активами криптовалюты Bitcoin. Проблема вытекает отсюда. Я реализовал услугу как своего рода систему условного депонирования биткойнов, управляя в ней отдельным узлом Bitcoin Core. Каждый пользователь моего сервиса берет каждый адрес, и адреса пользователей принадлежат каждой отдельной учетной записи, а учетные записи принадлежат узлу Bitcoin Core моего сервиса. Но, поскольку учетная запись устарела в недавнем обновлении, теперь я не могу указать определенный адрес пользователя в моем сервисном узле и управлять активом в нем. Проблема заключается, например, в том, что когда я вызываю метод sendmany для отправки 1 BTC из моего сервисного узла, актив, распределенный по адресам пользователей моего сервиса, будет случайным образом уменьшен, а общий объем сокращения должен составлять 1 BTC. Другими словами, я не может извлечь 1 BTC из целевого адреса пользователя, владелец которого должен был использовать наш сервис для оплаты чего-то на сумму 1 BTC, и бремя оттока BTC должно быть разделено для всех. Кроме того, поскольку метод sendfrom также устарел, я не могу указать пользователя моего сервиса для управления его или ее активами BTC, хранящимися на данном адресе кошелька. Решение, которое я сейчас обдумываю и временно использую, заключается в настройке системы базы данных для управления входом и выходом узла и пользовательского актива. т. е. я могу указать и управлять каждым пользователем и его или ее активом в адресе кошелька только через базу данных (например, mySQL), и когда другой участник вне моей службы найдет нашу небольшую сервисную сеть, он будет идентифицирован только как один узел , управление пакетом активов, хранящимся в одном хранилище. Я имею в виду, что мой сервисный узел должен быть свернутым биткойн-банком для сервиса. Тем не менее, я хочу попросить вашей помощи, чтобы найти другой способ идентифицировать каждого пользователя и управлять активом с точки зрения каждого адреса. Я не хочу, чтобы моя маленькая база данных была единственным доминатором для управления пользовательской информацией, так как реализация такой базы данных может привести к серьезной проблеме с безопасностью. Я хочу идентифицировать каждого пользователя, адрес и существующий актив только через протокол Bitcoin Core и API, определенный в RPC. Я могу указать и управлять каждым пользователем и его или ее активом в адресе кошелька только через базу данных (например, mySQL), и когда другой участник вне моего сервиса найдет нашу небольшую сервисную сеть, он будет идентифицирован только как один узел, контролирующий пакет активов, хранящийся в одном хранилище. Я имею в виду, что мой сервисный узел должен быть свернутым биткойн-банком для сервиса. Тем не менее, я хочу попросить вашей помощи, чтобы найти другой способ идентифицировать каждого пользователя и управлять активом с точки зрения каждого адреса. Я не хочу, чтобы моя маленькая база данных была единственным доминатором для управления пользовательской информацией, так как реализация такой базы данных может привести к серьезной проблеме с безопасностью. Я хочу идентифицировать каждого пользователя, адрес и существующий актив только через протокол Bitcoin Core и API, определенный в RPC. Я могу указать и управлять каждым пользователем и его или ее активом в адресе кошелька только через базу данных (например, mySQL), и когда другой участник вне моего сервиса найдет нашу небольшую сервисную сеть, он будет идентифицирован только как один узел, контролирующий пакет активов, хранящийся в одном хранилище. Я имею в виду, что мой сервисный узел должен быть свернутым биткойн-банком для сервиса. Тем не менее, я хочу попросить вашей помощи, чтобы найти другой способ идентифицировать каждого пользователя и управлять активом с точки зрения каждого адреса. Я не хочу, чтобы моя маленькая база данных была единственным доминатором для управления пользовательской информацией, так как реализация такой базы данных может привести к серьезной проблеме с безопасностью. Я хочу идентифицировать каждого пользователя, адрес и существующий актив только через протокол Bitcoin Core и API, определенный в RPC.
Пожалуйста, дайте мне несколько советов, если у вас есть.
Искренне,
Проблема заключается, например, в том, что когда я вызываю метод sendmany для отправки 1 BTC из моего сервисного узла, актив, распределенный по адресам пользователей моего сервиса, будет случайным образом уменьшен, а общий объем сокращения должен составлять 1 BTC. Другими словами, я не может извлечь 1 BTC из целевого адреса пользователя, владелец которого должен был использовать наш сервис для оплаты чего-то на сумму 1 BTC, и бремя оттока BTC должно быть разделено для всех.
Он никогда не делал этого в первую очередь. «От счета» никогда не делал того, что вы описали; он не выбрал монеты с адресов, принадлежащих этой учетной записи. Скорее, он выбирал монеты со всего кошелька (то есть «со» всех счетов), и результирующая транзакция говорила, что она уменьшает баланс «со счета». Параметр «со счета» ни разу не влиял на то, какие монеты выбирались.
Если вы действительно хотите разделить адреса пользователей, вы можете использовать функцию мультикошелька, где у каждого пользователя есть собственный файл кошелька со своим собственным пулом ключей, закрытыми ключами, транзакциями и т. д.
Стефан Н.
Питер Уилле