<div dir="ltr">A standard transaction is 225 bytes, leading to a savings of 8.6%.<div><br></div><div>However, that is essentially the minimum saving. For other sizes (eg, 10 outputs) which seem to be pretty frequent savings can be greater.</div><div><br></div><div>Furthermore, it is important to note that this is a memory saving for the UTXO pool so the reduction there is more (not super familiar with how the UTXO pool is stored, but it should be a better savings than 8.6%). <br><div><br></div><div><br></div></div><div>Does anyone have the tools currently to be able to easily run through the chain and analyze the impact of this change on historical data more directly?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
Quoting Gavin Andresen via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also requires most clients to be updated to support the new address<br>
system.<br>
</blockquote>
<br>
<br>
That's the killer: introducing Yet Another Type of Bitcoin Address takes a<br>
very long time and requires a lot of people to change their code. At least,<br>
that was the lesson learned when we introduced P2SH addresses.<br>
<br>
I think it's just not worth it for a very modest space savings (10 bytes,<br>
when scriptSig+scriptPubKey is about 120 bytes), especially with the<br>
extreme decrease in security (going from 2^160 to 2^80 to brute-force).<br>
<br>
--<br>
--<br>
Gavin Andresen<br>
</blockquote>
<br></div></div>
I think it would only save ~5% with all overhead (value, sequence, locktime, version, etc.) counted<br>
<br>
A better way is to introduce shorter ECDSA keys, which will save a lot of space for public key and signature. It is safe as long as the output value is much lower than the cost of attack.<br>
<br>
If this happens, I think it will be part of the OP_MAST which will require a new address type anyway.<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>