* [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN @ 2020-05-23 14:49 Thomas Voegtlin 2020-05-23 15:24 ` Greg Sanders 0 siblings, 1 reply; 5+ messages in thread From: Thomas Voegtlin @ 2020-05-23 14:49 UTC (permalink / raw) To: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN 2020-05-23 14:49 [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN Thomas Voegtlin @ 2020-05-23 15:24 ` Greg Sanders 2020-05-23 15:25 ` Greg Sanders 0 siblings, 1 reply; 5+ messages in thread From: Greg Sanders @ 2020-05-23 15:24 UTC (permalink / raw) To: Thomas Voegtlin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1039 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 1599 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN 2020-05-23 15:24 ` Greg Sanders @ 2020-05-23 15:25 ` Greg Sanders 2020-05-24 0:52 ` ZmnSCPxj 0 siblings, 1 reply; 5+ messages in thread From: Greg Sanders @ 2020-05-23 15:25 UTC (permalink / raw) To: Thomas Voegtlin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1237 bytes --] 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: > 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 >> > [-- Attachment #2: Type: text/html, Size: 2090 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN 2020-05-23 15:25 ` Greg Sanders @ 2020-05-24 0:52 ` ZmnSCPxj 2020-05-27 15:15 ` Russell O'Connor 0 siblings, 1 reply; 5+ messages in thread From: ZmnSCPxj @ 2020-05-24 0:52 UTC (permalink / raw) To: Greg Sanders, Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN 2020-05-24 0:52 ` ZmnSCPxj @ 2020-05-27 15:15 ` Russell O'Connor 0 siblings, 0 replies; 5+ messages in thread From: Russell O'Connor @ 2020-05-27 15:15 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Greg Sanders [-- Attachment #1: Type: text/plain, Size: 2654 bytes --] 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: > 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 > [-- Attachment #2: Type: text/html, Size: 3974 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-05-27 15:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-23 14:49 [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN Thomas Voegtlin 2020-05-23 15:24 ` Greg Sanders 2020-05-23 15:25 ` Greg Sanders 2020-05-24 0:52 ` ZmnSCPxj 2020-05-27 15:15 ` Russell O'Connor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox