Jennifer Zynn

私は、トレジャリウォレットが実際にバビロンのステークを回復できるかどうかを確認しました。

それは、預け入れ（デポジット）を資金供給するUTXOに署名できました。

次に、ステーキング出力の中にコミットされているStakerPkに対して、所有権のチェックを実行しました。

「キーが見つかりません。」

トレジャリウォレットはそのキーを管理するはずでした。回復システムは、依頼してもそれを生成できませんでした。

デポジットのフローのどこにも、それを露出させるものはありません。

資金供給トランザクションが署名します。ステークが確認（確定）します。委任が有効になります。

この破綻が現れるのは、BTCをもう一度移動する必要があるときだけです。

通常の引き出し経路も、早期アンボンディングも、依然としてステーカーキーに依存します。協約（カヴェナント）の承認は、それに代わりません。

つまり、BTCはバビロンに入った時点では回復可能であることは証明されず、資金供給可能であることだけが証明されました。

「キーが見つかりません」は、一見無害に見えますが、それがBTCを家に連れ戻せる唯一のキーに紐づけられると、害が明らかになります。

#BABY $BABY @BabylonLabs_io
$HOME
$TUT

私のリカバリードリルはキーのチェックを通過し、それでも最終性（ファイナリティ）の投票が生成されませんでした。

Babylon の最終性署名には EOTS キーだけでは不十分です。それは、その正確な高さ（height）に対して公開ランダムネスがコミットされたことを示すメルクル証明を伴う必要があります。これらの証明と、プロバイダの最後に投票した高さは finality-provider.db の中にあります。

クリーンなマシンにキーリングを復元しても、それは機能するリストアではありません。デーモンは私のプロバイダを認識し、eotsd に到達できますが、ランダムネス証明が欠けているため、あらゆる投票提出が失敗するだけの十分なガスを確保してしまいます。プロバイダはキーリング上では復元されたように見えますが、次の Babylon の高さでは黙ったままです。

修復は特定の内容です。fpd を停止し、選んだ開始高さから recover-rand-proof を実行しなければなりません。その高さを外してしまうと、ツールは最初のランダムネスコミットから証明を作り直し、プロバイダの稼働全履歴をリカバリ作業に変えてしまいます。

プロセスが起動するかどうかを確認するのではなく、実際の最終性投票を提出してバックアップをテストします。署名の証拠を復元しないままアイデンティティだけを復元しても、リカバリは半分にすぎません。

そのマシンは自分が誰かは覚えていても、次の投票を証明する方法は忘れてしまうのです。

#baby $BABY @BabylonLabs_io
$DOGE
$TAKE

署名者がバビロンへのプレステークを完全に署名済みとして返したとき、その失敗に気づきました。

それでもバビロンは、委任をPENDING（保留中）として表示していました。

それが問題でした。

コイン選択によって、レガシーUTXOが1つ、マルチ入力のステークに取り込まれていました。その入力にはscriptSig内での署名が必要だったため、私の署名者は、バビロンが誓約（covenant）の検証を完了する前に取引を完了してしまいました。

取引のhexは、もはや単なる登録パッケージではありませんでした。ビットコインノードはそれを受理し、中継できました。

私は署名済みの取引を破棄し、SegWit入力のみでコイン選択を作り直して、登録フローをもう一度開始しました。

無効な署名はありません。拒否されたビットコイン取引もありません。

ただ、BTCがマイニング可能になる一方で、バビロンはまだ委任を未完了として扱っていました。

#BABY $BABY @BabylonLabs_io

別のポジションが0.01188ドルまで下がって清算に向かっている間、私はBABYを「受理済み」の未委任状態で座らせていました。

「受理済み」って待機期間が始まったことだと思ったんです。そこでクリックした時点からカウントして、そのタイミングに合わせて担保移動の計画を立てました。

でも、始まっていませんでした。

そのリクエストは、エポックを通過し、さらにBitcoinのチェックポイントに到達する必要がありました。300回の確認が始まる前です。そう気づいたころには、BABYはまだロックされたままで、私が想定していたよりもポジションに余裕がありませんでした。

重要だったのは、受理済みのリクエストではありませんでした。Bitcoinの確認回数がまだ開始していないこと、それでした。

私は、0.01188ドルまでにそのBABYを担保として必要としていました。

しかし、清算リスクがどんどん近づく中で、BABYはエグジット・キューに引っかかったままになっていました。

#BABY $BABY @BabylonLabs_io

