[147860] in cryptography@c2.net mail archive
Re: [Cryptography] BitMessage?
daemon@ATHENA.MIT.EDU (Keyfur)
Mon Oct 28 13:38:11 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <21098.1136.79676.224538@desk.crynwr.com>
Date: Mon, 28 Oct 2013 00:31:27 -0400
From: Keyfur <james@keyfur.com>
To: Russ Nelson <nelson@crynwr.com>, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3075583032012041142==
Content-Type: multipart/alternative; boundary=047d7b343ef2c848ea04e9c59237
--047d7b343ef2c848ea04e9c59237
Content-Type: text/plain; charset=ISO-8859-1
That would get extremely bulky in mass-adoption, in both local storage and
network usage. Currently they have some structure to create tiered
"streams", but that still doesn't eliminate the excessive network burden,
it just saves some disk space.
The streams work in a hierarchy, with the uppermost assuming the highest
network burden. Because it's necessary to send an acknowledgement message,
a complete circuit must established (though not all at once) between nodes.
Also "broadcast messages" seem too risky to me. They're liable to be abused
and cause a DoS if this protocol is adopted on a large-scale.
Proof-of-work doesn't protect broadcast message abuse, because an attacker
could just use a small botnet to generate a bunch of untransmitted messages
with similar timestamps for a future date. Once that date arrives, then the
attacker could just submit a very large batch of valid broadcast
bitmessages.
I can't think of a solution to either of these problems right now, but I
otherwise think Bitmessage is a great idea. It's current, humbly sized
userbase makes for comfortable testing.
https://bitmessage.org/bitmessage.pdf
James
On 25 October 2013 01:41, Russ Nelson <nelson@crynwr.com> wrote:
> I haven't seen any discussion of BitMessage (http://bitmessage.org)
> here yet. The idea is to be a mixer with a pool of recipients, which
> currently seems to be 12,000ish. Before anybody will receive your
> message, they need to see a proof of work. Once they do, they forward
> the message to everyone else, using a flood-fill algorithm. Messages
> are encrypted so only the recipient can decode them. Mailing lists are
> simulated via a shared private key.
>
> It looks plausible. Not obviously snake oil.
>
> --
> --my blog is at http://blog.russnelson.com
> Crynwr supports open source software
> 521 Pleasant Valley Rd. | +1 315-600-8815
> Potsdam, NY 13676-3213 | Sheepdog
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--047d7b343ef2c848ea04e9c59237
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">That would get extremely bulky in mass-adoption, in both local storage an=
d network usage. Currently they have some structure to create tiered "=
streams", but that still doesn't eliminate the excessive network b=
urden, it just saves some disk space.=A0</span><br style=3D"font-family:ari=
al,sans-serif;font-size:13px">
<div class=3D"gmail_quote" style=3D"font-family:arial,sans-serif;font-size:=
13px"><div dir=3D"ltr"><div><br></div><div>The streams work in a hierarchy,=
with the uppermost assuming the highest network burden. Because it's n=
ecessary to send an acknowledgement message, a complete circuit must establ=
ished (though not all at once) between nodes.</div>
<div><br></div><div>Also "broadcast messages" seem too risky to m=
e. They're liable to be abused and cause a DoS if this protocol is adop=
ted on a large-scale.</div><div><br></div><div>Proof-of-work doesn't pr=
otect broadcast message abuse, because an attacker could just use a small b=
otnet to generate a bunch of untransmitted messages with similar timestamps=
for a future date. Once that date arrives, then the attacker could just su=
bmit a very large batch of valid broadcast bitmessages.</div>
<div><br></div><div>I can't think of a solution to either of these prob=
lems right now, but I otherwise think Bitmessage is a great idea. It's =
current, humbly sized userbase makes for comfortable testing.=A0</div><div>
<br></div><div><a href=3D"https://bitmessage.org/bitmessage.pdf" target=3D"=
_blank">https://bitmessage.org/bitmessage.pdf</a></div><font color=3D"#8888=
88"><div><br></div><div>James</div></font></div></div><div class=3D"gmail_e=
xtra">
<br><br><div class=3D"gmail_quote">On 25 October 2013 01:41, Russ Nelson <s=
pan dir=3D"ltr"><<a href=3D"mailto:nelson@crynwr.com" target=3D"_blank">=
nelson@crynwr.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I haven't seen any discussion of BitMessage (<a href=3D"http://bitmessa=
ge.org" target=3D"_blank">http://bitmessage.org</a>)<br>
here yet. The idea is to be a mixer with a pool of recipients, which<br>
currently seems to be 12,000ish. Before anybody will receive your<br>
message, they need to see a proof of work. Once they do, they forward<br>
the message to everyone else, using a flood-fill algorithm. Messages<br>
are encrypted so only the recipient can decode them. Mailing lists are<br>
simulated via a shared private key.<br>
<br>
It looks plausible. Not obviously snake oil.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
--my blog is at =A0 =A0<a href=3D"http://blog.russnelson.com" target=3D"_bl=
ank">http://blog.russnelson.com</a><br>
Crynwr supports open source software<br>
521 Pleasant Valley Rd. | <a href=3D"tel:%2B1%20315-600-8815" value=3D"+131=
56008815">+1 315-600-8815</a><br>
Potsdam, NY 13676-3213 =A0| =A0 =A0 Sheepdog<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>
</font></span></blockquote></div><br></div></div>
--047d7b343ef2c848ea04e9c59237--
--===============3075583032012041142==
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
--===============3075583032012041142==--
