ビットコインの情報サイトの運営者ブログ

サイトには掲載していない仮想通貨に関する時事的な情報や個人的な感想など。中級者以上向け。

NEMのNamespaceのレンタル期間を更新してみた

約1年前に作ったNEMのNamespaceのレンタル期間がそろそろ期限に近づいてきたので、更新してみました。Nano Walletに最近更新機能が実装されたので、記事にするまでもなく簡単なのですが、恐らくまだほとんどの人がやったことがないはずなので書いておきます。(ほとんどの人は手数料が下がった昨年の12月以降に借りているはずなので、更新する必要が出てくる時期には仕様とかUIは変わってるかもしれません・・・。)
f:id:jpbitcoin:20170303164703p:plain
1.画像の赤枠のところ、「Renew namespaces」を選択します。

f:id:jpbitcoin:20170303165022p:plain
2.ウォレットのパスワードを入力
3.「Renew」ボタンをクリック

f:id:jpbitcoin:20170303165141p:plain
4.完了!

これだけで終了です。ちなみにNamespaceの更新トランザクションはProvisionNamespaceTransactionという作成(借用)時のトランザクションと全く同じ型のようで、履歴にも作成時と同様の表示がされます。
現在の更新料は作成費用と同じ5000XEMですが、大本のネームスペースを更新すればサブネームスペースやモザイクも自動的に同時に更新され追加の費用を支払う必要はないようです。なお、寄付をいただいていたXEMが5000XEMを超えていたので、すべて寄付から更新料を出すことができました。ありがとうございました。

更新後はNamespaceの情報も更新されています。
更新前:

{"owner":"NBLK2AI3JONRZWVA57TC63W5UQ3JUD77MBXQWQES","fqn":"jpbit","height":511255}

更新後:

{"owner":"NBLK2AI3JONRZWVA57TC63W5UQ3JUD77MBXQWQES","fqn":"jpbit","height":1006151}

期限切れ一月前にならないと以下のように更新はできません。
f:id:jpbitcoin:20170303165924p:plain

Nano WalletのおかげでNamespaceの更新も非常に簡単にできたという話でした。

トランザクションがなかなか確認されないときの4つの解決策

ここ数日メモリプール(未確認トランザクション)の総サイズが60MB(blockchain.infoより)を超え過去最高レベルの混雑度になっています。ということで、手数料不足でトランザクションがなかなか確認されないときの解決法が、日本語サイト・ブログで意外と見つからなかったのでまとめておきます。

f:id:jpbitcoin:20170223141723p:plain

 1.待つ

ひたすら待てばいつか確認されるか、トランザクションがなかったことになりウォレットに残高が戻るかどちらかになります。一番単純な解決策で、初心者からどうしたらよいか聞かれたらとりあえず「待て」と言っておきましょう。

次からは事前に手数料を高めの設定にしてから送ってください。

2.RBF(後から手数料を変更できる設定にしてから送金)

詳細は過去のRBFの記事参照。Replace-by-Feeの略です。

事前にトランザクションに「このトランザクションは後から手数料が変更される可能性があるよ」とラベルを付けて送信することによって、送信後であってもあとから手数料を変更できます。

対応しているウォレットが非常に少ないのが難点で、主要ウォレットのなかで現在実装しているのはGreenAddress(GreenBits)とElectrumしかありません。公式クライアントBitcoin Coreも次バージョンの0.14からウォレットの機能としてようやく実装するようです。

3.CPFP(未確認トランザクションの確認を待たずに次の送金を実行)

Child Pays For Parentの略です。直訳すれば「親のために子供が(手数料を)支払う」といったところでしょうか。

ちょっとわかりにくいので例を出してみましょう。

A→B

アドレスAからアドレスBにBTCを送信するとします。このときの取引手数料の設定が低すぎたためになかなかトランザクションが確認されません。そんなときにトランザクションの確認をまたずにさらにBからCに送金を実行します。

A→B→C

このとき、B→Cの手数料を十分多くすれば、マイナーは「A→B→C」を一連の取引と考え、A→Bの取引手数料とB→Cの取引手数料の合計を「A→B→C」全体の取引手数料と見なし、A→Bの取引手数料が低かったとしても早めに確認してくれます。

 ただしこの方法には、わざわざ2取引分以上の取引手数料を余分に支払わなければならない点、自分が管理するアドレスへの入金トランザクションでないと実行できない点(ただし大抵の場合、「おつり」を自分のアドレスに送り返してるはずなので、意外と使える場面は多くあります。)などの欠点があります。どこか他人のアドレスに送ったトランザクションがなかなか確認されないというときには使えません。

また、一見「代わりにこっちで手数料支払ってあげるから手数料無料で送っていいよ」というような応用が効きそうな気がしますが、最初のA→Bの取引手数料があまりにも少なすぎると、そもそもノードからトランザクションが拒否されビットコインネットワークから直ちに除外されてしまうため、そのような応用はできません。

実際に行う時には以下の方法があります。

①未確認トランザクションを送金できるウォレット

そもそもそのウォレットが、未確認トランザクションによって送られてきたコインを確認を待たずにさらに送金できる必要があります。多くのウォレットでは対応していると思いますが、未確認トランザクションは結果的に確認されないリスクがありトラブルのもととなるため、デフォルトの設定では無効になっていたり、そもそもできないウォレットもあるかもしれません。

対応しているウォレットの場合、未確認トランザクションを含めた全残高をまとめてすべて自分のウォレット内のアドレスに送りかえすことでCPFPを利用することが可能です。要するに、全残高を使用すれば、必然的になかなか確認されない未確認トランザクションも含まれてCPFPになるということです。

お分かりのように、この方法はトランザクションサイズが大きくなり、それに伴い必要手数料が2取引分だけにとどまらずかなり大きくなってしまう可能性があります。入出金がかなり少ないウォレットでは使えるかもしれません。

②コインコントロール機能が使えるウォレット

コインコントロールというのは、どのUTXOを使うか、どのアドレスから送るかを選べる機能のことです。この機能も対応しているウォレットが非常に少なく、現在のところBitcoin CoreやElectrum、Armory等しかありません。

該当の未確認トランザクションのUTXOを使う取引を作成すれば、CPFPが適用できます。この場合は、2取引分だけの手数料で済みますし、自分のウォレットに送り返すことも、他の外部のウォレットに送って無駄な手数料を支払うことなく一度に済ませてしまうこともできます。

4.二重支払い

2のRBFのところで事前にRBFのマークを付けて送信しないと、後から手数料を変えられない・・・、と書きましたが、他の記事でも何回か書いているようにRBFもCPFPもマイナーやノードのローカルルールでしかありません。普通の取引であっても後から手数料だけを上げた二重支払い的な取引を作成・送信することで、後に送信された取引を確認させることが可能です。

