Sent a payment
RGB-Channel in Lightning
ライトニングネットワークはビットコインをオフチェーン上で送金する仕組みである。そのネットワークを構成するペイメントチャネルは2者間のビットコイン残高の状態を管理している。このチャネルの状態にビットコイン残高以外の特性を持たせようとする取り組みがいくつかある。 RGB-Channel in Lightning ビットコイン以外のトークン残高を管理できるようにするチャネル Lightning Network compatibility - RGB Docs DLC-Channel in Lightning 残高はビットコインのままだが、残高状態を更新するために必要な二者間の署名以外にオラクルの署名も有効とするチャネル DLC on Lightning. TLDR; | by Thibaut Le Guilly | Crypto Garage | Medium 今回はRGBチャネルに焦点を当ててその実用性を考察してみる。 RGBチャネルのプロコン RGBチャネルの場合、チャネル開設者がアセットを持ってさえいればよい。これはRGBチャネルのメリットである。なぜなら、RGBのオンチェーン送金では受け取り側もUTXOを事前に用意する必要があるから。RGBチャネルを開設さえすれば、受け取り側はLN上で0承認かつ低手数料で何度も送受信が可能で、アセットをオンチェーンへ引き出す際はチャネルを閉じるだけでよい。 現状のRGBチャネルは1チャネル1アセットなので、複数アセットを扱う場合、それぞれのチャネルを開設する必要がある。そのため、受け取りたいアセットのチャネルがない場合は受け取ることができない。RGBチャネルが普及する場合、特定のアセット、例えばUSDTなどのチャネルに限定的になる可能性が高い。 チャネル間を通してアセットを送金する方法は、分散ネットワーク型、ハブ&スポーク型、ゲートウェイ型の3通りある。RGBチャネルが普及する場合、特定のアセットに限定的になる可能性が高いので、その場合は分散ネットワーク型になる可能性もあるが、取引所やLSPなどがゲートウェイとしてRGBチャネルを運用する未来像の方がイメージしやすい。

SphinxプロトコルにHMACを追加する理由はリプレイ攻撃対策
ライトニングネットワーク上の送金はプライバシー向上のためにオニオンルーティングが使われている。そのプロトコルとしてSphinxプロトコルをベースとしているが、そこにHMACがなぜ追加されているのか、以下のLNメーリスに回答があったので、その備忘録。 [Lightning-dev] Reason for having HMACs in Sphinx (linuxfoundation.org) オニオンルーティングのペイロードのラップ、アウンラップについては以下のサイトが参考になるので、それをもとに以下、詳細を割愛しながら説明する。 lnbook/10_onion_routing.asciidoc at develop · lnbook/lnbook (github.com) オニオンペイロードのラップ・アンラップ オニオンペイロードは送信者によって構成される。このペイロードは1300バイトの固定長である。例えば、A→B→C→Dという経路で送信する場合、AはまずDへの情報をセットし、残りのスペースを1300バイトになるまでフィラーで埋め、Dとの共有鍵から生成したrho鍵でXORしてペイロードを暗号化(難読化)する(1)。次にCへの情報をセットし、暗号化したデータ(1)を追加する。この時、1300バイトを超過したデータは切り捨て、Cとの共有鍵から生成したrho鍵で全体を暗号化する(2)。次にBへの情報をセットし、暗号化したデータ(2)を追加する。この時も1300バイトを超過したデータは切り捨てて全体を暗号化する(3)。こうして入れ子になったデータをオニオンペイロードと呼ぶ。 Aはこのオニオンペイロードの先頭にBとのセッションキー(※1)をセットしてBへ送信する。Bはオニオンペイロードに1300バイトのゼロ埋めされたフィラーを追加して、共有鍵を使い2600バイトのペイロードを復号して(先頭1300バイトが復号され、残りの1300バイトは難読化される)、自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Bはこのオニオンペイロードの先頭にCのためのセッションキーをセットしてCへ送信する。Cも同様にペイメントの先頭に1300バイトのフィラーを追加してから共有鍵を使いペイロードを復号して自身のペイロードを切り取る。残ったペイロードを左へシフトして、1300バイトを超過するデータを切り捨てる。Cはこのオニオンペイロードの先頭にDのためのセッションキーをセットしてDへ送信する。Dも同様な処理を行い、自身のペイロードからこの送金

