Как известно, у Ёты уродский дизайн самого явного в криптовалюте - адресов. Они одноразовые. То есть ты не можешь на своей страничке написать свой ёто-адрес - мол, принимаю благодарность в ётах. Написать-то можешь, только это бессмысленно. Если тебе переведут сколько-то ёт, и ты их на что-то потратишь, то больше на этот адрес принимать ёты нельзя - адрес для траты одноразовый. Тебе нужно лезть на свой сайт и менять донатный адрес на другой. И тот, кто скопировал себе первый адрес, или записал его себе в адресную книгу - если он пошлёт ёты на тот адрес, он просто покормит хакеров, т.к. эти ёты будут мгновенно угнаны.
Нельзя сказать, что Chat-for-Ban не понимал всей маразматичности этой ситуации. Он даже пытался исправить ситуацию, но не смог:
Также не удалась затея с повторно используемыми адресами, пришлось снова вернуться к схеме с генерацией каждый раз нового адреса.
Эта хрень стала хорошим уроком. По меньшей мере неделя работы в две смены пошла коту под хвост, переписал код, оптимизировал, прогнал тесты и только тогда стало понятно, что даже десктопное железо не может переварить красивости, необходимые людям. В следующий раз даже не будем рассматривать варианты улучшения, если только они не для машин.
Прошло 3 года (!!), и вот ёптофаундейшин снова делает попытку исправить этот уродский дизайн адресов. Казалось бы, такая естественная вещь - получать монеты на свой адрес, но вот какую монструозную процедуру они предлагают:
Conditional Deposit Addresses (CDAs) are special addresses that allow you to specify the conditions for which they stay usable. As long as the conditions you specify hold, the CDAs can be used for withdrawals and deposits.
The main use for CDAs is to avoid address reuse. When you request IOTAs from a party, you create a CDA that is active for a certain period of time and that can specify the exact amount of IOTAs. This way, you communicate intent to the sender, who then makes a judgement on whether to make a deposit. A simplified flow is:
1. You generate a CDA.
2. When creating the CDA, you specify conditions like the timeout — for how long the CDA stays valid and can be deposited to. Or an amount — how many IOTAs you expect the sender to deposit to the address.
3. You share the CDA with the depositor via a medium of your choice and serialized as an object of your choice, for example as a QR code, protocol buffer, or a magnet link.
4. The depositor either sends tokens to the address specified in the CDA, or requests a new CDA if for example the CDA has already expired.
CDAs are simple, descriptive objects and you can serialize them into any format. This is what a CDA magnet link looks like, for example:
iota://GODULTSVAVRXBJFKTAEAJTULFKJUHIMKKVBCS9TJCNBWEVWFHAAVKVKLABMYTSK9EKWPMZJUVHAKGULLDAMABAGQIZ/?timeout_at=1554372484&expected_amount=1000