当然と言えば当然のことながら機能として二重支払いが可能なウォレットはありませんが、自力で生のトランザクションデータを作成できる知識があればだれでも簡単にできますし、知識がない人でも英語で検索すれば腐るほど情報がでてきます。

RBFの記事では、サポートしているマイナーが少ないので成功する確率は低いと書きましたが、ハッシュレートの1%を占めているマイニングプールだけがサポートしていたとしても100ブロックに1回、つまり1日に1回を超える期待値で確認されることになります。

前の取引から間髪入れずに次の取引を送信しても、ノードから拒否されてマイナーまで伝わる可能性は高くないかもしれませんが、現状は経験的に1日程経過すればほぼ確実に二重支払いが成功するようです(時間が立つと一部のノードの再起動などによりメモリプールがリセットされたり、一部のメモリプール内の最低必要手数料が上がること等によりトランザクションが除外され、二重支払いの取引とは認識しないノードが増えます。)。

もちろん悪用すると犯罪行為になる恐れもあるので、自己責任で十分理解している人が必要な範囲で行ってください。

まとめ

ということで、ビットコインに慣れてきた人はただ待つだけではなく2や3(や4)の方法を試してみてはいかがでしょうか。

おまけ

2も3も4も面倒だから知り合いのマイニングプールに優先して確認してもらいたいよ、という人にはBitcoin Unlimitedを支持していることで有名になった?ViaBTCというマイニングプールが提供しているTransaction Acceleratorというツールもあります。このツールにトランザクションIDを入力すると優先度を高くしてViaBTCが確認してくれます。ViaBTCのハッシュレートの占有率は現在5%弱なので、20ブロックに1回、つまり3~4時間に1回程度の期待値で採掘されることになります。

なんでこんなことを無償でしているかというと、リンク先のツールを見れば分かるようにBitcoin Coreの開発チームがいかに悪くビットコインを駄目にしているかということを長々と説明しています。つまり政治的な主張の一環として無償でツールを提供しているわけです。

スパム対策のために0.0001BTC/kb以上、1時間に最大100トランザクションという制限があるため、人気が出てきたときは使えなくなりますし、Bitcoin CoreとBitcoin Unlimitedのコミュニティの分裂問題が何らかの形で決着するまでの期間限定だとは思いますが、特に抵抗がなければ利用してみるのもいいかもしれません。

シングルボードコンピュータでビットコインのフルノードを構築してみた

一つ前の記事でも少し触れましたが、ビットコインのフルノードをシングルボードコンピュータで構築してみたので、その手順を書きたいと思います。シングルボードコンピュータとはRaspberry Piに代表される超小型コンピュータのことです。

なお、今回のノード構築には今までにいただいた寄付を利用させていただきました。いつもありがとうございます。

0.機種選び

最低2,3年程度の常時安定稼働を目指しノードを構築することにしました。

本体

まずは本体のコンピュータ選びから。Raspberry Piが超有名ですが、メモリ1GBというのが不安でした。bitcoin.orgにもフルノードの最低動作環境は2GBとありますし、その他いろいろ調べてみると、ノード接続数を絞ったりして工夫すれば動くことは動くらしいのですが、長期安定稼働という点やネットワークへの貢献を考えれば貧弱スペックで無理やり動かすのはためらわれたので別の選択肢を探しました。

結果見つけたのが韓国のHardkernelという企業が作っているOdroid XU-4というコンピュータ。詳細スペックはリンク先を参照してもらえればいいと思いますが、最新機種のRaspberry Piと比較すると、CPUは8コア2GHz、メモリ2GB、eMMC対応、USB3.0対応、1Gbpsとかなり高性能です。ちなみにRaspberry Pi 3は4コア1.2GHz、メモリ1GB、USB2.0、100Mbpsという内容。

肝心の価格はOdroid XU-4が74ドル+22ドル(配送料+Paypal為替手数料)、Raspberry Piは35ドルなので、価格差はあるものの性能を考えれば妥当な感じ。

ちなみにOdroidは公式代理店のリストの中に日本の店が無いようなので、配送料が余分にかかりますが公式から直接買うのが良いようです。

Odroidの日本語記事はほぼ皆無で英語情報に関してもかなり少なかったので、実はRaspberry Piすら触ったことがない身としてはやや不安でしたが、結果からいうとインターネット上に転がっているRasperry Piの情報を頼りにほぼ同様にセットアップできましたし特に大きなトラブルもなかったので良かったです。

ただ、やはり情報も使用ユーザーも少ないですし、トラブルがあったときは英語で問い合わせなければならず公式サポートの評判も怪しいので、慣れていない人にはあまりお薦めできません。

ストレージ

普通はマイクロSDカードを使用しますが、フルノードは容量も要求されますし、かなり頻繁にディスク書き込みがあることを考慮して、HDDを利用することにしました。今後ブロックサイズが上がることも考慮して1TBのものを購入。剪定モード(Pruning mode)で運用する人は容量的にはほとんど必要ありませんが、SDカードだとやはり寿命が心配な気がします。

ディスプレイ

ただビットコインノードを運用するだけでもいいのですが、正直それだけだと面白くないのでコンピュータの情報を表示するLCDディスプレイを取り付けることにしました。OdroidにはCloudshellという、2.5インチHDDの取り付けが可能なNAS用のちょうどいいディスプレイ付きケースが販売されているので購入。Odroidを選んだのも実はこのCloudshellに惹かれてと言うのが大きいです。

まとめ

思ったより高くついてしまいました。合計約24,000円です。一部ビットコインデビットカード(プリペイドカード)を使用したので、手数料等で実質にかかったコストは計25,000円程度。

本体部分
  • Odroid XU-4:96ドル(本体+配送料等)
  • 2.5インチHDD 1TB:5570円
  • マイクロSDカード 8GB:518円
  • LANケーブル(CAT6):326円
  • 計:約17200円

基本HDDを使用しますが、ブートローダー(起動用プログラム)にはSDカードを使用しなければいけないようのでマイクロSDも購入。容量は必要ないものの、最低クラスでも値段はほとんど変わらないので8GBのものにしました。いらないSDカードが家に転がっている人はそれでもいいと思います。

ちなみに今回は使用しませんでしたが、CPU8コアをフル運用するとかなりCPU温度が熱くなるので、特に夏場は使用コア数を制限するか追加でファンを取り付けることが必要になるかもしれません。CloudShellにはサイドに40mmのファンを取り付けられるようになっています。

ディスプレイ部分
  • CloudShell for XU4:39ドル
  • 電源アダプタ(5V/6A):2230円
  • 計:約6600円

Odroid-XU4にも標準で5V/4AのACアダプタがついてきますが、CloudShellを使用する場合、それだと足りないらしいので、いろいろと探してAmazonで5V/6Aのものを購入。Odroid公式でも売っていますが、PSEマークがついてないらしいので、値段はあまり変わりませんし日本で購入したほうがいいかもしれません。