LDP Seminar Week 1の備忘録
Chaincode labsが開催しているLDPというオンラインセミナーに参加しているので、そのWeek 1の復習を兼ねての備忘録。 Week 1はライトニングの基本的なプロトコルに関する内容で、事前に参加者には宿題が与えられるので当日までに解いておく。そして、当日その問題をグループ内でディスカッションする形式となっている。その中から一部抜粋してその問題を以下に記載する。 ・・・ 問題1 Why do we need the HTLC-Success and HTLC-Timeout transactions? Why can't we just use a sequence delay on the to_local output conditions of the HTLC itself? 回答 アリスからボブへの送金において考える。まずはアリスのコミットメントであるOffered HTLCについて。このHTLCのアウトプットの使用条件は以下の3つ ボブがプリイメジを使う CLTVによる絶対時間の経過後にアリスが自身の署名を使う ボブがrevocation keyを使う(アリスが古いコミットメントを送信した場合) ただし、CLTV経過後、アリス自身が使用する場合にはto_self_delayの相対時間も経過する必要がある(※1)。言い換えると、HTLCの有効期限が切れたのに

Eltoo: SIGHASH_ANYPREVOUTによるバインディング技術
Eltooはペイメントチャネルの残高更新の仕組みを簡素化する仕組みです。現状のライトニングネットワークに使われているペイメントチャネルはペナルティ型で、一方が不正をすると他方が全額没収することができる仕組みになっています。ペナルティ型のペイメントチャネルは、残高が更新される度にその更新に使われた鍵情報(revocation key)を保存する必要があり、データ容量を圧迫してしまいす。Eltooでは最新の残高に関するデータのみ保存するだけでよくなります。 Eltooの実現にはBIP118のSIGHASH_ANYPREVOUTと呼ばれる新しいSIGHASHタイプが必須で、ソフトフォークが必要です。Eltooの俯瞰図は以下が詳しいです(eltoo with Anyprevout and Taprootより抜粋)。またこちらの記事も日本語で詳しく解説されています。 Eltooでは、チャネルのライフサイクルを3つに分けて考えます。 セットアップ:funding_txとupdate_txを作る ネゴシエーション:update_txとsettelment_txを作る セトルメント:協調的な場合はclose_txを作り、非協調的な場合はupdate_txとsettlement_txをブロードキャストする ネゴシエーションは送金をする度に実行されます。ここで重要なのはupdatetxが消費できるtxは複数あることです。上図のUpdate:3を見ると、そのtxが消費できるtxはFunding:0、Update:1,Update:2の3つあることが分かります。現状ではtxに署名をする場合、そのtxが消費するtxをインプットとして指定する必要があります。しかしSIGHASHANYPREVOUTではインプットを指定することなく署名できるようになるので、どのtxに対しても有効な署名済みtxになります。そのため、もし相手がSettle:1の残高でセトルメントを実行しようと思いUpdate:1を

ペイメントチャネルのサイズ変更をするスプライシング(Splicing)
Splicingはペイメントチャネルのサイズを変更するための仕組みです。サイズを小さくする場合はSplicing-out、大きくする場合はSplicing-inと呼んだりします。現状のLNでチャネルのサイズを変更するには、一度チャネルを閉じて開き直す必要があり、これには2つのトランザクションが必要になります。Splicingを使うことでこのトランザクションを1つに纏めることができます。さらに、というよりこれが要点ですが、Splicingでチャネルサイズを変更している間(この新しいチャネルが未承認の場合)でも、既存のチャネルでルーティングを継続することができます。 既存のチャネル(これは閉鎖中のチャネルとも呼べる)と開設中のチャネルが共存するなか、どうやってルーティングをしているかというと、既存のチャネルのコミットメントにHTLCが追加・削除される場合、開設中のチャネルにも同じ金額のHTLCを追加・削除します。このHTLCは両コミットメントに共存していますが(コミットメントはオフライン上のデータであることに注意)、HTLCがオンチェーンに展開される場合、最終的にブロックチェーンに刻まれるのはどちらか一方なので、チャネル間の残高の整合性は担保されます。 Splicingの仕様は以下リンクに詳しいです。 Splice draft (feature 62/63) by rustyrussell · Pull Request #863 · lightning/bolts (github.com) Alternative splicing specification proposal with detailed examples (github.com) また、Splicingではinteractive-txと呼ばれる新しい仕様も必要になり、その仕様は以下のリンクに詳しいです。 interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) by niftynei · Pull Request #851 · lightning/bolts (github.com) interactive-txは、チャネル開設時にOpenerだけでなくAccepterにもfundingtxのためのインプットを追加できるようにするもので、より柔軟にfundingtxを構成

