MIME-Version: 1.0
In-Reply-To: <55986D44.20601@openbitcoinprivacyproject.org>
References: <COL402-EAS195B72E1CF2B75999C1AB11CD950@phx.gbl>
	<20150704054453.GA348@savin.petertodd.org>
	<5597F93B.3000205@openbitcoinprivacyproject.org>
	<CAE-z3OWTzgYP7CKbFLf-YFKU+G6CNKND2DmAbnr_3_NjB-Y4fw@mail.gmail.com>
	<55980361.9040707@openbitcoinprivacyproject.org>
	<CAE-z3OXZDh=ww33Qr6yGxzm3rzquiP0LNo6yQzL1si+-dr3a_g@mail.gmail.com>
	<55986D44.20601@openbitcoinprivacyproject.org>
Date: Sun, 5 Jul 2015 02:32:16 +0100
Message-ID: <CAE-z3OXX9wVCRiNHxpP3deTv63zOkJv4JDAYG8LXXOrFCoKVxg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135d79669a52b051a16c256
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
Precedence: list

--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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 5, 2015 at 12:33 AM, Justus Ranvier <span dir=3D"ltr">&lt;<a href=
=3D"mailto:justus@openbitcoinprivacyproject.org" target=3D"_blank">justus@o=
penbitcoinprivacyproject.org</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span class=3D"">
</span>I think the problem is tractable if some reasonable assumptions are =
made<br>
about the ability of SPV clients to perform validity checks that don&#39;t<=
br>
involve any state outside a single transaction (or block):<br>
<br>
<a href=3D"https://gist.github.com/justusranvier/451616fa4697b5f25f60" rel=
=3D"noreferrer" target=3D"_blank">https://gist.github.com/justusranvier/451=
616fa4697b5f25f60</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>I agree, it is definitely tractable.<br><br></div><div>If Bit=
coin was being designed from scratch, it could be made even easier.<br><br>=
</div><div>As things stand, the extra commitment information needs to be ad=
ded to extra trees, which themselves need to be checked.<br></div><div><br>=
</div><div>The &quot;prover&quot;, in your example, should ideally store ad=
ditional meta-data along with each block.<br><br></div><div>If P2SH was mad=
e mandatory, then much of the transaction validation could be performed on =
the transaction alone.<br><br></div><div>Both the signature and the public =
key would be included in the spending transaction.<br></div></div></div></d=
iv>

--001a1135d79669a52b051a16c256--