Cryptcoin Junkey
I'm just a BOT.
(;;)
フォローしているユーザーはまだいません
モナパーティの品質マネジメント問題
つぶやき、ぽえむ。 まず「本家 Counterparty の構造が testability 低すぎ問題」があり、それを全面的に継承してしまっている。 とはいえ Pyhton2 系の頃からの秘伝のタレの継ぎ足しなので、Counterparty を責められないところは、ある。 テストを書きながら、大規模なリファクタリングすべき時期なのだろうなぁ…。 本ぽえむ執筆時点での発行済アセット数 11,639。トランザクション数 155,364。大御所絵師の参入も見られるようで。 そろそろ内輪のノリや冗談では済みづらい領域に近づいているよね…。
taproot on Monacoin
つぶやき、ぽえむ。 Segwit の有効化については、あれはあれで各位がガチで動いた結果としてのネタとして面白かったと思うのですよ。 "開発されていないコイン" がなぜか世界最速で Segwit の mainnet activate するとか、たぶん万人にとって、ちょっと想定外だったはずなので。 けれども、ネタがウケたと思って何度も繰り返すのは、無職業者BOT的にはノーだな…。オツムの程度が低い感じがして。 もちろん妥当なプルリクが飛んでくれば拒否する理由は何も無いので、やりたい人が準備すればよいと思います。 あとたぶん無いけどワタナベ氏の超法規的ミラクルなリリースは有り得る。実は敢えてそういう余地を残している。 祈るなら、対象は無職業者BOTではなくて、ワタナベ氏やね…。 どちらにせよ、無さそうだけど。
結局、これに尽きるので。
つぶやき。ぽえむ。 もともとワタナベ氏が想定したモナコインの使い途は、投機ではないようですし。今となってはモナパーティの価値保存手段など多岐に渡っているので。 対円価格が騰がろうが滑落しようが、淡々とチェーンを保守運用するだけですわな…無職業者BOTとしては。
モナパーティの dispenser に求められるUI
つぶやき。ぽえむ。 チェーン公式が UI 側に言及すると、遊び方を規定するような感じになりかねないので、無職業者BOTとしては、ちょっと控えめにしたいところ。 でもアイデアが全く出ないのも寂しい感じするので、ここでポエムっておく。 Ⓜ まず、ソートは要らないと思う。代わりに、フィルタ適用都度、最高値・最安値(MONA)とそれぞれ dispenser アド
(N)FTはチェーンの壁を超えられるか
<iframe style="position: static; visibility: visible; width: 531px; height: 432px; display: block; flex-grow: 1;" id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-0&features=eyJ0ZndfZXhwZXJpbWVudHNfY29va2llX2V4cGlyYXRpb24iOnsiYnVja2V0IjoxMjA5NjAwLCJ2ZXJza
monaparty.me を支える技術
つぶやき。ぽえむ。タイトル詐欺。 こみ企画提供のサービス(モナパレットとか)が結構上手いこと隠蔽しつづけていたのと、mpurse のバックエンドでもある mpchain.info が抜群の安定性を誇っていたので気づきづらかったかもしれませんが。 本家 monaparty.me のサービス可用性が、全モナパーティのノード群のうちで最も低い状態が長らく続いていました。 NFT 流行りからモナカードが広く注目される中、さすがにこれはマズい、ということで先月くらいから、ごにょごにょ弄っていました。 紆余曲折があり、Azure のコミュニティに問い合わせたりもした結果、かなり良くなってきたかなという実感を、計測した数値とともに感じたりしています。(グラフは API サーバ群のバックエンド死活状況) 現在の2ノード冗長を3に増やせば、SLA 99.999% は行けそう。 仮想通貨・ブロックチェーンというと、すぐに「開発されているか」みたいな話になるのですが。本当に難しいのは、エコシステムの確立。その基礎になる「安定したノード保守運用」です。 以前も書きましたけれども。 <script s
転売とアドレスKYC
つぶやき。ぽえむ。今回は平素にも増して、ぽえむ。 「(N)FT が転売かどうか判別するために、販売元アドレスの身元を知りたい」…だと? そらまあトラストフルなら、手は幾らでもあるよ。すでに発行者のレベルでは、モナカードは Twitter アカウントを要求しているわけで。 しかしなぁ。そんなトラストフルな世界が、皆が望んでいた世界なのか? ならクリプト要らねーじゃん。事業者所有の中央集権な DB でグルグル回すだけなら、金融庁お墨付きの暗号資産交換業でもできるのよ。 ビットコイン高騰からの DeFi バブル経由の NFT フィーバーに踊らされて、みんな気がどうかしてんじゃね? 正気か?
嫌儲主義
つぶやき。ぽえむ。 嫌儲主義も、一枚岩では無いよね。 とにかく経済活動を嫌がる夢見る子供部屋おじさん(おばさん)層から、経済回るのはいいけど詐欺的な手段も辞さないのはダメだろという中道主義層まで。スペクトラム。 レッテル貼ると単色に見えてしまう。世界はもっと淡い色が混じり合う、美しいものなのに。
Counerparty 自動販売機の秘密機能
この文書はクリプトに分類しても良いかもしれない。だが、つぶやき、ぽえむ。 Ⓜ Counterparty は、たいてい CIP という改善提案を行って、寄付を募って、そこから開発、というスタイルを取ります。 ですが、自動販売機 (Dispenser) だけはちょっと特殊で、CIP-21 という文書はあるものの、その後の拡張を自前でやろうとしていたフシがあります。 未完の機能もありますが、OPEN_EMPTY_ADDRESS はコードが完成しているようです。 文書が無いうえに作者は次のステージへ逝ってしまったあとなので、コードから読み解きました。 おそらくモチベーションは、こんな感じでしょう。 無思慮に複数の Dispenser を同一アドレスに置いてしまうケースがあるので、他のアセットが入っていない別アドレスに Dispenser を設置できるようにする。 アセットを別アドレスへ send し send 先で Dispenser を open するのと同じです。 しかし、2 工程かかるのは時間の無駄ですし、完全に新規のアドレスの場合、open する際に、採掘手数料としての BTC (モナパーティの場合は MONA)が必要になります。つまり実質 3 工程。なるほどあっても無駄では無さそう。 ウォレットのサポートが要りますが、オプションの便利機能なので、ウォレット開発者判断でサポートがなかったとしても困るというわけでもない。 しかし、これをそのままモナパーティに持っていくかというと…うーん。 『「他のアセットがない」ではなく「既に Dispenser を open していない」という条件のほうが使いやすいのではないか』など、ちょっと考えることもあり…うーん。 Ⓜ 仮にモナパーティに OPEN_EMPTY_ADDRESS 的なものを導入した場合に、積極的に使う場合のユースケースとして、モナカードの発行代行があるかなという気がしています。 依頼者は絵とモナコインアドレスを用意するだけ。Dispenser を建てるところまで代行し、アセットの所有権も譲渡してしまえば後腐れないはず。発行するモナカードの一部は代行業者が受け取り、時期を見て代行業者も Dispenser で売る。いわばトラストレスで依頼者にも仮想通貨が手に入る版の<a href="https://twitter.com/monapachan" target="_blank" rel="noop
[予告] Dispenser の挙動を変えます。
非公式情報。まだ XMPIP は書いていません。コード修正先行の定常運転。 Ⓜ Dispenser を使いやすくするための Counterblock API を生やそうとしていたのですが、検討すればするほど「Dispenser 周りだけ Counterparty API や内部 DB の作りが宜しくない」感が強くなってきました。 ただし、ウォレット開発運用勢に余計な負荷を掛けないよう、互換性は可能な限り取ります。以下は、変更点概要。 Ⓜ まず、refill の廃止。同じアドレスに同じアセット(例えば XMP)の Dispenser を2回以上オープンしたとき、以前の残高を新しいコントラクトに継ぎ足してくれるという機能(refill)があります。便利なようでいて、残高の推移が DB から掴みづらくなる欠点があります。また、データがコントラクトに閉じなくなるので、設計として美しくありません。 変更後は、同じアドレス同じアセットの Dispenser を複数置けるようになります。 つまり、refill してくれると思って 1MONA→1000XMP を販売しているアドレスに 1MONA→1000XMP の Dispenser を置くと 1MONA→(1000+1000 == 2000)XMP の販売となり、損するようになります。 一方で、1MONA→1000XMP と 10MONA→100XMP の2種類の Dispenser を同じアドレスにおけるようになります。この例では 10MONA→((1000*10)+(100*1) == 10100)XMP です。このような大口購入者へのインセンティブを与えるには複数のアセットが必要でしたが、その制限が撤廃されます。 refill と同等のことをしたければ、一旦 close してから再度 open すれば叶います。 Ⓜ 次に Cancel メッセージが Dispenser をサポートします。これは、普通にモナパーティを使っている限りは気にならない、深い部分の話なのですが。たぶんウォレットを作っている人には少し影響があります。 Dispenser もモナパーティの組み込みコントラクトなので、識別は tx_hash で行えます。ならばコントラクトの取り下げは Cancel メッセージを経由するのが Counterparty の流儀に沿っています。現状のような close status を create するのは美しくありません。 しかし、create_dispenser API に破壊的変更を加えると既存のウォレットが軒並み動かなくなります。そこで、close status での create が飛んできた場合には
Counterparty にある危機とモナパーティの近未来リスク
つぶやき。ぽえむ。TL;DR 予告編出していたやつの続き。 Ⓜ 一口に「ブロックチェーン」といっても、その価値の保存方法は様々です。主流どころはUTXO 方式(Bitcoin 系)とアカウント方式(Ethereum とか NEM とか 系)で大きく分かれます。…なんとなく聞いたことがある方もいらっしゃるでしょう。 両者の技術的な違いは、本稿ではあまり関係なく、「マスタリング・ビットコイン」とか「マスタリング・イーサリアム」とか名著が既にありますので、そちらに譲ります。 ビットコインの系譜の上にあるモナコインは、UTXO を採用しています。一方、モナパーティはアカウントを採用しています。 ここまで聞いて「あ、モナパーティは Ethereum と同じなのね…」と思うかもしれませんが、それは早合点です。 アカウント方式でも、思想的に最低でも 2 種類の流派があります。 * ブロックが生成された瞬間の、配下にあるすべての状態を、ブロックに記録する。* ブロックには状態を記録しない。各ノードが後で再生して組み立てる。 (ここでいう「状態」とは、各アセットの残高だと思えば、だいたいあっています。) Ethereum は前者、状態をブロックに記録します。彼らが駆使する宇宙語では "ワールドステート" と呼ぶようです。 Ethereum はすべての状態をブロックに記録します。後から状態を改ざんすれば、すぐに検出できるようになっています。暗号学的
モナパーティの dispenser あれこれ
つぶやき。ぽえむ。 「UX がイケている dispenser がモナパーティに存在しない」 は、まあそうだねぇ。 しかし、「無職業者BOTは、可能な限りフロントエンドには手を出さない」という不文律があるので、優先度は最低寄りの低。 dispenser に関しては、(開発勢でもなければ気づかないだろうけれど)バックエンド側もイケていないという感がある。故 Jhon は Counterblock 撤廃志向だったからなぁ。しかし SQLite3 で膨大な dispenser クエリを捌けるはずもなく。 どう考えても複数API(モナカードAPI と Counterblock API) で絞り込む感じの UI が求められるので、REST や JSON API は向かない。GraphQL 辺りに解を求める感じかもしれない。 バックエンドが整ってくると、フロントエンドの開発負担が減る。うまくやれば、バックエンドへの負荷も減る。 …しかし一日は 24 時間しか無いしな。
Taprootアクティベーション 続報1
以前の記事では、Taprootのアクティベイト方法について2種類が提案されていることを紹介しました。1つはBIP8(LoT=True)を使い、1年以内にマイナーの90%が支持しない場合でも、ソフトフォークを行う方法です。この場合はSegwit時みたくユーザー圧力によるUASF(User Activated Soft-Fork)型で、それでもマイナーが支持しない場合はチェーンが分裂します。2つめのBIP9を使うSpeedy Trialという呼ばれる方法は、3ヶ月という短期間にマイナーの90%が支持を得られればアクティベーションするものです。Speedy Trialでマイナーの支持が得られなければ、別のアクティベーション方法へ移行します。 この2種類のアクティベーション方法のどちらを採るかの投票がTwitterで行われていました。以下がその結果です。 <iframe style="position: static; visibility: visible; width: 550px; height: 515px; display: block; flex-grow: 1;" id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-0&features=eyJ0ZndfZXhwZXJpbWVudHNfY29va2llX2V4cGlyYXRpb24iOnsiYnVja2V0IjoxMjA5NjAwLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X2hvcml6b25fdHdlZXRfZW1iZWRfOTU1NSI6eyJidWNrZXQiOiJodGUiLCJ2ZXJzaW9uIjpudWxsfX0%3D&frame=false&hideCard=false&hideThread=false&id=1384196789184581633&lang=ja&origin=https%3A%2F%2Fspotlight.soy%2Fwrite&sessionId=b6b87dade903eeabf957f01e206a57e5d40270c
30日で着金しました！！！ 時間をかけていいなら、悟コインから99％取り出せます(^▽^)/
つい一昨日、「悟コインからの送金を指示してから、4週間たっても着金しない」という内容の記事を書いたのですが・・・ 本日（2021年4月5日）、無事に着金しました！ 届いた金額は、0.0009904 BTC（99040 satoshi）です。 送金指示したのは、3月6日（土）でした。4月5日でもって、ちょうど30日経過したことになります。 無事に着金して、ひとまずほっとしました。ε-(´∀｀*) 私が何をしようとしていたかを一言で言いますと、「悟コインの中身を最大限取り出す」ということです。 皆さんご存じのように、1枚の悟コインには、0.001BTC（10万サトシ）が封入されています。 では、この額を自由に使えるかというと、そうじゃないんですよね。 なぜなら、送金するには手数料が発生するからです。 0.001BTC（10万サトシ）をどこかに送金するとき、送金手数料が差し引かれた分が、先方に届くことになります。封入されているビットコインの全額が着金するわけではないのです。 ですから、悟コインを持っているとしても、それに封入されている額のビットコインをまるまる保有していると思うのは、早合点というやつです。 もっと噛み砕いて言えば、0.001BTCの入った悟コインを1枚だけ持っていても、0.001BTCの商品の購入には使えないということです。 また、ビットコインの送金手数料
Monacard2.0計画
Monacardをアップデートして大きく仕組みを変えようと思います。ユーザー、開発者の意見によっては中止する可能性もあります。細かい仕様はMonapartyが更新されたのち動きを見ながら決定します。時期MonapartyがIPFSに対応したのち状況を見極めてからになります。 目的1. card.mona.jpが終了した場合にMonacardの情報が消失するリスクをなくす。2. IPFSへの画像アップロードを促し、画像が消失するリスクを減らす。 仕様card.mona.jpでのカード登録機能を廃止し、Monapartyアセットのいずれかの部分(Descriptionなど)に現在のMonacardに登録しているのと同じ情報をJSONとして書き込んでもらいます。imgurの部分だけはIPFSに関連する情報に変更になります。このJSONの形式をモナカードプロトコルと呼ぶことにします。しばらくはcard.mona.jpだけで十分かもしれませんが、モナカードプロトコルを参照するシステムはだれでも作ることができます。card.mona.jpの役割今まで通りエクスプローラーや保有カードの表示機能を維持します。APIはアセットのJSONから取得したものを今まで通り表示します。card.mona.jpは情報の橋渡しをするサイトになります。また、Monacard2.0で不便が生じた場合支援する機能を作成します。例えば、JSONを打つのは面倒ですので作成を支援するページなどを必要に応じて作成します。 互換性APIを使用しているサイトが何も対応しなくても問題が生じないように配慮したいと考えてます。今までのMonacardとMonacard2.0をラップする形でAPIが情報を提供します。現在imgur_urlのパラメーターで配信している部分にブラウザが直接参照できるURLを代わりに入力することを考えています。APIにはバージョン情報など新しいパラメーターが追加される可能性があります。登録機能に関してもしばらくは併存させる可能性があります。心配事imgurのように画像のサイズが自動で生成されないので、そこら辺をどうクリアすべきか考えています。Monacardの進捗LEVEL1: アセットと画像を結びつけることができるLEVEL2: Monacardで遊ぶユーザーがいるいまここ→LEVEL3: Monacard周辺のサービスが整うLEVEL4: Monacard2.0LEVEL5: 多くの日本のイラストレーターがMonacardの作成を検討するLEVEL6: 多くの世界のイラストレーターがMonacardの作成を検討する
Monapartyのアービトラージで稼いでみた
まだ完了していませんが1回転で資産3倍ですｗ 前知識トークンをMONA建てで自動販売するDispenserという機能がありますトークンを主にXMP建てで販売するDEXという機能があります アビトラの流れDispencerでXMPを500XMP/MONAで出品したところボチボチ売れています。XMPの在庫がなくなったらDEXで1500XMP/MONA(NA)で仕入れて売れば資産3倍になります。実際にさきほど14MONAで19000XMPを購入しました。これが今まで通りに売れれば約38MONAになるので 38-14 = 24MONA の利益で日本円換算すると5000円くらいの利益になります。 落とし穴実はDEXではMONAを使うことはできませんそのためMONAをEthereumで言うところのWBTCみたいのに変換する必要があります。また、自動販売機能にもくせがあります。Monaparty関連のサービスを使い慣れてる人なら大丈夫ですが、ある程度複雑な操作が必要になるので安易に稼ごうとするとGOXして大損すると思います。そのため、詳しい操作方法は記載しません。使い慣れてる人はすぐに理解できると思います。美味しい情報を公開した理由アビトラは参加者が増えればうまみがどんどんなくなっていきますが、流動性が増えたり価格差が埋まることで利用者にはプラスに働きますのでそれを期待してます。あとまさかMonapartyでアビトラできるなんて面白いなと思ったので書いてみました。
