(theymosの引用投稿)
それは有用だろうが、スクリプトはステートレスに保つのが最善だ。異なるノードが現在のブロックカウントについて異なる認識を持つ可能性があるため、ネットワークの半分がトランザクションを有効と見なし、半分が無効と見なす状況が発生しうる。これはネットワークにとって好ましくない。
Quote from: theymos on November 15, 2010, 01:49:59 AM
それは有用だろうが、スクリプトをステートレスに保つのがおそらく最善だ。異なるノードが現在のブロック数について異なる認識を持つ可能性があるため、ネットワークの半分が取引を有効と見なし、半分が無効と見なす状況が発生しうる。これはネットワークにとって良くない。
うーん……クライアントが現在のブロック数について意見が一致しないなら、特定の取引が有効かどうかについてもすでに意見が一致していないことになり、したがってあなたが言及する問題は私の提案なしにすでに存在している。 なぜこれがネットワークにとって良くないのか、もっと詳しく説明してほしい。
ByteCoin
さらに調査した結果、nLockTimeを有用にするにはインメモリ取引置換を再有効化する必要があることがわかった。
Code: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は逆のことをする。これは期限まで新しいバージョンで置き換えることができるオープントランザクションだ。ロックされるまで記録できない。期限が来た時点で最も高いバージョンが記録される。例えば、取り消されない限り期限後に自動的に永久にロックされて実行されるエスクロートランザクションを作成するために使用できる。この機能はまだ有効化も使用もされていないが、サポートは組み込まれているので後で実装できる。