MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN
5 messages, 23 to 27 May 2020. Started by Thomas Voegtlin.
Greg Sanders (2), Thomas Voegtlin, ZmnSCPxj, Russell O'Connor
Hello list,
I have been trying to CPFP a transaction using OP_RETURN, because the remaining output value would have been lower than the dust threshold.
The scriptPubkey of the output was OP_RETURN + OP_0, and there was a single p2wsh input.
The result is a 60 bytes transaction (without witness), that gets rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which is equal to 82 bytes.
Why is that value so high? Would it make sense to lower it to 60?
Thomas
AFAIU the number was picked to protect against CVE-2017-12842 covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 <https://github.com/bitcoin/bitcoin/pull/16885/files> which updated the text to explicitly mention this fact.
On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (21 lines)
> Hello list, > > I have been trying to CPFP a transaction using OP_RETURN, because the > remaining output value would have been lower than the dust threshold. > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a > single p2wsh input. > > The result is a 60 bytes transaction (without witness), that gets > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which > is equal to 82 bytes. > > Why is that value so high? Would it make sense to lower it to 60? > > > Thomas > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
So I think the question to ask would be "why can't we just make sure it's not 64?"
On Sat, May 23, 2020 at 11:24 AM Greg Sanders <gsanders87@gmail•com> wrote:
Quoted text (30 lines)
> AFAIU the number was picked to protect against CVE-2017-12842 covertly. > See: https://github.com/bitcoin/bitcoin/pull/16885 > <https://github.com/bitcoin/bitcoin/pull/16885/files> which updated the > text to explicitly mention this fact. > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> Hello list, >> >> I have been trying to CPFP a transaction using OP_RETURN, because the >> remaining output value would have been lower than the dust threshold. >> >> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a >> single p2wsh input. >> >> The result is a 60 bytes transaction (without witness), that gets >> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which >> is equal to 82 bytes. >> >> Why is that value so high? Would it make sense to lower it to 60? >> >> >> Thomas >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >
Good morning Thomas,
Quoted text (1 line)
> So I think the question to ask would be "why can't we just make sure it's not 64?"
If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may still be possible to mount CVE-2017-12842 attack with 32-bits of work. Of course some other details will be changed from the standard SHA-256 in mounting this attack, but from my poor understanding it seems safer to just avoid the area around length 64.
It *might* be safe to accept 65-byte or larger (but do not believe me, I only play a cryptographer on the Internet), but that does not help your specific application, which uses 60 byte tx.
Regards, ZmnSCPxj
Quoted text (26 lines)
> > On Sat, May 23, 2020 at 11:24 AM Greg Sanders <gsanders87@gmail•com> wrote: > > > AFAIU the number was picked to protect against CVE-2017-12842 covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which updated the text to explicitly mention this fact. > > > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > > Hello list, > > > > > > I have been trying to CPFP a transaction using OP_RETURN, because the > > > remaining output value would have been lower than the dust threshold. > > > > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a > > > single p2wsh input. > > > > > > The result is a 60 bytes transaction (without witness), that gets > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which > > > is equal to 82 bytes. > > > > > > Why is that value so high? Would it make sense to lower it to 60? > > > > > > Thomas > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists•linuxfoundation•org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I don't believe that 60 bytes is a problem here. SHA256 padding includes a length value of the original message data. Thus a padded non-64 byte transaction can never be the same as any padded 64-byte value, and therefore after applying the SHA256 compression function the resulting hashes cannot be identical (unless SHA256 itself is broken).
P.S. SHA256 also includes 10* padding, which also suffices to ensure messages of different lengths have different padding.
On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (54 lines)
> Good morning Thomas, > > > So I think the question to ask would be "why can't we just make sure > it's not 64?" > > If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it > may still be possible to mount CVE-2017-12842 attack with 32-bits of work. > Of course some other details will be changed from the standard SHA-256 in > mounting this attack, but from my poor understanding it seems safer to just > avoid the area around length 64. > > It *might* be safe to accept 65-byte or larger (but do not believe me, I > only play a cryptographer on the Internet), but that does not help your > specific application, which uses 60 byte tx. > > Regards, > ZmnSCPxj > > > > > On Sat, May 23, 2020 at 11:24 AM Greg Sanders <gsanders87@gmail•com> > wrote: > > > > > AFAIU the number was picked to protect against CVE-2017-12842 > covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which > updated the text to explicitly mention this fact. > > > > > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > > > > Hello list, > > > > > > > > I have been trying to CPFP a transaction using OP_RETURN, because the > > > > remaining output value would have been lower than the dust threshold. > > > > > > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a > > > > single p2wsh input. > > > > > > > > The result is a 60 bytes transaction (without witness), that gets > > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, > which > > > > is equal to 82 bytes. > > > > > > > > Why is that value so high? Would it make sense to lower it to 60? > > > > > > > > Thomas > > > > _______________________________________________ > > > > bitcoin-dev mailing list > > > > bitcoin-dev@lists•linuxfoundation•org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >