Welcome, Guest. Please login or register.

Author Topic: New Bitmessage protocol version 3  (Read 38779 times)

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 381
  • Karma: +57/-3
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #150 on: September 08, 2014, 05:24:40 PM »
Thomas,
Now pubkeys aren't going through at all.. for an hour. Are you sure that you added wiggle-room in the correct direction? The wiggle room for objects should make them more acceptable (by an hour) not less acceptable.
Also, I'm not getting error messages. I don't know whether you implemented them.

Tested using the debug node.

Thomas

  • Sr. Member
  • ****
  • Posts: 253
  • Karma: +28/-0
    • View Profile
    • bitmessaged is a bitmessage daemon (node) with an open plugin interface written in C++
Re: New Bitmessage protocol version 3
« Reply #151 on: September 09, 2014, 02:33:12 AM »
I checked again and no, I think I made it correct. And you are right, I've not yet implemented the error message.

But as it doesn't work there must be a bug somewhere  :(

The problem is, that I cannot test myself, because I've no test environment. The debug server is a very poor test method, because I've very limited access to it.
It would be easy, If I could run the tests on my development PC, where I've access to the console and can easily replace the daemon with a new version.
Let's see, what we can do:

  • We "meet" at a certain date for a "test session". I can debug on my side and your on yours.
  • I build my own test environment
  • You have a test client which I can use

Building my own test environment is not such complicate. But probably I would generate only objects I understand, and probably they will work.

