btc_dakara purchased this article lzlfigh7i
ビットコイン決済と税金
ありえないと思うけど、ビットコインが課税されつづけたら、あるコミュニティ内では換金せず匿名通貨として使われださないかな。 深く考えたことはないけど、損益がなければ課税対象にならないなら、BTCを担保にライトニングでSatoshiを借りて、それで支払いをする。借りた時点を基準価額にして支払い時の損益計算するならダメだけど、、、何かうまくいく方法ないかな。 あとは、単純にステーブルビットコインウォレット。ウォレットにはビットコインしかないけど、資産として保管するものと、通貨としてステーブルにしておくもので、残高が2面あるようなウォレットが出てくると、今の税制でも気にせずに決済できるよね。 何か質問、意見、アイディアあればコメントください 😺
0
1
Yuya
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を取得します。イメージとしては以下の図のようになります（参照元）。そして上記のスクリプトシステムに従
0
2
Yuya
ライトニングネットワークによる為替取引・資金移動の備忘録
資金移動に関しての海外サービス企業による考察は、中継者が盗むことができない仕様になっているから、資金移動ライセンスは不要と考えているみたい（記事はこちら） また、為替取引や資金移動よりも、AML/CFT（マネー・ローンダリング及びテロ資金供与対策）の方が日本含め世界のトレンドだとは思うのでとりあえず、金融庁と日銀が公開しているレポートを掲載しておく（日銀は単にブロックチェーンのスケーリング手法を紹介しているだけ） ResearchPaper_MRI_ja.pdf (fsa.go.jp) ブロックチェーン技術のスケーラビリティ問題への対応 (boj.or.jp) LNノードを運用することが規制対象になるかは分からないが、オフチェーン取引だけではあまり意味がなく、取引所やオンチェーンスワップとの接点をKYCやモニタリングすればいいんじゃないかなと、それで資金洗浄等の監視はできると思う。
0
3
Yuya
LN上でのDLCオプション取引
ある程度の実装目途が立ちそうなのでアイディアのみ以下に貼っておく。DLCの仕組みを知りたい方は以下のサイトがとても分かりやすいので、熟読されることをおススメします。 https://tech.bitbank.cc/20201214/
0
1
100,000
Yuya
ライトニングネットワークの成長に伴うアウトバウンドキャパシティ枯渇問題
ルーティング量が増えてきているのは良いことだけど、それに伴いルーティング失敗量も増えている。以前書いたDHレポートでは、ルーティング成功率は5％ほどで、残りはルーティング先の後続ノードのエラー（forward_fail_event）か自身のアウトバウンド資金不足（insuffcient_balance）によるもの。このエラー率の健全な？値はいくつくらいなのだろうか。ネットワークが拡大し、ノード運営者が増えることでさらにこのエラー率が増えるのか（新規参入ノードほどチャネルバランスが悪いため）、ルーティングアルゴリズムの向上で改善されるのか。ルーティングのエラーログを眺めていると、あぁルーティングの機会損失がぁって感じでちょっと悲しくなる。LNを始めると最初に出くわすのがインバウンドキャパシティ問題だが、ノード運用をしていくとアウトバウンドキャパシティ枯渇問題に直面する時がくる。アウトバウンドが枯渇すると以下の図のinsufficient_balanceというエラーが頻出する。これはルーティング依頼は来たが、自チャネルにルーティング可能な資金がないことで起こるエラー。
0
4
1,000
Yuya
Witness EncryptionによるトラストレスなWBTC発行（の備忘録）
ちょっと面白そうな記事が公開されたのでざっと読んでみた。こういう記事が日本からでると嬉しいので、もっと出してほしい笑 記事の内容は、カストディアンを必要としないWBTCの発行についてです。以下に自分のメモ用に記事の趣旨を書きだしてみました（間違っている可能性大）。 入金用ビットコインアドレスの生成 入金用ビットコインアドレスの秘密鍵はジェネレーターによって生成される。ジェネレーターが不正をすればWBTC返済前に勝手に出金できてしまうので、複数人でのN-of-Nマルチシグを生成することでセキュリティを高めることができる。この秘密鍵はWitness Encryptionとよばれる方法で暗号化され、そのwitnessで復号できる。 入金 上記で生成されたアドレスへ入金し、そのProofをコントラクトへ提出することでWBTCを受け取ることができる。正当なProofかの判断として、最長チェーン判定等が必要。 Witness Encryption あるinstance xに対するwitnessがあると復号できるものなので、このxは「WBTCを返済したか」の判定プログラムで、そのwitnessをもって秘密鍵の復号ができる（のかな？）。 WE.Enc(1λ,x,m): It takes a security parameter λ, an instance x, and a message m &is
0
3
1,000
Yuya
ZKPによるライトニングネットワークでの送金前チェック
ライトニングネットワークでの基本的な送金手順は、受信者がインボイスを生成し送信者へ渡し、送信者はそのインボイスに含まれるハッシュ値を使ってHTLCを作成して送金をする。受信者は受け取ったHTLCに対してそれに対応するプリイメジを引き渡すことで着金が完了する。現状、送信者は受信者が本当にプリイメジを持っているか確認することはないが、もしできるのであれば以下の方法でできそう。我らがHal Finneyという言葉もしれっと登場しているので参考までにどうぞ。 以下のサイトではどんなプログラムでもZKPへ変換可能であることが証明されていると書いてあるし面白いね。 https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
0
6
Yuya
Python + ngrokでLN決済APIサーバの構築
本業が落ち着いて時間的に余裕ができたので久しぶりにLN系の開発に戻ってきました。久々にLNDのAPIドキュメント見ましたが完全に忘れてます！ さて、今回はpythonでLNの決済処理をやってみたいと思います。内容的には以前にDH開発部で作った内容から決済部分のみを切り出してシンプルなWEB APIにしたものになります。DHチャットでngrokの話題を見かけたのと決済の所は以前から気になっていたので合わせて実装してみました。 大した事してないので、もういきなりソースで説明します。呼び出し側のサンプルhtmlはこんな感じです。 <html><head> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script> <script type="text/javascript"> $(function(){ $('#button1').click(function (){ $.get('https://0fcb-117-108-71-175.jp.ngrok.io/createinvoice/' + $('#text1').val() + '/' + $('#text2').val()) .done(function(ret){ $('#amount').text(ret.amount); $('#bolt11').text(ret.bolt11); $('#desc').text(ret.desc); $('#rhash').text(ret.rhash); $('#qrImg').attr("src", ret.qr_str); $('#sect').show(); }) ; }); $('#button2').click(function (){ if($('#r_hash').text() != ""){ $.get('https://0fcb-117-108-71-175.jp.ngrok.io/checkinvoice/' + $('#r_hash').text()) .done(function(ret){ //1:支払い済み; 0:未払い if(ret.state == "1"){ $('#status').text("決済完了!"); }else{ $('#status').text("決済未完了.."); } }) ; } }); }); </script
0
2
monamona
モナカードが BTC や LTC でトラストレスに買える未来
または、MONA で Counterparty や Dogeparty のアセットが買える未来。 つぶやき。ぽえむ。 Ⓜ️ 技術的なフィージビリティ・テストを通過させたわけではないのですが。 モナカードを MONA 以外の暗号資産で売買できる可能性があります。 Lightning Network がキーコンポーネントになるので、スマコン推し系のチェーンでは無理そうですが。 まあ、そういうチェーンに対する対応は、もなちぇんあるので。もんだいないもんだいない。 Ⓜ️ この技術って、日本の資金決済法には抵触しないのですよ。だから、後ろめたさを全く感じず、日本発祥のモナカードを日本の事業者が国境を超えて商売できる。 そして日本以外の事業者も、所属国の法規に従えるなら、商売できる。 Ⓜ️ モナパーティのエコシステムが圧倒的実装工数貧乏の現在にあって、いつ実現されるのかは、極めて不透明ですが。 技術的には不可能ではなさそうで、おそらく需要はあるでしょう。 クロスチェーンでトラストレスのトークンアセット売買プラットフォーム。 「開発されていない」はずで「ローカルで逆張りしたから失敗した」はずのモナコインのエコシステムから、グローバルで使えるものを提供できたなら、意外で面白いですよねー?、と。 ぽえむ。
0
4
Cryptcoin Junkey
100
Cryptcoin Junkey purchased this article 2varnplan
100
Purchased this article 3rlvddsls
-100
Purchased this article ai0wsbl4i
-100
こるけ (@coruket@mstdn.jp) purchased this article lsi01x8qs
1000
Purchased this article 4b8dzmp2r
-100
Purchased this article vpcvh5083
-100
Purchased this article rlgkwdelx
-100
Cryptcoin Junkey purchased this article 9fez25vp5
10000
Purchased this article jfgj298kh
-100
Sent a tip w85to0ijj
-1000
Purchased this article w85to0ijj
-100
極度妄想（しなさい） tipped this article f613vxl9f
1000
極度妄想（しなさい） purchased this article f613vxl9f
1000
