Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BC7E021FA for ; Mon, 5 Oct 2015 16:46:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F28571A7 for ; Mon, 5 Oct 2015 16:46:29 +0000 (UTC) Received: by igcrk20 with SMTP id rk20so65305281igc.1 for ; Mon, 05 Oct 2015 09:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wQulGXg33u3wE9rm1fIfQyThOidetb5lJFmMtcVGmCc=; b=nSYQBLDIvkKzXYuRSYLqHk1MdzjLAYye1X42PwsuTeCbAsAGmqWiNFPv13RHK81TUN U5i4GI7q1d8jttv7lr2bIupnlDTPJ6arh1GcavAxsXI6b5p10qpfYuncxCUqaFMw5jtC nguYwHP+8ScA1zuEeJjPULzan0rylKXqBIDUQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wQulGXg33u3wE9rm1fIfQyThOidetb5lJFmMtcVGmCc=; b=YdWXr5FCfcxdSJ7t3iXWyMl4cVEnB4lcts1ww3yKcwtr+xakDMmZF/HRhdizeGW1hV jRHG/xFXGkslHaWOss2uAZ3CjZSYpuC/1ws7OyfhcXS2cXdtnx47aDYWUIeoCiJ0vlbz sNNc2OGmzqHQUYyOxX9me6Nk5x+Rk7pE1M/uutc9yIE1b7+jiDHXRM/ATSSaWSbc3e/H CF2A23sCHFXbAyj2Qdly2P12hkr9ONTKh70hknpdZ0SzgnViSmozHBUhK2qgd0Y58Clk PKLn4Z3GlrtbnPU0rpRiIvsb5z+TEC0YZQrObHpmJ5m9T6hKyRKNjZpC9YTOUbwcDkGQ gEQg== X-Gm-Message-State: ALoCoQnvMXD3+wF5g8VKbT4id5h/ej43vvJeV/ElJ9mLj0+aFY/pBX2hotomxozEj3LWsuzfmyRb MIME-Version: 1.0 X-Received: by 10.50.111.231 with SMTP id il7mr9016025igb.34.1444063588842; Mon, 05 Oct 2015 09:46:28 -0700 (PDT) Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 09:46:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 18:46:28 +0200 Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=047d7b4142c83f363605215e411f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Dev Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Mon, 05 Oct 2015 16:46:30 -0000 --047d7b4142c83f363605215e411f Content-Type: text/plain; charset=UTF-8 > > As Greg explained to you repeatedly, a softfork won't cause a > non-upgraded full node to start accepting blocks that create more > subsidy than is valid. > It was an example. Adam Back's extension blocks proposal would, in fact, allow for a soft forking change that creates more subsidy than is valid (or does anything else) by hiding one block inside another. Anyway, I think you got my point. > That's very different security from an SPV node, and as Greg > also explained, SPV nodes could be much more secure than bitcoinj > nodes (they could, for example, validate the coinbase transaction of > every block). > I'm pretty sure Gregory did not use such an example because it's dead wrong. You cannot verify the size of a coinbase without being a fully verifying node because you need to know the fees in the block, and calculating that requires access to the entire UTXO set. This sort of thing is why I get annoyed when people lecture me about SPV wallets and the things they "should" do. None of you guys has built one. I keep seeing wild statements about theoretical unicorn wallets that nobody has even designed, and how all existing wallets are crappy and insecure because they don't meet your ever shifting goal posts. To everyone making such statements I say: go away and build an SPV wallet of your own from scratch. Then you will understand the engineering tradeoffs involved much better, and be in a much better position to debate what they should or should not be doing. And bear in mind if it weren't for the work myself and a few others did on SPV wallets, everyone would be using web wallets instead. Then you'd all just complain about that instead. > Can you give an example of an attack in which a non-upgraded full node > wallet is defrauded with BIP65 but could not with the hardfork > alternative (that nobody seems to be willing to implement)? > Making it a hard fork instead is changing one line of code (ignoring the code to set up the flag day, which can be based on the code for BIP101). If it comes down to it, then I'll do the work to change that one line. But obviously I'd need to see agreement from the maintainers that such a pull req would be merged first. The example is this: find someone that accepts 1-block confirmed transactions in return for something valuable. There are plenty of them out there. Once the soft fork starts, send a P2SH transaction that defines a new output controlled by OP_CLTV. It will be incorporated into the UTXO set by all miners because it's opaque (p2sh). Now send a transaction that pays the merchant, and make it spend your OP_CLTV output with an invalid script. New nodes will reject it as a rule violator. Old nodes won't. So at some point an old miner will create a block containing your invalid transaction, the merchant will think they got paid, they'll give you the stuff and the fraud is done. > Please, don't assume 0 confirmation transactions or similar > unreasonable assumptions (ie see section 11 "Calculations" of the > Bitcoin whitepaper). > This is just embarrassing - do any of you guys at Blockstream actually use Bitcoin in the real world? Virtually all payments that aren't moving money into/out of exchange wallets are 0-confirm in reality. I described a 1-confirm attack above, but really ... come on. --047d7b4142c83f363605215e411f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Greg explained to you repeatedly, a softfork won't caus= e a
non-upgraded full node to start accepting blocks that create more
subsidy than is valid.

