Pay Transaction Fees with Different Inputs (Multiple Source Addresses)

[mtbitcoin]

At the moment the bitcoin transaction fees have to come from the "source" address unspent outputs.

Are there plans to allow payment of bitcoin transaction fees using a non source address.? This would reduce the number of transactions required to consolidate balances from a large list of addresses.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7916710-pay-transaction-fees-with-different-inputs-multiple-source-addresses?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F494307&utm_medium=issues&utm_source=github).

[adamkrellenstein]

Yes. The question is how we'll allow transactions with multiple sources to be parsed. This is a low-level protocol feature, and a potential security issue.

[mtbitcoin]

One way I see this is to create an option for specifying a "-feesource" address and use just that address outputs for the fee, its probably more straightforward this way.

Right now if counterparty is used for token payments/tickets/coupouns, etc, there is a need to topup the new address with some dust BTC first to cover transaction fees when consolidating the token. This option however reduces the number of transactions and time required.

The recently launched getgems also faced a similar issue with the tokens because new users that had received the GEMZ tokens were unable to spend it because they had no BTC on their addresses . An option for specifying different source address could allow an operator/wallet to bear the transaction fees while still allowing end users full control of their private keys. There are other use cases, but these are the obvious ones that I see

[SouKw]

What is the security issue? Why does the BTC fee have to come from the same address as the address sending XCP?

[mtbitcoin]

@SouKw I don't think it's so much a security issue but the complexity and additional testing required to make sure this works correctly

[adamkrellenstein]

Yep On Jan 21, 2015 8:43 AM, "Matt" notifications@github.com wrote:

@SouKw https://github.com/SouKw I don't think it's so much a security issue but the complexity and additional testing required to make sure this works correctly

— Reply to this email directly or view it on GitHub https://github.com/CounterpartyXCP/counterpartyd/issues/649#issuecomment-70838337 .

[karlkeefer]

This would be pretty awesome - we are using tokens in HD wallets so managing the dust for sends adds a lot of complexity to certain operations

[ninjaboon]

would love to see this feature implemented.

[gemamegantara]

i agree for the implementation of this feature, we have the same problem with mtbitcoin. our new users who got promotional token/asset in our platform cant spend their asset, because their newly created bitcoin address does not have any bitcoin for it to pay for the tx fee.

i was wondering whether anyone have a work around for this? appreciate it.

[mtbitcoin]

The workaround is to pre-fund the addresses with some dust when you send the tokens over...

Which bring us to the next feature request of being able to also send btc over during an an asset send.

At the moment, what you can probably do is to break it up into two transactions. One an asset send and the other a btc send with some "dust btc" to cover the initial transactions. This is your workaround for now because its unlikely that these new features will make it before the "hackaton" deadline :-)

[adamkrellenstein]

You can already send over as much BTC as you want along with the asset send. Set --regular-dust-size=$amount.

[mtbitcoin]

Thanks Adam! Great to know that is now possible, but is this also available via the APIs. (i.e create_send) or is this a "hard feature" for all SEND transactions when activated?

http://counterparty.io/docs/api/#create_send

[deweller]

Yes. This is available via the API. I use it all the time for custom dust sizes.

Use regular_dust_size when passing it in via the API (just as it is listed at http://counterparty.io/docs/api/#create_send)

[mtbitcoin]

Ahh.. But I am not seeing this in the docs (http://counterparty.io/docs/api/#create_send) though

[deweller]

You're right - regular_dust_size is missing from the official docs.

Feel like making a pull request? :smile:

[mtbitcoin]

Sure, will try to do the pull request :-) .. whats the default "regular_dust_size" ? And is this specified in decimal or integer value ? for example to send 0.1 btc over is that denoted as 10000000 or 0.1?

[deweller]

Here are the 3 relevant settings:

fee_per_kb
regular_dust_size
multisig_dust_size

And here are the defaults (in satoshis)

DEFAULT_FEE_PER_KB = 10000
DEFAULT_REGULAR_DUST_SIZE = 5430
DEFAULT_MULTISIG_DUST_SIZE = 7800

Note that multisig_dust_size doesn't apply to OP_RETURN transactions which are the default type used for sends now.

[unsystemizer]

@deweller do recent changes change anything related to this issue?

[longhoangwkm]

@deweller Does this feature is finished ?!, l got this problems too Pay Transaction Fees with Different Inputs (Multiple Source Addresses)

[adamkrellenstein]

Related to https://github.com/CounterpartyXCP/counterparty-core/issues/2162