[148752] in cryptography@c2.net mail archive
Re: [Cryptography] On Security Architecture, The Panopticon,
daemon@ATHENA.MIT.EDU (Natanael)
Thu Dec 26 16:16:07 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAOLP8p7_3xx6K8YBO=_1r+ZyctNpuwtLHnqP7CqBn3Z9kzFggQ@mail.gmail.com>
Date: Thu, 26 Dec 2013 22:11:59 +0100
From: Natanael <natanael.l@gmail.com>
To: Bill Cox <waywardgeek@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>,
Bill Frantz <frantz@pwpconsult.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============0728084638022018998==
Content-Type: multipart/alternative; boundary=001a11c28aca9e5e0d04ee766d52
--001a11c28aca9e5e0d04ee766d52
Content-Type: text/plain; charset=UTF-8
Why do you think Bitcoin is a ponzi? It rather mimics the mining process of
precious metals in digital form. (There is also no need for it to go up and
up forever. And I'd like to note that I actually have bought things with
them.)
And regarding Ripple, that system relies entirely on mutual trust in
between a set of servers. It can not scale and at the same time ensure a
high level of (well founded) trust. It's a weird form of web of trust,
where the users have very little say in the process.
IMHO the best choice would be a P2P system ("federation" is OK, no need for
most users to run full nodes tracking all public conversations ever posted)
where each post simply references the previous posts seen by that person
(maybe with a Merkle tree hash), where the current state occasionally is
synced to the blockchain in the form of a checksum (for timestamping and
tamper proofing). I don't yet have any particular opinion on how the
details should work.
(And I do not like the design of Bitmessage either, I doubt it can scale.
There is no need to force every peer to keep everything in the chain or to
keep it up to date 24/7.)
Bitcoin SPV nodes are an interesting comparison, they rely on servers
hosting the full chain, themselves they just hold the headers and the full
blocks that apply to themselves. And the servers are fundamentally Bitcoin
nodes like any other (except with an additional API layer for the SPV
clients to use, like Stratum).
I like Bote mail in I2P (DHT based). Syndie is another interesting piece of
software ("syndication based"), but it doesn't seem to perform very well
and doesn't seem all to reliable.
- Sent from my phone
Den 26 dec 2013 19:43 skrev "Bill Cox" <waywardgeek@gmail.com>:
> On Wed, Dec 25, 2013 at 10:05 PM, Bill Frantz <frantz@pwpconsult.com>wrote:
>
>> The bigest problem I can see with leaving the third parties out is that
>> is -- where's the revenue model that provides an economic incentive to
>> drive adoption? Even when third parties start out with a privacy goal, they
>> provide a place to pry as seen by RIM's and Skype's dance with the national
>> security agencies. There needs to be a revenue model, perhaps a distributed
>> revenue model like Bitcoin's enabling of low cost electronic monitory
>> exchange and the opportunity to make money by minting.
>>
>
> I agree. We need a distributed global commit-only database, and some sort
> of revenue model. The BitCoin solution is extremely cool, but in the end
> it's basically a Ponzi scheme. The value of the coins keeps going up, but
> no one is using them to buy anything.
>
> I have some dumb ideas in this area. I think we could build a P2P system
> that allows Ripple-style microtransactions. It could allow us to plug in
> our Raspberry Pi's and sell services such as storage of encrypted data or
> email, speeding up downloads in torrents, or hosting games, files or web
> sites.
>
> The financial incentives would be that we essentially get free Rasberry
> Pi's and other server hardware while users get cheap services. The P2P
> aspects are hard, but IMO, the crypto part is even harder. As soon as
> there is anything of value online that we can trade, it becomes a target.
>
>
>> General purpose hardware manufacturers are as rare as Unicorns, making
>> them a logical target for black coercion. A possible solution to hardware
>> compromise is to run crypto code through one or more layers of
>> interpretation, so it will be hard for the hardware to detect what
>> computations are being performed.
>>
>
> Even something as simple and cheap as a Raspberry Pi is so complex that it
> could have multiple back-doors and unintended security weaknesses in both
> hardware and software. iPhones keep getting rooted, demonstrating that
> even the most valuable company in the world can't secure a phone.
>
> I agree a possible solution is multiple layers, preferably multiple layers
> of hardware. For example, a simple USB stick microprocessor could have a
> small single-chip RAM buffer that can electrically connect to either the
> host PC/Rasberry Pi, or the USB microprocessor, but only one at a time.
> The USB microprocessor could be FPGA based, making it also more easily
> auditable, and we could have a discrete zener-noise based RNG that can be
> fully probed providing random data. All signing of things could be done in
> the FPGA. If that could be done for $20 and plugged into a $35 Rasberry
> Pi, just maybe we'd be able to build a P2P system we could trust enough to
> enable microtransactions. After that, all kinds of services might follow.
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--001a11c28aca9e5e0d04ee766d52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Why do you think Bitcoin is a ponzi? It rather mimics the mi=
ning process of precious metals in digital form. (There is also no need for=
it to go up and up forever. And I'd like to note that I actually have =
bought things with them.) </p>
<p dir=3D"ltr">And regarding Ripple,=C2=A0 that system relies entirely on m=
utual trust in between a set of servers. It can not scale and at the same t=
ime ensure a high level of (well founded) trust. It's a weird form of w=
eb of trust, where the users have very little say in the process. </p>
<p dir=3D"ltr">IMHO the best choice would be a P2P system ("federation=
" is OK, no need for most users to run full nodes tracking all public =
conversations ever posted) where each post simply references the previous p=
osts seen by that person=C2=A0 (maybe with a Merkle tree hash), where the c=
urrent state occasionally is synced to the blockchain in the form of a chec=
ksum (for timestamping and tamper proofing). I don't yet have any parti=
cular opinion on how the details should work. </p>
<p dir=3D"ltr">(And I do not like the design of Bitmessage either, I doubt =
it can scale. There is no need to force every peer to keep everything in th=
e chain or to keep it up to date 24/7.) </p>
<p dir=3D"ltr">Bitcoin SPV nodes are an interesting comparison, they rely o=
n servers hosting the full chain, themselves they just hold the headers and=
the full blocks that apply to themselves. And the servers are fundamentall=
y Bitcoin nodes like any other (except with an additional API layer for the=
SPV clients to use, like Stratum).</p>
<p dir=3D"ltr">I like Bote mail in I2P (DHT based). Syndie is another inter=
esting piece of software ("syndication based"), but it doesn'=
t seem to perform very well and doesn't seem all to reliable. </p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 26 dec 2013 19:43 skrev "Bill Cox"=
<<a href=3D"mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>>=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 25, 2013 at 10:05 PM, Bill Frantz <span dir=3D"ltr"><<a href=3D"=
mailto:frantz@pwpconsult.com" target=3D"_blank">frantz@pwpconsult.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><span style=3D"color:rgb(34,34,34)">The=
bigest problem I can see with leaving the third parties out is that is -- =
where's the revenue model that provides an economic incentive to drive =
adoption? Even when third parties start out with a privacy goal, they provi=
de a place to pry as seen by RIM's and Skype's dance with the natio=
nal security agencies. There needs to be a revenue model, perhaps a distrib=
uted revenue model like Bitcoin's enabling of low cost electronic monit=
ory exchange and the opportunity to make money by minting.</span></div>
</blockquote><div><br></div><div>I agree. =C2=A0We need a distributed globa=
l commit-only database, and some sort of revenue model. =C2=A0The BitCoin s=
olution is extremely cool, but in the end it's basically a Ponzi scheme=
. =C2=A0The value of the coins keeps going up, but no one is using them to =
buy anything.</div>
<div><br></div><div>I have some dumb ideas in this area. =C2=A0I think we c=
ould build a P2P system that allows Ripple-style microtransactions. =C2=A0I=
t could allow us to plug in our Raspberry Pi's and sell services such a=
s storage of encrypted data or email, speeding up downloads in torrents, or=
hosting games, files or web sites.</div>
<div><br></div><div>The financial incentives would be that we essentially g=
et free Rasberry Pi's and other server hardware while users get cheap s=
ervices. =C2=A0The P2P aspects are hard, but IMO, the crypto part is even h=
arder. =C2=A0As soon as there is anything of value online that we can trade=
, it becomes a target.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
General purpose hardware manufacturers are as rare as Unicorns, making them=
a logical target for black coercion. A possible solution to hardware compr=
omise is to run crypto code through one or more layers of interpretation, s=
o it will be hard for the hardware to detect what computations are being pe=
rformed.<br>
</blockquote><div><br></div><div>Even something as simple and cheap as a Ra=
spberry Pi is so complex that it could have multiple back-doors and uninten=
ded security weaknesses in both hardware and software. =C2=A0iPhones keep g=
etting rooted, demonstrating that even the most valuable company in the wor=
ld can't secure a phone.</div>
<div><br></div><div>I agree a possible solution is multiple layers, prefera=
bly multiple layers of hardware. =C2=A0For example, a simple USB stick micr=
oprocessor could have a small single-chip RAM buffer that can electrically =
connect to either the host PC/Rasberry Pi, or the USB microprocessor, but o=
nly one at a time. =C2=A0The USB microprocessor could be FPGA based, making=
it also more easily auditable, and we could have a discrete zener-noise ba=
sed RNG that can be fully probed providing random data. =C2=A0All signing o=
f things could be done in the FPGA. =C2=A0If that could be done for $20 and=
plugged into a $35 Rasberry Pi, just maybe we'd be able to build a P2P=
system we could trust enough to enable microtransactions. =C2=A0After that=
, all kinds of services might follow.</div>
</div></div></div>
<br>_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br></blo=
ckquote></div>
--001a11c28aca9e5e0d04ee766d52--
--===============0728084638022018998==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============0728084638022018998==--