1.OSイメージをダウンロード

適当なPCからOSイメージをダウンロード。Odroidの公式wikiにXU4用のUbuntuが置いてあるので、最新のUbuntu16.04をダウンロードしました。

2.OSイメージをSDカードに書き込み

ダウンロードしたOSをSDカードに書き込み。方法は検索すればいくらでもでてくるので省略。

 3.CloudShell(ケース)の組み立て、起動

公式ページを参考にケースを組み立てます。組み立てが終わったら、SDカードやLANケーブルを接続して起動します。今回は使用しませんでしたが、HDMI端子もついているので必要な人はディスプレイにつないでも良いです。

4.SSH接続

ディスプレイ無しでセットアップしたので、ローカルIPを適当に探して他のPCからSSHで接続。同じく方法は省略。

5.HDDで起動するように設定

セキュリティ設定する前にHDDのみを使用するように設定。方法は省略。

6.セキュリティ設定

24時間自宅サーバーを公開するのはいろいろと危険なので、セキュリティ設定にも気を遣う必要があります。SSHのポート変更、rootログイン禁止、パスワードでのログイン禁止、公開鍵認証の設定などが最低限。その他必要に応じて設定してください。方法は省略。

7.LCDディスプレイの設定・表示

公式wikiに設定方法が書いてあります。CPU使用率やメモリ使用率を表示できるサンプルスクリプトも用意されているので、フルノードの起動前に設定・表示しておくと便利かも。

ちなみに初期状態だとスクリーンセーバーのような感じで起動後しばらくして画面が真っ黒になるのでさらに設定を変更する必要がありました。ここが一連のセットアップの中で一番悩みましたが、/media/boot/boot.ini内の、setenv bootrootfs "console...と続く行に「consoleblank=0」を追加したら常時ディスプレイが表示状態になりました。

8.Bitcoin Coreのインストール

いよいよBitcoin Coreのインストール。普通にソースコードからビルドする方法と、PPA(非公式レポジトリ)からインストールする方法の2種類があります。PPAはインストールやバージョンアップが非常に簡単というメリットがあります。ただし、デメリットとしてUbuntu以外のOSは使えない、バージョンアップの際に更新が遅くなる可能性がある、その他やや信頼性に欠けるという点もありますが、幸いなことにUbuntuを使用していたのと、Bitcoin CoreのPPAの管理者はBluemattというコア開発者の一人ですしかなり利用者も多く信頼性はまあ十分と考えて、今回はPPAを利用しました。

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

 この三行でインストール終了。GUIウォレットの画面を利用したい方は「bitcoind」だけではなく「bitcoin-qt」もインストールしてください。

9.OSやBitcoin Core等のチューニング

フルノードのためのチューニング。まずはメモリのスワップ領域が全く設定されていなかったので、4GBほど設定(たぶんそんなにいらないです)。最初は何もやらずにノードを起動したんですが、起動後メモリ使用量が95%を超えていたために今回は後から設定しました。ちなみに同期中のスワップ領域の使用容量は200MB程度でした。その他にもいろいろあるかもしれませんが、ここらへんは全く詳しくないので何もいじってません。

それからBitcoin Coreの設定ファイル(bitcoin.conf)を設定します。なにも設定しなくても動くので、必要に応じて設定してください。Raspberry Pi等の場合、メモリがかなり厳しくbitcoindが落ちる可能性があるので、いろいろと絞ったほうが良い場合があります。以下のページが参考になります。

Reducing bitcoind memory usage · GitHub

ちなみにOdroid XU-4もCPUがかなりオーバーヒート気味になるので、par=1などで使用コア数を制限したりする必要があるかもしれません。今回は何も設定しませんでしたが、同期中に一回だけbitcoindが落ちました。CPUが原因かメモリ不足が原因かは不明ですが、メモリのスワップ領域を設定後は落ちなかったです。

10.Bitcoin Coreを起動、同期を待つ

bitcoind -daemon

で起動し、同期するのをひたすら待ちます。Odroid XU-4では2017年2月時点(約120GB)で同期完了まで丸8日かかりました。今回はテストの目的がありましたが、現在は最新のPCなどスペックによっては1日もかからず同期が終わるらしいので、別のPCで同期させてからノード本体機に移動させたほうが良いかもしれません。

ちなみに昔はbootstrap.datなどをtorrentなどでダウンロードする方法もありましたが、現在ではダウンロード速度というよりもブロック、トランザクションの検証速度がボトルネックらしいので普通にBitcoin Coreから起動するのが一番いいらしいです。

 ビットコインノード用にディスプレイ表示をカスタマイズ

サンプルの表示プログラムもCPU使用率等が表示され便利ですが、やはりビットコイン用にノード接続数とかメモリプール、未確認トランザクションのデータなどを表示したいのでプログラムを改変。プログラムはシェルスクリプトになっています。

以下に置いておきますが、スクリプトとしてコマンドを書いたことはほとんどなかったので微妙なコードになってるかもしれません。必要に応じてコードをいじってパラメータを変更しなければならない場合もあるので、少なくともコードを読める人向けです。

GitHub - bitkatana/cloudshell_lcd_bitcoin: ODROID-XU4 Cloudshell LCD Informations for Bitcoin Node

同期中の表示はこちら。

f:id:jpbitcoin:20170218195316j:plain

 

詳細はGithubのページに書きましたが、ビットコイン関連のデータだけ軽く解説。実はブロックの検証中はbitcoin-cliコマンドにほとんど反応せず数十分かかるとかタイムアウトするとか問題があるので、ブロックチェーンの同期中は停止しておいたほうがいいかもしれません。

 ノード接続数

ノード接続数をBitcoin Connectionとして表示しています。「bitcoin-cli getconnectioncount」で普通に取得できます。画面だと61とかなり多めになっていますが、Torで接続するとこんなに行かないと思います(画面はTorのIPになっていますが、同期中は普通に接続していました)。接続数が増えるほど負荷が高くなるので、bitcoindやコンピュータが落ちる場合はmaxconnectionをbitcoin.confで制限するのを推奨。

最新のブロック

「getblockcount」で最新のブロック番号を表示。それから「getblockhash ブロック番号」でブロックのハッシュ値を取得し、さらに「getblock ハッシュ値」でブロックの生成時刻を取得します。現在時刻も取得し、「現在時刻-ブロックの生成時刻」でどれぐらい前のブロックか表示しています。

ちなみにブロックチェーンが同期状態にあるかは、blockchain.info等のブロックエクスプローラー(つまり他のノード)のブロック番号と比較する方法もありますが、Bitcoin Coreでは単純に最後のブロックが90分以内だと同期状態と判断するようにGUIウォレット上では表示しているようです。

