はじめに

Bitcoinのリハビリシリーズ。今回はBitcoinアドレスについてである。

Bitcoinアドレスはトランザクションに載っていない

Bitcoinアドレスは、例えばmainnetであれば 1 や 3 、 bcで始まった文字列を見たことがあると思う。

あれはあくまで人間向けに表現した文字列であって、Bitcoinトランザクションにはそういった文字列は現れない。バイナリのデータ列を人間が見て分かるように文字列に置き換えたものである。

現在よく使われているアドレスは、 1 や 3 で始まるBase58エンコードや、 bc で始まる Bech32エンコードである。mainnet以外だと文字列は異なるが、エンコード方式は同じだ。

トランザクション送金先の種類

先ほど「よく使われている」と書いたが、もうあまり使われていないものなんかもある。

Bitcoin Coreではこの辺りに定義されている。これは2021年4月4日にcommitされている内容だ。

• PUBKEY
• PUBKEYHASH
• SCRIPTHASH
• MULTISIG
• NULL_DATA
• WITNESS_V0_SCRIPTHASH
• WITNESS_V0_KEYHASH
• WITNESS_V1_TAPROOT

私がBitcoinの仕事をし始めた頃はNULL_DATAまで定義されていて、segwitがそれ以降だ。今の時点で正式に認められているのは WITNESS_V0_KEYHASHまでで、taprootはこれから。

仕事し始めた頃はもうPUBKEY(P2PK)はあまり使われていなくて、PUBKEYHASH(P2PKH)が個人アドレスだとほとんどだったと思う。スクリプトはSCRIPTHASH(P2SH)、MULTISIGはスクリプトのようなそうでもないような。

NULL_DATAは OP_RETURN だ。これは送金先として無効(エラーではない)なので、トランザクションにデータを埋め込むときに使われたりする。

アドレスとトランザクション送金先