私は、BTCのステーキングを見つけてビットコイン上で確認できたとしても、それがバビロンでは使えないまま到達してしまうことがあると分かりました。
罠は「パラメータのタイミング」です。バビロンは、btc_activation_height によって BTC ステーキングのルールをバージョン管理します。事前ステーキングのフローでは、私は登録時にバビロン自身のビットコインライトクライアントが見ているパラメータセットに対してビルドしなければなりません。後になってビットコインがそのトランザクションをマイニングする時に、見た目に最新のものではありません。選ばれたバージョンは、協定（covenant）の鍵とクォーラム、さらにバビロンが検証することになるアンボンディング条件を固定します。
このルックアップを外すと、取引は私が署名した通りの動作を“そのまま”行えます。ビットコインはアウトプットを受け入れます。マイナーは報酬を受け取ります。コンファメーションが積み上がります。すると、スクリプトが間違ったルールセット用に作られていたため、バビロンはステーキングパッケージを検証できません。
ウォレットビルダーにとってそれは、残酷な「誤った成功」です。ユーザーのBTCは支払い可能残高から出て、時間制限付きのステーキングアウトプット内に座っていますが、そのポジションには投票権がなく、何も得られません。通常のリトライでは、すでにビットコインにコミットされてしまったスクリプトは修復できません。
私は、署名画面に「パラメータのバージョン」と「アクティベーション・ハイト」を表示し、それからバビロンのライトクライアント視点が古い（stale）限りブロードキャストを禁止します。ルックアップを緑の確認表示の裏に隠すことで、連携は有効なビットコインを“取り残されたステーキング資本”に変えてしまうのです。
#baby $BABY @BabylonLabs_io

バビロンの最終性プロバイダが、重要な署名要求がすでにすべて死んでいるのに、ヘルスチェックには通ってしまうことを見つけました。
死角は fpd と eotsd の間にあります。バビロンは HMAC なしで Ping を通すため、モニタは EOTS マネージャーが到達可能だと表示し続けられます。ですが SignEOTS、SignSchnorrSig、そして CreateRandomnessPairList はすべて共有鍵を必要とします。 fpd.conf と eotsd.conf の間で少しでも不一致があれば（混入した空白ですら）、無害な呼び出しは緑のままでも、本番向けの呼び出しは拒否されます。
つまり、2つのデーモンを動かし、同期済みのバビロンの Genesis ノードを用意して、RPC 接続は開いているのに、使える最終性出力が得られない状態にできます。そのプロバイダは起動時に大きくは失敗しません。失敗するのは、fpd が次の高さに必要な署名またはランダムネスを eotsd に要求するときです。
私は Ping だけではアラートを出しません。認証付きの署名パスをテストし、最後に成功した EOTS 要求を追跡します。そうしないと、ダッシュボードはドアが存在することしか証明せず、鍵がまだ開けられているかまでは分からないからです。
バビロンのオペレーターにとっては、緑の接続表示が、すでに投票を停止しているプロバイダを隠してしまうことがあります。
#baby $BABY @BabylonLabs_io

BABYの委任を送信でき、取引をリアルタイムで確認でき、かつ取引に対する持分がないこと。

委任、無効化、再委任のメッセージをx/epoching内で行うには、Babylonのキューを使用します。契約内容はここに記録されますが、バリデータの権限は360ブロックのエポックが終了したときにのみ更新されます。これは約1時間後です。私が不正に仕込んだとされるこのBABYの壁は、その境界まではまだ流動的です。

それがひどいウォレットの問題につながります。「success」を見てからトークンを移動すると、キューに入った委任は待機していた残高がないままエポック処理に到達し、失敗します。チェーンが伝えたことは嘘ではありません。インターフェースが、完了として誤った段階を作ってしまいました。

ステータスの有用性は検証されていません。エポック終了を待っており、その時点でロックされ、報酬を得ます。ウォレットには、キュー、残りのエポック時間、そして正常に実行されたステークの最終結果を表示すべきです。そうすれば、有効なステークに署名したあと、後続の転送で誤ってキャンセルしてしまっても、キュー内にステークが残っているのが確認できます。

ただ、その足りない1時間からはどうしても逃げられません。Babylonでは、取引の成功とステーキングの成功は別の出来事です。これらを1つの緑のチェックにまとめてしまうインターフェースは、通常のトークン移動を失敗した委任として扱うことになります。

#baby $BABY @BabylonLabs_io

$COTI update:

このリカバリーは短期的なリカバリーのように見えます。私の見立てでは、次の大きな強気のインパルスが始まるまでに、最終的にもう一段低い安値の終値を作ることになるでしょう。

私が引き続き希望する売りのゾーンは $0.01900–$0.02170 です。そこから、$0.0050-$0.0055 の蓄積（アキュミュレーション）ゾーンへのブレイクを待ちます。

その水準に到達したら、ショートをクローズして、このリカバリー・ラリーの代わりにロングポジションを新たにオープンします。これは、上方向に向かう大きなものになると私は考えています。

金庫を登録します。ビットコインのロックを確認します。担保の状態を追跡します。償還（リデンプション）の経路を構築します。そして、金融商品自体が何か有用なことを行う前に、同じビットコイン固有の作業をもう一度繰り返します。

Babylon はそのボトルネックを解消しました。

その Trustless BTCVault テストネットは、ネイティブ BTC 担保のための動作する開発環境をビルダーに提供し、一方で TBV マネージャー・コントラクトが、標準的な1つのインターフェースの裏で、金庫の登録、検証、そして安全な償還を処理します。

これでプロダクトのロジックは前面に出られます。

ビルダーは担保に何を行うべきかを定義し、その後、ビットコインを重く扱う実行をマネージャー・コントラクトに渡せます。既存のアプリケーションも、まったく新しい担保システムを中心に作り直す代わりに、プロキシ経由で接続できます。

これは実用的なアンロックです。

貸付や担保プロダクトの難しい部分は、そのリスク規則とユーザーの成果であるべきです。各チームがそれぞれ別々に、ビットコインが同じ外部状態を認識できるように教えることが必要になっていてはなりません。

Babylon はより小さな最初の構築を作りました。最初に動くフローは、手作りのビットコイン償還エンジンではなく、財務上のアクションに集中できるようになりました。

@BabylonLabs_io $BABY #baby

これは、最新のBabylonステーキングパラメータが、ステークを検証する際に誤りである可能性があるということです。

検証者は、今日の設定を取得して、これまでに作成されたすべてのBTCステーキング取引に適用することはできません。Babylonは、Bitcoinのアクティベーション時の高さによってステーキング規則のバージョン管理を行います。正しいスナップショットは、そのステークがシステムに入った時期と方法に依存します。

ステーク登録が事後の場合、検証者は取引が含まれたBitcoinブロックで有効だったパラメータを使用します。事前の場合は、登録が行われた時点でBabylonのBitcoinライトクライアントに表示されていたパラメータに、取引が固定されます。たとえBitcoinがその後のアップデートでそれを含めたとしてもです。

この違いにより、より新しい規則によって以前の約束（コミットメント）が書き換えられることが防がれます。

また、検証者が必要とする証拠も変わります。取引だけでは不十分です。登録の経路と、そのパラメータのバージョンを選択した高さも、一緒に移動していなければなりません。

この文脈を無視すると、有効な歴史的ステークが、今日の連合（コベナンツ）セット、制限、またはタイミング規則に照らして不正に見えることがあります。バイト列は変わっていません。検証者は誤ったルールブックを開いているのです。

多くの設定チェックは、オブジェクトが現在のシステムと一致しているかを尋ねます。Babylonは、ステークが条件を固定した瞬間に、そのシステムに一致していたかを尋ねます。

ここでの検証は「最新状態との一致」ではありません。BTCがコミットしたのとまったく同一のルールセットを再構築することです。

@BabylonLabs_io $BABY #baby
$DGB
$DIA

製品を開いてください。

BTCを移動できる個人を特定してください。

会社が清算された原因を特定してください。

同じ担保を使用する可能性があるかどうかを判断してください。

各ポジションが、既知のビットコインのどれを指しているのかを計算してください。

各デザインごとに繰り返してください。

昔、私はそれを研究の間接費として前提にして受け止めていました。BabylonのSCRIPTとしてリリースされているため、防御がより難しくなっています。

Trustless Bitcoin Vaultsを設計する際にBabylonが内部で用いていたリスクグリッドはSCRIPTと呼ばれます。unlockという頭字語は研究者のためのものではありません。
unlockという頭字語は研究者のためのものではありません。混沌とした問いには、そこへ向かって進んでいく特定の行き先があるのです。

所有者は、ある出来事が起こるまで支配を維持しますか？

借り手の明確な許可なしに、BTCを再担保化（rehypothecation）できますか？

単一のアプリケーションのポジションは、ビットコインの担保における元のポジションまで追跡できるでしょうか？

しかし、これらの確認では、「native」や「non-custodial」といった言葉によって隠されているギャップが明らかになります。

プロトコル・レベルでのデューデリジェンスは、SCRIPTによって影響を受けません。

各レビューが新しいページから始まるのを防ぎます。また、Babylonian vaultの自前の設計に基づく公開テストを提供する効果もあり、Babylonian vaultまわりのすべてに適用できます。

それが、私が気にしているレートです。

Bitcoin担保に関する、反復可能な最初の一次確認。ラベルの解読から、支配・隔離・帰属が破綻する正確な地点を見つけるところまで。

@BabylonLabs_io $BABY #baby
$DIA

$EUL

🎁ご支援ありがとうございます、@Binance Square Official 🎁