メモリプール情報

「getmempoolinfo」でメモリプール(未確認トランザクションの保存領域)に関する情報が取得できます。上の方に表示しているmempool usageが実際のメモリの占有領域、下のほうが未確認トランザクションの数とサイズです。写真上では同期中なので、メモリプールには何にも入っておらずゼロ表示です。

手数料予測

「estimatefee 6」で手数料の予測値を表示しています。estimatefeeの後ろはブロック数を表し、この場合は6ブロック(約1時間)以内に確認されるのに最適な手数料を表示するような設定です。

メモリプールから計算するので同期中では計算ができず-1が返されます。ちなみに、Bitcoin Core 0.14からはデフォルトの値が6になるらしいので、ここでも6にしています。最低値は2で、1にすると計算できないので必ず-1が返されます。

価格情報

取引所のAPIにアクセスして最新価格を取得しています。どこでもいいですが、とりあえずbitflyerとbitfinexのAPIを利用させていただきました。

 11.同期完了

f:id:jpbitcoin:20170218200742j:plain

ということで同期が完了しました。同期中の写真からちょっとスクリプトをいじって表示を変えました。同期後はメモリプールや手数料予測の情報も表示されます。

単なるフルノードだと面白くないし実用性に困りますが、メモリプールや手数料情報、価格情報も表示するとなかなか使えるのではないでしょうか。

 

 12.(オプション)Torとしてノード運用する

IPを隠したい場合や不足気味なTorノードとして運用したい場合はまずTorをインストールします。Torの公式ページにインストール方法があるのでそちらを参照すると良いでしょう。Option1は最新バージョンが入らないらしいのでOption2でインストールするのがおすすめです。

インストールしたら設定ファイルの/etc/tor/torrcを開き以下の行を追加します。

HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333

 再起動後、

cat /var/lib/tor/bitcoin-service/hostname

 でビットコインノード用のIPを確認します。

さらにbitcoin.confに以下の行を追加します。

onlynet=onion
onion=127.0.0.1:9050
listen=1
bind=127.0.0.1:8333
externalip=yourip.onion

 externalipのところはcat~で確認した自分のIPを入力してください。

ちなみにこの設定だとIPが固定になり、Torネットワーク以外の普通のノードには接続しないようになっています。

動的IPや匿名性ではなくネットワークの貢献のための運用で一般ノードにも接続したい場合は以下のページが参考になります。

bitcoin/tor.md at master · bitcoin/bitcoin · GitHub

Setting up a Tor hidden service - Bitcoin Wiki

13.(オプション)どこからでも自分のフルノードに接続してウォレットを使う

前回の記事で書いた通り、フルノードにはセキュリティ(は現実的にSPVとほとんど変わりませんが)、プライバシーが優れているというメリットがあります。今後SPVウォレットのプライバシーも改善される可能性はありますが、現状だといろいろと問題があるらしいので信用できる自分のフルノード以外と通信しないようにすれば大きなメリットとなるでしょう。

残念ながら現状はAndroid用のBitcoin Walletにしか対応していません。同ウォレットの設定メニューからIPアドレスを設定すれば完了です。

ただし、ビットコインの通信というのは実は全く暗号化されていないので、Torを使わないと通信を傍受されて簡単に内容を読み取られる恐れがありあまり意味がありません。プライバシーが気になる方は通信内容を暗号化できるTorを使いましょう。AndroidにOrbotというTorアプリをインストールすると通信できるようになります。

ただし、TorはTorでいろいろと問題があるらしいですし、第三者のソフトに頼るのはあまり良くないので、SSL通信ぐらい実装してくれと思います。ここらへんはBIP150/BIP151で信頼できるノードの認証方法や暗号化通信が提案されており、前向きに検討されているようなので時期は不明ですが今後の実装に期待というところです。

最後に

ということでビットコインのフルノードを構築してみました。ビットコインのプライバシーというとビットコインアドレスの非匿名性が話題に上がるのが普通ですが、軽量型ウォレットの通信のプライバシーも大きな課題の一つであり、フルノードをたてれば軽量型ウォレットから信頼できる自分のフルノードに接続することでその課題がある程度解消されます。

同期中はかなり負荷が高くなりますが、同期後は安定しており負荷も低いようなので、今後はスペック的にできるかどうかわかりませんがElectrumのサーバーでもたててみようかと思います。

Bitcoreという、ブロックエクスプローラーやCopayで利用できるウォレットAPIが使える(つまりCopayから自分専用のフルノードだけに接続できる)便利なライブラリもあるのですが、やる気がないのかもともとこんなものなのか、いまだに最新のBitcoin Core 0.13系には対応していないようなのでとりあえずは見送ります。Bitcoreに関しては、日本語でもかなり情報が多い印象なので気になる人は検索すると良いでしょう。

どちらにしてもBitcoin Core上でBitcoreとかElectrumサーバーとかCounterpartyとかさらにいろいろとやりたい人は、txindex=1オプション等をbitcoin.confとかに書いてトランザクションにインデックスを付けなければならないので、最初に忘れずに設定ファイルに書いておきましょう(今回忘れたので、再度長い日数をかけてreindexしなければいけなくなりそうです・・・。)。

※BitcoreやCounterpartyはトランザクションだけではなくアドレスなどにもインデックスを付けなければならず、そのために別にBitcoin Coreへパッチをあてる必要があります。

ビットコインのフルノードとは?定義と役割・メリット

今更と言えば今更な内容ですが、最近シングルボードコンピュータを使ってビットコインのフルノードを立ち上げ始めたので、そのレポート記事を書く前に一本解説記事を書いておきます。

定義と役割

定義というのは変わるもので、「フルノード」の定義についてもあれこれ追加の条件を付けくわえる人はいますが、最も一般的には「すべてのブロックとトランザクションをダウンロードし検証するノード」と言えると思います。ちなみにビットコインネットワークに接続しているコンピュータのことは総称して「ノード」と呼ばれます。

普段ウォレットで使うような、いわゆる軽量型クライアントはSPVクライアント(正確には軽量型の中にはサーバー・クライアント型と呼ばれるものもあり、さらにサーバー・クライアント型のものでもSPV型の検証を行っているソフトもあるので、細かく説明するとややこしくなります)とも呼ばれフルノードとは区別されます。こちらは、過去のすべてのブロック・トランザクションをダウンロード・検証するわけではなく、起動後すぐにウォレットとして使用できるため、ほとんどの人はフルノードのウォレットを利用することはありません。

フルノードとマイナー

よく混同されるのがフルノードとマイナーです。マイナーはブロックやトランザクションの検証も行いますが、主目的はブロックを生成して(nonceを探索)採掘報酬を得ることです。一方フルノードの役割は、ブロックやトランザクションを検証し、各ブロック・トランザクションがビットコインの基本ルールを守っていることを確認し、有効なもののみを他のノードやマイナーに伝達する役割があります。

