Techniques to reduce transaction fees

提供: tezos-wiki
移動先: 案内、 検索

このページには、現在利用可能な技術のリストがあり、消費者が支払う取引手数料の額を減らすことができます。すべての手法がすべての状況に適用されるわけではなく、いくつかの手法では、より低い手数料で他のメリットをトレードオフする必要があります。

支払う手数料を減らすと、ほとんどの場合、他のユーザーも支払う手数料が減ります。高頻度の消費者にとっては、この効果は大きくなり、2次的にかなりの節約効果が得られます。たとえば、組織がすべてのトランザクションの10％を作成し、トランザクションを50％効率的に開始する場合、ブロックスペースの5％がBitcoinのすべてのユーザーに解放されます。これにより、いくらかの金額（5％を超える可能性がある）で手数料を引き下げることが期待され、50％の一次節約の上に二次節約を提供する。

このページでは、支払い指向の取引に適用される手法についてのみ説明しています。データキャリアのトランザクション（OP_RETURNやOpenTimestamps）、コインプロトコル、Bitcoinトランザクションの提案されたその他の用途には、以下のテクニックのいくつかのメリットがあるかもしれませんが、ユースケース。

効率改善=[編集]

サイズの小さいトランザクション（ weight）を作成するか、特定のサイズに対してより多くの処理を実行すると、不十分なブロックスペースを使用するより効率的な方法が提供されますので、 #feerates | feerate]]になります。 このセクションでは、より効率的なトランザクションを生成するためのいくつかの手法について説明します。

