Purchased this article xlco5hfc6
知識0からはじまるLNチャネル復旧その2
前回までのあらすじ未だラズパイの中にデータを移さないとバックアップが働かないことに気が付かない私はヒントを探しに右下にちっちゃく乗ってるリンク(この記事では上)からUmbrel Communityへ乗り込んだのだったやっと本編だよ 探し方が間違っていたのだろうが探し回って見つけた先がバックアップの復元手順はよくある質問を見てくださいThe procedure for restoring from backup is explained here Frepuently Asked Questions(FAQs) Oops!!!!!! ふざけんなと叫んだりしたがぐるぐるコミュニティーを右往左往しているうちに <

知識0からはじまるLNチャネル復旧その1
買い替えたラズパイ組み立てパスフレーズ入れたけどBitcoinが足りないぞこれはLightningチャネルの分だねー以上前回のあらすじ パスフレーズ入力したんだからLNチャネル分も一緒に復旧してくればいいじゃんと文句垂れつつもまぁちゃんとバックアップしてるから問題ないもんね楽勝楽勝 あの……。どこからアップロードすればいいんですか?ダウンロードする場所があるならその逆も然りが通常なのでは?????まぁいいやわたしはRTLのバックアップもとってあるしそっちでも大丈夫だろう多分 こっちもかよ! (最近勝手に日本語に変換されましたけど カタカナで”ライト・ザ・ライトニング”って ちょっとばかしダサくないですか?)バックアップフォルダの置き場?いちいち指定されてるのか……PC上でdataファイルをつくりバックアップを移動させるわたししかしうんともすんとも反応しませんね それは当然ラズパイの中にバックアップデータがなければ意味がないんですそんなこととはつゆ知らずPC再起動するなど無意味な行動を重ねて1日をムダにしました 意味がわからない。なんでこんなことに……今振り返ればそりゃそうだって話ですが当時のわたしは頭をかかえました自然と落ちる目線 ん? こ

知識0からはじまるLNチャネル復旧その3(完)
前回までのあらすじWinSCPでラズパイにバックアップデータ送ったぜ疲れたからもう寝るぜ 翌日――朝から作業してちゃっちゃと終わらせようえーっと手順は…… あーはいはいそうそうSSHでステップ1を実行して…… する必要がない 前日移動させてるので全く必要ないのだが何を勘違いしたのかステップ1から進めばもうできると思い込んでしまったそして<>が不要ということにも気がついていないので延々と失敗を繰り返す意味のない堂々巡りで時間をドブに捨てた2回くらいバックアップデータを送り直した もうDHTelegramで質問しちゃおう 流石にここまでやれば質問してもggrksとは言われまい。言われまいな?今はなんか他の方が質問してるっぽいので解決したら投げよう傲慢かつ謙虚な心持ちでその時を待つ 必死だな(笑) tanakeiさんキタ!ログ見てたら親切かつ詳しそうだしこれで勝っ 何を理解してないか理解していないと質問の答えが帰ってきてもその中身を理解できない キャッチボールにはボールと必要であれば他に道具がいるけどわたしのそれはバドミントンのラケットでバスケットボールを打ち返そうとす