マイナーも無効なトランザクションなどをブロックに含めてしまったり、無効なブロックを生成してしまってはせっかく採掘に成功しても報酬が無駄になってしまうので、フルノードと同じくすべてのブロックとトランザクションの検証を行うのが基本となりますが、ソフトフォークの記事で少し書いたように、SPVマイニングと呼ばれるようなすべて検証せずに採掘を行うような方法もあるので、「フルノードの一部をマイナーと呼ぶ」と単純に言うとやや語弊がある気がします。

悪意のあるマイナーによるビットコインへの攻撃はしばしば話題にあがりますが、その時に重要な防御策となるのがフルノードの存在です。単一のマイナー・マイニングプールが多くのハッシュレートを確保することによる51%攻撃では、何もないところからお金を生成したり採掘報酬を勝手に増やしたりして、ビットコインネットワークのルールを破るようなことは通常できず、攻撃の範囲が限られますが、それは善良なフルノードが存在するという前提での話です。

軽量型のウォレットノードはいちいちブロックの正当性を検証しないので、悪意のあるマイナーが生成したトランザクションを有効なものとしてほとんど無条件に受け入れてしまうことがあります。実際は多くの善意のフルノードの存在により、不正なトランザクション・ブロックはフルノードから弾かれ、軽量型のウォレットはフルノードから情報を受け取るので、悪意のあるマイナーからのトランザクションを直接受け取るようなことはなく攻撃が防がれることになります。

アーカイブノード(Archival Node)と剪定ノード(Pruning Node)

かつては、フルノードの説明として「すべてのブロックチェーン、取引履歴を保存するノード」という表現が使われることがしばしばあり、当時は間違いではなかったのですが、現在ではやや不十分な説明になってしまっています。

それは、Bitcoin Core 0.11.0へのバージョンアップにより、剪定モード(Pruning Mode)というものが実装されたためです。ブロックチェーンのサイズは現在では100GBを超えるため、フルノードの運用は大きな負担となっています。その負担を少しでも減らすため、過去の不要なトランザクション・ブロックを削除して保存しないようにしようという試みが剪定モードです。剪定モードでは、最初は全てのブロック・トランザクションをダウンロード・検証しますが、不要になったものは削除し、最終的にはすべてのUTXOと直近のブロックのみを残します。二重支払いがない有効な取引かどうかは、ブロックチェーン全てを検証するまでもなくUTXOだけを検証すればよい話なので、いらないデータは削除してしまおうというわけです。

この剪定モードを採用しているノードは剪定ノード(Pruning Node)と呼ばれますが、一度は全てのブロック・トランザクションのダウンロード・検証を行うので、一般的には「フルノード」に含められます。

対して、従来のように過去のデータを削除せずすべてのブロックチェーンを保存するノードは、アーカイブノード(Archival Node)と呼ばれます。最新の取引の有効性を確認するのは、剪定ノードだけで十分ですが、剪定ノードも最初はすべてのブロックをダウンロードする必要があります。当然他の剪定ノードはもう古いデータを削除してしまっているため、他のノードからダウンロードしなくてはなりません。そのときデータを提供するのがアーカイブノードです。剪定ノードもアーカイブノードもどちらもフルノードであり、直近の取引の検証という意味では違いがありませんが、アーカイブノードもビットコインネットワークのためには重要な存在と言えます。

フルノードを運用するメリット

ビットコインはフルノードを運用するインセンティブがない!とよく言われ、確かにそれに反対する人は少ないでしょうが、全くゼロかというとそういうわけでもないので、簡単に説明してみたいと思います。

セキュリティとプライバシー

前半で説明したように、軽量型のSPVウォレットは、ブロックチェーン全体やブロック自体、トランザクションそのものの正当性を自分では検証できず無条件に正しいものと信じるようになっています。ただし、軽量型であっても現実的には一つではなく複数のフルノードからの情報を比較・検証するので、単一のノードから送信された不正なブロックは実際上は弾かれることになります。たまたま接続したいずれのフルノードもビットコインのルールに違反する不正なブロックを有効なものとして伝達していた場合は、防ぐことができませんが、現状そこまでフルノード数は減少していないので、リスクは無視できるほど小さいものです。

フルノードを利用していれば自分ですべてのブロックチェーンを検証できるので、他のノードをそもそも信用する必要がありません。もちろん前述のように、不正なブロックチェーンを有効と認識してしまうような現実的なリスクはかなり少ないと思われるので、気分以外に普通のユーザーがフルノードウォレットをセキュリティ面で利用するメリットは、フルノードの運用コストと比較するとほぼゼロと言えるでしょう。

もう一点がプライバシー面です。軽量型のウォレットは実装によって多少の差はあるものの、基本的には特定の複数または単一のフルノードに自分のアドレス情報などを伝達しないといけないので、そのノードにIPアドレスとアドレス情報などが結び付けられてしまいプライバシーがダダ漏れになってしまう可能性があります。フルノードは自分が作成したトランザクションだけではなく他のノードから受け取ったトランザクションも同時に伝達するので、他人のトランザクションと紛れてどれが自分のトランザクションかわからなくなりますが、軽量型のSPVノードは自分が作成したトランザクションしか送信しないと考えると、プライバシーのリスクの差が分かりやすいと思います。

とはいえ通常のユーザーであれば、そもそもフルノード側もいちいちそれが誰のトランザクションなのかなんて気にしないと思いますし実質的に気持ちの問題以外のリスクはないと思います。

攻撃のターゲットになりやすい多額のBTCを保有している資産家の人や有名人なんかはプライバシー面が大きなメリットになる場合もあります。

セキュリティ・プライバシー面を考えてフルノードを運用するには?

実際にセキュリティやプライバシーの観点からウォレットにフルノードを利用したい!となった場合、いろいろな困難が付きまといます。

まず、ブロックチェーンが常に同期状態でないといけないため、コンピュータを常時起動しておく必要があります(1日放置しただけで検証に結構な時間がかかります。)。さらに問題となるのが、自分が自宅サーバーなりVPSとして運用している特定のフルノードに直接接続できるウォレットがかなり少ないということです。

フルノードをインストールしているコンピュータに直接ウォレットをインストールするのはいろいろと不便ですし、他のPCのウォレットからであったり、スマホのウォレットからであったり、外出先であっても自分のフルノードに接続できると便利でしょう。しかし、知る限り現状では特定のIPを指定してノード(Bitcoin Core)に接続、通信が可能なのは、PC用のmSIGNA、Android用のBitcoin Wallet(Schildbath wallet)のみです。

