On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell <gmaxw...@gmail.com> wrote:
> An example would
> be tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size -
> 3*utxo_consumed_size).
This could be implemented as a soft fork too.
* 1MB hard size limit
* 900kB soft limit
S = block size
U = UTXO_adjusted_size = S + 4 * outputs - 3 * inputs
A block is valid if S < 1MB and U < 1MB
A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
size of 252 bytes.
The memory pool could be sorted by fee per adjusted_size.
Coin selection could be adjusted so it tries to have at least 2 inputs
when creating transactions, unless the input is worth more than a threshold
(say 0.001 BTC).
This is a pretty weak incentive, especially if the block size is
increased. Maybe it will cause a "nudge"
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
