Is Appendix E of the spec (fees) still correct after the Bitcoin 0.9 fee changes?
ripper234 opened this issue · 8 comments
There was the recent x10 fee drop in Bitcoin 0.9. Is the Append E in our spec that estimates the approx fees in BTC (and USD) still correct? Can we save our users a bunch of money by lowering the transaction fees in the various Mastercoin implementations?
@petertodd can you shed some light on this?
Unfortunately the majority of the cost of an MP message lays in the outputs
rather than mining fee. Dust hasn't changed so those minimums can't change
either.
It is feasible to consider reducing the mining fee though I have concerns
(suspicions) around deprioritization of MP messages by some parties/pools
already occurring and I'd like to see some healthy testing on lower fee
transactions.
Note for a long time I've been a proponent of dropping the Exodus output
(using an alt method for MP message identification) which a) reduces fees
by .00005460 but also b) removes an easy censorship vector - we put so much
effort into obfuscation in class B and then hang an Exodus tag on the front
door as it were - kind of ironic if you ask me :P
Thanks
Zathras
On May 17, 2014 1:28 PM, "Ron Gross" notifications@github.com wrote:
@petertodd https://github.com/petertodd can you shed some light on this?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/167#issuecomment-43396426
.
Here is some light: the minrelayfee is what is used as basis to determine, if the output value is too low and the transaction is considered as dust. Since 0.9 this number was indeed cut by a factor of 10 in the reference client which means 0.00000564 BTC is enough. I'm running that number (well, slightly more) since yesterday on the faucet and the results are not really satisfying. Transaction confirmations are significantly delayed, at least that's my impression. Since they are eventually confirming I'll continue to do so over the next days to get a greater sample set. This is related to min. output amounts, not the transaction fee - which was not reduced.
See: https://github.com/bitcoin/bitcoin/blob/master/src/core.h#L151
If you want to lower MSC costs, one way could be to move the marker (Exodus) to OP_RETURN or somewhere else and transform receiver references into data packages which are redeemable by the sender. Not a light change though.
I know this is about reducing fees, so I may be off. However, I'm with @zathras-crypto here. I do have confirmation that some pools are censoring/deprioritizing MP messages. If @dexX7 is able to run some more sampling, it might help clarify whether this is indeed the case, but if we can remove censorship vectors, we will also disrupt the ability to easily filter MP messages. If this results in lower fees to the protocol, then even more wins.
I named OP_RETURN as example, but actually this would make it a lot more difficult for mastercoin-tools and sx which is able to list transactions associated with an address (or pay-to-pubkeyhash output), but not other output types. This was more about thinking about the future.
Nevertheless, I lowered the amounts to the absolute minimum and they are relayed without a problem.
Also FYI, to have it have some numbers:
Fee: RoundUp(tx size / 1000 byte) * 0.0001, so usually 0.0001 BTC
Minimum output amounts: 3 * (148 + output size) * 0.00000001, that is:
Pay-to-pubkey-hash (34 byte): 0.00000546 BTC
Multisig, two compressed public keys (80 byte): 0.00000684 BTC
Multisig, one compressed, one uncompressed public key (112 byte): 0.00000780 BTC
Multisig, three compressed public keys (114 byte): 0.00000786 BTC
Multisig, one uncompressed, two compressed public keys (146 byte): 0.00000882 BTC
Output amounts are x 10 for < v0.9, so 0.0000546 BTC for standard outputs
and 0.0000684-0.0000882 BTC for data outputs.
TL;TR: Even without the 0.9 patch we are overpaying multisig outputs which are appearingly not twice as expensive as standard outputs.
Alright, thanks everyone, I'm closing this question as answered.
Might be reopened. Even though the question is answered, the spec still needs to be adjusted.
Right :)