This guide will walk you through the various types of transactions you can make using Samourai Wallet, when they are best used, and how they work under the hood.
UTXOs are grouped by address type (P2PKH
, P2SH-P2WPKH
, or P2WPKH
).
For a group to be considered the total value of the group must be greater or equal to twice the amount being sent.
If a group exists with the same address type as the address that is being spent to it is selected. If the above condition is not met, then a group with a different address type is selected. If a single group isn’t enough to cover the total value requirement, a second group will be selected.
Transaction composition is arranged by “sets”.
Set A
contains the actual spend output and a change output.
Set B
contains a “mix” output in the same amount and the same address type as the spend output and a change output.
The change outputs in each set use the same address type as the UTXO(s) for that set. The miner’s fee amount must be an even amount. Each set pays half of the miner’s fee by deducting exactly 50% from each change output.
The technical conditions for building a STONEWALLx2 is the same as a STONEWALL
Or a T1 transaction corresponding to a classic payment (ex: payment of 9BTC by userA to userB)
9 (B)
(A) 10 =
1 (A)
T1 can be obfuscated in a T2 transaction in which userB contributes one or more inputs from which it collects the amount
(A) 10 11 (B)
=
(B) 2 1 (A)
The entropy of obfuscated transactions is most of the time zero, with the exception of specific combinations.
(assumption: no intrafee paid in these transactions)
(A) 10 9.5 (B)
= E (Tx) = 0
(B) 0.5 1 (A)
(A) 10 10 (B)
= E (Tx) = 1
(B) 1 1 (A)
(A) 10 14 (B)
= E (Tx) = 0
(B) 5 1 (A)
(A) 10 18 (B)
= E (Tx) = 0
(B) 9 1 (A)
(A) 10 20 (B)
= E (Tx) = 0
(B) 11 1 (A)
Although the entropy is identical, there is a difference between the following scenarios
(A) 10 9.5 (B)
=
(B) 0.5 1 (A)
In this scenario, the input contributed by B is superfluous.
This is true whether we consider 9.5 or 1 as the amount paid or the change.
If we consider that most wallets implement selection algorithms aimed at reducing the number of inputs, this form produces a specific imprint making it possible to distinguish a nested samurai transaction.
(A) 10 14 (B)
=
(B) 5 1 (A)
In this scenario, the input contributed by B does not appear to be superfluous.
On the contrary, he suggests that all the inputs were necessary to reach a payable amount of 14BTC.
However, the result obtained with this constraint deteriorates when the amount of the exchange is greater than the amount paid:
(A) 10 6 (B)
=
(B) 5 9 (A)
In this case, the input contributed by B again appears to be superfluous.
(A) 10 19 (B)
=
(B) 10 1 (A)
(A) 10 11 (B)
=
(B) 10 9 (A)
IF amount (payment)> amount (change) THEN
amount (inputs_payee)> amount (change)
IF amount (payment) <amount (change) THEN
amount (inputs_payee)> = amount (change)
Certain general rules applied by Samourai for the selection of inputs should also be respected:
ex: paying or paying should not contribute 2 inputs from the same transaction
On the other hand the rule of selection of all the inputs "controlled" by an address * must not be used *.
Indeed, by using the utxos controlled by the same address within different nested txs, we maximize the over-clustering by the analysis tools. In fact, we should perhaps even prioritize the selection of such utxos for the construction of nested txs.
This scheme allows:
In return, it reveals which output is the payment and which output is the exchange.
The protocol between the payee and the payee should include protection mechanisms to avoid:
If a protocol is implemented to support this scheme, it is likely that we could make it a variant aiming to build boltzman spends rather than nested / embedded transactions. This could go in the direction of having a tool increasing the deniability of boltzman spends (at least in terms of monitoring tools).