NP困難とライトニングネットワークの手数料関数が及ぼす計算量
以下のスレッドを読んでの備忘録。 https://bitcointalk.org/index.php?topic=5437244.0 ライトニングネットワーク(LN)での経路選択は、巡回セールスマン問題としても知られている。巡回セールスマン問題で、すべての都市を通る経路の計算をする場合、計算量はΘ(N!)なので指数関数時間となる。 そこで、LNではダイクストラ法※などの動的計画法を用いて比較的効率的に最適な経路を選択するような実装がされている。しかし、最適な経路選択するうえでも以下のような問題が指摘されている。(※計算量はΘ(E + V*log(V)) 、Eはチャネル数、Vはノード数) LNでは手数料の合計値が最小であるような経路選択が望ましい。手数料関数をf(x) = rx + b、rは手数料率(fee rate)、bは基本手数料(base fee)とする。この関数は、b = 0でない限り、線形代数的には線形ではない。線形性を有するには、 f(x+y)=a(x+y)+b=ax+ay+b=(ax+b)+(ay+b)=f(x)+f(y) を満たす必要があるが、手数料関数においてはb = 0 の場合のみである。線形性を持つ問題は数学的に解きやすいが、手数料関数にはこの性質がないため(基本手数料であるbをなくせばよい)、経路選択という最適化問題を解くことが難しくなる。 スレッド内で質問されていた手数料関数がどのくらい計算量に影響を与えるかの具体的な数値の回答はなかった。もしかしたらこちらの論文に記載されているのかもしれないがしっかりと読めていない。 余談上記の手数料関数で、f(0) = 0 だが δ→ 0 なので f(δ) → bであり、これは x = 0 において連続で、そこで 0 から b へとジャンプする不連続性を持つ。これは凸性を失うので(凸性も最適化問題を解くのに重要な性質)、手数料関数の最適解を解くのが難しいと言われる。この 0 から b へジャンプするというのもイマイチ理解できていない…

学校教育と右脳閉塞症候群
日本の教育、文科省、政府はおかしい。なぜ小中学生にデジタル教科書なるものを推進するのか。 以下の引用は、作家の安部公房氏の評論集の一部抜粋です。氏の時代からデジタル化(ここでいうデジタルは言語や理論、理性などの意味合いですが、それを突き詰めていったものがコンピュータ、所謂デジタル化だと思う)について如何に人を豊かさから遠ざけるかについての警笛を鳴らしています。 日本語の特殊性は母音だけで意味が形成できるためにデジタル脳(左脳)を刺激されやすくその分アナログ脳(右脳)の閉塞を起こしやすいという。右脳閉塞というのはアナログ的思考が停止した状態なのだがさして深刻な障害でもない。 しかるにわが国では右脳が閉塞した感性の障害者がまかり通っている。デジタル作家にデジタル評論家だ。もっと悪いのは感性がはたらく右脳の欠陥を補うためにデジタル脳たる左脳を使って情緒過多症に陥ってしまった連中である。 もともと言語脳である左脳を使って情緒を表現することほど豊かな感性にとって不幸なことはないのである。 安部公房「右脳閉塞症候群」より

