<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>This could render transactions with a locktime in the future as unspendable.<br><br></div><div>It is pretty low probability that someone has created a &gt;100kB locked transaction though.<br><br></div><div>It violates the principle that no fork should render someone&#39;s coins unspendable.<br></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Mmmm.... you&#39;d have to:</div><div class="gmail_extra"><br></div><div class="gmail_extra">a) Have lost or thrown away the keys to the unspent transaction outputs</div><div class="gmail_extra">b) Have created a locktime&#39;d transaction with a lock time after the BIP100/101 switchover times</div><div class="gmail_extra">that is more than 100,000 bytes big</div><div class="gmail_extra">c) Have some special relationship with a miner that you trust to still be around when the transaction</div><div class="gmail_extra">unlocks that would mine the bigger-than-standard transaction for you.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don&#39;t think adding extra complexity to consensus-critical code to support such an incredibly unlikely</div><div class="gmail_extra">scenario is the right decision here. I think it is more likely that the extra complexity would trigger a bug</div><div class="gmail_extra">that causes a loss of bitcoin greater than the amount of bitcoin tied up in locktime&#39;ed transactions</div><div class="gmail_extra">(because I think there are approximately zero BTC tied up in &gt;100K locktime&#39;ed transactions).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">RE: limit size of transaction+parents:  Feature creep, belongs in another BIP in my opinion. This one</div><div class="gmail_extra">is focused on fixing CVE-2013-2292</div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>