Bitcoinのトランザクションは、Bitcoinの所有者を変更する情報が載っている。誰に送るか(どのスクリプトに送るか）がトランザクション送金先情報で、それを人間に見せる場合にはアドレス形式に変換する。

個人であれば、Bitcoinの所有者＝送金先の秘密鍵所有者になるため、送金先は秘密鍵を元にして作られている。もちろん秘密鍵をそのまま載せてしまうと誰でも所有者になってしまうので、秘密鍵が分からないよう変換してある。先ほどのPUBKEYであれば、秘密鍵→公開鍵→SHA256→RIPEMD160、である。

これにプレフィクスとCRC付与→Base58エンコード、とすると人間が見るアドレス形式になる。さっきの 1 や 3 で始まるタイプがこれだ。

そうではなく、witnessバージョンとチェックサムを付与→Bech32エンコード→ bc などをつける、とするとWITNESS形式の方のアドレスになる。 bc で始まるタイプだ。

このように、同じ秘密鍵から異なるアドレスを作ることができる。RIPEMD160までは同じなのでトランザクションのバイナリデータを見れば分からんでもないし、文字列をデコードすればバイナリデータが出てくるので分かるかもしれん。

おわりに

今回はBitcoinアドレスについて簡単に説明した。

Bitcoinに関する計算の中でもアドレス算出は比較的簡単な部類だと思うので、自分で実装しても面白いかもしれない。

株式会社Nayuta

Bitcoinの2nd Layer技術－ライトニングネットワークのプロトコルとアプリケーションの開発を両輪で行う。この分野において当社は世界的認知を得、コントリビュータとしてグローバルなコミュニティで活動を継続中。最新のリリースの中には利便性とセキュリティを両立したSPVとフルノードのハイブリッドモデルNayuta Coreがある。
また、様々なタイプのブロックチェーンが共存する時代が近づいていることから、エンタープライズ向けブロックチェーンに関するビジネスも行っている。

はじめに

Bitcoinのリハビリをやっている。以前覚えた箇所を思い出す作業だ。前回の復習はトランザクション構造だった。

今回は bitcoind とのネットワーク接続について書いていこう。

アイコンの色

本編から違う話になってしまうが、Bitcoin CoreのGUIアプリを起動したとき、どのネットワークで起動しているかによってアイコンの色が異なる。

オレンジはmainnet、グリーンはtestnet、シアンはregtest。signetはこんな色だった。画像ファイルを持っていないので色を作っているのだと思うが、何か計算式があるんだろうか？

大きく2つ

Bitcoinノード同士の接続はP2P(peer to peer)方式である。私はLightning Networkノードを実装するときに初めてP2Pを扱うことになってひどく悩んだのだが、クライアントとして接続する手段とサーバとして接続される手段を用意しておくだけだった。サーバになるときは複数からの接続を処理しないといけないので、 accept が通ったらスレッドを立てて後の処理は別スレッドで行うようなことになる。

もう1つよく使うのは、Bitcoinノードに指示を出す場合である。これはJSON-RPCで行っている。 bitcoin-cli コマンドで行う場合も内部でJSON-RPCに置き換えられている。

はじめに

2021年の春にAzure AD Verifiable Credentialがpublic previewになった。

その前は確か招待制で、メールを出さないと使えなかったと思う(私はやってない)。

せっかくpublic previewになったので動かしてみる。ちなみに記事を作り始めたのが2021年4月上旬なので、少し情報にずれがあるかもしれない。

いるもの

今回は無料で利用してみるのだが、スマートフォンは持っていないと使えない。Microsoft Authenticatorがいるからだ。

以前はベータ版テスターになってベータ版をインストールしていないといけなかったので、私はAndroidのベータ版 6.2104.2518で試している。

あとは、GitHubからcloneしてNode.jsで動かす環境がいる。私は …

はじめに

過去2回signetの記事を書いてきた。

signet その1: bitcoin coreで立てるだけ

signet その2: signetの詳細を確認

3回目となる今回は、今の最新リリースであるBitcoin Core v0.21.0で自分の鍵を使ったsignet環境を構築したい。

そしてタイトルを見てわかるように、v0.21.0での構築はうまくできなかった。

signet用パラメータ

bitcoindのsignetに関する直接のパラメータは3つある。

-signet : signetを使う

-signetchallenge : blockを署名して作成する場合のlocking scriptにあたるもの

-signetseednode : ノード

1台で試すのなら -signet は指定するだけでいいし、 -signetseed …

はじめに

Bitcoinのブロックヘッダの中にmerkle rootという32バイトのデータがある。

その話だ。

merkle root

ブロックのデータには、ブロックヘッダとそのブロックが承認したトランザクションデータたちが入っている。ブロックハッシュ(あるいはブロックヘッダハッシュ)の計算はブロックヘッダしか使わない。
その代わりにというのも変だが、トランザクションのデータのダイジェストでもあるTXIDをさらにダイジェストしたmerkle rootという値がブロックヘッダに入っている。

計算の仕方

トランザクションが6個だった場合で見ていこう。

まず、TXIDを順番に並べる。ちなみにTXIDはトランザクションデータのハッシュ値だが、人間に見せたりJSON-RPCの値として使う場合にはハッシュ値のバイト列を逆順に並べている。ここでは計算に使うのでハッシュ値の並びそのままにして並べる。そして、1番目と2番目、3番目と4番目、5番目と6番目という組を作る。

組になったデータはバイト列を連結して64バイトのデータにする。その64バイトのデータをsha256でハッシュ計算し、得られた32バイトをさらにsha256でハッシュ計算する。HASH256とかsha256dとか呼ばれる計算だ。

そうすると6個のデータが3個になる。
同じ要領で1番目と2番目、3番目と4番目の組を作るのだが、4番目がいない。そういうときは同じデータ列、今回なら3番目のデータと同じデータ列を4番目と見なして組を作る。

はじめに

以前にbitcoindでsignetを立ち上げたので、今回はもう少し詳細に見る。

P2Pメッセージ

P2Pでのメッセージにはマジックナンバーを埋め込む箇所(magic)があり、ここがネットワークごとに異なる。signetのオリジナル(ユーザがカスタマイズしない場合)では0x0A, 0x03, 0xCF, 0x40になっている。

念のためwiresharkで見ておく。

はじめに

前回、Raspberry Pi3でbitcoindを立ち上げるところまでやった。

今回はその続き。ちなみに、まだ最新ブロックまでたどり着いていない。

以下、dbcacheの値を変えてやってみた記録である。計測は手動でやっているので、n時間、といっても数分の誤差がある。

dbcache=100

速度がバラバラなので何とも言えないのだが、2時間で590ブロックくらいだったり3時間で530ブロックくらいだったり。

dbcache=200

5時間で1800ブロックくらいだったり、2時間で370ブロックくらいだったり。

これだけばらつくと、dbcacheの値ごとに速度を計測する意味がほとんどないんじゃないかね……

dbcache=300

これは今日の設定値だ。1時間で330ブロックくらいだったり520ブロックくらいだったり。

dbcacheのデフォルト値は450ということなので、もうこの辺りが限界なんじゃないだろうか。

$ free -m
       total  used   free  shared  buff/cache   available
Mem:     924   335     36       0         551         533
Swap:  14761   321  14439

データディレクトリはHDD上だが、swapはUSBメモリにしている。microSDにおいた方が速そうだけどシステムディスクが摩耗するのは避けたいし、HDDは耐久性がありそうだけど遅そうだし、ということでUSBメモリにしている。正直なところ効果はよくわからん。

こんな感じで、ダウンロードしたブロックはようやく45万くらいだ。今の最新が67万8千ブロックくらいだから、まだまだだ。PCでbitcoind立ててブロックをダウンロードしてコピーすればよいのだが、それはそれで負けた気がする。

会社の人は1週間も経たずにできていたのだが、これはRaspberry Pi4の威力なのか、Umbrelの設定値が最適なのか。v0.2.10の設定を見てみよう。

/proc/meminfo の値を使っているようだ。これが今Raspberry Pi3で見た値。

$ cat /proc/meminfo | grep MemTotal
MemTotal:         946392 kB

dbcacheの単位がMBなので、kB値を1024で割ってMBにして、半分にして300引いているというところか。私の値だと、162になる。それよりも多く設定しているから、少なすぎということはないのだろう。それにUmbrelはbitcoind以外にもいろいろ起動させているので、その分のメモリも空けておきたいに違いない。

umbrel-osのREADMEを見ると、Raspberry Pi4のメモリは4GBか8GBと書いてあった。4GBだとしてもdbcacheは1700以上割り当てるので、まあさもありなんというところか。ちなみにUmbrel v0.3.8ではブロックのダウンロードが完了するまではこの計算値で、終わってからは200にしている。ダウンロードを早く終わらせるためだろう。

おわりに

というわけで、今回は途中経過の報告だった。

しかし、ダウンロードしているブロック数が大幅にばらつくのはなんでだろう？ segwitが始まる前だったらだいたいブロックは1MBくらいだと思っているのだ。1時間で300ブロックダウンロードしたとして1分に5ブロック。5MBくらい。Raspberry Pi3だからといって1分で5MBしかダウンロードできないことは中労使、検証にかかる時間もそんなに変わらないと思うのだ。じゃあHDDの遅さかといっても、USB2.0とはいえそんなにデータ量が多くないし。そもそもswapが必要という時点で遅くなっているのかもしれん。

株式会社Nayuta

Bitcoinの2nd Layer技術－ライトニングネットワークのプロトコルとアプリケーションの開発を両輪で行う。この分野において当社は世界的認知を得、コントリビュータとしてグローバルなコミュニティで活動を継続中。最新のリリースの中には利便性とセキュリティを両立したSPVとフルノードのハイブリッドモデルNayuta Coreがある。
また、様々なタイプのブロックチェーンが共存する時代が近づいていることから、エンタープライズ向けブロックチェーンに関するビジネスも行っている。

はじめに

会社の人が、Umbrelでノードを立てる動画を作ってました。

(英語版はこちら)

負けてられん！ 私も立てねば！！

謎の焦燥感に駆られて、フルノードを立てることにしました。ただ、同じことをやっても面白くないので、Raspberry Pi3を使うことにしましょう。

ちなみに↑の準備に関して、技術班は社内に余ってたmicroSDの提供くらいしかしてません。

UmbrelのRasPi3版はもうやってない

Umbrelの手順通りにやりました。SSDはなかったのでHDDで。まあ遅いだろうけど急いでないしいいでしょう。

電源を入れると、止まってはいないようだけど・・・動けていないという感じがします。HDDの中を見るとbitcoindのブロックデータはありそうだから、まったく動いていないというわけではなさそう。念のため何回かやり直したけど、ダメ。

そして、ようやく気付いたのです。。。

そのときの最新はv0.3.6だったですが、Raspberry Pi3に対応しているのはv0.2.10までとのこと。

じゃあ、v0.2.10でいいや

Umbrel v0.2.10だと起動しました。「起動した」の意味は、ブラウザで画面が見えるようになったという意味です。ブロックダウンロードにどのくらい時間がかかるか分からないけれど、ゆっくり待ちましょう。

おや、ブラウザの上の方にソフトウェアアップデートの案内が出てるじゃないですか。bitcoindの再起動はダウンロードしたブロックデータが大きいと読み込むのに時間がかかるので、先にアップデートしておきますかね。ぽちっ。

・・・馬鹿でしたよ、ほんとに。さっきバージョンの上限を確認したばかりやん。アップデートが終わって再起動した後は、もう起動できないようになってました。

Umbrelがダメなら素で立てればいいじゃないの

Umbrelの構成を詳しくは知らないけど、bitcoind立てて、lnd立てて、ブロックエクスプローラみたいなのを立てて、管理画面立てて、Torブラウザで見られるように仕立ててるだけだと思うのですよ。

じゃあ、素のbitcoindでやればいいはずです。まあなんだかんだ言ってbitcoindはよく立ててますしね。

Raspberry Pi3は、CPUは64bitですがRaspbianOSのダウンロードできる方は32bitなので、Bitcoin CoreもARMの32bit版をダウンロードします。あとは展開して、データの保存先をHDDにしてbitcoindを立ち上げるだけ。

実はRaspberry Pi3は今回初めて個人で買ったもので、今まではPi2とかZeroとかしか使ったことがありませんでした。会社にPi3はあるけど、Pi2しか使ったこと無かった私からすると「もうパソコンやん・・・」と思ったものです。
ならば、bitcoindも普通に起動すればいいでしょう。

・・・ダメでした。
さっきのUmbrelと同じかもしれないけど、動いていそうだけど動けてない感じです。

ここに来てようやく、Rapsberry Pi3で立ち上げるのってそこそこノウハウが入るんじゃないの、ということに気付きました。

絞りすぎると遅くなる

Bitcoin Coreのドキュメントに「Reduce Memory」というのがあります。こんなことするとメモリの使用量が減らせますよ、というやつだ。bitcoindを素で動かして変な感じがするのも、たぶんメモリを使い切ってしまっているからでしょう。

どのくらいにしたらよいかわからんので、少なそうな感じにしてみました。

• dbcache: 10
• maxmempool: 5
• maxconnections: 6

グローバルなところに置いていないのでmaxconnectionsはあまり意味が無かったかもしれん。dbcacheはパフォーマンスに影響しそうだけど、最小値(4)の倍以上はあるからまあいいか。

と、こんな感じで動かし続けて早10日以上経過しましたが、まだブロック同期は終わっていません・・・。43万ブロックにも達していない状況。様子を見てみると、どうも1時間で200ブロック程度しか進んでいないようです。

200ブロック/時！
まあたまたま遅かっただけかもと思ったが、3時間で500ブロックだったりしているところを見ると、平均でそのくらいなのかもしれない。

一度 bitcoin-cli stop で止めて、dbcacheを見直すことにしました。10→100。どのくらい変わるのか期待する気持ちと、RasPiが止まったりしないように祈る気持ちとで複雑です。

おわりに

bitcoindの再起動をしたので、ブロックデータの読込とか考えると1週間後ですかね。

・・・と思っていたのですが、まだ1時間も経っていないのに bitcoin-cli getblockcount が応答しました。こ、これがdbcacheを10倍にした効果なのか？？

思ったより次の記事を書くための時間が短くなりそうなので内心焦っていますが、ひとまず様子を見ましょう。