lnprototestの備忘録
以下のlnprototestにてテストを走らせたところエラーが起きたのでその備忘録 https://github.com/rustyrussell/lnprototest 実行環境 ubuntu 20.04 lnprototest: master core-lightning: master bitcoin core: v25.0 テスト実行すると以下のエラーとなる。rpc周りのエラーっぽかったので、bitcoin.confなどの設定をしてみたが解決には至らず。 lnprototest/runner.py:100: in run alldone = sequence.action(self) lnprototest/structure.py:55: in action alldone &= e.action(runner) lnprototest/event.py:409: in action runner.addblocks( lnprototest/clightning/clightning.py:231: in addblocks self.bitcoind.rpc.generatetoaddress(n, self.bitcoind.rpc.getnewaddress()) lnprototest/backend/bitcoind.py:42: in f res = self.proxy.call(name, *args) ../.cache/pypoetry/virtualenvs/lnprototest-PV4H-O3-py3.10/lib/python3.10/site-packages/bitcoin/rpc.py:246: in call response = self.getresponse() ../.cache/pypoetry/virtualenvs/lnprototest-PV4H-O3-py3.10/lib/python3.10/site-packages/bitcoin/rpc.py:276: in getresponse http_response = self.conn.getresponse() /usr/lib/python3.10/http/client.py:1375: in getresponse response.begin() /usr/lib/python3.10/http/client.py:318: in begin version, status,

option_simple_close
チャネルの協調閉鎖をする際、現状では協調的チャネル閉鎖TXのための手数料を二者間で交渉して決定し、またこの手数料はチャネル開設者が支払うことになっています。option_simple_closeによる提案は、この交渉フェーズをなくすことで二者間のやり取りを簡素化するものです。本提案による協調チャネル閉鎖の変更内容は以下になります。 手数料の交渉フェーズがなくなる チャネル閉鎖を要求した側が手数料を支払う RBFをサポート 現状は、以下の図のように手数料の交渉フェーズ(3)(4)...(?)(?)があり、このやりとりが実装間の手数料決定アルゴリズムの差異などからバグの温床となっています。 本提案の協調的チャネル閉鎖時のメッセージは以下の図の流れになります。shutdownメッセージを送った側(クロージャー, closer)は閉鎖時の手数料を相手に送信します(3)。メッセージを受け取った側(クロージイ, closee)はその手数料に同意するなら署名を添えて返信します。もし同意できなければ、エラーを返して通信を閉じます。同意されなかった場合、クロージャーはチャネル閉鎖時メッセージを最初から始めます。 本提案ではAがチャネル閉鎖の要求および手数料を提示し、それに同意した場合のみBが署名を添えて返信する。同意しなければ、再度同じプロセスを繰り返すだけなので、協調閉鎖時のプロセスが簡素化されました。具体的な提案に関しては以下を参照してください。 https://github.com/lightning/bolts/pull/1096

ゼロ知識証明によるビットコインの条件付き支払い
ゼロ知識証明は昨今のブロックチェーンのバズワードとなっており、興味を持つ方も多いと思います。イーサリアムではZK-SNARKなどゼロ知識証明を使ったアプリケーションの開発が進んでいます。ビットコインでもゼロ知識証明を活用したアプリケーションの提案も少しずつ出てきています(OP_ZKPやValidity rollups)。イーサリアムにはゼロ知識証明の検証をするためのプレコンパイルされたコントラクトが導入されています(EIP196, EIP197)が、ビットコインにはこのようなOPコードは存在しないので、ソフトフォークによる導入が必要になってきます。しかし、ビットコインでもゼロ知識証明をブロックチェーン外で行うことで、任意のプログラムを実行させて、その結果に対して支払をすることができます。今回紹介するのはゼロ知識証明による条件付き支払い(Zero-Knowledge Contingent Payment, ZKCP)で、これはGMaxwellによって2011年に提案され2016年に実際にビットコイン上で証明されました。なんと10年以上前からビットコイン上でのゼロ知識証明の活用が提案されていたのです。このZKCPの引用元は以下になります。https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment 以下の図は数読パズルの正解をBuyerがSellerから購入するというシナリオになっています。本例ではトラストセットアップのZKSNARKを使っていますが、Buyerがゼロ知識証明の検証をするため、自身でそのセットアップをすることに問題はありません。 Buyerは数読パズルの正解が正しいかを判定する数読チェッカーを作成し、トラストセットアップをします。 Sellerは数読パズルの正解Xを見つけ、ランダムな値Kを選び、KでXを暗号化してExを得ます。そして下図のProgram(K, Ex, H())をプルーフへ変換してBuyerへ送付します。 Buyerはプルーフを検証して問題なければ、下図のP2SHアドレスへ支払いをします。このアドレスは、Sellerが数読パズルの正解Xを公開することでSellerは支払いを回収できると同時にBuyerは正解Xを復号するためのKを得ることができる、ようなアトミックスワップに使われるスクリプトと同類のものです。 SellerはKを公開することで支払を回収し、BuyerはKからXを復号し数読パズルの正解を得ることができます。 <img src="https://s3-ap-northeast-1.amazonaws.com/spotlight-s3-001/article/20230710045144mceu_68066159621688

