The recent spam

Aug 9 21:34 [raw]

So public chans appear to be a lost cause. Is any of BitMessage salvageable? Should we bother?

Aug 9 23:31 [raw]

BM has a high utility value. but spam is a problem. there are several remedies already available, such as chans / dml or pml with hi difficulty, making it too expensive to spam them. A difficulty 6 pml is e.g. BM-2cTTb9f5bd31y73zS9QaX2q8Y1sf8Qkug4 but very few used it, except the fucking spammer himself ... so now we know we sth like difficulty 30 to ward off the fucker but too few legit users were interested so fuck it.

Aug 10 01:16 [raw]

Don't mean to sound patronizing, but if you need to ask this question then no, you probably shouldn't bother. Why not find a project that you can **truly** believe in, and bother with that instead. You'll be a happier camper that way.

Aug 10 01:42 [raw]

go to youtube and get fuckiong censored there, u idiot

Aug 10 06:51 [raw]

Another alternative to raising the chan difficulty is to raise the pubkey object difficulty. I've read some papers that propose this (not for bitmessage but in general for spam protection). This way it would be expensive to create an identity. While this doesn't prevent him from spamming once he has the address, it makes it less costly to block him. Peter Surda Bitmessage core developer

Aug 10 07:10 [raw]

I guess it would be appropriate to refer to a post that suggested something to that regard, which might have drowned in spam: > This attack fully exploits that address creation has absolutely no cost, so blacklisting as a feature becomes completely useless. > The logical consequence would be to add a very much noticable overhead to address creation, and usage. This could be achieved by > REQUIRING a public key object for an address for a message from this address to be considered valid, and increasing the PoW for the public > key object. > And yes, obviously, for this to become meaningful it requires automatic blacklisting of the channel addresses, or completely preventing > to use them to post from in the first place, which would be the more effective solution. > This way, normal communication is not negatively affected (since a normal user does not need to create 5000 addresses), but spamming > this way becomes harder, since it's not feasible to create a million addresses. I guess what's meant with "requiring" a public key object is that for every message received, bitmessage would check the inventory for pubkey objects, and try to find one that matches the sender. If it can't find one, the message is ditched. This could be further enhanced by requiring the pubkey object to be valid for at least until the message expires, maybe even more. That would prevent a message from being sent with a 28 day PoW, when the pubkey is only valid for an hour. However, this requires some grace period on implementation, since on first sync after reconnect, it's not likely that the pubkeys are available when a message is received. Similarly, during normal operations, connections might just hang for a few minutes and then receive a bundle of messages out of order. This means that a message, for which no pubkey could be found, needs to be queued and checked against pubkeys received after, and only ditched after some configured grace period.

Aug 10 11:27 [raw]

you are so stupid

Aug 10 18:36 [raw]

Quite a solid and important contribution you made.

Aug 10 18:46 [raw]

Here you go, version more comprehensible by stupid person you are: Public chans are not lost, we can make as many of them as we need, more than spammer's attack capacity. Bitmessage does not need to be salvageable. it is joly good as it is. If really big shit happens, switch to private chans. Don't thank me.

Aug 10 18:49 [raw]

youtube is a lost cause, dumbass

Aug 10 18:50 [raw]

Sooooooo, to paraphrase: you're not addressing that the core concept has issues at it is right now (since it doesn't hinder this kind of spam attack AT ALL), and you're being an asshole about it. Nice job. Also, since you seem to be too stupid to understand: I didn't thank you, and never will thank people like you. And since you're retort is probably going to be ">Don't thank me< was meant sarcastically", how about go fuck yourself.

Aug 11 08:22 [raw]

[chans] work as designed. design goal is the opposite to fucking youtube: NO CENSORSHIP. this comes at a price, but censorship is just unacceptable, given that each and every cenaor is a huge abusing asshole.

Aug 13 05:29 [raw]

And as always, any suggestion to improve on shit like this gets absolutely no feedback and is ignored. *sigh*

Aug 13 07:52 [raw]

The suggestion was noticed, both by the devs and by the attackers. It really boils down to a matter of degrading one of the system fundamentals (uncompromised complete anonymity) in order to *maybe* strengthen a marginal property (group chats). You can imagine why some Bitmessage veterans are less excited about the idea than you seem to be. There are already plenty of group chat services and apps out there that support pseudonymous accounts and only require a captcha to sign up. They are faster, more manageable, better UX, cross-platform compatible and have a greater network effect than Bitmessage will EVER have. I use some of these services, and I even operated one in another life. There is only one Bitmessage - a decentralized peer-to-peer protocol for fully anonymous uncensored encrypted messaging. It's slow, clunky and ugly as fuck, but tell you what: it does its job remarkably well to carry messages securely from one peer to another, come hell or high water. I use Bitmessage for this, quite a lot. It's perfectly OK to use different tools for different jobs. Can Bitmessage ever be able to compete with the existing group chat services? Proudly FUCK NO, and that's by deliberate design. You see, in communication systems, some properties are incompatible with others, and that's definitely the case with the properties that make a group chat successful versus those that make an anonymous uncensored encrypted messenger successful. The recent attacks have shown that. Why sacrifice the system fundamentals in order to try (and fail) to turn it into something that it was never designed to be?