例えばCopayであったりElectrumであったりは専用のサーバーを別に立ち上げなければなりませんし、そもそも特定のサーバーに接続できないSPVウォレットも多く存在します。

ウォレット用途でフルノードの運用を考える場合は、そこらへんをよく調べておいたほうが良いかもしれません。

ネットワークへの貢献

もう一つのメリットがネットワークの貢献です。とはいえこちらも気分の問題なのでメリットといえるかどうかは怪しいところです。

現状、ビットコインのノード数はかなりの減少傾向にあるとはいえ、問題となる領域には達しておらずまだまだ安全な状況だと思います。とはいえ危険領域になってからでは遅いので今から貢献しておいてもいいかもしれません。

実際フルノードを運用するとなったときいくつかの選択肢があります。

外部からのノード接続を受け入れるか(ポート開放するか)

通常、フルノードを運用するにはポートを開ける必要はありません。ただし、ポートが空いていないと外部からのノード接続は受け入れないので、自分が一方通行的に適当なノードと接続するだけで、ネットワークへの貢献としては小さくなります(ネットワーク帯域を消費するだけの存在なのでむしろ害であると主張する人もいます。)。

ただしノードとの接続数が多くなればなるほどメモリの消費量などが多くなるので、使用するコンピュータによってはスペック上難しい場合もあります。

ちなみによくビットコインノード数として公開されているデータはポート解放されているノードの数だけであり、実際に運用されているフルノードはもっと多いと考えられます(そもそもポート解放されていないと、自分から接続しに行かない限り、第三者からはそのコンピュータがノードであると認識・接続できないので取得しようがありません。)。

アーカイブノードか剪定ノードか

前述のようにブロックチェーンをすべて保存するかしないか、を選ぶことが可能です。アーカイブノードのほうが役割は多いですが、剪定ノードでも十分フルノードとしての役割を果たせるので、コストを考えて選ぶと良いでしょう。

VPS・クラウドか自宅ノードか

ネットワークへの貢献を考えるなら自宅ノードのほうが良いでしょう。VPSのノードがいくら増えたところで、VPSはあくまでも仮想サーバーでしかなく分散されていないので、攻撃などにより同一のVPSを利用しているノードが同時に影響を受けるリスクがあります。また、例えばAmazon AWSがビットコインノード利用禁止!と掲げた場合には一斉にAWS上のノードは中止を強いられます。

実際の運用コストや安定性を考える場合にはVPSのほうがいいかもしれません。AWSなんかはノードを運用しようと思うとコストがかさんでしまいますが、海外の格安VPSを利用すればかなり安く運用することができます。

自宅ノードではインターネット回線の帯域制限があったり、コンピュータの故障リスクなども大きいので、ビットコイン関連のサービス運用に利用するにはVPSやクラウドを利用するのが安定だと思います。

終わりに

ということで、割と本気を出してアーカイブノード&自宅ノードの運用をはじめましたが、100GBを超えるブロックチェーンの同期にあと1日~2日ぐらいかかりそうなので、同期が終わった後にまた記事を書きたいと思います。

【独自トークン】初配当を実施しました。(独自トークンプラットフォームの配当機能について)

当サイト・ブログの独自トークンJPBITPTを保有している方向けに各プラットフォーム上の通貨で50%分の配当を実施しました。元々記念トークン、実験トークンという位置づけですが、1年近く経っていて保有者向けに何もお返しできていなかったので、1月のサイトからの収入が多かったこともあっての配当です。

記念トークンという位置づけは変えないつもりでこれが最後かもしれないので、今後の配当は期待しないでください。

 

せっかく、配当を行ったので簡単に「配当機能」についてまとめておきます。独自トークンの配当機能といっても各プラットフォームで違いがあり、現在ウォレットに機能として実装されているのがCounterpartyとNxtのみです。

ただし、配当機能というのは、要するにブロックチェーンから各アドレス・アカウントが保有するトークン量を読み取り、それに合わせてコインを配布する、というだけのものなので、プロトコルなどのバックエンド・根本的なシステムの問題ではなく、基本的にはウォレットやその他送金ツールなどのフロントエンドの機能です(トランザクションのタイプとして「配当」というものをプロトコル実装して、配当時だけ特別に送金手数料を安くする、といった機能は考えられますが・・・)。

そのため、プログラムが書ける人はAPIなどを利用すれば、自力で割と簡単に配当ツールを作れるのではないかと思います。今回利用したBitShares、NEM、Ethereumは、現在のところウォレットに機能が実装されていませんが、トークン保有者が少数だったので、手間を考えて手動ですべて送ってしまいました。

Ethereumなんかは、特に自由にプログラムが書けるので、毎月トークン保有者に自動的に配当を送るとか希望者が特定のアカウントにメッセージを送ることで自主的に配当をもらうことができるとか、いろんなかたちの実装が考えられます。

ということで、配当ということだけを考えた場合は、現状でもツールを作ろうと思えばどれでも作れるので、真面目なビジネス用途のトークンはどのプラットフォームを使おうと構わないのですが、非技術者のお遊び程度であれば、現状はCounterpartyとNxtの二択ということになると思います。とはいえ、実際は利用者が多いことが何よりも重要なので、特定のプラットフォームに思い入れがない限りCounterparty一択になってしまいますが。

利用者数という面を考えるとNEMもよさそうですが、作成手数料(約5500XEM)を考えると現状はちょっとハードルが高い感じがします。NEMに関してはmijinとかcatapultとかプライベート方面を先に攻めていっている印象なので、そこがある程度終わってからNEM自体の環境整備(分散型取引所の実装とか)に期待というところでしょうか。

BitSharesの近況

Ethereumはなんかよくハードフォークしてるし、NEMはApostille出してCatapultっていうのを開発中らしいし、Nxtはとりあえず2.0(Ardor)待ちだし、CounterpartyはEVM(Ethereum Virtual Machine)をtestnetに実装したりpicopaymentsなんてものもあったな・・・。

そういえばBitSharesってどうなってるの?ということで、BTSの最新情報を発信をしている人が皆無なので現状をまとめておきたいと思います。

開発者が交代

BitSharesの開発者といえば兼創業者のbytemaster(Daniel Larimer)でしたが、昨年のはじめ頃から分散型RedditことSteemの開発に専念するようになり、BitSharesの開発からは完全に手を引きました。

彼はcryptonomex社という会社を立ち上げ、そのメンバーと共にBitSharesの開発を行っていましたが、cryptonomex社自体も開発を行わなくなり、現在は過去の開発チームのごく一部の人とBitShares Munichというドイツの会社が引き続き開発を行っています。

オープンソースで分散型なので、元々の開発チームが開発を完全に止めてしまってもネットワークが止まることはありませんし引き続き他の人が開発を行えるというのは強みといえるでしょう。

実際の開発状況は?

