From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E819483 for ; Thu, 1 Sep 2016 11:29:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from erelay3.ox.registrar-servers.com (erelay3.ox.registrar-servers.com [192.64.117.2]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46D5B139 for ; Thu, 1 Sep 2016 11:29:35 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id 60ACA2207E0A; Thu, 1 Sep 2016 11:29:32 +0000 (UTC) Received: from erelay1.ox.registrar-servers.com ([127.0.0.1]) by localhost (erelay.ox.registrar-servers.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cLgkTYEFsoW6; Thu, 1 Sep 2016 07:29:29 -0400 (EDT) Received: from MTA-07.privateemail.com (unknown [10.20.150.170]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by erelay1.ox.registrar-servers.com (Postfix) with ESMTPS id C52D22207DA3; Thu, 1 Sep 2016 07:29:29 -0400 (EDT) Received: from APP-06 (unknown [10.20.147.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by MTA-07.privateemail.com (Postfix) with ESMTPSA id 828E160032; Thu, 1 Sep 2016 11:29:29 +0000 (UTC) Date: Thu, 1 Sep 2016 07:29:29 -0400 (EDT) From: Johnson Lau Reply-To: Johnson Lau To: Sergio Demian Lerner Message-ID: <1348417205.55392.1472729369522@privateemail.com> In-Reply-To: References: <339348690.148734.1472089774841@privateemail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_55391_974684541.1472729369462" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.1-Rev19 X-Originating-Client: open-xchange-appsuite X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Attack by modifying non-segwit transactions after segwit is accepted ? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:29:38 -0000 ------=_Part_55391_974684541.1472729369462 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you so much for taking time to actually review the codes. I hope you will keep raising questions when you feel something might be wrong. This is how things supposed to work and we should not be affected by some forum discussions. > On August 26, 2016 at 9:16 AM Sergio Demian Lerner wrote: > > Because there was a discussion on reddit about this topic, I want to clarify that Johnson Lau explained how a check in the code prevents this attack. > So there is no real attack. > > Also note that the subject of this thread has a question mark, which means that I'm asking the community for clarification, not asserting the existence of a vulnerability. > > The segwit code is complex, and some key parts of the consensus code are spread over the source files (such as state.CorruptionPossible() relation to DoS banning, IsNull() check in witness program serialization, etc.). > > Thanks again Johnson for your clarifications. > > > On Wed, Aug 24, 2016 at 10:49 PM, Johnson Lau wrote: > > > > > > Adding witness data to a non-segwit script is invalid by consensus: > > > > https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467 https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467 > > > > > > This PR will detect such violation early and ban the peer: > > > > https://github.com/bitcoin/bitcoin/pull/8499 https://github.com/bitcoin/bitcoin/pull/8499 > > > > > > > > > > Another approach is to run the scripts of all incoming transactions. That's not too bad as you have already fetched the utxos which is a major part of validation. > > > > > > ------=_Part_55391_974684541.1472729369462 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you so much for taking time to actually review the co= des. I hope you will keep raising questions when you feel something mi= ght be wrong. This is how things supposed to work and we should not be= affected by some forum discussions.

On August= 26, 2016 at 9:16 AM Sergio Demian Lerner <sergio.d.lerner@gmail.com= 2; wrote:

Because there was a discussion on re= ddit about this topic, I want to clarify that Johnson Lau explained how a c= heck in the code prevents this attack.
So there is no real at= tack.

Also note that the subject of this threa= d has a question mark, which means that I'm asking the community for cl= arification, not asserting the existence of a vulnerability.

<= div>The segwit code is complex, and some key parts of the consensus code ar= e spread over the source files (such as state.CorruptionPossible() relation= to DoS banning, IsNull() check in witness program serialization, etc.).
Thanks again Johnson for your clarifications.


On Wed, Aug 24, 2016 at 10:49 PM, Johnson La= u <jl2012@xbt.hk= > wrote:

Adding witness data to a non-seg= wit script is invalid by consensus:

https://github.com/bitcoin/bitcoi= n/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467


This PR will detect such viola= tion early and ban the peer:

https://github.com/bitcoin/bitcoin= /pull/8499

 


Another approach is to run= the scripts of all incoming transactions. That's not too bad as you ha= ve already fetched the utxos which is a major part of validation.

<= /div>

=20 ------=_Part_55391_974684541.1472729369462--