Results: confirmation delays with lower output amounts

[de...@bitwatch.co]

Hey all,

in May Ron asked, if appendix E of the spec (fees) is still correct
after Bitcoin Core v0.9 was released.

One of the significant changes was a new default value of the
"minrelayfee" which basically was reduced by a factor of 10. This does
not affect transaction fees, but has an effect on the so called "dust"
threshold which relates to the minimum amounts required for transaction
outputs.

Back in May I started an experiment and took a closer look at what
actually happens under the hood in Bitcoin Core and adopted the minimal
amounts which should be accepted by newer Core clients.

Since then and over the course of about 250 transactions I used the
Mastercoin Faucet to collect data and here are the results:

https://docs.google.com/spreadsheets/d/1FOvhNdC8XZtW_2TC36WRzZCJYIY4EeEChMsULY5urJk/edit?usp=sharing


Every transaction was a class B encoded "simple send" transaction which
mostly used output amounts between 0.00000546-0.00000684 BTC.

It looks like the new amounts are finally accepted by the network on a
broader scale and I conclude it's safe to adopt the following lower
output amounts:

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

As of now, most clients seem to use amounts between 0.0000546-0.00018
BTC, depending on what kind of output is used, so - at least in relation
to output amounts - the cost can be cut by a factor between 10x - 20.4x. (!)


The original thread with some additional information can be found here:

https://github.com/mastercoin-MSC/spec/issues/167#issuecomment-43412342


Cheers!

[zathras crypto]

Nice work Dexx, good to know that the network is getting broader support for the lower fees :)

I'd suggest a staged migration to lower fees, perhaps Omni (since 'Chest wallet is dead) could offer a 'high priority' checkbox to use higher fees and default to this for time sensitive transactions (such as DEx payments and crowdsale purchases etc)...  Everything else can default to the lower fee...  Just a thought :)

Thanks

Z

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@mastercoin.org.

[de...@bitwatch.co]

Yeah, that's a good idea. Especially DEx related transactions should be issued in a way to confirm as fast as possible.

Related to the data I should have made the following two things right from the start:

1. The faucet sends one MSC and one TMSC transaction at the same time. Would have been perfect for a comparison - one uses reduced amounts, the other not.
2. Log blockheight at broadcast right from the beginning.

Nevertheless, it looks like mid June was a significant turning point.

Next experiment in the queue:

Adopt non-rounded fees - currency transactions are sent with a fee of 0.0001 BTC/1000 byte transaction size whereby this number is rounded up. For example a "simple send" transaction with a size of 340 byte still uses 0.0001 BTC. This was also changed recently - not sure, if it's only adopted on the Bitcoin Core master branch or already made it into a release, but the new change would allow to use a transaction fee of only 0.000034 BTC (factor 3x cheaper).

Will become even more interesting, when "smart fees" are fully adopted:

https://bitcoinfoundation.org/2014/07/07/floating-fees
https://github.com/bitcoin/bitcoin/pull/4250