技術的には、[[支払いチャネル]で行われたものなどのオフチェーン支払いは非常に効率的な支払いの一種であり、このカテゴリに属しますが、高い達成度で独特の方法 効率。

圧縮された公開鍵=[編集]

「普遍的に有用だが既に広く配備されている」

2009年にリリースされたオリジナルのBitcoinソフトウェアは、ビットコンドの所有者を識別するために65バイトの非圧縮公開鍵を使用していました。 2012年、Bitcoinプロトコル開発者のPieter Wuilleは、現在Bitcoin Coreとして知られているプログラムに変更を加え、代わりに33バイトの圧縮された公開鍵を使用できるようにしました。[ref> Bitcoin Core 0.6.0リリースノート、Bitcoin.org、2012-03-20、retrieved 2018-01-27 </ ref> Bitcoin Coreユーザーがこの機能を採用し、他のWalletもこれを使用するようにアップグレードされたため、ネットワーク上の典型的なトランザクション（1つの入力と2つの出力）のサイズは約258バイトから約226バイトに14％削減されました。

center | 800px | thumb | scriptSigsに古い圧縮されていないpubkey形式を使用するブロックあたりのトランザクション入力の割合。注：初期のBitcoinトランザクションでは、pubkeysがscriptSigではなくscriptPubKeysに配置されることがよくありました。

この変更は完全に下位互換性があり、セキュリティを変更することはありませんでしたが、新しいBitcoinアドレスを生成するためにスペース節約にアクセスする必要がありました。

2012年以降、多くの財布では圧縮された公開鍵が採用されていますが、まだ一部の財布では非効率な非圧縮公開鍵が引き続き使用されています。これらの財布は、圧縮された公開鍵に切り替えることにより、同じ優先順位の取引手数料を大幅に節約することができます。すべてのウォレットがそれを採用した場合、有効なブロック・スペースはわずかに増加します。

center | 800px | thumb |圧縮されていないpubkeysの余分なバイトで消費される利用可能な最大ブロックスペースの割合

参照：

支払いバッチ処理[編集]

高頻度の消費者（組織など）には非常に便利です。低頻度の消費者（例えば、個人）にとっては適度に有用である

すべてのBitcoin取引では、使用された資金を参照し、その取引がその資金の所有者によって承認された証拠を提示する必要があります。 1回の資金回収には、通常の状況下で最低でも79vバイトがかかります。そのトランザクションで何人の受取人が支払われても、同じ量のブロックスペースが使用されます。たとえば、次の2つのシナリオを考えます。

  • アリスは1回の取引でボブに支払い、2回目の取引でチャーリーに支払います。各取引には、使用されている資金に関連して最低79 vバイト（合計158 Vバイト）が含まれています。
  • アリスは、ボブとチャーリーの両方に一つの取引をします。 1回の取引では、使用されている資金に関連した1セットの79 vバイトしか必要とせず、このフィールドでは50％の節減になります。

このタイプの節約は、支払額が取引の支払いに直接関連するvbytesを追加するコストよりほんの少し上回るまで、単一の取引に追加される支払額が増えるにつれて増加します。下のプロットは、他のP2WPKH出力を支払うネイティブsegwit P2WPKHトランザクションの支払いあたりのコストを示しています。

center

5回の支払いが追加された後、50％以上のコスト削減が見られ、セグジット取引の場合、約70％のコスト削減効果が見られます。図示されていないのは、レガシートランザクションの場合、セグジットトランザクションより効率が低下するため、セービングは従来のトランザクションの約80％まで増加することです。これは大きな利点であり、組織などの高頻度の消費者が容易に入手できるものです。

多くのウォレットはバッチ処理をサポートしています。グラフィカル・ウォレットでは、多くの場合、トランザクションに追加の受信者を追加できるボタンがあります（下の図を参照）。コマンドラインとRPCウォレットでは、複数の受信者に支払うことができる sendmany </ code>のような呼び出しがよくあります。

thumb | 200px |右| Bitcoin Core 0.15.0で受信者ボタンを追加

支払いが追加されたときに一定のサイズ（またはそれに近い）を維持するトランザクションの他の部分があるので、79 vbytesの固定コストよりも速く積み重ねることができます。以下のセクションでは、これらのケースの1つをコストとしてどのように排除することができるかについて説明します。

参照：

P2SHで包まれたセグウィット[編集]

'普遍的に有用な'

[segregated witness]（segwit）によって保護されたビットコインを使用するトランザクションは、同等の非segwit（従来の）トランザクションよりもブロック内のスペースを少なくして、segwitトランザクションが同じ[フェイエート]]をレガシー取引とみなします。節約額は取引の詳細によって異なりますが、例としてよく使われるトランザクションタイプがいくつかあります：

！タイプ ！従来のvbytes ！ P2SHでラップされたsegwit vbytes ！貯蓄
- シングルサイン 226 167 26％ - 2-of-2 multisig 335 197 41％ - 2-of-3 multisig 369 206 44％

上記のmultisigの例は、同等のレガシーP2SH multisigと同じセキュリティを使用しています。 Segwitは、1次元でより安全なmultisig形式へのアクセスをオプションで許可しますが、出力ごとに余分な12vバイトが必要となり、いくらか効率が低下します。

これらの節約にアクセスするには、P2SHでラップされたsegwitアドレスの生成をサポートするウォレットを使用する必要があります（3から始まるアドレスはすべてsegwit対応です）。これらのP2SHでラップされたsegwitアドレスに受信したビットコインを使用すると、トランザクションは自動的にブロックスペースを消費し、ウォレットには比例してより少ない料金を支払うことができます。

参照：

ネイティブセグウィット[編集]

普遍的に有用です。完全な使用には、ビットコインを送信する人々によるネイティブセグウィットの採用が必要ですが、すぐにあなたの変更出力に使用することができます

上で説明したP2SHでラップされたsegwitは、古いウォレットによってサポートされているP2SHアドレス形式と下位互換性がありますが、追加の領域を節約する新しい互換性のない形式が利用可能です。次の例と節約は、上記のP2SHで囲まれた例のサイズと比較されます。

！タイプ ！ P2SHでラップされたsegwit vbytes ！ネイティブセグウィット
vbytes ！追加貯蓄
- シングルサイン 167 141 16％ - 2-of-2 multisig 197 169 14％ - 2-of-3 multisig 206 178 14％

これらの節約にアクセスするには、bech32アドレス（ "bc1"で始まるアドレス）と呼ばれるネイティブsegwitアドレスの生成をサポートするウォレットを使用する必要があります。これらの固有のsegwitアドレスに受け取ったビットコインを使用すると、P2SHでラップされたsegwitアドレスよりも少ないブロックスペースで自動的にトランザクションが消費され、ウォレットの料金を比例して少なくすることができます。

ウォレットがネイティブsegwitをサポートすると、他の誰かがネイティブsegwitを使用し始めるのを待たずに、自分自身に生成されたchange outputに対してすぐに使用することができます。 2018年初めに、ネイティブセグウィットの採用が低い場合、これにより、どの出力が変更であるかを識別しやすくなり、プライバシーを低下させることが容易になります。ただし、ネイティブセグウィットの採用がわずかに増加すると、これはプライバシーに悪影響を与えるとは考えられません。

参照：

回避策を変更[編集]

高頻度の受信者（組織など）、特に既にトランザクションバッチ処理を効果的に使用している人に便利です

Bitcoinの取引で費やしたい資金を参照するときは、それらの資金をすべて消費する必要があります。たとえば、以前の取引で5 BTCを受け取り、2 BTCを費やしたい場合、Bitcoinは5つのBTCすべてを費やすことを要求します。このため、ほとんどすべてのBitcoin取引では現在、一部のビットコインが消費者に支払われています。たとえば、前の例の残りの3 BTCを自分に戻します。あなたが（例えば）$ 5の請求書を使って$ 2のアイテムを購入したときに、店員があなたに手渡す変更に類似して、自分自身へのこの返品は「変更」と呼ばれます。

典型的な変更出力は、トランザクションのサイズに約32バイトを追加します。消費者が正確な変更を支払うことができれば、つまり、自己への変更を払い戻す必要がない場合、変更出力を排除して、最大23％の取引を生成することができます。さらに、変更出力は、後で69vバイト以上の標準コストで費やされますが、正確な変更で支払いを行う場合、この将来コストも回避されます。

変更回避を使用するには、以前に支払った金額（取引手数料を含む）のサイズに近い支払額または支払額を受け取る必要があります。これは、選択する支払を多く受けておらず、支出トランザクションの金額を大きく変えることができない個々のユーザー・ウォレットの場合はまれですが、多数の支払いを受け取り、すでに支払いバッチ処理を使用して複数支払の変更は、容易に得ることができる効率改善となり得る。

消費者は、Bitcoinの完全な10ナノビットの精度と正確に取引の入力と出力を一致させる必要はありませんが、代わりに希望の量よりわずかに多いまたは少ない入力を含めることによってわずかに料金を超過または未払いにすることができます。必要以上に料金を支払ったとしても、変更出力のために余分な32 vbytes（またはそれ以上）を支払うのに比べてわずかな料金の引き上げが通常よりも少なく、後では通常の最小の69 vbytesその出力を費やしています。<ref> Transaction Merge（bip125 relaxation）、Rhavar、bitcoin-devメーリングリスト、2018-01わずかに低い手数料を支払う場合、取引の確認が遅れる可能性がありますが、現在の世代（2018年）の料金見積もりは依然として不正確であるため、運賃額のわずかな差異が遅延に強く関係しない場合があります。

参照：

連結[編集]

すべての財布には便利だが、ユーザーはプライバシーを犠牲にする必要があるかもしれない。

取引が支払う手数料は、vバイトでのサイズに比例し、サイズの主な貢献者の1つは、トランザクションが費やす入力の数です。各入力は、トランザクションが費やしたいファンドへの参照であり、ウォレットには価値の低いインプットのみが含まれている場合、そのインプットの多くを追加せずに受取人に支払う比較的高いアウトプットを作成することはできません。各入力はトランザクションに最低41バイト、ほとんど常に69以上のvバイトを追加するので、入力数を減らす戦略は考慮する価値があります。

手数料は時間の経過とともに変化する、全体的な手数料を削減できる方法の1つは、入力統合です。小さな連結のセットを1つの大きな入力に組み合わせるのは、料金は通常より低くなります。たとえば、通常の価格帯の期間中の通常のターゲットが100ナノビットコイン/ vbyで、現在の費用は10ナノビットコイン/ vbyteであれば、次に統合することで料金の約90％を節約することができます。それらの入力。

center

統合には、1つの入力を1つの出力に費やすコストに等しい、連結トランザクションを作成するオーバーヘッドが伴います。これは、P2WPKH入出力に対して約110 vbytesです。また、最初に送信された入力を互いに接続されていないアドレスに結合すると、統合トランザクションでその接続を確立することでプライバシーが低下することがあります（現在、入力を管理している人はほとんどいないプライバシーのこの要素を維持する）。

参照：

インテリジェントな料金選択[編集]

手数料に関しては、Bitcoinトランザクションを送信することはパッケージを郵送するのと同様です。高速優先度サービスに対しては高い料金を、低優先度サービスでは低料金を支払うことができます。このセクションでは、より手頃な価格の低優先度サービスを利用するためのいくつかの手法について説明します。

動的料金見積もり[編集]

普遍的に有用です。すでに広く普及していますが、研究開発が進むにつれて改善されています。

初期のBitcoin財布は、取引を行うたびに一定の料金を支払うことになることがよくありましたが、それを含めるには鉱夫にインセンティブを与えるだけで、手数料市場での確認を求める他の取引と競合するには十分ではありません。ブロックがいっぱいになると、これは変更されています.2018年初頭に、広く使用されているすべての財布は、現在の料金市場の状況に基づいて料金を選択するために動的な料金見積もりを使用します。

thumb | 200px |右| Bitcoin Core 0.15.0の料金セレクタ

しかし、いくつかの料金見積もりツールは、他のものより優れているかもしれません、より低い料金を支払っても、希望の時間で確認を達成する。複数の財布と料金見積もりサービスのデータを比較することができますが、P2SH.infoは、2018-01-23 </ ref>を検索します[5] >異なるウォレット間の料金見積もりを比較しようとする試みがいくつかあります。<ref> Bitcoin Transaction Feeの課題推定値、Jameson Lopp、BitGoブロック、2017-05-10、retrieved 2018-01-23 </ ref> 2018年の早い時点で多数の一般的な財布の料金見積もりに関する調査は知られていません。

さらに、2018年の初めには、現行の[mempool]データを確認ベースの料金見積もりに分解するなど、料金見積もりを大幅に改善できるいくつかの技術が最近説明されています。<ref name = "mempool-fee-est-スライド "> mempool州（スライド、PDF）を介して料金見積もりを最適化、カール-Johan Alm、Scaling Bitcoin 2017（スタンフォード）、2017-11-05、検索2018-01-23 <ref name = "mempool-fee-est-video"> mempool状態（プレゼンテーションビデオ）を介した料金見積もりの​​最適化、Karl-Johan Alm、Scaling Bitcoin 2017（スタンフォード）、2017-11-05、検索2018-01-23 </ ref>

も参照してください

患者の支出[編集]

緊急でない取引には非常に便利です。緊急の取引には役に立たない

忍耐強く彼らの取引が確認されるのを待つことができる支出者は、確認を達成するのに必要な[[取引手数料] | [feerates | feerate]]の変動を利用することができます。たとえば、いくつかのBitcoinブロックが連続して生成されることがあり、ブロック空間の効果的な供給が数倍に向上します。他の時には、日曜日の手数料が金曜日の金曜日の手数料より20％安くなるなど、需要は減少します。2017年の第4四半期のBitcoin Wikiでは、2018-01-27 </ ref>が回収されました。 Bitcoin Coreに含まれる広く使用されている料金見積もりの​​データを見ると、90％以上の手数料の節約が可能であり、約50％は多くの患者の手当てを受けることが容易です。

center

上記のデータでは、Bitcoin Core料金見積もり者は、このサンプル期間中、次の節約額が利用可能であることを示唆しています。


  • 経済的な節約は達成される可能性が低く、後のセクションで説明するトランザクションの置き換え可能性のために使用することをお勧めします。

多くのユースケースでは4日まで待つことは実用的ではありませんが、実用的な場合も多くあります。 いくつかの例：自分の財布間で資金を移動し、より多くの小さなインプットをより効率的に費やすことができる1つの大きなインプットに移すか、または消費者を信頼する友人や家族への支払いや送金 速い確認が必要です。

参照：

オプトイン取引の交換[編集]

普遍的に有用だが、受取人の財布にUIの問題を引き起こす可能性がある

厳密には手数料を削減する方法ではありませんが、オプトイン取引の交換により、ウォレットは以前に送信された取引を、より高い料金を支払う可能性のある新しいバージョンで更新し、おそらくは取引を他のものに変更する可能性があります。この方法は、オプトイン・リプレース・バイ・フィー（RBF）とも呼ばれます。この手法では、ブロックスペースの供給が急激に増加したり、そのスペースの需要が急減したり、低額の取引が確認される可能性のある状況が発生した場合に、ウォレットは当初より低い料金を支払うことができます。そのようなことが起こらなければ、消費者は取引の手数料を増額（「バンプ」）して、確認の確率を上げることができます。

これにより、取引の交換をサポートする財布は、交換をサポートしない財布よりも低い料金を支払うことができます。

取引の交換は、一部の受取人の財布には奇妙に見えることがあります。 Bitcoin Core（下の写真）などのウォレットは、取引のリストで別々の支払いとしてそれぞれの取り替えを表示します。置換の1つのバージョンが確認されると、通常のトランザクションとして表示されます。他のバージョンはXアイコンで表示され、それらが[競合している]ことを示します（同じ有効なブロックチェーンで一緒に発生することはできません）。これにより、影響を受けるすべての支払いのステータスを受信者に伝えるのに役立ちますが、置換に慣れていないユーザーには何が起きているのかは完全には分からないことがあります。他のウォレットには、トランザクションの1つのバージョンが確認されるまで、交換を選択するトランザクションは表示されない場合があります。ユーザーインターフェイス、ドキュメント、またはその両方を使用してこの状況を正しく処理する方法については、コミュニティの共通のコンセンサスは明確ではありません。

交換は、有利には、「支払いバッチ処理」（前述）と組み合わせることができます。たとえば、すべての出金をバッチ処理するのに30分かかるのを待つのではなく、最初の10分間の支払いを低額でバッチ処理することができます。それが10分以内に確認されなければ、消費者はその取引を次の10分間の支払いを含むわずかに高い取引と交換することができます。それが再度確認されない場合、別の更新には、最初の10分のトランザクションを元の意図したフェレートで含めることもできます。これにより、最初の10分間の受取人は、通常のバッチ処理よりも20分早く送金されたという通知を受け取ることができます。また、早期支払いでは予想よりも低い報酬で確認する機会が与えられます。より多くの支払いを伴うバッチ処理を更新するには、トランザクションサイズ100キロバイトの[リレー制限]まで必要な回数だけ更新を行うことができます。

現在のところ、取引の置き換えには大きな欠点があります。プライバシーを低下させる傾向があります。取引の手数料が増えると、追加の入力を追加するか、変更出力の値を減らす必要があります。どちらの場合も、これにより、トランザクションによって支払われている異なる出力間での変更出力の識別が容易になります。このような状況を改善する可能性があるが、2018年初頭にBitcoinにそのような機能を追加する予定はない。このプライバシー問題を回避することができます。

参照：

事前に計算された手数料=[編集]

事前計算された料金の差し引きは、最初のトランザクションが作成された時点でトランザクションの複数の差し替えを登録して署名する考えです。最初のトランザクションバージョンはすぐに放送され、各置換は連続してより高い料金を支払うことになります。このアイデアは、Bitcoinの既存のnLockTime機能と組み合わせて、指定された時間またはblock heightより前のブロックに置換バージョンを含めることを禁じることができます。これにより、置換えを信頼できないようにパーティー（鉱夫自身でさえ）。

例えば、アリスは次の10ブロック内でボブに支払ったかったと彼女の財布に伝え、支払う最高の手数料は何かを示します。アリスの財布は、既存の料金見積もり機能を使用して、Bobの取引の初期バージョンを作成し、10ブロック以内に確認するためにトランザクションの最低料金を支払った。同時に、Aliceの財布は、おそらく9つの他のバージョンのトランザクションを作成します。最初のトランザクションはnLockTimeを使用して、これから2つのブロックまで追加できないようにします。 2つ目のタイムロックは今から3ブロックまでロックされています。等…

これらの後続の取引のそれぞれは、取引を採掘するための鉱夫のインセンティブを高めるために、元の取引よりわずかに高い手数料を支払う（アリスの最高額まで）。

アリスが最初のトランザクションを送信した時点で、トランザクションのすべてのバージョンが署名されるため、ウォレットのロックを一度解除するだけで済みます。また、トランザクションの後続バージョンはすべてnLockTimeを使用するため、アリスはオフラインになった場合に後でブロードキャストするために、これらのトランザクションのコピーを信頼できないように他の人に配布することができます。

要するに、ソフトウェアは自動的にアリスの最大手数料を自動的に提供しますが、アリスの手数料を払うことができれば安くなります。

参照：


オフチャイン支払い[編集]

すべてのBitcoin支払いをBitcoinブロックチェーンに追加する必要はありません。たとえば、アリスがボブに1 BTCを支払い、ボブがチャレンに1 BTCを支払ったとします。これらの支払いをブロックチェーンに追加するのではなく、AliceからCharlieにBTC支払いを1つだけ追加することができます。

この特定の最適化を使用した初期の説明では、「トランザクションカットスルー」と呼ばれていました。[ref] [6]、Gregory Maxwell、2013-08- 23、検索された2018-01-25 </ ref>が、ブロックチェーンに記録されているすべての支払いではないという概念は、今日、「オフチェーン支払い」として広く知られています。

すべてのBitcoin支払いの最大99％がオフチェーンの支払いと見なされます。<ref> [7]、アダム・バック、2015年6月19日</ ref>、そのほとんどはBitcoin取引所での売買注文である可能性が高い。他の第三者も、ティップサービスなど、ユーザーのオフチェーン支払いを容易にするのに役立ちます。これらのサービスは、Bitcoinが多数のユーザーの間でコンセンサスを維持する負担を負わないため、非常に効率的です。しかし、この効率は、一般的にユーザーがサービス事業者に資金を盗まないように信頼させる必要があります。これらは、「執行不能なオフチェーンの支払い」です。

しかし、特定の第三者への信頼が必要ない「執行可能なオフチェーンの支払い」も存在します.Becoinがトランザクション検閲なしで継続して信頼しているだけです。

このセクションでは現在、執行可能なオフチェーンの支払いに重点を置いていますが、単純な信頼できる第三者よりも安全でプライベートなソリューションを提供するために、暗号化やその他のセキュリティソリューションを使用する、

支払いチャネル[編集]

「小規模および中規模の支払いには非常に便利だが、2018年初頭にはまだ広く展開されていない」

Payment channelsは、ビットコインが2つ以上の当事者間で[スマート契約]に入金され、関係する同業者が相互に信頼できない支払いを行うことを可能にする、「強制的なオフチェーンの支払い」の一種です。 hashlockと組み合わせることで、Lightning Networkのように、ピアのネットワークを介して安全に支払いを行うことができるため、Aliceは相互のピアBobを通じて支払いをルーティングしてCharlieに支払うことができます。

決済チャネルを開くには、確認された取引が必要となり、その取引の手数料は発生しますが、通常の取引の場合と同じです。チャネルを閉じるには、取引の手数料を支払いチャネルのコストに加算する確認済みの取引が必要ですが、その手数料も新しい受取人に再送金する受取人の費用に似ています。つまり、決済チャネルの手数料は、1回限りの決済と非常によく似ています。

チャンネルオープンおよびチャネルクローズ取引の外では、決済チャネルは、さらなる取引手数料を支払うことなく、無制限の支払いをサポートすることができます。これにより、非常に効率的なものにすることができます。たとえば、2つの取引手数料のコストに対して1万万円のチャネル内支払いを行うとします。注：チャネルピアや他のチャネルノードで支払いをルーティングする場合、サービスを使用するための独自の料金が必要になる場合があります。これらは、この記事のトピックである取引手数料とは関係ありません。

2018年初頭には、決済チャネルの実装は広く行われていませんが、Lightning Networkの最初のバージョンのいくつかの協調実装が利用できます。

参照：

潜在的な将来の改善[編集]

Bitcoinユーザーは、以下の改善点や改善点をご利用いただけます。改善を採用したユーザーは、さらに料金を下げることができます。

  • 効率改善
    • '公開鍵と署名集約：複数の公開鍵と署名を単一の公開鍵と署名に結合する機能で、マルチシググ取引は単一署名取引と同じくらい効率的です。また、トランザクション内の複数の入力からの署名を結合することもできます。これは[[Schnorrの署名]の変形で可能になると跳ね上がっています。 ソフトフォークが必要です。
    • 'Merkelized Abstract Syntax Trees（MAST）：未使用の条件を部分的に省略できるスクリプトを作成するためのメソッドであり、複雑なスクリプトをより効率的に使用できるようにする方法です。<ref> [https：// bitcointechtalk Bitcoin Merkelized Abstract Syntax Treeとは何ですか？]、David A. Harding、BitcoinTechTalk.com、2017-10-12、retrieved 2018この記事は、以前は次のIDで公開されていました：もしもtaproot <ref> [8]と一緒に使用されるならば、-01-27 </ ref>切り替え可能なスクリプト]、Gregory Maxwell、Bitcoin-Devメーリングリスト、2018-01-23 </ ref>特定のユースケースでは、署名の集約（前述）とうまく組み合わされます。 ソフトフォークが必要です。
    • CoinJoin with signature aggregation： CoinJoinはセキュリティを低下させることなくプライバシーを強化するBitcoinの技術です。患者の消費者のグループは、一緒にコインジョインに入ることができ、どちらがどのレシピを支払ったのかを曖昧にし、受け取ったアウトプットを（もしあれば）戻します。署名集約（前の箇条書きで説明した）と組み合わせることで、このプライバシ・モードの強化は、個別の非プライベート・トランザクションを作成する各消費者よりも安価であり、それでもセキュリティは同じです。 Bitcoinの楕円曲線Schnorrベースのシグネチャ]、Pieter Wuille、Scaling Bitcoin 2016（ミラノ）、2016-10-09、検索2018-01-27 </ ref>前述の署名集約ソフトフォークが必要です。
  • インテリジェントな料金選択
    • 'Mempool使用料見積もり：' 最近確認された取引だけでなく、未確認取引のキューも考慮した料金見積もりの​​潜在的改善[1] [2]プロトコルを変更する必要はありません。
  • オフチェーン決済