Aug 13 16:40 [raw]

I see your points, and at the same time I fail to see them fit together. You mention that it's purpose is to carry messages from one person to another, securely and fully encrypted, THEN it works well. I agree on this point. On the other hand, BitMessage features a channel mechanism, to allow public communication. And as we have been shown several times now, this concept holds up extremely poorly when actually exposed to humanity at it's worst. I just had to kill my BitMessage and rerun it after manually removing the general channel from the keys list, because it already spent over half an hour choking on the tens of thousands of one-letter spam messages, trying desperatelly to process them all and then stall itself while trying to flush every single one out to disk individually. And even if that didn't choke it, it would mean that a person would have to spend hours, combing through tens of thousands of messages, and take a look at every single one to see if it's not spam. You can't really claim this is not an issue. No normal mortal has that much time to waste if they seek to communicate in anonymous/pseudonymous, secure public channels. What I am saying is, FULL anonymity and uncensorability can not work well together in reality, without causing a shitstorm like we've seen several times. Either we are willing to accept this and do something about it (which, yes, will break FULL anonymity, but the extremely concerned citizen can still create multiple addresses, even though much harder, and use those), or we are unwilling to do something about it, but then we should at least be honest and agree that properly usable public communication is not part of BitMessages design goals. And if that is the case, then BitMessage is not something I consider useful. Which is sad, since it's a really interesting concept.

Aug 13 17:09 [raw]

Everyone, stop whining and repeat after me: "Why sacrifice the system fundamentals in order to try (and fail) to turn it into something that it was never designed to be?"

Aug 13 17:12 [raw]

Small addition: If you're using it to communicate one-on-one, anonymity is not exactly a core aspect at play here. You'd expect to talk to the same person, which means it'd be pseudonymous at best. If you'd use a channel to communicate "one-on-one", you'd have no means to guarantee you're talking to the same person, nor do you have any guarantee it won't turn into yet another mess. If you're using private channels, that means you've explicitly grouped a bunch of people, by whatever means, and invited them to this private channel. This is not an anonymous interaction, since this requires to be able to contact one specific person, even though you don't know who they are. Otherwise, the private channel turns into a public channel and the base assumption of privacy doesn't hold. Or, in short, what I mean is: The only point where full anonymity is actually any usefull IS in group chats. So if group chats are only a "marginal property", then what use is BitMessage to begin with? That's where I fail to see your points fit together.

Aug 13 17:42 [raw]

You're not helping. "it was never designed to be"? Usable?

Aug 14 05:23 [raw]

> BitMessage features a channel mechanism It does, as an ill-fitting afterthought feature which is not a realistic application of the Bitmessage protocol. It may even turn out to be a fatally flawed idea; I'm not smart enough to make this call, but let's just say I wouldn't be shocked. > we should at least be honest and agree that properly usable public communication is not part of BitMessages design goals Having read the whitepaper several times, I honestly agree with this statement. Public group chats were never part of the design goals. Please, Bitmessage stranger. Let's act rationally and not allow this marginal inconvenience to become a wedge issue. Bigger fish to fry.

Aug 14 11:09 [raw]

> one-on-one, anonymity is not exactly a core aspect Not necessarily. There are several important one-on-one cases where asymmetrical anonymity (one endpoint public, the other secret) is crucial. One example is information services that must protect one side of the communication, such as data brokers, anonymous tip lines or whistleblower services. More specifically, the cases when the recipient of the communication needs to provide a verifiable guarantee: "our BM address is well-known, published on our website and signed with our PGP key; any information sent to this address is provably anonymous as we are technically unable to identify the source" Another example is off-chain atomic trading of cryptocurrency tokens, or privacy applications like Coinjoin, where reusing an identifier can result in coin clustering. And probably more that don't come to mind right now. So, outside of the boring case of two IRL acquaintances using Bitmessage to chat 1-on-1, one key property of Bitmessage currently is anti-reidentification resistance. Limiting the users ability to create new addresses (via extreme POW requirements for new addresses etc) weakens this property. Is it a big deal? Not really up to me to decide. I'm just signaling so it doesn't get broken by accident.

