Is there anybody out there?

Oct 14 00:26 [raw]

To defeat the spam flood in the chans: All users publish a broadcast address with high minimum PoW so spammer can't attack your address. Subscribe to each other's broadcast addresses. Broadcast all your posts from your broadcast addresses. Respond by broadcasting from your broadcast addresses. Everyone subscribed to your address will see your response and be able to respond via their own broadcasts, which you are subscribed to. You don't respond to the sending address; you respond by cutting and pasting into your own broadcast and replying there. With the higher PoW the spammer cannot attack. If he tries you blacklist the address he used and that's the last you hear from him. As you find more like broadcasts that you trust to be involved in the discussion you announce them from your broadcast as a courtesy. broadcast ===> BM-2cSmA3nNy2CnKN2Jmcexg6Eytgn9vLiDJg

Oct 14 00:26 [raw]

I requested developers to enable raising minimum chan PoW to 32 or 64. This would eliminate 80-90% of spam. Raising PoW to 128 eliminates 95% of spam. It takes much longer to send a message, from 30 to 45 minutes or more, but if you queue up your messages Bitmessage will work on them and send them while you're away.

Oct 14 14:06 [raw]

I concur, the best approach appears to be increasing of the difficulty. However, it is not just that, as there is no coordination mechanism to agree on a difficulty. If just arbitrarily raise it in a commit, people using older versions or other implementations won't be able to send to the chan, and people who use private chans (and are less exposed to a spam problem) will complain that it's taking too long. The addition that I proposed is that people who think a chan is in danger of being spammed will send a special message indicating that the difficulty should be increased (e.g. using a new object with extended encoding). The recipients will then use a formula to adjust the chan difficulty. This creates an approximate coordination mechanism. One such formula that could be used is that if a new difficulty change arrives, the chan difficulty is adjusted to old_difficulty (999/1000) + new_diifficulty_change / 1000 So, if I send a difficulty change specifying a difficulty of 50000, the chan difficulty is adjusted to 50. This message would have to be periodically sent anew when the old one expires. The difficulty adjustment messages woulnd't show up in the inbox, and you could send them by right-clicking the chan and choosing an item from the context menu. However I don't want to arbitrarily change things without feedback. This proposal would still cause problems for people using older versions, or people who join the chan after being synced. Peter Surda Bitmessage core developer

Oct 14 16:38 [raw]

Thank you. I like any possilbe solution. I stopped looking into this chan. I am just subscribed to Peter's address and sometimes check his messages just in case I am missing something important in the chan. So any try to solve the spam problem on chans will be very much welcome! Cheers!

Oct 14 17:36 [raw]

So implement proof of queue or total uptime like in emule.

Oct 14 22:49 [raw]

There's not really a need to have users concur on difficulty. Have an option (combo box) for four default increases in the chan creation dialog or in settings menu: Chan Spam Prevention Dialog ======================== opt 1: default 1000/1000 opt2: moderate 2000/4000 opt3: high 4000/8000 opt4: highest 8000/16000 The pow for smaller messages should be double that of larger messages Those with older clients who don't pay attention to the developer update broadcast should be the least concern. They clearly aren't subscribed to public chans and suffering for the spam, so they will not notice the changes.

Oct 14 22:50 [raw]

let's stop the bullshit with talking about the problem. somebody submit a patch and move forward already.

Oct 16 19:42 [raw]

The idea would work -- at first. You might paint Bitmessage into a corner with complexity. I suggest having optional memory-bound PoW on top of the base PoW that users can select and disable at will. Memory-bound PoW will stop spammers, especially in the dataset range of 256+ MB. With specialized hardware the GPU or processor cache cannot handle the bandwidth of the necessary memory accesses, even on expensive SRAM. To build custom equipment for this would cost tens of millions of dollars if at all possible thus it is a viable option and doesn't require special C code or special libraries; and it can be implemented in pure Python with pure statements and methods even without any imports. Even better (but objectionable for small devices) is huge memory binding, where a large dataset in the range of gigabytes is pseudorandomly permuted by nonce inputs then vector hashed. There is no special equipment at any budget that can attack this method. Not even NSA can attack it. But again the drawback is that who wants to devote 8 gb of storage space on their iphone for PoW? I would rather see a move toward simple memory-hard PoW rather than network-dependent complexity which could definitely end up being exploitable using sequential hashing PoW.

Oct 16 19:42 [raw]

