On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev < [email protected]> 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
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