一部のパッケージは単なる商品以上のものです。
作品が見られていることを人々に思い出してもらうために。
感謝されているかのように。

私のことを思ってくれて、そして支えてくれてありがとうございます。

BABYを委任したトレーダーは、実際にマーケットのトレーダーとしてそのインベントリにアクセスしているため、未ステークのクリックを「できない」とは考えられません。ただし、もう一つの前提も誤りです。これは、多くのPoSネットワークにあるような21日間の「クールダウン」期間ではありません。

Babylonは最初に、未委任をキューに入れ、現在のエポックの終了まで待機します。このエポックはビットコインに紐づいており、トークンのリリースは300回のビットコイン確認を待ちます。通常のタイミングでは約50時間です。ネットワーク状況によっては、より長くかかる可能性があります。

つまり、「流動残高」や長期ロックの「資本」に別のカテゴリを追加するべきではありません。これは、ビットコインのタイミングに基づく在庫のように機能します。

それが、トレーダーが自身（本人）のために計画を立てる方法の違いです。時計は有用で、エポックの境界から始まり、BABYが再び譲渡可能になるまでしか終わりません。この順序に従わない場合、資金が準備できていないタイミングでトレーダーが取引を行う状況になってしまう可能性があります。

ステークはBabylon Genesisに保持されますが、ビットコインがいつ退出を使えるかを決定します。つまり、確認のカウントダウンは注記（細かい記載）の中にあるのではなく、入札価格のすぐそばに配置されている、ということです。

@BabylonLabs_io $BABY #baby

下書きを開いてください。「自己管理（セルフ・カストディアル）のBTCステーキング」と入力します。それを削除して、もう一度入力してください。しばらくの間、それがBabylonをめぐる“作り手のループ”でした。というのも、その概念がほとんどの仕事をしてくれていて、その結果は画面の外に留まっていたからです。フェーズ2は、その最初の一文の先へ物語を進めました。Babylon Genesisが稼働し、続いて許可不要のBTCステーキングが、ダッシュボードからフェーズ1の両方のポジションと新規ステークに向けて開放されました。これにより、BTCはロックされたビットコインの状態から、ベースのステーキング報酬が紐づいたGenesisのための“稼働するセキュリティ”へと切り替えられるようになりました。
作り手の仕事もそれに伴って変わりました。
今度は、ロックの後から始めます。自己保管（セルフ・カストディ）は依然として重要ですが、それが投稿全体の要ではなくなりました。より強い流れは見える形になっています。BTCはビットコイン上にとどまり、ステークはセキュリティの役割に入り、そしてその役割が実行されることで保有者の結果も変わるのです。これにより、作り手は“ステーキングがどう機能するか”という別の説明を積み重ねる代わりに、最初から最後まで運ぶべき1つの帰結を持てるようになります。
マイルストーンは単にアクセスを開いただけではありません。Babylonの作り手たちに、動きのある物語を与えました。そして最も強いフレームは、これまでの古い投稿が止まっていた場所から始まります。
@BabylonLabs_io $BABY #baby

監査人は、BTCが一度もビットコインから離れていないことを確認できるが、それでもなお重要なリスクを見落とす可能性がある。
私がBabylonのステーキングポジションをレビューしているなら、ウォレットの所有権は最初のチェックポイントにすぎません。難しいのは、ビットコインのステーキング取引、Babylon Genesisに登録された最終性プロバイダー、そして最終性の投票が、すべて1つの強制可能なセキュリティ経路に属していることを証明することです。
そのつながりが重要なのは、Babylonが不適切な署名を漠然とした評判上の出来事として扱わないからです。EOTSの設計により、最終性プロバイダーの二重署名における再利用として、私的なランダムネスが使われてしまい、スラッシングに必要な鍵が露出します。プロバイダーは投票権を失い、スラッシング取引はそのプロバイダーに委任されたBTCに到達できます。
そのため、監査人の負担は変わります。単にコインが自己管理のままであったかを確認するだけではありません。ビットコインとBabylon Genesisにまたがる活動を突き合わせ、そのうえで、レビュー対象の正確なステークに対してペナルティ経路が引き続き有効に維持されていることを検証する必要があります。
Babylonは、Genesis上でステークと最終性プロバイダーを登録し、監視・インデクサが対応するビットコイン取引を追跡することで、その作業を支援します。重要なアウトプットは、別のダッシュボードの数値ではありません。ロックされたBTCから、説明責任のある最終性へと至る継続的な痕跡です。
より鋭い見方は、スラッシュ可能性（slashability）監査です。自己管理は資産のコントロールを守りますが、監査人が義務を強制可能なペナルティまで追跡できる場合に限って、セキュリティ主張は生き残ります。
@BabylonLabs_io $BABY #baby