Open Dawn-githup opened 3 months ago
The current logic of the sendRbf()
API suggests that when the changeIndex
is specified, the change satoshi should always be returned to the original change address from the original transaction, which makes sense because it's how the original transaction was intended. Ref: https://github.com/ckb-cell/rgbpp-sdk/blob/develop/packages/btc/src/api/sendRbf.ts#L82-L88
if (changeAddress && changeAddress !== outputs[changeIndex].address) {
throw TxBuildError.withComment(
ErrorCodes.INVALID_CHANGE_OUTPUT,
`The address of outputs[${changeIndex}] does not match the specified changeAddress, expected: ${changeAddress}, actual: ${outputs[changeIndex].address}`,
);
}
However, from another perspective, if the RBF transaction is sponsored by another address, it is also reasonable to return the change to the RBF sponsor instead of the original change address, since the RBF sponsor may provide a large UTXO to the RBF transaction. In this situation, by removing the restriction for the changeAddress
option when changeIndex !== undefined
, users can freely decide which address the change should be returned to.
Worth mentioning, though, the RBF transaction can be fairly complex:
However, from another perspective, if the RBF transaction is sponsored by another address, it is also reasonable to return the change to the RBF sponsor instead of the original change address, since the RBF sponsor may provide a large UTXO to the RBF transaction.
Usually, the RBF sponsor
and the original change address
are managed by the same private_key. I thought they belongs to one user.
Another option is to do nothing about it, because the restriction mentioned above only applies when changeIndex
is not undefined. This means if the user leaves the changeIndex
option empty, then the changeAddress
option is customizable, and the change satoshi of the RBF transaction can be returned to the RBF sponsor.
Basically the restriction ensures that the change output to the original change address exists in the RBF transaction.
Description
Currently, when
changeIndex
is not null, the change in satoshis is returned to:changeAddress
, ifchangeAddress
is not null.This works fine for single addresses but seems a bit odd when dealing with mixed address UTXOs.
Example Scenario
Let's illustrate with a real-world example:
Problem
In the context of UTXOs, if the borrowed 50-unit note is from a different address (mixed address UTXO), the system should be able to handle this by correctly returning the change to the lender’s address.
Proposal
To handle this scenario effectively, we suggest discussing whether to remove the restriction on
changeAddress
. This would allow the system to dynamically allocate the change to the appropriate address based on the UTXOs involved.This adjustment will ensure that the returned change correctly reflects the source addresses, thereby improving the handling of mixed address UTXOs.