LNノードの年間売上
Torqで年間のルーティング手数料収益が簡単に見れるので、ちょっと覗いてみました。また、DHノードよりも稼いでいるノードの1つについても簡単に紹介しています。

Arkの txlock について
以前の記事でビットコインの新しいL2技術であるArkの概要について紹介しました。ArkはvTXOと呼ばれるアウトプットを各ユーザーがL2としてのコインとして所有しており、そのvTXOを纏めたコミットメントをアウトプットにしてArkサービスプロバイダーがトランザクションを生成して送信します。Ark上でのユーザー間の送金は、送信者のvTXOを失効させて受信者に新しいvTXOを割り当てることで行われます。このvTXOの失効と割り当てはアトミックに行われます。この送金をアトミックに行うために使われるのがtxlockと呼ばれるテクニックです。 txlockについては、RubenSomsenによるArkの解説が分かりやすいです。以下の図はその引用です。 上段の「S if UTXO2 exists(UTXO2が存在する場合)」という条件は現在のビットコインスクリプトでは不可能ですが、ソフトフォークなしでこれを実現することができます。UTXO2を含むトランザクションには、S(Arkサービスプロバイダーを指す)によってのみ使用可能な別の小さなアンカーアウトプットを含めます。このアンカーアウトプットをFORFEITTXのインプットとして構成して署名をします。そうすることで、UTXO2とアンカーアウトプットを含むトランザクションが先にオンチェーンに送信されない限り、FORFEITTXはオンチェーンに送信されないので、「UTXO2が存在する場合」という条件が満たされます。よって、AがBへ送金する場合、FORFEITTXの署名によりAのvTXOが失効されて、UTXO2をインプットとしたREDEEMTX(これをArkではvTXOと呼んでいる)がBへのvTXOの割り当てとなります。そしてこれはUTXO2がオンチェーンに送信されることで失効と割り当てがアトミックに行われるのです。この「UTXO2が存在する場合」という条件がtxlockの正体です。またArkの公式サイトでは、アンカーアウトプットのことをコネクターアウトプット、「UTXO_2が存在する場合」というスクリプトをATLC(anchor timelock contract)と呼

DAOには二度と参加しないと決めた理由
まあ端的に言えば情弱向けDAOに引っかかって騙されました DAOは無理だと思う自分のようなド素人が「勉学のためにDAOに入りたい!」と思うじゃないですか、まずググるじゃないですか、上の方の記事見るじゃないですか、「MakerDAO?」「PleasrDAO?」「英語とか無理だし」じゃないですか、 でYoutubeだのTwitterだのVoicyだので見つけた初心者にもやさしそうなDAOが見つかるわけですよこれなら自分でもできるんじゃない?とか思っちゃうわけですよ 自分の場合はお金は損してないけど時間を損しました数日間だけど時間と労力をすごく無駄にした 今思うと完全に商材屋系列のDAOでしたねとあるタスクがあって、タスクをボランティアで頑張る感じ報酬は無し 自分が興味ある分野で、すごく上を目指すとか言ってたからホイホイされてしまいました参加してみたらレベルが低くて「いや・・・なんかおかしくない?」てなりました あと印象に残ってるのはメインメンバーの立ち振る舞い新しく参加した人にどうこうするよりも、「フォロワーをそれなりに抱えている中小インフルエンサー」を呼び込むかに注力してた大物インフル来ちゃうと逆に食われるから、支配下に置けそうで恩を売れそうな中小インフルを狙うんだろうなぁマルチうける まあ情弱時代に騙された恨みが大きいんだけどそれでも自分はもうDAOとかそーいうコミュニティは参加しないですね時間を搾取される場所だと思ってる あと自分が単純に人と関わるのが苦手だから1対1なら喋れるけど3人になったら喋れなくなるし大勢になったらもっと無理よみがえる押し込まれ時代の悲しい記憶 長くなったけど結論としては一般人がDAOを探そうとすると、とんでもないDAOに誘導されちゃうんですよという話Voicyとか本当にもうひどい 「いや何でVoicyとか行くねん」って思うでしょ私の場合はライティングの勉強→ブログとかYoutubeで勉強→いろんな人が二大巨頭()をおすすめしてる→二大巨頭がVoicyやってる経由今からライティング始める人は忍者の民コースだと思う多分他にも商材屋御用達のプラットフォームが山ほどあるんだろうなぁ てゆか今シンプルにググったんですけど<br

