Mcore floating output amounts

[dexX7]

Replaces #66 with an up-to-date version.

---

1. GetDustLimit(const CScript&) is used instead of MP_DUST_LIMIT. See 426592e for additional details.
2. nMinRelayTxFee was set to 1001 which results in output amounts of:
   • 552 (pay-to-pubkey-hash)
   • 685 (multisig, two compressed public keys)
   • 781 (multisig, one uncompressed, one compressed public key)
   • 787 (multisig, three compressed public keys)
   • 883 (multisig, one uncompressed, two compressed public keys)

Set this value to 10000 to mirror the old "6000 / packet rule" with slightly tighter (and more accurate) amounts.

The default value was set to 1000 back in November 2013, so this amount should be safe. +1 Satoshi is used as marker. Increment further, if a new marker is needed.

The minrelaytxfee can be set via bitcoin.conf or startup parameter. Note: minrelaytxfee=0.00001001 in decimal form must used! Verify via getinfo and look out for relayfee.

1. DEFAULT_TRANSACTION_FEE was set to 10000 from 0.

This simply mirrors the actual default value and has no effect, unless the mintxfee is overwritten. In this case all it does is to act as safeguard for the case that only mintxfee was set and paytxfee was forgotten.

---

Get minimum output amount to be spent by an output based on scriptPubKey size in relation to the minimum relay fee.

The minimum relay fee can be defined as command-line argument -minrelayfee=<amount> or minrelayfee=<amount> in bitcoin.conf.

As per default minrelayfee=0.00001 is used which results in the following dust limits:

• 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

Related:

• core.h: bool IsDust(int64_t nMinRelayTxFee)
• init.cpp: int64_t CTransaction::nMinRelayTxFee

[ghost]

I think these fees are too low, as per your analysis:

CHA reduced output amounts as well as fees. I'm unsure, if a sample size
of 2.1k is sufficient, but you're right. Those 20 min on average equal
roughly 2.5 confirmations. Unanswered (at least for me): is a fee of
0.0001 sufficient to push the average down by 2.5x? I'm really unsure.
Anyway, I rather think of this as something experimental for cost savers.

This pull request should include an option to use classB_send with the lowered fees, and by default the lower fees should not be enabled, since it delays (in your own words) transactions by 2.5x the normal network speed

Just my 0.02B

[ghost]

Sorry, I'll be clear, I think that there needs to be an explicit choice made to use GetDustLimit versus the standard MP_DUST_LIMIT, since one causes transactions to be accepted more slowly by the network (on average)

[dexX7]

This does not affect transaction fees, but output amounts and it does not introduce a delay. Minimum output amounts and transaction fees are two different topics.

You might differentiate between pre Nov 2013 values and post Nov 2013 values, so let me outline this a bit.

There are basically two levels:

• Before Nov 2013 an output needed to be greater than 0.0000564-0.0000882 BTC, depending on the output type, otherwise the transaction would have been considered as dust. The minimum amount for multisig outputs was 0.0000684 BTC.
• After this commit the minimum requirement dropped by a factor of 10x to 0.00000564-0.00000882 BTC.

The dust check can be found in core.h - IsDust(nMinRelayTxFee).

The crucial part is that the static dust value is currently set to 0.00005678 BTC, so it's already lower than the threshold used before Nov 2013. This means it's perfectly safe to use the lower range of that level, namely values between 0.00000564-0.00000882 BTC - it doesn't make any difference.

The dynamic amount adjustment makes sure you don't end up with 0.00000564 where 0.00000882 are required. But nevertheless, if a static value is prefered, then I suggest to set this value to somewhere around 0.00000882 BTC which is the maximum amount we'll ever need (with multisig).

Again, just to be clear.. ;) (it sounds too good to be true, huh? :P) ... there is no difference between the current static value of 0.0005678 BTC and 0.00000882 BTC, besides a side-effect free cost reduction of about 6.4x.

Edit: the tip of the iceberg is that early Mastercoin clients were running with values of 0.0000543 BTC, sligthly below the actual treshold of before Nov 2013 as well. Even back at that time it would have been safe to use those lower numbers.

[ghost]

6.4x is a pretty slick ratio, ++ on this to be merged

[m21]

@dexX7 all merged in, some manual tweaks -- please review the pull when you get around to it, thanks !

[m21]

@zathras-crypto
Just merged - dynamic output amounts; thus another concern I got, related to the parser - surprise! :)

http://tbtc.blockr.io/tx/info/a85b08df223f5e45250513abad305bf9a234baafcfa9e7f82ed9d4fcd04f42f7
In this TX output amounts in multisig chunks are 685, but the marker's and reference amounts are both 547.

See my concern? Right now I'll push a change to go with the fixed amount for all output types, until you and I analyze the parser & spec once again...

[dexX7]

@m21: What's the problem with that transaction? Edit: I think this was the misunderstanding. - Different amounts are a feature, not a bug. ;)

You don't need to spend as much for a pay-to-pubkey-hash output as for a multisig output. The dust or threshold value is based on size of the output whereby the nMinRelayTxFee acts as modificator. I posted a few values for different output types in the first post.

In a post you mentioned that you like the static number due to it's ability to act as marker, in the sense of "this is core version x, because the amount is y". Because the output amounts are not fixed, but based on size, my idea was to sligthly change the nMinRelayTxFee to yield a different set of amounts, so the ability to identify versions remains.

The nMinRelayTxFee can be hardcoded in main.cpp or set via the config or startup parameter -minrelaytxfee=<amt>. In code the value is defined in Satoshi while the config uses decimal numbers. Default value is 1000 Satoshi or 0.00001 BTC.

This basis for all this is IsDust(nMinRelayTxFee) in core.h which ultimately determines, if a transaction is dropped, because it's dust and the output values are too low.

[m21]

Thanks @dexX7 . The parser(s) may use output amounts within the TX to find the reference, for instance.
Sometimes the fallback mechanism is to match up the output amount to Exodus (marker) with the others. It is possible that we don't have an issue since pertinent non-multisig outputs receive same amount vs chunks of multisig. But want to run this concern by the guys, better be safe than sorry.

Edit: I understand about using the Core to determine the min dust for each type of Bitcoin output, it is very nice. My concern is confusing MasterProtocol parser(s).

[dexX7]

Aah, I see.

The class B multisig scheme has strict rules related to input, marker, reference and data identification and does not depend on amounts. This is only done in some cases in class A non-multisig parsing as last chance, if identification by sequence numbers fails.

Here are two examples:

0d5bff910edbe301837bb6a199878071cce45a5662e82e2df4d4310753271ea6 on blockchain.info
0d5bff910edbe301837bb6a199878071cce45a5662e82e2df4d4310753271ea6 on masterchest.info
0d5bff910edbe301837bb6a199878071cce45a5662e82e2df4d4310753271ea6 on omniwallet.org

294c48b76ec419cea34e1b404d2dafe62da52f4304d0cc6169e2d85d2c940ea4 on blockchain.info
294c48b76ec419cea34e1b404d2dafe62da52f4304d0cc6169e2d85d2c940ea4 on masterchest.info
294c48b76ec419cea34e1b404d2dafe62da52f4304d0cc6169e2d85d2c940ea4 on omniwallet.org