Miner's (commonly spelled "miners") fee is normally required by the bitcoin miner to process the transfer of bitcoins from one address to another.

By default there are two "tiers" of fees, depending on whether bitcoin is used or not: When a transaction uses bitcoins (e.g. when one is using BTC to buy XCP): this transaction is said to contain BTC_Pay and the fee is referred to as "fee provided" and goes to bitcoin miners. (Notice: As of Nov 5, 2014, BTC Pay has been disabled, but the fees are still payable the same way if BTC is traded on the DEx using counterpartyd.)When a transaction does not involve bitcoins (the currency), then the fee is approximately 0.0002 BTC (this can vary depending on the transaction size which in turn is impacted by the number of inputs). If, for example, you're buying or selling a Counterparty asset for XCP or another Counterparty asset such transaction will use Bitcoin (the protocol), but not bitcoin (the currency).

When you are selling BTC on the Counterparty Distributed Exchange (DEx) the default fee charged to the seller (fee_provided) is set to 1% and it is not recommended to make it lower because it can easily impact your order matching. When the fee provided is too low, BTC buyers who filter out BTC sellers unwilling to show a commitment to the transaction will not be matched with such BTC sellers. Matching one's offers with "troll orders" would result in wasted time and fees (0.0002 fees + 2 * 0.0000078 BTC) for the buyer of BTC.

Redeemable fee is the dust amount used to embed data (Counterparty tokens stored on the blockchain, price, and so on) in multisig output.

On the bitcoin blockchain, CHECKMULTISIG opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:

In the multisig transaction example (taken from bitcoin testnet) below we can see these redeemable amounts as well as miners' fee (in this case it's 0.0002 BTC which tells us that it's a transaction that does involve bitcoin).

Expanded CHECKMULTISIG code from above transaction looks like this (note that this example is 1-of-2, which is the initial multisig implementation in Counterparty):

As you can see each multisig output has 2 "destinations": the source address (here mqPCfvqTfYctXMUfmniXeG2nyaN8w6tPmj), and a fake address to embed the data. There is no private key for the fake address, so only the source address can redeem the fund. Later 1-of-3 will be available as well, but there will always be 2 "fake" addresses with embedded data, and one for the source address, so multisig outputs will be always redeemable only by the source address.

Redeemable fee can be collected by a tool such as one below. There is no time limit for this optional activity - unspent dust transaction outputs can be redeemed (sweeped) as long as the sender has control over that address and Bitcoin is up and running.

If one sends a Counterparty-based token to another address and inspects the transaction on the blockchain, it may become clear that such transaction also contains a dust amount of BTC - e.g. 0.0000547 BTC (5470 satoshi)).

This fee is the minimum amount (dust amount) required for the miners to process transaction.

Unlike the made up addresses (to which 0.000078 BTC is sent) used in Counterparty protocol escrow, this transaction, which carries a Counterparty asset or token to its destination, must be processed so it must have the minimum (=>5430 satoshi) amount of BTC.

Also unlike in the "fake" escrow transactions, Counterparty or the sender do not know the private key that belongs to the destination address, so this amount is not redeemable by the sender and can be swept only if the sender also controls the destination address.