打つことができる」という要件が必要なのか疑問である。これは、オペレータと同じことをすれば可能である。打つことを妨げることはできない(が、オペレータはユーザーのトランザクションを妨げることはできるため、これで全てが解決するわけではない)。表現するという方法の代替案を検討する十分な理由だと思う。同意した全てのコインをどうにかして識別できるということである。含まれている場合)これはビットマップによって実現できるが、参加するコインが非常にまばらである場合、インデックスのリストはより効率良く集約できる。コインが非常に密であれば、含まれていないコインをより効率良く集約できるし、ある種の連長圧縮を適用することもできる。打たれる場合でも有用であるが、ビットマップが最も効率の良い表現であるくらいコインが十分に密もしくはまばらである必要がある)。bond!kfichter:素晴らしい見解だ。「理解する」必要さえないところである。終わる全てのコイン」という文字列と一緒にビットマップを公開することもでき、それは(理論的には)機能する。受信する側にきちんと情報が伝わっていることを証明する必要があると思う。表現が特定のコインを含んでいるのか判断できる必要がある。not.kfichter:ごもっとも。打たれているかどうかを知ることができなければならない。ためにこれを利用することができるかもしれない。これができれば、最初のチェーンのオペレータの協力は不要である。コインの活性を維持できる。基本的には全て同じ仕組みで可能である。coins.tasd:仮定が若干変わっていると思う。ユーザーはチェーンの監視や引き出し開始を他の誰かに委任することができるので、実際、ユーザーは常時オンラインである必要はない。委任によって発生する不必要な引き出しや諸々のミスはユーザーを苛ませることはあるだろうが、ユーザーのコインが盗まれることはない。信頼できない団体に委任できないように見える。おいて承認を行うためにはその団体に秘密鍵を提供する必要があるから。おける仮定とは変わっているという点は自分も同意する。おける仮定とは変わらないと思う。positive.kfichter:ユーザーがオンラインである必要があっても最初の実装としては大丈夫だと思うが、それらをアウトソーシングできることは間違いなくユーザーにとって非常に有用だろう。おいて承認を行えるサードパーティを指定するオンチェーンなトランザクションをつくることだろう。マルチシグのようなもの。provider.kfichter:もちろん、これは、サードパーティが署名を拒否することによってユーザーを一時的に苛ませる可能性があることを意味する。ユーザーが委任先のサードパーティを変更する別のトランザクションを簡単に送信することができる場合、おそらくこれは最悪なことではない。していると仮定している)。拒否権を与える必要がある(が、コインを引き出す権限だけは残しておくことはできる)。アウトソーシングではない。削減するためにコインを使用する前に常にそれを行うことができるから)。後者が可能かどうかはわからない。承認を行ってしまうというサードパーティに責任のない問題が起こりうるから。文は意図を正しく解釈できてる自信なし。