Aug 14 18:06 [raw]

Bitmessage is cleverly-disguised malware.

Aug 14 18:23 [raw]

BM has a random rules. Fake nodes may forward messages or not. Good programmers may run many fake nodes and stop forwarding messages.

Aug 14 18:31 [raw]

Why are we arguing about this old stuff? Remove the C PoW module, and replace the PoW algorithm with cuckoo cycles or a combo of scrypt and argon, and target the difficulty and memory hardness to 15 minutes to send a message on a i7 processor with 8gb ram, about 30 min on a celeron with 4 gb ram. Fucking problem solved. Really, scrap the bitcoin pow, it's useless as a antispam measure. It needs memory bound function for anti-spam.

Aug 14 18:31 [raw]

The bitmessage devs did not design bitmessage to be usable. Maybe they designed it to use for their resume before applying to sigint jobs.

Aug 14 18:49 [raw]

because the devs have a secret agenda

Aug 14 23:52 [raw]

... and the mome raths outgrabe.

Aug 15 01:57 [raw]

This is a known problem in all swarm networks and successful mitigations exist. For example, opening multiple connections and changing peers often reduces the risk that any node or group of nodes becomes partitioned from the rest of the network for a long period. Remember, this is not a matter of bad nodes outnumbering the good ones, since you only need one good peer to route traffic around all bad peers. Even in a network with over 50% bad nodes, if you churn peers fast enough, you'll end up on a good node eventually, at which point you pick up all missed updates. Again: it's a swarm, not a democracy.

Aug 15 03:51 [raw]

the devs are not serious about bringing this product to market in a usable form or they would have already going on 6 years since first release someone is throwing monkey wrenches in the gears

Aug 15 10:32 [raw]

So BM should disconnect from the worst node. The worst node is the node that forward least of all.

Aug 15 10:46 [raw]

Not necessarily. Strangely, dumb (random) works better than smart (metric-based) peer-selection in this scenario. Metrics are easy to game, for example in this case having the sybil (bad) nodes send a lot of nonsense traffic to out-voice the good nodes and cause the latter to get disconnected as they "forward least of all". By way of contrast, randomness can't be gamed - everyone, bad and good, gets a fair shot, EVENTUALLY. :)

Aug 15 11:58 [raw]

Smart works better than dumb. Every node should forward every new message to the worst node at first. This will align the number of messages from every node. If the worst node don't forward to next node then it means it is bad node or too slow node. If your node will be normal then you have very minimal chance to be marked as a bad node.

Aug 16 19:20 [raw]

fuck your old pentium 4. get a modern computer, $35 single board, or repurpose a $30 smartphone.

Aug 16 19:23 [raw]

> the difficulty and memory hardness to 15 minutes to send a message on a i7 processor with 8gb ram, about 30 min on a celeron with 4 gb ram. Fucking problem solved. How am I supposed to send a message on my old Pentium 4 with only 2GB of memory?

Aug 16 19:24 [raw]

you don't dinosaurs extinct

Aug 16 21:10 [raw]

without memory hardness pow is useless spam prevention

Aug 17 07:31 [raw]

I recently rescued a 2006 Dell Inspiron 630m laptop and PSU from a skip. I have put 2GB of DDR2 PC-5300 memory into it, and changed the original processor for an Intel Pentium M Mobile 780 @ 2.26GHz. I've installed Windows 7 Enterprise 32-bit, and now it works better than when it was new. It's great for web surfing and email, and I've been using it for Boinc, Folding at Home and Prime 95. If your plans for harder POW go ahead then I don't think it'll be much use for Bitmessage.

Aug 17 07:42 [raw]

My cure was to go into my keys.dat file and change [chan] general from enabled = true to enabled = false. I'll re-enable it when the spam attack has finished.

Aug 17 10:52 [raw]

Wow that's an eclectic collection of apps.

Aug 17 14:03 [raw]

That get's computationally punishing for every single node rather quickly. In Coin-type networks that works, since a node has to compute one scrypt for a block every X seconds (or minutes). In bitmessage that computational load would be per object on the net. I.e. while it WILL increase the computational requirements for spamming massively, we should also try and estaminate how much this impacts every single node on normal usage.

Aug 17 18:36 [raw]

> If your plans for harder POW go ahead then I don't think it'll be much use for Bitmessage. You need to study "memory hard proof of work", "memory bound function," and then come back to the discussion. Memory hard proof of work leverages the system bottleneck of slow memory accesses. I have memory hard functions that will slow down your laptop and an asic or gpu would take days to prove one job.

Aug 17 22:58 [raw]

