rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-07-20 📝 Original message:On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > This could render transactions with a locktime in the future as > unspendable. > > It is pretty low probability that someone has created a >100kB locked > transaction though. > > It violates the principle that no fork should render someone's coins > unspendable. > Mmmm.... you'd have to: a) Have lost or thrown away the keys to the unspent transaction outputs b) Have created a locktime'd transaction with a lock time after the BIP100/101 switchover times that is more than 100,000 bytes big c) Have some special relationship with a miner that you trust to still be around when the transaction unlocks that would mine the bigger-than-standard transaction for you. I don't think adding extra complexity to consensus-critical code to support such an incredibly unlikely scenario is the right decision here. I think it is more likely that the extra complexity would trigger a bug that causes a loss of bitcoin greater than the amount of bitcoin tied up in locktime'ed transactions (because I think there are approximately zero BTC tied up in >100K locktime'ed transactions). RE: limit size of transaction+parents: Feature creep, belongs in another BIP in my opinion. This one is focused on fixing CVE-2013-2292 -- -- Gavin Andresen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/05a16bf2/attachment.html>