# Gas支払いになんらかのBTC払いを利用するモデルについて

## Totoroトークン設計の前提

- こちらの3番のEOSモデルかつMeta TransctionでLN払いができることが前提
- つまりTX Payloadのなかにgas支払いに関する署名を追加し、その署名者の帯域を利用できるようにする
- ただしこのままではユーザーにgas代かわりのln払いを矯正できてもtxをOPが実行してくれるかどうかは確実ではない
- ただしLNで返金を強制させるのはあまり現実的ではない

## やりたいこと

- この際、送金の際にOPにgas利用の署名を公開することを強制できないか？
- Userの送金時に同時に交換するイメージ
- それがあれば署名を添付して他のOPに投げたりすることができる

sequenceDiagram

actor U as User
participant O as Operator A
participant AU as Operator B

autonumber
U --> O : Throw Tx data
O --> U : Send Invoice(?)
U --> O : Transfer BTC
O --> U : Send Signature for using calculation power
O --> O : Execute Tx with signature
Note over O : If Operator A doesn't execute Tx
U --> AU : Throw Tx with Operator A's signature
AU --> AU : Execute Tx

## 想定しているモデル

- Bitcoinのトランザクションのなかでgas消費署名の検証を行う
=> 任意のデータに対する署名は存在しないので出来ない

- Secretのような形で公開しないとトランザクションの利用をできないようにする
=> 先にオペレーターからユーザーに対して渡された署名のハッシュが正しいハッシュなのか検証する手段がない

## 懸念点と想定される解決案

- Totoroをオペレーターが署名を渡した直後にUnstakeすることでtxを実行できないようにする
=> Unstake時にCosmosのように一定期間引き出せないLock期間を設ける
- オペレーターが偽の署名をわたしてくる
=> 第三者に検証させる or BitcoinのTx内でなんらかの縛りをつけたい
- 計算コストを嫌がってOperatorがなかなかTxをとりこまない
=> Totoro配布メカニズムにTxの消費量に従ったインセンティブ付を行う

###### tags: LightningNetwork, fee