GPUtopiaで余剰GPUリソースをSatsに
LightningNetwork周りのサービスを探していたら面白いものを見つけたので共有です。 ETHがPoS移行してからというもの、GPUリソースを余らせているマイニング勢もいるかと思われます。 その余ったGPUリソースを売るという興味深いサービスを発見。 ブラウザ経由でWebGPUを使用し、GPUリソースを貸し出すことができます。 こんな感じ。 しばらく稼働させてみると、GTX1070で1000Sats/hに届くか届かないかくらいの収益かな。もしかするとマイニングより稼げるかもしれない! と、喜んでいたところ…… <iframe style="position: static; visibility: visible; width: 530px; height: 671px; display: block; flex-grow: 1;" id="twitter-widget-1" scrolli

同僚からビットコインの相談が来たのだが
二人とも平均的なサラリーの非金融系会社員である。 1件目 基本情報:30代男性 妻と子供1人 一軒家住まい ローンあり 残業終わりの雑談中、私が投資歴長く、FP持ってる関係で、家計と資産運用の相談に。 彼『株式投資やってるんですが、今度はビットコイン買おうか悩んでて。どう思います?』 私『いいんじゃない。価格の上下が激しいから、余裕資金がいいよ。実は俺も少し買ってる(全家計資産の95%前後がビットコインだけど、激ヤバ認定必至と察知)』 とりあえず、その頃使ってたビットフライヤークレカ見せて、悩んでるならポイントサービスで入手も出来ると伝え、プチオレンジピル終了。 2件目 基本情報:30代女性 夫と子供3人 親名義マンション住まい 夫が5年ほど前から資産運用中 昼休みの会話。 彼女『夫が転職するので、退職金が入るんですけど、インド株とビットコイン買うって言うんですよ。私はよくわからないんですけどね。』 私『お!旦那さんかなり詳しいね。インド株は最近調子いいもん。ビットコイン選ぶのもセンスある。余裕資金で運用するならいいと思う…』の辺で外線電話あり終了。 暗号資産の話もちろん、投資の話題さえ皆無な同僚から、短期間に複数の相談が来たのは何を暗示しているのか…。 いきなり『ビットコインスタンダードとマスタリングビットコインとデジタルゴールドっていう本貸すから読んでみて!』とかは引くだろうし。 また2人と話す機会があったら、どうやってビットコインに興味を持ったのか聞いてみたい。