とはいえ、引き続き開発を行っているBitShares Munich社もウォレットなど主にフロントエンドの開発を行っており、バックエンドのプロトコルの改良等はほとんど手付かずの状態です。昨年の3月を最後にハードフォークを要するようなプロトコルのアップデートは行われていません。

フロントエンド自体に関しても、モバイルウォレットをリリースしたのは良いものの、セキュリティ上のバグにより数か月間停止状態になっていたり、bytemasterが最後に置き土産としてプロトコルに実装したStealth Transactionという匿名送金の機能がいまだにGUIウォレット上で実装されず・・・、というようにやや開発力には不安がある状況です。

暗号通貨の開発チームは、○○に支配されているとか分散されていないとかいった批判を受けることが良くありますが、小さいプロジェクトは個人・企業がある種強権的に開発を推し進めないと、開発がうまくすすまないという側面はあるような気がします。

ネットワークの状況

バックエンドの開発はあまり進んでいないものの、BitShares自体がまだまだ未完成なものかと言うと、分散型取引所としての完成度は十分高いと思われ、ネットワーク自体のトラブル等も特になくかなり安定した状態が続いています。価格はどん底まで落ちていますが、新規アカウントの作成数やトランザクション数は安定しており、分散型取引所の約定数は増加傾向にあります。

f:id:jpbitcoin:20170131201226p:plain

(画像はcryptofresh.comより)

関連プロジェクト

正直、BitSharesにもまだまだ課題があり、増加傾向にあるとはいえ分散型取引所の取引量がなかなか増えないことや、大きなアピールポイントであるはずの価格連動型トークンのSmartcoinsが実質的にほとんど利用されていないことなどに対する対策の提案も過去には活発になされていました。現在その開発も議論も停滞状態にあるのは大きなマイナスであることは間違いありませんが、現状を見るとBitSharesそのものよりも他の関連プロジェクトに引っ張り上げられるかたちに期待するしかないのかなあ、という印象です。

OpenLedger

BitSharesそのものとよく混同されやすいOpenLedger(過去記事参照)。同社が掲げているような分散型取引所、というよりはただのIOU発行企業なのですが、やはりBitSharesの強みはIOUではなくSmartcoinsのほうなので、ややインパクトに欠ける感じです。

あまり最近の状況を追い切れていないのでなんともいえないのですが、同社の分散型取引所ビジネスというよりはBitTeaserのようなさらにサイドのプロジェクトに期待したいです。

個人的にはICO連発、無駄?なトークン連発であまりいい印象がありませんが、継続してサービス提供してくれているので、APIサーバー、faucetサーバーとしての役割でBitSharesのインフラの安定には大きな役割を果たしているところです。

Peerplays

ブロックチェーンベースのゲームプラットフォーム。ブロックチェーン自体は全く別に立ち上げられていますが、BitSharesと同じGrapheneというプラットフォームを元にしているため、基本的システムからウォレットGUIまでほとんど一緒です。現在はじゃんけんゲームで相手に勝つと所持金(掛け金?)を貰えるような簡単なゲームだけtestnetに実装されています。

昨年一度ICOを行っており、今年近いうちにまた二度目のクラウドファンディング(ICO?)を行う予定のようです。BitShares関連の中では期待が高いように思えますが、過去の同様の関連プロジェクトは、DAC Play(旧BitShares Play)やMUSE(Peertracks、旧BitShares Music)をはじめとして、お金を集めたのにも関わらず全てのプロジェクトがほぼ音信不通で近況不明状態なので、コミュニティ外からの評判は良くなく去年のICOもあまり成功していません。

Steem

去年立ち上がった分散型SNSで時価総額3位に上り詰めたことで話題になりました。

f:id:jpbitcoin:20170131204638p:plain

(画像はsteemb.comより)

ユーザー数等の良いデータがあまり見つからなかったのですが、去年8月から見るとアクティブユーザー数は大きく減ったものの、11月頃からは下げ止まって現在はほとんど成長なしで横ばいという状況のようです。複雑なインフレの仕組みはとりあえず置いといて解決したと仮定したとしても、少なくともなかなか暗号通貨に対するリテラシーのある人でないと使う気にはならないと思うので、暗号通貨コミュニティ内で十分知られるようになった後の成長は、暗号通貨自体の一般層への普及がすすまないと厳しそうな感じです。

開発に関しては独自路線を進んでいるため(Graphene外の部分での機能拡張、新たにGraphene 2.0の開発を発表、Graphene 2.0はBitSharesに適用するメリットがどこまであるか不明等・・・)、Peerplaysほどは密接に結びついていませんが、SteemはBitSharesと同じくGrapheneを元にはしているので、Steemが成功すればBitSharesにもいい影響を与えられる可能性があります。

ビットコインの取引手数料の仕様を詳しくまとめてみる

ネットワークの混雑でビットコインの取引手数料について改めて考えることが多いので、仕様についてまとめることにしました。手数料周りの仕様は意外と頻繁に変わっており、改めて調べるまで個人的に勘違いというか知識が古いものもありました。この記事の情報も後から見返すと古い可能性がありますのでご注意ください。

取引手数料の基本

まずは基本的事項について再確認。ビットコインの取引手数料は、取引の承認者であるマイナー(採掘者)に支払われ、高ければ高いほど早く確認(承認)される傾向にあります。マイナーからみると報酬を多くもらえる取引を優先して処理したほうが儲かるので当然の傾向です。また、手数料の大小はBTCの送信額に対する割合ではなくトランザクション(取引データ)のサイズあたりの割合(BTC/バイト)により判断されます。これも、データとして見た時にビットコインの送信額は関係ないので(10BTCであろうが1BTCであろうがデータの大きさが変わらなければ取引データの通信コストは変わりません)、当然の傾向です。

トランザクションのサイズの決定方法

取引手数料を決めるにはまずデータのサイズを求める必要があります。トランザクションには署名データが含まれ、署名は作成するまでサイズが分からないので、正確なサイズを算出することはできませんが、以下の式でおおよそのサイズを求めることができます。単位はバイト(byte)です。
148*input数+34*output数+10

このようにinputの数とoutputの数に依存します。inputとoutputについてはUTXOの概念を知っていれば分かるかと思います(以前の記事参照)。outputは単純に送金先のアドレス数と等しいです。inputの場合はUTXOの数になるので、送金元が一つのアドレスだけであってもUTXOが何個もある場合があります。

最もよくあるinputが一つでoutputが二つ(送金相手のアドレスだけではなく自分のお釣り用アドレスにも送金する場合がほとんど)のトランザクションのサイズは、
148*1+34*2+10=226バイト
となります。特に例は貼りませんが、実際にinputが1つでoutputが2つのトランザクションのサイズをブロックエクスプローラーで見ると、ほぼすべてが226バイトから1~2バイト程度のサイズに収まっていることがわかります。

