Rename to additionalfeeoutputindex and maxadditionalfeecontribution

This commit is contained in:
nicolas.dorier 2020-05-17 19:58:17 +09:00
parent c33f0759d6
commit 24dd275445
No known key found for this signature in database
GPG Key ID: 6618763EF09186FE

View File

@ -174,14 +174,14 @@ The sender should check the payjoin proposal before signing it to prevent a mali
* Check that the sender's inputs' sequence numbers are unchanged.
* If the sender's inputs' sequence numbers the homogenous, check that the receiver's contributed inputs match those.
* Check that the sender's own outputs have not been modified, except for paying increased fee, or by simple shuffling.
* If sender specified <code>feebumpindex=</code> (see later), the fee should have been subtracted from the output at the same index in the original PSBT.
* If sender specified <code>additionalfeeoutputindex=</code> (see later), the fee should have been subtracted from the output at the same index in the original PSBT.
* Check that the sent amount in the payjoin proposal is less than or equal to the sent amount of the original transaction. (Defined as the sum of the inputs' value to be signed minus the sender's ouput change)
If the sent amount in the payjoin proposal is above the amount sent in the original PSBT
* Check that the additional paid amount has been add paid to the fee.
* Check that the estimated fee rate of the payjoin proposal is not more than the fee rate of the original PSBT. (fee estimation is hard, so we should allow ~2 satoshi per inputs as margin of error)
* If <code>maxfeebumpcontribution=</code> was specified, check the additional paid amount is less than or equal to this amount.
* If <code>maxfeebumpcontribution=</code> was not specified, the sender's software should ask an interactive confirmation to the user.
* If <code>maxadditionalfeecontribution=</code> was specified, check the additional paid amount is less than or equal to this amount.
* If <code>maxadditionalfeecontribution=</code> was not specified, the sender's software should ask an interactive confirmation to the user.
The sender must be careful to only sign the inputs that were present in the original PSBT and nothing else.
@ -212,13 +212,13 @@ If the receiver does not support the version of the sender, they should send an
}
</pre>
* <code>feebumpindex=</code>, the preferred output from which to increase the fee for the added inputs. (default: <code>-1</code>)
* <code>additionalfeeoutputindex=</code>, the preferred output from which to increase the fee for the added inputs. (default: <code>-1</code>)
If the <code>feebumpindex</code> is out of bounds or pointing to the payment ouptut meant for the receiver, the receiver should ignore the parameter.
If the <code>additionalfeeoutputindex</code> is out of bounds or pointing to the payment ouptut meant for the receiver, the receiver should ignore the parameter.
* <code>maxfeebumpcontribution=</code>, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. <code>maxfeebumpcontribution</code> must be ignored if set to less than zero. (default: -1)
* <code>maxadditionalfeecontribution=</code>, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. <code>maxadditionalfeecontribution</code> must be ignored if set to less than zero. (default: -1)
Note that if <code>maxfeebumpcontribution</code> is too low, the sender should create a transaction with RBF disabled, as the original transaction could replace the payjoin transaction.
Note that if <code>maxadditionalfeecontribution</code> is too low, the sender should create a transaction with RBF disabled, as the original transaction could replace the payjoin transaction.
==Rationale==