チャネルバックアップなしでLNの資金をオンチェーンへ回収する方法 [Umbrel対応]
Lightning Networkのノードを運用していて、ディスク障害などでサーバーの復旧をする際、オンチェーン資金はシード(秘密鍵)から復旧できますが、オフチェーン資金はチャネルバックアップなどを使って復旧する必要があることは以前の記事で何度か紹介しました。チャネルバックアップ(LNDの場合、Static Channel Backup、SCBと呼ばれるもの)がない場合は、相手ノードへチャネルの強制閉鎖を要求してチャネルを閉じることで資金を復旧できます。ただし、チャネルの強制閉鎖後に、こちら側でもある手順を踏む必要がり、その手順はあまり知られていません。今回はその手順を紹介したいと思います。 今回使うツールは以下で、LNDのみ対応しています。c-lightningでの復旧方法はこちらを参照ください。 ・・・ 最初にチャネルの相手方へチャネルの強制閉鎖を依頼します。その後、自身のUmbrelの復旧をしましょう。復旧手順はUmbrelを再構築してセットアップ時にバックアップしていた24個のシードを入力することで復旧できます。 次にUmbrelへSSHログインをします(<a href="detail?article_id=zvxudpp25

LNノードのバックアップ&リストア考察
Lightning Networkのノード運用をする場合、特に重要なのがバックアップです。オンチェーン上のビットコインのバックアップは秘密鍵を保管しておくだけで良いですが、LNのノード運用をする場合は少し特殊です。LNノードのバックアップは大きく2つに区別することができます。それは①オンチェーン資金のバックアップと②オフチェーン資金のバックアップです。①のバックアップは秘密鍵の保管をするだけで問題ありません。②のオフチェーン資金のバックアップとは、チャネルのバックアップです。LN上のチャネルは送受信がある度にチャネル状態が更新されていくので、その都度バックアップをとる必要があります。もし古いチャネル状態で相手と通信をすると、不正な状態と見なされ、最悪の場合、資金を失うかもしれません。 data loss protection そのような場合を考慮して、LNの仕様書では data loss protection (DLP)と呼ばれる安全装置が付いています(02-peer-protocol)。これは、もしアリスのチャネル状態が5で、ボブのチャネル状態が6だった場合、アリスのチャネルは古い状態なので、ボブにチャネルを強制閉鎖することを依頼できる仕組みです。この依頼を受けたボブが取れる行動は、(a)最新のチャネル状態6で強制閉鎖するか、(b)古いチャネル状態、例えば自分の残高が多くなるようなチャネル状態まで遡り、そのチャネル状態で強制閉鎖することが考えられます。ボブが(b)の選択をしても、もしアリスが嘘を付いていて最新のチャネル状態までデータを保持していると、ボブはペナルティとして、アリスに全額没収されてしまいます。そのため、ボブは(a)の正直な選択を取ったほうが無難なのです。これが data loss protection と呼ばれる仕組みで、ゲーム理論的な側面があります。この仕様は各LNソフトウェアに実装されています。 またLNDでは、static channel backup(SCB)と呼ばれるチャネル開設がある度に取得するバックアップがあります。これは、最初のチャネル状態だけをバックアップして、リストア時にSCBからチャネル状態を復元しようとするとチャネル状態が古いので、DLPによってチャネルの強制閉鎖を相手に依頼するというものです。このSCBはLNDのみ実装されており、c-lightningやEclair coreには実装されていません。LNのバックアップでは秘密鍵以外にも②のチャネルのバックアップも必要でした。一見するとこのSCBは必須な気がしますが(実際コミュニティでも議論されている<a href="https://github.c

Solana 事案と秘密鍵とモナコインアドレスと mpurse 認証
つぶやき。ぽえむ。 ポエム書いている時点では原因不明らしいですけれども、「ETH より優れているぜ」系の新興チェーンである Solana の資産が、大規模にハッキングされているようですね…。 チェーン側のバグ、たとえば署名検証アルゴリズムが理由である可能性は残されていますが、おそらく違うでしょう。こういう「お祭り」のときは、チェーンと利害があったりなかったりするエンジニアらが、チェーンのコードを精査して指摘するはずなので。 Ⓜ 全く話が別のところに飛びますが。 ビットコイン系…モナコインは当然含まれます…のチェーンには、「秘密鍵と公開鍵を使った電子署名機能」があります。これを使ったモナコイン系のサービスは存在します。しかし、ビットコイン系では見かけません。不思議に思ったこと、無いですか? そしてさらに巻き戻して。電子署名に基づくコントラクトなら、公開鍵を公開すればよいはずなのに、なんで公開鍵にハッシュをかけたものをアドレスとしているのか、不思議に思ったこと、ないですか?(…これを不思議に思うのは、暗号資産エンジョイ勢よりもガチクリプト寄りのはずなので、技術至上でない読者が不思議に思わなくても変じゃないです) Ⓜ 答えを知るだけなら事情ははシンブルで。 電子署名と検証のプロセスを何度も重ねると、公開鍵から秘密鍵が推測可能になる(可能性が微レ存でもある)なのです。だから、公開鍵でさえもハッシュで隠してアドレスとして扱う。 無職業者BOT的見解としては「んなもん心配するなら頭上に流れ星が降ってくる可能性をあんじて畏れよ」なのですが。 ガチのクリプト勢は、そこまで考えているっていうことですね。 …などいうとガチ勢を揶揄しているように捉えられそうなので真顔で補足しておくならば。 彼ら、ふわっと畏れているわけでなく、かつて鉄壁と思われていたアルゴリズムが綿だったので酷い目を見た、という手痛い過去が記憶にあるわけです。界隈に。サイファーパンク宣言から生き残ってきた連中なので、仮想通貨勢が思うより遥かにガチなのです。 Ⓜ じゃあどうすればいいのよ、ってなっても答えは出せません。なにかあっても責任取れないので。 ただし、AskMona 3.0 の設計は、参考になるとは思います。 Ⓜ (AskMona の開発者、サービス設計の妥当性といい、税制へのアクティビズムといい、一体何者なんだ?) (正体への興味はあるけど、謎のままのほうが個人的には面白い。クリプトだからね) <p s

Purchased this article o09l2ojky
Purchased this article cwvnlf4n5
Purchased this article 8tz1w4aqr
Purchased this article yqymlagm2
Purchased this article yk2xr92d1
Purchased this article 4pt44q6z9
Purchased this article o38b3zme7
Purchased this article hh5dlrsvh
Purchased this article emu6dbib3
Purchased this article o0o5a34da
Purchased this article vyvk3kvf8
Cryptcoin Junkey purchased this article orueontc9
Purchased this article n4lz7k2n9
Purchased this article m8qgfwt2a
Purchased this article 2te833p3h
Purchased this article 32u6bi6tf