Propagation of these kinds of transactions will be hampered until becomes 10%+ of the network or so, like any other policy relaxation. On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH wrote: > I am reading between the lines, wouldn't that mean an older client like > v0.18 may not be able to receive a transaction from a newer client if it > has to validate 85 non-witness serialized bytes? If so we should not > concern but retain the backward compatibility especially since this was for > a vulnerability? I have not checked to code to see what it does. > > KING JAMES HRMH > > Get Outlook for Android > ------------------------------ > *From:* bitcoin-dev on > behalf of Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> > *Sent:* Tuesday, October 11, 2022 11:50:07 PM > *To:* Bitcoin Dev > *Subject:* [bitcoin-dev] Relaxing minimum non-witness transaction size > policy restriction > > Hello fellow Bitcoiners, > > After looking at some fairly exotic possible transaction types, I ran into > the current policy limit requiring transactions to be 85 non-witness > serialized bytes. This was introduced as a covert fix to policy fix > for CVE-2017-12842. Later the real motivation was revealed, but the > "reasonable" constant chosen was not. > > I'd like to propose relaxing this to effectively the value BlueMatt > proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would > allow a single input, single output transaction with 4 bytes of OP_RETURN > padding, rather than padding out 21 bytes to get to p2wpkh size. > > The alternative would be to also allow anything below 64 non-witness > bytes, but this seems fraught with footguns for a few bytes gain. > > The PR is here with more relevant background and alternatives included in > the thread: > https://github.com/bitcoin/bitcoin/pull/26265 > > Please let us know if there's a fundamental issue with this approach, or > any other feedback. > > Best, > Greg >