2018/02/17

[btc]addwitnessaddressのアドレスからdumpprivkeyはできない

bitcoindの話だ。

bitcoin-cli getnewaddressすると、P2PKHのアドレスが返ってくる。
HDウォレットのインデックスがインクリメントされて新しいアドレスが生成されたということか。

そのアドレスについてbitcoin-cli addwitnessaddressすると、P2WPKHのアドレスが返ってくる。
ただし、現在(2018/02/17)のところ、bitcoindではnativeのP2WPKHアドレスを扱うことができない。
だから、P2WPKH nested in BIP16 P2SHというアドレスがが返ってきている。

nested in BIP16 P2SH形式のよいところは、見た目上はP2SHアドレスになっているというところだ。
これなら、segwitに対応していないウォレットであっても送金することができる。
じゃあ、その形式だけでいいじゃないか、となりそうだが、segwitのnativeアドレスには利点がある。
その場合には、トランザクションのサイズを小さくすることができるのだ。

nativeなP2WPKHの場合、今までのscriptSigの部分がまったく無くなり、witnessのセクションに移動する。
segwitにするとブロックに入るトランザクションの数が増えるというが、たしかにトランザクションの数は増えるものの、トランザクション自体のサイズについては別の話だ。
nested in BIP16 P2SH形式の場合、scriptSigにもデータを置かないと既存ウォレットとの互換性が無くなってしまうので、トランザクションとしてのサイズが多少増えてしまうのだ。
ブロックに入れる際にwitnessの部分は別の場所に入るため、そこまで影響は無いのかもしれんが、大きくなることはなるのだ。
これがnative形式だとトランザクション自体が別物という扱いになるからかscriptSigのサイズは0になり、署名などはすべてwitnessに押し込められる。


私が不勉強なので、ブロックに取り込むところなどのしくみをよくわかっていないのだが、まあ、そこはbitcoindなんかがやってくれるからいいや、と割り切っている。
フルノードの庇護を受けている間は、けっこう楽ができるのだ。


ただ、というか、しょうがないか、というところだが、addwitnessaddressでつくったアドレスはdumpprivkeyで秘密鍵が取って来れないのだ。
P2SHという時点であきらめてしまう気がする。


次の0.16ではBECH32形式のアドレスが使えるようになるとか。
そうなると、直接nativeの形式でアドレスを生成できるようになるのかもしれん。

2nd Layerというか、BOLTではfundingにnativeなアドレスを使うことになっているので、今の時点では何とかしてP2WPKHから送金させる必要があるのだった。

まあ、そういうこともあるさっ。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。