Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F26AAE81 for ; Sun, 20 Dec 2015 18:51:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C420129 for ; Sun, 20 Dec 2015 18:51:45 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 74586140B96; Mon, 21 Dec 2015 05:51:43 +1100 (AEDT) From: Rusty Russell To: Jonathan Toomim , Pieter Wuille In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 20 Dec 2015 14:44:25 +1030 Message-ID: <878u4poixq.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DATE_IN_PAST_12_24, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 20 Dec 2015 18:53:50 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] On the security of softforks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 18:51:47 -0000 Jonathan Toomim via bitcoin-dev writes: > On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev wrote: > >> 1) The risk of an old full node wallet accepting a transaction that is >> invalid to the new rules. >> >> The receiver wallet chooses what address/script to accept coins on. >> They'll upgrade to the new softfork rules before creating an address >> that depends on the softfork's features. >> >> So, not a problem. > > > Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob > runs the old rules. Bob creates a p2pkh address for Mallory to > use. Mallory takes 1 BTC, and creates an invalid SegWit transaction > that Bob cannot properly validate and that pays into one of Mallory's > wallets. Mallory then immediately spends the unconfirmed transaction > into Bob's address. Bob sees what appears to be a valid transaction > chain which is not actually valid. Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG" scriptSig. The SegWit-usable outputs will (have to) look different, won't they? Cheers, Rusty.