Have any of those ever produced something of value? I remember running the SETI screensaver but still waiting for the aliens to land on the White House lawn. They all seem to be a lot of fluff but no real results.

Aug 18 07:38 [raw]

I don't run SETI on Boinc. Their credits are too mingy! Try Asteroids@home. My rescued Dell laptop can earn over 1000 credits per day.

[chan] bitmessage

Subject Last Count
How do I benchmark bitmessage PoW Nov 15 22:13 3
Support request -- GPUs (Intel(R) HD Graphics IvyBridge M GT1) did not calculate correctly Nov 15 17:04 2
Spam... Nov 15 17:02 4
Ebola on the rampage in USA again Nov 13 06:47 1
ending the waffle Nov 13 04:56 7
Vuvuzela - anonymous messaging that scales to millions of users Nov 12 16:07 6
forwarding in BM Nov 12 15:04 5
Dear Freemasons Nov 12 07:13 2
CSS3 in Bitmessage interface Nov 12 06:56 1
Pastwatch & Aqua Distributed Version Control Nov 11 11:56 1
SOLUTION for spam Nov 11 11:56 23
Vuvuzela - Metadata-private messaging Nov 11 11:56 1
tes Nov 9 11:19 2
I'm back Nov 9 03:35 8
Bitmessage Network Health Report Nov 7 23:48 12
nodejs clientr KEWLIO Nov 7 07:26 4
Scalability Idea Nov 7 07:24 7
Do NOT spam Nov 7 03:09 8
here is the trick to run pyBM on a server without trouble Nov 5 18:41 8
Scalability Question?? Nov 5 09:09 3
re Re: Scalability Question?? Nov 5 08:21 1
aaa Nov 5 02:48 1
Bitmessage Plugins Nov 3 21:33 3
Any nodejs interface to the bitmessage api yet? Nov 3 19:12 2
Recent API status bug Nov 2 12:38 9
zero bundle -- 0net Nov 2 10:41 4
zero git on 0net Nov 1 12:43 6
(no subject) Nov 1 02:48 6
greetings Oct 31 23:05 3
Re: Oct 31 22:25 1
{ ^ } break { ^ } Oct 31 22:11 1
(no subject) Oct 31 14:33 4
INVALID FORMAT Oct 31 12:12 6
hello world Oct 31 07:40 1
Is there anybody out there? Oct 30 08:03 1
join the darknet - be badass at leakswldjpesnuvn.onion Oct 29 20:33 5
more cores, slower pyBM Oct 29 01:36 15
new bitboard thread Oct 27 17:17 3
http://leakswldjpesnuvn.onion seems stable Oct 27 16:36 1
spot the spammer Oct 27 09:37 3
oniontkryve46opu.onion Oct 27 09:01 2
3 BM websites and all fucked Oct 26 21:00 12
Newcomer Oct 26 18:36 10
135453 Oct 25 22:06 1
Stay in touch Oct 25 13:06 1
new BM site online Oct 25 10:39 3
134730 Oct 25 09:59 1
BM is flatlining : Oct 25 08:13 9
a new bitboard went online Oct 25 02:10 4
BM is flatlining : Oct 25 00:23 1
sql Oct 24 22:44 1
how I hacked BM Oct 24 22:11 3
--curses mode with bitboard crashy Oct 24 21:30 5
BMF bug Oct 24 04:21 1
onion4442sx7tvvk.onion ONION 444 new website for BM ! hot shit ! Oct 24 04:21 5
running pyBM as daemon on a remote server Oct 24 04:21 11
post with \ backskash Oct 24 04:21 1
BM is flatlining : 1200 bytes the average object Oct 24 04:17 2
how I hacked BM Oct 24 04:17 3
secret bin for Bitmessage people Oct 24 04:16 4
post with \ backskash Oct 24 04:11 1
anti-crash loop for BM Oct 22 06:53 2
actually, Oct 22 03:45 1
onion4442sx7tvvk.onion ONION 444 new website for BM ! hot shit ! Oct 21 21:49 1
magnet link publishing Oct 21 19:11 4
wanna hack a webserver ? free link here : Oct 21 07:16 17
cypherpunk Oct 21 06:54 5
leakswldjpesnuvn.onion relaunched and works like a charm ! Oct 20 22:49 1
leakswldjpesnuvn.onion relaunched and works like a charm ! Oct 20 20:44 1
new chan for BM site: http://leakswldjpesnuvn.onion/board/?chan=BM-2cVDWbAj3oftfGD1saBukfgGHDeUFKzNHc Oct 20 19:08 1
http://leakswldjpesnuvn.onion hot !!!! Oct 20 18:49 5
feature request Oct 20 08:04 3
http://leakswldjpesnuvn.onion Oct 20 04:36 1