「時間」制限付きトランザクションを可能にするために OP_BLOCKNUMBER が必要
現在、誰かに支払いをしたが相手がウォレットを消去してしまった場合、そのコインは取り返しのつかない形で失われる。 同様に、ネットワークが 0.01 の手数料トランザクションで溢れている時に緊急の支払いをしたが、より高い手数料を含めるのを忘れた場合、同じコインを裏付けとしてその支払いを手数料付きで再発行することができない。
もし現在のブロック番号をスタックにプッシュし、それを使って計算を行えるようにすれば、受取人が特定のブロック番号に達する前に使わなければならない支払いを実装できる。期限を過ぎた場合、例えばスクリプトが送金者による再度の使用を許可するようにできる。
これは非常に人気のあるトランザクションの仕組みになると思う。
ByteCoin
それは有用だろうが、スクリプトはステートレスに保つのが最善だ。異なるノードが現在のブロックカウントについて異なる認識を持つ可能性があるため、ネットワークの半分がトランザクションを有効と見なし、半分が無効と見なす状況が発生しうる。これはネットワークにとって好ましくない。
それは有用だろうが、スクリプトはステートレスに保つのが最善だ。異なるノードが現在のブロックカウントについて異なる認識を持つ可能性があるため、ネットワークの半分がトランザクションを有効と見なし、半分が無効と見なす状況が発生しうる。これはネットワークにとって好ましくない。
うーん……クライアントが現在のブロック数について意見が一致しないなら、特定の取引が有効かどうかについてもすでに意見が一致していないことになり、したがってあなたが言及する問題は私の提案なしにすでに存在している。 なぜこれがネットワークにとって良くないのか、もっと詳しく説明してほしい。
ByteCoin
さらに調査した結果、nLockTime を有用にするにはインメモリー取引置換を再有効化する必要があることがわかった。
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (!IsNewerThan(*ptxOld))
return false;
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)
return false;
}
break;OP_BLOCKNUMBER を安全に実装することはできない。セグメンテーション後のブロックチェーン再編成の場合、トランザクションは後のブロックに入れるようにする必要がある。OP_BLOCKNUMBER トランザクションとそのすべての依存トランザクションが無効になる。時間制限付きトランザクションに関与していなかった後のコイン所有者にとって不公平だ。
nTimeLock は逆のことをする。これは期限まで新しいバージョンで置き換えることができるオープントランザクションだ。ロックされるまで記録できない。期限が来た時点で最も高いバージョンが記録される。例えば、取り消されない限り期限後に自動的に永久にロックされて実行されるエスクロートランザクションを作成するために使用できる。この機能はまだ有効化も使用もされていないが、サポートは組み込まれているので後で実装できる。
nTimeLock は逆のことをする。これは期限まで新しいバージョンで置き換えることができるオープントランザクションだ。ロックされるまで記録できない。期限が来た時点で最も高いバージョンが記録される。例えば、取り消されない限り期限後に自動的に永久にロックされて実行されるエスクロートランザクションを作成するために使用できる。この機能はまだ有効化も使用もされていないが、サポートは組み込まれているので後で実装できる。
nTimeLock を使うと、ロックが切れるまで送信者のコインも一部拘束されるのか？ そうならざるを得ないと想像するが、それならエスクロー問題は即座に解決し、送信者は事実上、Bitcoin 版の先日付小切手を書けるようになる。さらに良いことに、ネットワーク上でロックされたトランザクションを見ることで、マーチャントは送信者が実際に商品を買う資金を持っていると分かる。そしてコインがロック切れまで拘束されているなら、おそらく送信者はまだ同じ資金を持っているということだ。詐欺師がオンラインで何かを買うためにロックされたトランザクションを送り、商品が発送された後にトランザクションを取り消す可能性は依然として存在する。だがサードパーティのエスクローを必要とせずにトランザクションへの信頼を加えることができる。トランザクションの取り消しは blockchain の内側か外側に記録を残すのか？ もし残すなら、blockchain をスキャンすることで、詐欺師が同じコイン群で他人に対して既に一度詐欺を働いていた場合、取り消されたトランザクションのリスクが高まっていることを浮き彫りにできるかもしれない。これにより、取り消されたトランザクションで使われたコインは、いくつかの有効なトランザクションで使われるまで一時的に「汚染」されることになる。
OP_BLOCKNUMBER を安全に実装することはできない。セグメンテーション後のブロックチェーン再編成の場合、トランザクションは後のブロックに入れるようにする必要がある。OP_BLOCKNUMBER トランザクションとそのすべての依存トランザクションが無効になる。時間制限付きトランザクションに関与していなかった後のコイン所有者にとって不公平だ。
OP_BLOCKNUMBER は既存のシステムと比べて新たな脆弱性を導入しない。なぜなら現時点でも分断を悪用して人を騙すことは可能だからだ。これは次のように実現できる：
機会主義的な攻撃者は世界中の複数の場所でクライアントを動かしている。攻撃者のクライアントは同じウォレットを持ち、それぞれ異なるピアの部分集合に接続する。おそらくローカルのピアを優先し、確実にローカルのマイニングピアと連絡を保つ。クライアントは一定間隔で互いに通信し、ネットワークが分断されていないかを確認し、自分が話しているピアのリストを交換する。 攻撃者のクライアントの一つ以上との通信が失われた場合（オフラインになる）、残りのクライアントはオフラインクライアントのすべてのピアと通信を試みる。すべて成功すれば、その攻撃者のクライアントは単にクラッシュしたかインターネット接続を失っただけの可能性が高い。しかし、そのクライアントがオフラインになり、いくつかのピアにも連絡が取れなければ、ネットワークが分断された可能性がある。攻撃者のクライアントは、自分がマイニングパワーの多数派側にあるのか少数派側にあるのかを判定する。さらに、ネットワークの別のアクセス不能な部分が、孤立していると想定される時間中にブロックを生成するだけのマイニングパワーを持っているかも推測する。条件が好都合であれば、攻撃は次のように進む： ネットワークの多数派側にある攻撃者のクライアントは、もっともらしく無害に見えるトランザクションでウォレットから新しいアドレスにコインを送る。少数派側にある攻撃者のクライアントは、同じウォレットの同じコインを使って、サブネットワーク上で見つけられる任意の商品を買う。ネットワークが再び結合したとき、多数派側がより多くのブロックを生成している可能性が高く、少数派側のチェーンのブロック内のすべてのトランザクションはトランザクションプールに戻る。短いチェーン上の攻撃者のトランザクションは、コインが既に長いチェーン上で使われているため破棄される。詐欺完了！
このように、OP_BLOCKNUMBER は新たなリスクを導入せず、分断ベースの詐欺の本当の防止はマイニングパワー喪失の何らかの検出に頼るしかないことが分かる。
ByteCoin