{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-20\n📝 Original message:On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e This could render transactions with a locktime in the future as\n\u003e unspendable.\n\u003e\n\u003e It is pretty low probability that someone has created a \u003e100kB locked\n\u003e transaction though.\n\u003e\n\u003e It violates the principle that no fork should render someone's coins\n\u003e unspendable.\n\u003e\n\nMmmm.... you'd have to:\n\na) Have lost or thrown away the keys to the unspent transaction outputs\nb) Have created a locktime'd transaction with a lock time after the\nBIP100/101 switchover times\nthat is more than 100,000 bytes big\nc) Have some special relationship with a miner that you trust to still be\naround when the transaction\nunlocks that would mine the bigger-than-standard transaction for you.\n\nI don't think adding extra complexity to consensus-critical code to support\nsuch an incredibly unlikely\nscenario is the right decision here. I think it is more likely that the\nextra complexity would trigger a bug\nthat causes a loss of bitcoin greater than the amount of bitcoin tied up in\nlocktime'ed transactions\n(because I think there are approximately zero BTC tied up in \u003e100K\nlocktime'ed transactions).\n\n\nRE: limit size of transaction+parents:  Feature creep, belongs in another\nBIP in my opinion. This one\nis focused on fixing CVE-2013-2292\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/05a16bf2/attachment.html\u003e"}