ちなみにトランザクションサイズの算出方法を調べると
180*input+34*output+10
という式がよく見られますが、これはinputの中に含まれている公開鍵の形式が非圧縮型(uncompressed key)であるためです。間違いというわけではありませんが、現在はほぼすべてのウォレットが非圧縮型より32バイト小さい圧縮型の鍵(compressed key)を利用しているので、inputのサイズは基本的に148程度と考えるのが良いと思います。

これらの算出式は通常のビットコインアドレスからの送金なので、マルチシグネチャアドレスやCounterpartyを利用する場合は通常よりもサイズがやや大きくなります。CounterpartyはOP_RETURNという上限40バイトのデータが付加されるだけなのでそこまで大きくはなりませんが、2of3のよくあるマルチシグの場合は倍近くになります(ただしCounterpartyではトークンの送付時に非常に少額のBTCを送らなければならないので、頻繁にトークン受信を行っているような場合はUTXO・小銭の数が増えinputの数も増えて合計サイズが大きくなる傾向にあります。)。
採用されない可能性も十分ありそうなので省略しますが、Segwitが実装されるともちろん上記の計算式は変わってきます。

最適な取引手数料の予測

取引手数料は、未確認のトランザクションの総サイズ(メモリプールの総サイズ)などに影響を受けてマイナーが決めるものなので単純な計算によって正確に求めることは難しいです。幸いなことに以下のような計算サイトがあるので、参考にすると良いでしょう。複雑なので具体的な算出方法はよく理解できていませんが、最近のハッシュレート、トランザクションサイズ、手数料の大きさなどによって算出しているようです。
https://bitcoinfees.21.co/
https://bitcoinfees.github.io/
上のサイトが有名で、グラフの緑部分以上の手数料を払うと遅延なし(10分で確認)で済みます。この記事を書いている時点では、90satoshi/byte=0.0000009BTC/byteがベストのようです。先ほど計算したように1input2outputの典型的なトランザクションの場合は、226*0.0000009=0.0002034BTC支払えば良いということになります。

あくまでも226バイトはほぼ最小のサイズであり、実際はinputの数が多かったりします。現在の平均のトランザクションサイズ約500バイトで計算すると500*0.0000009=0.00045BTCとなります。
f:id:jpbitcoin:20170118221003p:plain
https://tradeblock.com/bitcoin/historical/1d-f-tsize_per_avg-01101

基本的にこれらの作業は全部ウォレット側がやってくれますし(一部手数料予測の性能の悪いウォレットもあるようですが)、そもそもUTXOが見れなかったりトランザクションのサイズ表示ができないウォレットが多いので、普通のユーザーはあまり気にする必要はなく自力で計算したくてもできないことが多いのですが、なかなか確認されない取引があったら、ブロックエクスプローラーでその取引のサイズと手数料を確認して先の手数料予測サイトの最適手数料と照らし合わせると確認が遅い理由が納得できるかもしれません。

取引確認の優先度

現在、ビットコインの取引の確認の優先度は単純に手数料によって決定されています。以前は、priorityというパラメータも考慮されており、priorityの中には以下のようにcoin ageというコイン・UTXOの古さ(最後に使用されたときからの未使用期間の長さ)やコイン量があるので、古いコインほど残高が多いほど早く確認されやすいという面もありましたが、このpriorityは現在では実質的にほとんど使われていません。
priority=(coin\ amount*coin\ age)/transaction\ size

ちなみに、Bitcoin Core(Qt)0.6までは取引確認の優先度は完全にこのpriorityに依存しており、送信額が多ければ逆に手数料を支払わなくて良いという一見不思議な仕組み(送信額が少ないほど要求手数料が少なくなるとネットワークへのスパム攻撃が容易になるので理にはかなっています)でした。

バージョン0.7からは現在の手数料が大きければ大きいほど優先して取引される仕様が導入され、一定額以下の手数料(現在のBitcoin Coreの規定の設定は0.00001BTC/byte)の取引のみを対象としてpriorityが考慮されるようになりました。priorityが一定以上になれば手数料無料でも送信できるという仕様です。

ネットワーク全体のトランザクション数の増加により、バージョン0.12からはBitcoin Coreでのマイニングの際の既定の設定として全くpriorityが考慮されないようになってしまい、単純に手数料のみから優先度が決定されるようになりました。同時に手数料が0.00001BTC/byte以下の取引が承認される見込みはほとんどゼロとなりました。
他にデータソースが見つからなかったのでtwitterからの引用になってしまいますが、以前は可能とされていた手数料無料の取引は2016年には実際にほとんど絶滅した状態になっているようです。

現在もトランザクションのリレー(ノードからノードへの伝達)においてはpriorityが使用され、priorityが十分高ければ手数料がなくてもリレーされる設定が規定となっていますが、Coreの開発チームではpriorityの完全廃止が議論されており、現在のところ0.14ではpriorityに基づくリレーの仕様も規定でなくなり、0.15ではpriorityの概念が完全になくなる予定となっています。

ちなみにこのpriorityというのは、基本的にはビットコインのユーザー数やトランザクション数を増加させるための一つの戦略であり、手数料無料でも送信できることでビットコインの利用数を増やそうという目的のもとに利用されていたものでした。現在はトランザクションが多すぎるほどになっており、手数料無料の取引をわざわざブロックに入れてくれるマイナーがいなくなったために廃止の方向になったということです。

最終的にはマイナーが自由にどの取引を確認するか決められる

今までpriorityなど取引確認の優先度の「仕様」を説明してきましたが、これらはすべて未確認状態の取引の話なので、実際にはマイナーが恣意的にどの取引を確認するかを決められます。Bitcoin Coreではデフォルトの数値が設定されているだけなので、数値を変えるだけですぐに最低の取引手数料を0.00001BTC/byteから引き上げることもできますし、今は使わない設定になっているpriorityを復活させて手数料無料の取引を受け入れることもできます。
Bitcoin Coreでは、priority以外にも「fee delta」という、取引の優先度をマイナーが自由に変えられる架空の取引手数料の概念も実装されています。特定の取引IDを対象にしてfee deltaの数値に大きな架空の手数料を入力すれば、あたかも高手数料の取引として実際の手数料に関係なく最優先で確認することが可能というわけです。そのため、マイナーが自分や友人が送信する取引は手数料無料でも優先して承認・確認するというのは普通に行われ得ることだと考えられます。
究極的に言えば、マイナーが特定のアドレスをブラックリスト化したりホワイトリスト化したりして、取引を制限することも可能です。ただし1%でもすべての取引を受け入れるマイナーがいれば100ブロックに1回は対象の取引が確認されることになるので、単一のマイナーが100%支配するという現実離れした事態が起こらない限り、完全にコントロールすることはできません。