Relaxing minimum non-witness transaction size policy restriction

Relaxing minimum non-witness transaction size policy restriction
[not found] ` <PS2P216MB1089C3131115B700C840BEFB9D239@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
  2022-10-20 23:21 ` Peter Todd
  
From: Greg Sanders @ 2022-10-11 12:50 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1271 bytes --]

 permalink raw reply	[|nested]
[not found] ` <PS2P216MB1089C3131115B700C840BEFB9D239@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>

  
From: Greg Sanders @ 2022-10-11 13:14 UTC (permalink / raw)
  To: KING JAMES HRMH;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

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 <willtech@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-bounces@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
>

[-- Attachment #2: Type: text/html, Size: 3527 bytes --]

 permalink raw reply	[|nested]
2022-10-11 12:50 [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction Greg Sanders
       [not found] ` <PS2P216MB1089C3131115B700C840BEFB9D239@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>

  2022-10-21  0:07   ` Greg Sanders
  
From: Peter Todd @ 2022-10-20 23:21 UTC (permalink / raw)
  To: Greg Sanders, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev wrote:
> 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.

What footguns exactly? Spending a single input to OP_RETURN with no payload is
a valid use to get rid of dust in the UTXO set.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

 permalink raw reply	[|nested]
2022-10-20 23:21 ` Peter Todd

  2022-10-21  0:13     ` Peter Todd
  
From: Greg Sanders @ 2022-10-21  0:07 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

I don't doubt the use case(it's why I opened the issue!). I didn't want the
proposal to die in case people found it odd that 61, 62, 63, but not 64
bytes ended up being broadcast able.

Perhaps this is not an issue, especially since this isn't a consensus
change like the Great Consensus Cleanup. Willing to change my proposal and
PR if people have no strong objections.

Greg

On Thu, Oct 20, 2022, 7:21 PM Peter Todd <pete@petertodd•org> wrote:

> On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > 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.
>
> What footguns exactly? Spending a single input to OP_RETURN with no
> payload is
> a valid use to get rid of dust in the UTXO set.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 2208 bytes --]

 permalink raw reply	[|nested]
2022-10-21  0:07   ` Greg Sanders

  2022-10-26 19:09       ` Greg Sanders
  
From: Peter Todd @ 2022-10-21  0:13 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg Sanders wrote:
> I don't doubt the use case(it's why I opened the issue!). I didn't want the
> proposal to die in case people found it odd that 61, 62, 63, but not 64
> bytes ended up being broadcast able.
> 
> Perhaps this is not an issue, especially since this isn't a consensus
> change like the Great Consensus Cleanup. Willing to change my proposal and
> PR if people have no strong objections.

I think it's fine if we only restrict 64 bytes. We have a specific reason to do
that and it's ok if we just tell people that. Only fairly-technical use-cases
are affected anyway.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

 permalink raw reply	[|nested]
2022-10-21  0:13     ` Peter Todd

  
From: Greg Sanders @ 2022-10-26 19:09 UTC ( / )
  To: Peter Todd;  Bitcoin Protocol Discussion



As there has been some feedback to the same effect, I've opened a competing
PR for separate evaluation here:
https://github.com/bitcoin/bitcoin/pull/26398

Please give feedback if anyone has any.

On Thu, Oct 20, 2022 at 8:13 PM Peter Todd <pete@petertodd•org> wrote:

> On Thu, Oct 20, 2022 at 08:07:54PM -0400, Greg Sanders wrote:
> > I don't doubt the use case(it's why I opened the issue!). I didn't want
> the
> > proposal to die in case people found it odd that 61, 62, 63, but not 64
> > bytes ended up being broadcast able.
> >
> > Perhaps this is not an issue, especially since this isn't a consensus
> > change like the Great Consensus Cleanup. Willing to change my proposal
> and
> > PR if people have no strong objections.
>
> I think it's fine if we only restrict 64 bytes. We have a specific reason
> to do
> that and it's ok if we just tell people that. Only fairly-technical
> use-cases
> are affected anyway.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>