信頼できるサードパーティのセットはBitcoinユーザーのプールのビットコインを制御しますが、信頼できるサードパーティの個人または少数が窃盗するのを防ぐためにmultisigを使用します預金者の資金。公開ブロックチェーン（Bitcoinのブロックチェーンではありません）を使用して、ユーザーがシステムへの、システムからの、またはシステムからのすべての転送を監査できるようにします。 <ref> [10];ハードウェアセキュリティモジュール（HSM）は、第三者の信頼をさらに低下させるために使用されます。 Johnny Dilley、Andrew Poelstra、Jonathan Wilkins、Marta Piekarska、Ben Gorlick、Mark Friedenbach、取り出した2018-01-28 </ ref>ブロックチェーンを使用していますが、これはBitcoinの観点からはオフチェーンの支払いソリューションとなります。 2018年の早い時点で、フリーソフトウェア連合sidechainソフトウェアは検索された機密トランザクション [ref] Confidential Transactions、ElementsProject.org以前の箇条書きで説明したChaumian銀行の利点と同じものを多く提供していますが、連合したサイドチェーンソフトウェアは他の多くの機能もサポートしています（また、サポートしています）。[ref>：https：// 2018-01-28 </ ref> /elementsproject.org/elements/ Elements（features）]、ElementsProject.org、retrieved 2018-01-28 </ ref>

参考文献[編集]

<リファレンス/>

  1. ↑ 引用エラー: 無効な <ref> タグです。 「mempool-fee-est-.E3.82.B9.E3.83.A9.E3.82.A4.E3.83.89」という名前の引用句に対するテキストが指定されていません
  2. ↑ 引用エラー: 無効な <ref> タグです。 「mempool-fee-est-video」という名前の引用句に対するテキストが指定されていません
「http://tezos-wiki.jp/wiki/index.php?title=Techniques_to_reduce_transaction_fees&oldid=20327」から取得