Если бы два вопроса о текущей реализации:
1) отрицательное сальдо счетов:
котировка
- Проверка наличия денежных средств производится до уплаты сборов транзакций (если таковые имеются); если
плата за сделку необходимо, и достаточное количество средств в кошельке, то
Плата за транзакции будут выплачены и списывается со счета. Например, если учетная запись
'Foo' содержит 10 биткойнов, вы sendfrom Foo 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC 10,
и транзакционные издержки 0,01, «баланс Foo будет -0.01 Bitcoins.
Конец цитаты
Что было рациональное для осуществления управления платой таким образом? В большинстве бизнес-сценариев, отрицательные остатки могут запутать неправильно разработанные алгоритмы, и остановить правильно проектируемых. Учетная запись пользователя должна быть также отвечают за вознаграждение по своим операциям с логической точки зрения.
Я не рецензируются код платных вычислений еще, но можно рассчитать сборы заранее и включить их в чеке НФС?
Существует много спроса на статические адреса от пользователей Bitcoin, но большинство современных реализаций имитировать это через очень большое значение ключа бассейна. Это может быть лучше, чтобы предложить эту функцию изначально, добавив истина / ложь флаг Berkeley DB хранения адресов.
Два вызова API может быть добавлен, чтобы предложить эту функцию:
makestatic <адрес>
removestatic <адрес>
Для того, чтобы установить и сбросить эти статические флаги для адресов.
Желая услышать ваши мысли о них,
Keyur