Propagation of these kinds of transactions will be hampered until <merge version in core> becomes 10%+ of the network or so, like any other policy relaxation.
On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH <willt...@live.com.au> 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 <https://aka.ms/AAb9ysg> > ------------------------------ > *From:* bitcoin-dev <bitcoin-dev-boun...@lists.linuxfoundation.org> 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 <bitcoin-dev@lists.linuxfoundation.org> > *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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
