MIME-Version: 1.0
In-Reply-To: <56155572.5040501@domob.eu>
References: <56155572.5040501@domob.eu>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Wed, 7 Oct 2015 16:32:03 -0700
Message-ID: <CAPfvXfLw25J_mXn6b9QO_VDTU3EoVP9zxt7bbN0RF+2coYAdJA@mail.gmail.com>
To: Daniel Kraft <d@domob.eu>
Content-Type: multipart/alternative; boundary=089e011763518a242805218c28fd
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The new obfuscation patch & GetStats
Precedence: list

--089e011763518a242805218c28fd
Content-Type: text/plain; charset=UTF-8

Hey, Daniel.

Patch author here. Thanks for the diligence; I think this indeed may be an
oversight, though I'm going to need to look into a bit more thoroughly at
home. Curious that it didn't fail any of the automated tests.

Correct me if I'm wrong, but the only actual invocation of that method is
here
<https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp#L448>
(and even then, proxied through a few layers of CCoinView-machinery). In
fact, this line
<https://github.com/bitcoin/bitcoin/blob/master/src/coins.cpp#L48> makes me
suspect that the implementation of GetStats you reference may be dead code.

In any case, you raise a good point: if users of CLevelDBWrapper go
directly for the iterator, they run the risk of dealing with obfuscated
data. This should be remedied somehow.

I'll give it more look this evening.

Thanks again for the find,
James

On Wed, Oct 7, 2015 at 10:25 AM, Daniel Kraft via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi!
>
> I hope this is not a stupid question, but I thought I'd ask here first
> instead of opening a Github ticket (in case I'm wrong).
>
> With the recently merged "obfuscation" patch, content of the
> "chainstate" LevelDB is obfuscated by XOR'ing against a random "key".
> This is handled by CLevelDBWrapper's Read/Write methods, which probably
> cover most of the usecases.
>
> *However*, shouldn't it also be handled when iterating over the
> database?  In particular, I would expect that the obfuscation key is
> applied before line 119 in txdb.cpp (i. e., while iterating over the
> coin database in CCoinsViewDB::GetStats).
>
> Is there a reason why this need not be done there, or is this an actual
> oversight?
>
> Yours,
> Daniel
>
> --
> http://www.domob.eu/
> OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
> Namecoin: id/domob -> https://nameid.org/?name=domob
> --
> Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
> To go: Mon-Pri
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Hey, Daniel.<div><br></div><div>Patch author here. Thanks =
for the diligence; I think this indeed may be an oversight, though I&#39;m =
going to need to look into a bit more thoroughly at home. Curious that it d=
idn&#39;t fail any of the automated tests.</div><div><br></div><div>Correct=
 me if I&#39;m wrong, but the only actual invocation of that method is <a h=
ref=3D"https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp=
#L448">here</a> (and even then, proxied through a few layers of CCoinView-m=
achinery). In fact, <a href=3D"https://github.com/bitcoin/bitcoin/blob/mast=
er/src/coins.cpp#L48">this line</a> makes me suspect that the implementatio=
n of GetStats you reference may be dead code.</div><div><br></div><div>In a=
ny case, you raise a good point: if users of CLevelDBWrapper go directly fo=
r the iterator, they run the risk of dealing with obfuscated data. This sho=
uld be remedied somehow.</div><div><br></div><div>I&#39;ll give it more loo=
k this evening.</div><div><br></div><div>Thanks again for the find,</div><d=
iv>James</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Wed, Oct 7, 2015 at 10:25 AM, Daniel Kraft via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I hope this is not a stupid question, but I thought I&#39;d ask here first<=
br>
instead of opening a Github ticket (in case I&#39;m wrong).<br>
<br>
With the recently merged &quot;obfuscation&quot; patch, content of the<br>
&quot;chainstate&quot; LevelDB is obfuscated by XOR&#39;ing against a rando=
m &quot;key&quot;.<br>
This is handled by CLevelDBWrapper&#39;s Read/Write methods, which probably=
<br>
cover most of the usecases.<br>
<br>
*However*, shouldn&#39;t it also be handled when iterating over the<br>
database?=C2=A0 In particular, I would expect that the obfuscation key is<b=
r>
applied before line 119 in txdb.cpp (i. e., while iterating over the<br>
coin database in CCoinsViewDB::GetStats).<br>
<br>
Is there a reason why this need not be done there, or is this an actual<br>
oversight?<br>
<br>
Yours,<br>
Daniel<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"http://www.domob.eu/" rel=3D"noreferrer" target=3D"_blank">http:=
//www.domob.eu/</a><br>
OpenPGP: 1142 850E 6DFF 65BA 63D6=C2=A0 88A8 B249 2AC4 A733 0737<br>
Namecoin: id/domob -&gt; <a href=3D"https://nameid.org/?name=3Ddomob" rel=
=3D"noreferrer" target=3D"_blank">https://nameid.org/?name=3Ddomob</a><br>
--<br>
Done:=C2=A0 Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz<br>
To go: Mon-Pri<br>
<br>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--089e011763518a242805218c28fd--