Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAE-z3OWUGPqruBkuXggzdNkOn+L-SSg84Qd1_JZYBunmY+j=HQ@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
	<CAE-z3OWUGPqruBkuXggzdNkOn+L-SSg84Qd1_JZYBunmY+j=HQ@mail.gmail.com>
Date: Wed, 13 May 2015 09:41:44 -0400
Message-ID: <CABsx9T1tPP_qrdyKPneZciwtWh2gho_d=qTCjnipo3463dJbpA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c382d09c5e250515f6c523
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Precedence: list

--001a11c382d09c5e250515f6c523
Content-Type: text/plain; charset=UTF-8

I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?

I think there might actually be two or three or four BIPs here:

 + Overall "what is trying to be accomplished"
 + Changes to the OP_*SIG* opcodes
 + Changes to the bloom-filtering SPV support
 + ...eventually, hard fork rollout plan

I also think that it is a good idea to have actually implemented a proposal
before getting a BIP number. At least, I find that actually writing the
code often turns up issues I hadn't considered when thinking about the
problem at a high level. And I STRONGLY believe BIPs should be descriptive
("here is how this thing works") not proscriptive ("here's how I think we
should all do it").

Finally: I like the idea of moving to a normalized txid. But it might make
sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg
Maxwell's excellent talk about his current thoughts on that topic:
  https://www.youtube.com/watch?v=Gs9lJTRZCDc


On Wed, May 13, 2015 at 9:12 AM, Tier Nolan <tier.nolan@gmail.com> wrote:

> I think this is a good way to handle things, but as you say, it is a hard
> fork.
>
> CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
> fix malleability once and for all.
>
> This has the effect of doubling the size of the UTXO database.  At
> minimum, there needs to be a legacy txid to normalized txid map in the
> database.
>
> An addition to the BIP would eliminate the need for the 2nd index.  You
> could require a SPV proof of the spending transaction to be included with
> legacy transactions.  This would allow clients to verify that the
> normalized txid matched the legacy id.
>
> The OutPoint would be {LegacyId | SPV Proof to spending tx  | spending tx
> | index}.  This allows a legacy transaction to be upgraded.  OutPoints
> which use a normalized txid don't need the SPV proof.
>
> The hard fork would be followed by a transitional period, in which both
> txids could be used.  Afterwards, legacy transactions have to have the SPV
> proof added.  This means that old transactions with locktimes years in the
> future can be upgraded for spending, without nodes needing to maintain two
> indexes.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
--
Gavin Andresen

--001a11c382d09c5e250515f6c523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this needs more details before it gets a BIP numbe=
r; for example, which opcodes does this affect, and how, exactly, does it a=
ffect them? Is the merkle root in the block header computed using normalize=
d transaction ids or normalized ids?=C2=A0<div><br></div><div>I think there=
 might actually be two or three or four BIPs here:</div><div><br></div><div=
>=C2=A0+ Overall &quot;what is trying to be accomplished&quot;</div><div>=
=C2=A0+ Changes to the OP_*SIG* opcodes</div><div>=C2=A0+ Changes to the bl=
oom-filtering SPV support</div><div>=C2=A0+ ...eventually, hard fork rollou=
t plan</div><div><br><div>I also think that it is a good idea to have actua=
lly implemented a proposal before getting a BIP number. At least, I find th=
at actually writing the code often turns up issues I hadn&#39;t considered =
when thinking about the problem at a high level. And I STRONGLY believe BIP=
s should be descriptive (&quot;here is how this thing works&quot;) not pros=
criptive (&quot;here&#39;s how I think we should all do it&quot;).</div></d=
iv><div><br></div><div>Finally: I like the idea of moving to a normalized t=
xid. But it might make sense to bundle that change with a bigger change to =
OP_CHECKSIG; see Greg Maxwell&#39;s excellent talk about his current though=
ts on that topic:</div><div>=C2=A0=C2=A0<a href=3D"https://www.youtube.com/=
watch?v=3DGs9lJTRZCDc">https://www.youtube.com/watch?v=3DGs9lJTRZCDc</a></d=
iv><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, May 13, 2015 at 9:12 AM, Tier Nolan <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>I think this is a good way to handle things, but as you say, it is a h=
ard fork.<br><br></div>CHECKLOCKTIMEVERIFY covers many of the use cases, bu=
t it would be nice to fix malleability once and for all.<br><div><div><br>T=
his has the effect of doubling the size of the UTXO database.=C2=A0 At mini=
mum, there needs to be a legacy txid to normalized txid map in the database=
.<br><br></div><div>An addition to the BIP would eliminate the need for the=
 2nd index.=C2=A0 You could require a SPV proof of the spending transaction=
 to be included with legacy transactions.=C2=A0 This would allow clients to=
 verify that the normalized txid matched the legacy id.<br><br></div><div>T=
he OutPoint would be {LegacyId | SPV Proof to spending tx=C2=A0 | spending =
tx | index}.=C2=A0 This allows a legacy transaction to be upgraded.=C2=A0 O=
utPoints which use a normalized txid don&#39;t need the SPV proof.<br><br><=
/div><div>The hard fork would be followed by a transitional period, in whic=
h both txids could be used.=C2=A0 Afterwards, legacy transactions have to h=
ave the SPV proof added.=C2=A0 This means that old transactions with lockti=
mes years in the future can be upgraded for spending, without nodes needing=
 to maintain two indexes.<br></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div>

--001a11c382d09c5e250515f6c523--