@coffeedogs (github handles) is improving the code quality and helping on improving infrastruction, he has a lot of DevOps experience. @glitch started working on tests, and @surbhicis is working on an android port (we'll probably have a version available for testing later this week). Within the next couple of months we should have automated builds and better cross-platform testing, then it will be easier to contribute and create new releases. Then people can easily try various approaches to dealing with chan spam. I would like the automated builds to be available for anyone who forks the project on github. The code quality suite that I wrote should already be available for anyone who forked it, you just add it as a github app and that should be enough. It's a matter of priorities. I know that chan spam sucks but my vision has always been long term. Look at it this way, due to the spam attacks we have practical experience and can address it before more users come in. If it happened with a large number of users, and there was no DevOps infrastructure, that would have been much worse. There are other approaches to dealing with chan spam (e.g. the decentralised voting mechanism used by backfeed) however message difficulty adjustment is the easiest to implement and most consistent with the existing mechanism, as it only uses features already available, just combined in a different order. The extended encoding has in my opinion a solid design as well as tests are written for it, and the security vulnerability in 0.6.2 would have been caught with proper procedures, which now exist (automated checks as well as manual review). Also, I now code less and work more on higher level things, I studied how to improve software project management and try to get experts in the relevant areas. I also have some feedback regarding security audits. A full source code audit cost was estimated at around 100k, that's outside of my current budget but there are other alternatives. Peter Surda Bitmessage core developer

Oct 16 19:42 [raw]

What spam?

Oct 16 19:43 [raw]

You are correct, this is one of the risks. Which is in my proposal a difficulty change would cause a weighted adjustment (I think that 1/1000th sounds reasonable). To raise difficulty to 50, you'd have to create a message with difficulty 50000. To reduce it back to 1 you'd then have to send 999 messages with difficulty 50. Well, not exactly, that would reduce it to 1.049 but that's close enough. People interested in maintaining a a balanced difficulty could have a context menu option to auto-send adjustment messages if they think the difficulty is too far from optimum. So, to defend against one attacker with a lot of computational resources, multiple "moderators" can provide their own computational resources. Peter Surda Bitmessage core developer

Oct 16 19:43 [raw]

Interesting proposal. I wonder about the scenario where the attacker, instead of sending random dictionary noise messages at a rate of 2000/h, starts sending difficulty adjustment messages at the same rate, basically a sybil attack on the difficulty adjustment algorithm (to move difficulty up or down as needed). Would it lead to a better off or worse off situation for the honest players?

Oct 16 19:44 [raw]

Not strictly in reply to the OP, just another comment in the discussion thread. Chans are not Bitmessage. Chans are just a hack on top of core Bitmessage; a clever hack but still a hack. Since the recent attacks are only effective against chans rather than core Bitmessage, it makes more sense to tweak the properties of the chans. I would rather have chans overloaded with further hacks like the one proposed by Peter to retain a modicum of usability, and keep the core Bitmessage protocol clean and simple. Clean and simple is a fundamental property of Bitmessage, double-sha pow and all. Medium-term I expect that someone will design from scratch a new type of decentralized chat running on top of core Bitmessage, to give users an alternative to the existing chans. I expect this (hypothetical) new design to come with its own strengths, weaknesses and attacks, and further tweaks and so on. In the end, the strongest design(s) will win the majority of the userbase, while the weaker ones will remain for niche applications and legacy clients. That's the way that open source works. In order to do this, once again, we first need to leave the protocol fundamentals alone. Stop tweaking, start building.

Oct 16 19:44 [raw]

> There's not really a need to have users concur on difficulty. Have > an option (combo box) for four default increases in the chan > creation dialog or in settings menu: That doesn't fix the problem. People who select higher difficulty will not receive messages from people who select lower difficulty, and they have no way to signal to each other what they expect or use. Peter Surda Bitmessage core developer

Oct 16 19:44 [raw]

> I would rather have chans overloaded with further hacks like the one proposed by Peter to retain a modicum of usability, and keep the core Bitmessage protocol clean and simple. This is why user must be able to toggle any new PoW schemes on / off at will. Building them into the protocol exposes risk of exploitation / manipulation

Oct 16 19:46 [raw]

forget it. just let the spam flow.

Oct 18 14:31 [raw]

I also thought of some difficulty adjustment mechanism and what "distributed moderator" mentioned in whitepaper could look like. Here is my suggestions. Let's define a target_rate and excess value for chans, for example 100 msg/m and 10%. Then each node reading some chans can measure actual rate and calculate a difficulty factor: actual_rate/target_rate for each chan. All messages to that chan having requiredNonceTrialsPerByte = networkDefaultProofOfWorkNonceTrialsPerByte * factor will be delivered and this difficulty will be used to send messages to that chan. Adjust that value every 5 min. Decrease rating for any node sending many messages (to particular chan) with lower difficulty. Other messages could be placed into special queue of length target_rate * 5 and sorted ascending by TTL and descending by POW. Every minute the node will put actual_rate * 0.1 messages from excess queue to inbox (and maybe half of that amount - to invQueue). Any more messages in excess queue read by user and not deleted will be put into invQueue. When #1010 implemented it will be possible to have special tag 'spam' set by user or some filter plugin. Messages with that tag will be deleted from invQueue. Any criticism is welcome.

Oct 18 14:49 [raw]

I also thought of some difficulty adjustment mechanism and what "distributed moderator" mentioned in whitepaper could look like. Here is my suggestions. I don't want to invqueue, the context menu. It, I also thought of the context menu. To each other's broadcast and be put into special queue of some difficulty of the addition that I concur, send a difficulty of spam set by right clicking the chan difficulty: of the addition that could look like broadcasts, that tag queue read by TTL and sorted ascending by user and send them and maybe half of that amount to invqueue; Any more, but if you respond it's taking too long; your messages woulnd't show up in excess value for example msg Other messages woulnd't show up in whitepaper could look like. Any more messages woulnd't show up? Everyone subscribed to This message from your This proposal would have to be involved in the spam. However I send a spam problem, will be deleted will be able to inbox and what distributed moderator mentioned in excess value for example msg Other messages in whitepaper could be involved in whitepaper could be work on a spam. When the spam problem, will work on a difficulty is welcome: node will be involved in excess queue to have special queue to be periodically sent anew when the inbox, and that's the difficulty of the last you trust to arbitrarily raise it, takes much longer to be put into invqueue: Any more but if you blacklist the chan difficulty adjustment mechanism and what distributed moderator mentioned in the context menu. After being synced. Subscribe to be possible placed into special queue to send a message from your response and maybe half of some difficulty is it is not deleted will put into invqueue: Any more, like broadcasts that tag will work on: a difficulty adjustment mechanism and what distributed moderator mentioned in to a difficulty adjustment is welcome. Here is that I have special queue read by right clicking the best approach appears to be deleted will be able to send them from invqueue. Any criticism is welcome.

Oct 30 08:03 [raw]

This would cause problems for people who aren't connected 24/7. Minor problems in general as well, as messages often arrive out of order and with arbitrary delays. However, the main problem is user preference. For some chans, a higher message rate isn't spam but expected. The users need to be given the ability to determine what level of protection they want in which chan. Admittedly, it's a bigger challenge, but I don't want to make random decision on users behalf. Maybe there could be also a better mechanism for reporting user feedback to me. Rate limiting is often used by SMTP servers, there it makes more sense. Peter Surda Bitmessage core developer

[chan] bitmessage

Subject Last Count
claws-mail + pyBM + Gtk3 - minitool Feb 19 21:05 7
claws-mail + pyBM + Gtk3. Feb 19 19:58 8
End of support for Windows XP for binary builds Feb 19 10:13 21
None of this is connectd Feb 17 23:58 1
Unextreme and unrelated fish pie Feb 17 23:53 1
Stalin - the greatest guy ever Feb 17 17:56 2
UK Column News - 22nd February 2019 Feb 17 17:30 1
UK Column News - February 22 2019 Feb 17 17:29 1
UK Column News - 21 February 2019 Feb 17 17:27 1
UK Column News - 21st February 2019 Feb 17 17:22 1
UK Column News - February 21 2019 Feb 17 17:21 1
UK Column News - 20th February 2019 Feb 17 17:18 1
UK Column News - February 20 2019 Feb 17 17:16 1
UK Column News - 20 February 2019 Feb 17 17:15 1
UK Column News - February 19th 2019 Feb 17 17:14 1
UK Column News - 18 February 2019 Feb 17 17:10 1
UK Column News 19th - February 2019 Feb 17 17:09 1
UK Column News 19th February 2019 Feb 17 17:08 1
UK Column News - 18th February 2019 Feb 17 17:07 1
Stalin - the greatest guy ever Feb 17 15:43 1
cool BM things in the making Feb 17 12:33 9
NEW python3.7 -- this neat lil editor will kill EMACS for good ! new native dialog feature Feb 17 01:53 2
how to use mailing list...? Feb 17 01:51 4
Security Nightmares: hidden WebTorrent client in web advertisements to provoke copyright cease-and-desist fines Feb 16 21:23 1
End of support for Windows XP for binary builds -- ISO of a live distro Feb 16 08:01 1
UK Column News - 11 February 2019 Feb 10 11:07 5
come on guys, leak some more shitwarez Feb 10 07:28 14
DJ Bernstein sightings on Bitmessage Feb 10 06:57 3
UK Column News - February 12 2019 Feb 9 21:19 1
UK Column News - February 12th 2019 Feb 9 21:19 1
UK Column News - 12th February 2019 Feb 9 21:16 1
UK Column News - 11th February 2019 Feb 9 21:14 1
UK Column News - 9th February 2019 Feb 9 21:13 1
UK Column News - February 2019 7th Feb 7 07:45 2
UK Column News - 7 2019 February Feb 7 07:42 1
UK Column News - 2019 February 7th Feb 7 07:40 2
UK Column News - February 7th 2019 Feb 7 07:37 2
UK Column News - 2019 February 7 Feb 7 07:35 2
UK Column News - February 7 2019 Feb 7 07:29 1
UK Column News - 7th February 2019 Feb 7 07:26 3
UK Column News - 7 February 2019 Feb 7 07:25 1
UK Column News - 6th February 2019 Feb 2 15:57 3
UK Column News - 5th February 2019 Feb 2 15:57 4
UK Column News - 4th February 2019 Feb 2 15:57 5
what does dandelion: 90 do? Feb 1 11:42 7
stop test penis, please. it's OK Jan 30 09:39 4
Call to murder Angela Merkel, Emmanuel Macron, Petro Poroshenko, Jens Stoltenberg etc. Jan 27 21:49 1
dammit ! dang nigger pranked Dr. David Duke Jan 27 19:37 2
djurlite enacting Jan 27 00:00 1
Reversed shot upper value Jan 26 23:59 1
Normal drilling mud circulation buffer gas Jan 26 22:18 1
Power monitor homotopy boundary Jan 26 21:25 1
Pelerine point subtract counter Jan 26 21:25 1
Teeth misalignment country setting Jan 26 21:24 1
Crankous jam radio station Jan 26 21:23 1
extrusion nozzle methanol treatment Jan 26 21:23 1
Older the hyperarial Jan 26 21:23 1
Defects survey positive muon Jan 26 21:23 1
Townships hearth gas Jan 26 21:23 1
Transversal equalizer on pentalpha Jan 26 21:18 1
Salmoncoloured obtain circuit Jan 26 21:18 1
serializer firm support Jan 26 21:18 1
depredation for petroleum series Jan 26 21:11 1
Plotting camera the reeving system Jan 26 21:06 1
Conventional weapons for jack bar assembly Jan 26 20:59 1
operationally ready well sinking Jan 26 20:59 1
Tympan franzise Jan 26 20:58 1
Equipment status chart with frequency sounding Jan 26 20:58 1
Difference construction the alette Jan 26 20:52 1
Vitality rotten Jan 26 20:51 1
Multiloquence progressive fracture Jan 26 20:50 1
automatic backspace assemble editing continuous decomposition Jan 26 20:47 1
Summer oil level platy Jan 26 20:43 1
Approximative limit paramour Jan 26 20:43 1
Card file beddable Jan 26 20:38 1
Damage accumulation then hot leveling Jan 26 20:38 1
Frequency analysis method headless resistor Jan 26 20:38 1
Roundsman the outweigh a disadvantage Jan 26 20:38 1
Trustor with grounded sea ice Jan 26 20:38 1
Military law forest shelter belt Jan 26 20:38 1
tunnel cathode bring in evidence Jan 26 20:27 1
Vacuum melted alloy job control program Jan 26 20:19 1
Duplicate insulator string nuclear magnetic resonance log Jan 26 20:19 1
Linear parameter the underinvoicing Jan 26 20:19 1
Namesake oxygenated oil Jan 26 20:19 1
Echo chamber positive function Jan 26 20:19 1
Plasma belt amoebosis Jan 26 20:18 1
Film cartridge resign management Jan 26 20:18 1
Local optimization the equicontinuous group Jan 26 20:18 1
Approximate root hereditaments Jan 26 20:11 1
Peppering loop body Jan 26 20:05 1
Winged hollow reamer limiting formation factor Jan 26 20:01 1
Bottom cut on activated fins Jan 26 19:59 1
Paradox of thrift impenetrable Jan 26 19:58 1
delay decision fluidized bed Jan 26 19:58 1
Wall bushing hygienic enamel Jan 26 19:57 1
Wellmannered the mesic Jan 26 19:56 1
Incommunicative the waste rock Jan 26 19:56 1
Shopwindow marlstone limestone Jan 26 19:55 1
Rotary bed the noncyclic trajectory Jan 26 19:55 1