ビットコインはどのように日本社会に浸透するか
どんどんコンテンツが出てきたDH Magazine Proへのリアクションを。 ビットコインへの理解度が世界最低レベルの日本。どのみち普及するのだろうが、浸透する過程を予想し、逆算的に普及活動について考えてみた。 ・ビットコイン理解度は新興国で高い ドル覇権の実害、法定通貨リスクの有無が大きい国ほど切実なニーズにつながる。まだまだ日本は、親方日の丸意識が残り、現金主義が幅を効かせる状態。現在形では、ゆでガエル的な法定通貨安とインフレ期到来中なので、今後、オレンジピリングへのニーズが高まる季節に入っていくと予測。生活は苦しく大変だが、ビットコイン普及活動のタイミングには申し分ない。 ・日本はアメリカの後追い国家 1945年の国家的クライシスを経て、政治も経済もカルチャーも、総じてアメリカ右ならえトレンドが続いている。よって、アメリカでのビットコイン普及が時間差で波及する形で制度化・定着化する流れが最有力のシナリオだが、民間から加速するには先人の経営者達の成功例が参考になるかも知れない。 ・タイムマシン経営論 アメリカで流行っている事業を時間差で日本に導入するタイムマシン経営が、長きに渡り成功を収めた戦後の日本経済。 マクドナルドの藤田氏、セブンイレブンの鈴木氏が有名だが、最大の成功者はタイムマシン経営の生みの親でもある孫正義氏だろう。彼らは、アメリカのトレンドを日本に最適化する能力に長けていたため、サイクルの早い経済環境にも関わらず、非常に長い期間、市場での優位性を維持している。模倣すれば、アメリカでのマスアダプションを日本に適合させるのが、成功確率の高い手法だと言える。 ・トレンドフォロー&ローカライズ アメリカのトレンドを見れば、日本の未来が予想出来る。次は、日本におけるローカライズが大きな課題となる。米国流そのままから、日本の特性にフィットさせることが鍵になる。また一定の影響力を有する主体が存在しないと、普及に影響を与えるのは難しい。 主体は企業体なのか、財団なのか、著名人なのか、DAOなのか。組織の形態は活動内容に直接関係する。例えば、著名人のサロンのような形態は独善的になりやすく継続率も低い。企業は事業の継続性は高いが、初心を忘れ営利優先の活動に陥りやすい。また、ビットコイン普及よりも団体自体の永続が目的化しやすく、本末転倒な結果に終わるリスクがある。ビットコインの分散性に習い、自然発生的な個々人の活動の緩い連帯が理想形だが、影響力を有するには長い時間が必要になる。 ・権力に従順な特性を利用する 古から続くお上に逆らわない日本人の特性、政治体制やマスコミ論調に従順な特徴から、アメリカに習って投資制度や税制が変化したり、それに乗っかる大手マスコミの論調変化で、わかりやすくトレンド変化が起きる可能性が高い。直近の日経新聞でも、久々にビットコイン推しの記事が出ているが、相場環境、SECの規制方針、ETF実現可能性の加速などが後押ししているのは明白だ。

30億円集めた会社が消えた!?ブロックチェーンのスマートコントラクトって何?
こんにちは、みなさん。今日は、ブロックチェーンという技術を使って、スマートコントラクトというものを安全にチェックする会社が、アメリカの政府からおこられた話をします。 ブロックチェーンとは、インターネット上でデータを分散して保存する方法で、ビットコインなどの仮想通貨に使われています。スマートコントラクトとは、ブロックチェーン上で自動的に実行される契約のようなもので、例えば、ある条件が満たされたらお金を送るとか、商品を届けるとか、そういうことができます。 このスマートコントラクトは、プログラムで書かれているので、間違いやバグがあると大変なことになります。だから、安全にチェックする方法が必要なんです。その方法を提供する会社がQuantstamp(クアンタムスタンプ)という会社です。 Quantstampは2017年にICOという方法でお金を集めました。ICOとは、仮想通貨の一種であるトークンを売って資金を調達する方法です。Quantstampは自分たちのトークンであるQSPを5000人の人に売って、約30億円ものお金を集めました。 でも、このICOはアメリカの政府の許可を得ていなかったんです。アメリカの政府は、QSPは証券(株や債券など)に当たると考えていて、証券を売るには登録が必要だと言っています。Quantstampは登録せずにQSPを売ったので、法律に違反したことになります。 アメリカの政府はQuantstampに対して罰金を科しました。Quantstampは罰金だけでなく、QSPを買った人にお金を返すことにも同意しました。Quantstampが持っていたQSPも全部消すことになりました。 Quantstampは今ではスマートコントラクトのチェックサービスもやめてしまいました。QuantstampはICOで集めたお金をどう使ったのか、わかりません。 みなさんはどう思いますか?ICOは良い方法だと思いますか?QSPは証券だと思いますか?コメント欄で教えてくださいね。 以上が今日の話題でした。次回もお楽しみに! 参考文献https://cointelegraph.com/news/sec-charges-quantstamp-for-20190
Purchased this article blbefdxui
Purchased this article d4twdrw6u
Sigeru Minami purchased this article o6lb44185
btc_dakara purchased this article 9sxim5z7a
Purchased this article 0n6av4y4u
Boost mined
Boost mined
Boost mined
Sent a payment
Yuya tipped you
Purchased this article 8esd8io79
Purchased this article 4edsbi878
Purchased this article isyxk8n8w