Linux に勝てなかった Plan9
つぶやき。ぽえむ。 暗号資産界隈は、技術に関しての詳しさについて両極端なので。 Plan9 という OS について、知っている人は Inferno 含めて知っているでしょうし、そうでない人は初耳だとしても不思議ではないでしょう。 一方、Linux は、詳しくなくてもなんとなく耳にしたことはあるかなと想像します。Android で使われていたり、Spotlight でしばしば記事になる Umbrel OS でも使われています。おそらく世界で最も商業的に … Windows や macos と比べても … 成功した OS の一つです。 Plan9 は、誰もが先進性を認める OS でした。Linux の元となった Unix を開発した優秀な技術者らが、ドリームチームを組んで設計した成果です。その時点での叡智が結集されていました。 しかし Plan9 は生き残れませんでした。 細かい事情は別の記事に譲り、暗号資産界隈が得られる教訓だけ、ここでは取り上げます。 https://atmarkit.itmedia.co.jp/news/analysis/200902/09/future.html 「技術を軸にするなら、よほど革新的でないと、生き残るためのポジションは取れない」 Plan9 の革新的であった部分のうち、いくつかは、競合である Linux や macos に取り込まれ今も生きています。これはつまり、Plan9 は革新的であったが、競合が対応できる程度の革新さしかなかったということでもあります。 Ⓜ️ さて、パブリック・ブロックチェーンは、OS と類似点があります。 ソフトウェアである。 アプリケーションのための基盤技術である。 改良案が出続けている途上技術である。 レイヤーを積み重ねることで基盤層を機能・性能的に補える。 OS で起きたことをパブリック・ブロックチェーンに当てはめると、簡単な未来予想ができます。当たるも八卦。 「"改良版イーサリアム" らは生き残れない」 特にトランザクション性能や開発言語の軸でイーサリアムと差別化しようとしたチェーンらの、この先は暗いでしょう。もし革新的であったなら、イーサリアムが採り込むはずですから。 「"改良版ビットコイン" らは生き残れない」 こちらも同様です。アルトの存在理由であったトランザクションのサイズや承認間隔の問題が、L1 改良である Segwit や L2
Monacoin-core 0.20, when?
base-0.18 構築作業で、コードベースを Bitcoin 化する手順は概ね確立できているのだが。 いつやるかねぇ…。pump の材料にするなら、このタイミングだろうけど。 なんだかそういうモチベーションで動くのも、ダルいし、ねぇ。 モナパーティ冬祭りで予告した機能も、とっとと実装せにゃならんしなぁ…。
OP_CAT😺とCovenants📜の備忘録
先月末に物議を醸しだしたOP_CTVを調べていくなかで、他のOPコードや暗号トリックを使ってCovenantsを実現する方法が面白かったので、以下の記事をベースに纏めてみました（以下の記事を理解した前提で記事を書いてます）。 https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html 前提 Covenantsの仕組みを理解するためには、ビットコインのトランザクションのデータ構造とスクリプトシステムを理解する必要があります。 1. トランザクションのデータ構造 トランザクションのデータ構造は以下のようになっています。inputsフィールドはさらにprev txidやscriptSigに、outpusフィールドはvalueやscriptPubkeyに細分化されています。 2. スクリプトシステム スクリプトシステムは、OPコード（命令語・機械語）を１つ１つ実行し、データをスタック領域へプッシュしたりする実行環境のことです。以下の図例は標準的なビットコインのスクリプトを実行しているもので、scriptPubkeyとscriptSigを結合し、OPコードを実行、データをスタックへプッシュしていく流れを表しています。 ビットコインを送金する場合、上記のデータ構造に沿ってデータを組み立て、それに対して署名をしscriptSigに署名をセットします。このデータをブロードキャストし、受け取ったノードが、この署名を検証する時、prev txidとprev txout-indexを参照して消費しようとしている前のトランザクションのscriptPubkeyを取得します。イメージとしては以下の図のようになります（参照元）。そして上記のスクリプトシステムに従