If we try to organize the "test meeting" when would be a good time? I not even know, in which time zone you live (I'm in Germany).
So maybe we find some hours this weekend?

Or I could implement a test environment as "plugin" for the daemon. Could you send me a set of test objects as binary files? So I would make a test "plugin" which reads the files, actualizes the time and the POW and send them to the database of the daemon.

By the way: The daemon has to notify, which objects are already translated. For that it calculates the MD5SUM over the payload of the objects (payload without nonce and time). So identical objects are not bridged twice.
« Last Edit: September 09, 2014, 02:34:58 AM by Thomas »

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1261
  • Karma: +75/-7
  • bitmessage.ch and timeservice operator
    • View Profile
    • AyrAs Homepage
Re: New Bitmessage protocol version 3
« Reply #152 on: September 09, 2014, 07:14:29 AM »
... For that it calculates the MD5SUM over the payload of the objects (payload without nonce and time). So identical objects are not bridged twice. ...

MD5 is broken. if you want to have fun yourself, you can visit this site for examples and practical scenarios
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 381
  • Karma: +57/-3
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #153 on: September 11, 2014, 06:40:54 PM »
We can coordinate via PM.

UncleAndy

  • Newbie
  • *
  • Posts: 4
  • Karma: +1/-0
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #154 on: September 15, 2014, 05:42:08 AM »
Hi, all!

Sorry, I not read previos messages, but read "Protocol specification v3". But I not undestend - do you have plan for include flow control in  new protocol? Is it posible? For example, send messages with large PoW before messages with low PoW? With posibility for set PoW larger then required for receiver.

May be, additional dificult for PoW possible calculate on client depending on the network activity. Becouse every client node have full network activity at every time.
« Last Edit: September 15, 2014, 09:00:35 AM by UncleAndy »

Atheros

  • Lead Bitmessage developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 381
  • Karma: +57/-3
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #155 on: September 15, 2014, 01:38:04 PM »
It would be possible to add that without any sort of explicit protocol upgrade. Currently, nodes which need to get objects request them randomly. They could instead request them in the order that they hear about them. Then on the sending side, nodes could order objects in inv messages by the strength of the POW instead of randomly like they do now. Ultimately the only reason to do this would be to not relay some objects with a low POW. That part should get figured out also if any of this actually starts getting implemented. That part would be quite a large protocol change.

RAHGK

  • Guest
Re: New Bitmessage protocol version 3
« Reply #156 on: September 16, 2014, 02:11:50 PM »
It would be possible to add that without any sort of explicit protocol upgrade. Currently, nodes which need to get objects request them randomly. They could instead request them in the order that they hear about them. Then on the sending side, nodes could order objects in inv messages by the strength of the POW instead of randomly like they do now. Ultimately the only reason to do this would be to not relay some objects with a low POW. That part should get figured out also if any of this actually starts getting implemented. That part would be quite a large protocol change.

I don't think the goal would have to be to strictly "not relay some objects with a low POW"...just delay them until there is sufficient resources in the network to deliver them.

Of course if they are delayed too long then they will ultimately expire and get dropped from the relay queue, which is just fine because it gives originators of messages an incentive to provide enough computational resources for the network to function (instead of freeloading as spammers) AND this incentive automatically adjusts as more resources are needed so that clients originating messages could, for example, automatically increase their POW whenever an unacceptably high percentage of their outgoing messages start failing to receive acknowledgements.

UncleAndy

  • Newbie
  • *
  • Posts: 4
  • Karma: +1/-0
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #157 on: September 17, 2014, 08:57:15 AM »
I don't think the goal would have to be to strictly "not relay some objects with a low POW"...just delay them until there is sufficient resources in the network to deliver them.

Yes. I mean that case.

stevegee58

  • Newbie
  • *
  • Posts: 45
  • Karma: +4/-0
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #158 on: September 20, 2014, 08:35:47 AM »
It's nice to see riseup.net connected to my Version 3 client.

Thomas

  • Sr. Member
  • ****
  • Posts: 253
  • Karma: +28/-0
    • View Profile
    • bitmessaged is a bitmessage daemon (node) with an open plugin interface written in C++
Re: New Bitmessage protocol version 3
« Reply #159 on: September 20, 2014, 08:52:27 AM »
What does this mean?

stevegee58

  • Newbie
  • *
  • Posts: 45
  • Karma: +4/-0
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #160 on: September 20, 2014, 09:10:36 AM »
It means that privacy-oriented email services are interested in BitMessage V3!
I just saw ipredator.se (another privacy email service) connected to me as well.

AyrA

  • BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1261
  • Karma: +75/-7
  • bitmessage.ch and timeservice operator
    • View Profile
    • AyrAs Homepage
Re: New Bitmessage protocol version 3
« Reply #161 on: September 20, 2014, 09:55:39 AM »
ipredator and riseup provide VPN services, so you probably saw a user of those services connecting.
My Address: BM-Bc7Rspa4zxAPy9PK26vmcyoovftipStp
Bitmessage Time Service (Subscribe): BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
Support the Multipart Message Declaration Draft for Bitmessage: https://bitmessage.org/forum/index.php/topic,1553.0.html
Free Bitmessage to E-Mail Gateway: https://bitmessage.ch

p2pmessage

  • Newbie
  • *
  • Posts: 40
  • Karma: +4/-5
  • https://github.com/p2pmessage/PyBitmessage/
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #162 on: September 24, 2014, 07:11:22 PM »
How does the creator of the V3 protocol expect to retain messages for 28 days when we don't even have sufficient network resources to deliver V2 messages for 2.5 days?

We need to stop adding new features until after we get the basics working. V3 protocol isn't going to work nor is the Android client.

Thomas

  • Sr. Member
  • ****
  • Posts: 253
  • Karma: +28/-0
    • View Profile
    • bitmessaged is a bitmessage daemon (node) with an open plugin interface written in C++
Re: New Bitmessage protocol version 3
« Reply #163 on: September 25, 2014, 02:32:31 AM »
How does the creator of the V3 protocol expect to retain messages for 28 days when we don't even have sufficient network resources to deliver V2 messages for 2.5 days?
We need to stop adding new features until after we get the basics working. V3 protocol isn't going to work nor is the Android client.

V3 protocol was invented, mainly because V2 can be attacked very easy by a "confusing node". That is, because the object types are not included in the messages itself in V2. So if a node just mixes up object types, this messages are lost.

You can lookup the "confusing node" here: http://buildbot.dyn.astade.de:8080/view/bitmessaged/job/bitmessaged/lastSuccessfulBuild/artifact/model/Components_bitmessaged/Component_bitmessaged/Config_Linux/html/spoofing_nodes.html

Along with this change, we decided to calculate the POW difficulty analog with the time to life. This was not intended to let messages life for 28 days (the POW gets extremely difficult in that case), but to give weak devices, like smart phones, the possibility to let messages live only for 60 minutes (and get an easy POW for that). 28 days as maximum is intended for keys, which are 28 days already in V2 of the protocol.

If the current spammer would like to flood the network with something that is stored for 28 days, he could easily do this even in V2 protocol, by using pubkey objects, instead of broadcasts. They are stored for 28 days and have not even a more difficult POW!

Beside that, you mix up something: delivering messages for 2.5 days or for 25 days needs (nearly) the same network resources (It needs ten times more storage resources).
« Last Edit: September 25, 2014, 02:43:52 AM by Thomas »

adamduzz

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: New Bitmessage protocol version 3
« Reply #164 on: December 28, 2017, 11:29:33 AM »
The new version of Bitcoin protocol is very easy to use.

I usually use this character count tool to count words and characters.