It was an exampl= e. Adam Back's extension blocks proposal would, in fact, allow for a so= ft forking change that creates more subsidy than is valid (or does anything= else) by hiding one block inside another.

Anyway,= I think you got my point.
=C2=A0
That'= s very different security from an SPV node, and as Greg also=C2=A0explained= , SPV nodes could be much more secure than bitcoinj nodes=C2=A0(they could,= for example, validate the coinbase transaction of every=C2=A0block).

I'm pretty sure Gregory did not use such= an example because it's dead wrong. You cannot verify the size of a co= inbase without being a fully verifying node because you need to know the fe= es in the block, and calculating that requires access to the entire UTXO se= t.

This sort of thing is why I get annoyed when pe= ople lecture me about SPV wallets and the things they "should" do= . None of you guys has built one. I keep seeing wild statements about theor= etical unicorn wallets that nobody has even designed, and how all existing = wallets are crappy and insecure because they don't meet your ever shift= ing goal posts.

To everyone making such statements= I say: go away and build an SPV wallet of your own from scratch. Then you = will understand the engineering tradeoffs involved much better, and be in a= much better position to debate what they should or should not be doing.

And bear in mind if it weren't for the work = myself and a few others did on SPV wallets, everyone would be using web wal= lets instead. Then you'd all just complain about that instead.
=C2=A0
Can you give an example of an attack in = which a non-upgraded full node
wallet is defrauded with BIP65 but could not with the hardfork
alternative (that nobody seems to be willing to implement)?

Making it a hard fork instead is changing one line of = code (ignoring the code to set up the flag day, which can be based on the c= ode for BIP101). If it comes down to it, then I'll do the work to chang= e that one line. But obviously I'd need to see agreement from the maint= ainers that such a pull req would be merged first.

The example is this: find someone that accepts 1-block confirmed transacti= ons in return for something valuable. There are plenty of them out there. O= nce the soft fork starts, send a P2SH transaction that defines a new output= controlled by OP_CLTV. It will be incorporated into the UTXO set by all mi= ners because it's opaque (p2sh).

Now send a tr= ansaction that pays the merchant, and make it spend your OP_CLTV output wit= h an invalid script. New nodes will reject it as a rule violator. Old nodes= won't. So at some point an old miner will create a block containing yo= ur invalid transaction, the merchant will think they got paid, they'll = give you the stuff and the fraud is done.
=C2=A0
Please, don't assume 0 confirmation transactions or similar
unreasonable assumptions (ie see section 11 "Calculations" of the=
Bitcoin whitepaper).

This is just embarr= assing - do any of you guys at Blockstream actually use Bitcoin in the real= world? Virtually all payments that aren't moving money into/out of exc= hange wallets are 0-confirm in reality. I described a 1-confirm attack abov= e, but really ... come on.
--047d7b4142c83f363605215e411f--