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 917E4982 for ; Sun, 5 Jul 2015 01:32:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A766DA8 for ; Sun, 5 Jul 2015 01:32:17 +0000 (UTC) Received: by qkbp125 with SMTP id p125so95677548qkb.2 for ; Sat, 04 Jul 2015 18:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=545PjtTtrgZWyhJOxrFE3jNyb2K/Rd8qosXgYBMKuMs=; b=hRQuwQOYpyIbCY8yR79KKV9Id8GeZa0w2aTGyIG7WmJjD99cwVSjAiEvZcuDkJd25b DgqyFTg3y3lxr9o0sSV5wX+aTekvQ9NIuH8hc8sZHMJaK7fdWisIqu5HlF4RwuuCaxh5 JxIzZ3XeIHVqsw8SLod8GHVSytQCRVmI9O+2NreAvcm/NsI2CxJdnfPnXy5wnnqP3K3X gLHA3PZklPHCfj2UfyHPUN/KPofoyBVm6nzSSHgGYNMWKriWqBVmIuDOwgZChi2YmhhF 6APo9ek05gxPatD5j5ZyCLsEnGQdDR0cdzlon+NOGsGhD9dIeiIdQPY23LVXQ1Qvs0RS 8ChQ== MIME-Version: 1.0 X-Received: by 10.140.216.208 with SMTP id m199mr65684228qhb.69.1436059936858; Sat, 04 Jul 2015 18:32:16 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Sat, 4 Jul 2015 18:32:16 -0700 (PDT) In-Reply-To: <55986D44.20601@openbitcoinprivacyproject.org> References: <20150704054453.GA348@savin.petertodd.org> <5597F93B.3000205@openbitcoinprivacyproject.org> <55980361.9040707@openbitcoinprivacyproject.org> <55986D44.20601@openbitcoinprivacyproject.org> Date: Sun, 5 Jul 2015 02:32:16 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1135d79669a52b051a16c256 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations 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, 05 Jul 2015 01:32:21 -0000 --001a1135d79669a52b051a16c256 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 5, 2015 at 12:33 AM, Justus Ranvier < justus@openbitcoinprivacyproject.org> wrote: > I think the problem is tractable if some reasonable assumptions are made > about the ability of SPV clients to perform validity checks that don't > involve any state outside a single transaction (or block): > > https://gist.github.com/justusranvier/451616fa4697b5f25f60 > > I agree, it is definitely tractable. If Bitcoin was being designed from scratch, it could be made even easier. As things stand, the extra commitment information needs to be added to extra trees, which themselves need to be checked. The "prover", in your example, should ideally store additional meta-data along with each block. If P2SH was made mandatory, then much of the transaction validation could be performed on the transaction alone. Both the signature and the public key would be included in the spending transaction. --001a1135d79669a52b051a16c256 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 5, 2015 at 12:33 AM, Justus Ranvier <justus@o= penbitcoinprivacyproject.org> wrote:
I think the problem is tractable if some reasonable assumptions are = made
about the ability of SPV clients to perform validity checks that don't<= br> involve any state outside a single transaction (or block):

https://gist.github.com/justusranvier/451= 616fa4697b5f25f60

<= br>
I agree, it is definitely tractable.

If Bit= coin was being designed from scratch, it could be made even easier.

=
As things stand, the extra commitment information needs to be ad= ded to extra trees, which themselves need to be checked.

=
The "prover", in your example, should ideally store ad= ditional meta-data along with each block.

If P2SH was mad= e mandatory, then much of the transaction validation could be performed on = the transaction alone.

Both the signature and the public = key would be included in the spending transaction.
--001a1135d79669a52b051a16c256--