Bitmessage Installation Instructions Fedora 20

Discussion in 'Bitmessage' started by DarkLight, Feb 18, 2014.


  1. DarkLight

    DarkLight I self identify as a Blackhawk Attack Helicopter! Site Supporter

    Updated instructions in Post #3: Bitmessage Installation Instructions Fedora 20

    This thread will be for walk-throughs of the instructions that can be found at Compiling instructions - Bitmessage Wiki I'm shamelessly copying their work here as a basis for these How-Tos.

    Fedora 20

    Fedora 20 is proving to be an interesting animal as this is the second How-To I've written that is basically just for this distribution. The biggest issue with Fedora (18 and after) is that RedHat has hobbled the OpenSSL package due to a perceived patent issue. I say perceived because RedHat had a knee jerk reaction over something someone said (no legal threat has EVER been made to the best of my knowledge) and rather than do the due diligence and research the issue and then correct the problem, they have chosen to ignore it.

    In RedHat's defense, they have re-enabled the minimal necessary functionality to the OpenSSL crypto libraries in order to get the Bitcoin wallet running but that's it. Specifically, they are refusing to do any work to re-enable ECC or Elliptic Curve Cryptography (not going to go into it now). This capability, unfortunately, is required for bitmessage to function.

    So, enough with the background and on to the walk-through.

    You need to know the root user password in order to install RPM packages. After each command you will be prompted for the root user password. As such, run them one at a time.

    As mentioned earlier, the OpenSSL that is installed by default (and maintained by RedHat/the Fedora Project) prevents bitmessage from running. The next two commands install RingingLiberty YUM repository, a version of the OpenSSL crypto libraries with ECC enabled (to an alternate location) and some additional, required supporting applicatoins.

    Code:
    *** This command installs the RingingLiberty YUM repository ***
    su -c 'yum install -y http://linux.ringingliberty.com/bitcoin/f18/x86_64/bitcoin-release-1-4.noarch.rpm'
    
    *** This command adds the required supporting apps/programs, namely Python and the unhobbled OpenSSL***
    su -c 'yum install -y python python-qt4 git openssl-compat-bitcoin-libs'
    
    There will most likely be additional packages installed as dependencies.

    Once the install of the above packages is complete, you will need to pull down the actual Python (programming/scripting language) program for bitmessage. Unlike the bitmessage website, it is suggested that you pull this down into a centralized/shared location. Each user who runs bitmessage will have their own configuration folder so it makes sense not to have bitmessage "installed" under your user's home directory.

    Code:
    *** This command synchronizes the PyBitmessage code from the external, centralized repository, to your computer into a shared location ***
    su -c 'git clone https://github.com/Bitmessage/PyBitmessage /opt/PyBitmessage'
    
    Lastly, if you've compared my notes with the official page, you will notice that we haven't set any environment variables. That's for a VERY GOOD REASON. The original instructions are wrong and my edit's show up AFTER the original instructions.

    Instead of setting a global variable that will cause ALL SSL/SSH/Secured communications and tasks to use the modified OpenSSL libraries, we should create what is called a wrapper script to confine our environment change to ONLY affect the app that needs it.

    Code:
    *** The following is a single line and sets a "local" variable ***
    su -c 'echo export LD_LIBRARY_PATH=\"\/opt\/openssl\-compat\-bitcoin\/lib\$\{LD_LIBRARY_PATH:+:\$LD_LIBRARY_PATH}\" >> /usr/bin/bitmessage.sh'
    *** The following (all one line) should be the path to the main PyBitmessage program ***
    su -c 'echo \/opt\/PyBitmessage\/src\/bitmessagemain.py \> \/dev\/null 2\>\&1 \& >> /usr/bin/bitmessage.sh'
    
    Next, you need to make the wrapper script executable.

    Code:
    su -c 'chmod 755 /usr/bin/bitmessage'
    
    Finally, you should be able to run the bitmessage wrapper script from anywhere by simply typing "bitmessage" (without the quotes) since /usr/bin is in everyone's path by default.
     
    Last edited by a moderator: Sep 10, 2014
    BTPost likes this.
  2. BTPost

    BTPost Old Fart Snow Monkey Moderator

    Great work, DarkLight....
     
  3. melbo

    melbo Hunter Gatherer Administrator Founding Member

    I've made some updates to the above based on newer versions of the ringingliberty package.
    Working flawlessly on my F20 install.

    Short form :)

    This command installs the RingingLiberty YUM repository
    Code:
    su -c 'yum install -y http://linux.ringingliberty.com/bitcoin/f20/x86_64/bitcoin-release-1-6.noarch.rpm'

    This command adds the required supporting apps/programs, namely Python and the unhobbled OpenSSL
    Code:
    su -c 'yum install -y python python-qt4 git openssl-compat-bitcoin-libs'

    This command synchronizes the PyBitmessage code from the external, centralized repository, to your computer into a shared location
    Code:
    su -c 'git clone https://github.com/Bitmessage/PyBitmessage /opt/PyBitmessage'

    The following is a single line and sets a "local" variable
    Code:
    su -c 'echo export LD_LIBRARY_PATH=\"\/opt\/openssl\-compat\-bitcoin\/lib\$\{LD_LIBRARY_PATH:+:\$LD_LIBRARY_PATH}\" >> /usr/bin/bitmessage.sh'

    The following (all one line) should be the path to the main PyBitmessage program
    Code:
    su -c 'echo \/opt\/PyBitmessage\/src\/bitmessagemain.py \> \/dev\/null 2\>\&1 \& >> /usr/bin/bitmessage.sh'

    Last, you need to make the wrapper script executable.
    Code:
    su -c 'chmod 755 /usr/bin/bitmessage.sh'

    Now run bitmessage.sh from any terminal. I created a gnome menu icon with menulibre.
     
    Last edited: Sep 8, 2014
    BTPost likes this.
  4. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Updating Bitmessage if installed as above is trivial:
    Code:
    cd /opt/PyBitmessage
    sudo git pull



    0.4.4 was recently released and is a mandatory update (by 11-16-2014) as the protocol has moved to v3:
    All objects sent on the network should support protocol v3 starting on Sun, 16 Nov 2014 22:00:00 GMT.

    Protocol specification v3 - Bitmessage Wiki
    This is a DRAFT for the protocol version 3. It describes the changes in protocol version 3 versus version 2. Things which are unchanged from version 2 are not described in detail. So you should use the current protocol specification, which includes the version 3 changes, as a reference for all formats which are not mentioned in this description.

    New features in version 3
    Here are the new features of the version 3 of Bitmessage protocol in keywords:

    • object type is now coded inside the message
    • objects may have a variable time to live
    • The POW is more difficult but can be easier if you lower the time to live
    • The protocol is tolerant for further message extension
    • The protocol is tolerant for further object extension
    • A lower maximum object size


    Common structures
    Variable length integer
    The shortest possible encoding MUST be used. In version 2 the decimal value 10 could be encoded as 0x0A, 0xFD000A, 0xFE0000000A, or 0xFF000000000000000A. In version 3 only the shortest representation, 0x0A, is allowed. The 9-byte form is no longer useful and SHOULD NOT be used.

    Here is an example address which uses malformed varints: BM-CVA3RC7Mvy7JDNSpQChktwrSe4KNMaEdDdcymfUo. This address is invalid.



    Message types
    Most message types are unchanged from version 2 to version 3. Only the four "objecttype" messages are not valid any more. They are summarized into one single message.

    version
    The version message is identical to version 2 version message.

    verack
    The verack message is identical to version 2 verack message.

    addr
    The addr message is identical to version 2 addr message.

    inv
    The inv message is identical to version 2 inv message.

    getdata
    The getdata message is identical to version 2 getdata message.

    error
    Version 3 of the protocol defined a special error (or debug) message. This message may be silently ignored (and therefor handled like any other "unknown" message). The message is intended to inform the other node about protocol errors and can be used for debugging and improving code.

    Field SizeDescriptionData typeComments
    1+fatalvar_int
    This qualifies the error. If set to 0, than its just a "warning". You can expect, everything still worked fine. If set to 1, than it's an error, so you may expect, something was going wrong (e.g. an object got lost). If set to 2, it's a fatal error. The node will drop the line for that error and maybe ban you for some time.

    1+ban timevar_int
    If the error is fatal, you can specify the ban time in seconds, here. You inform the other node, that you will not accept further connections for this number of seconds. For non fatal errors this field has no meaning and should be zero.

    1+inventory vectorvar_str
    If the error is related to an object, this Variable length string contains the inventory vector of that object. If the error is not related to an object, this string is empty.

    1+error textvar_str
    A human readable string in English, which describes the error.

    Unsupported messages
    If a node receives an unknown message it must silently ignore it. This is for further extensions of the protocol with other messages. Nodes that don't understand such a new message type shall be able to work correct with the message types they understand.

    Maybe some version 2 nodes did already implement it that way, but in version 3 it is part of the protocol specification, that a node must silently ignore unsupported messages.

    Object type
    The four former object types "getpubkey", "pubkey", "msg" and "broadcast" are summarized into a single Message type "object". The four Messages as they did exist in version 2 protocol are not valid any more.

    Objects are shared throughout a stream. A client should advertise objects until their end of life time is reached. To be a valid object, the Proof Of Work has to be done.

    Field SizeDescriptionData typeComments
    8POW nonceuint64_t
    Random nonce used for the Proof Of Work

    8timeuint64_t
    The "end of life" time of this object (be aware, in version 2 of the protocol this was the generation time). Objects shall be broadcast until its end of life time has been reached. The node shall store the inventory vector of that object for at least another hour to avoid reloading it from another node with a small time delay. The maximum value for the "time to life" of an object is 28 days. so the "end of life time" is 28 days in the future at maximum.

    4object typeuint32_t
    This field specifies the content of the object. Valid values are (at the moment) 0-"getpubkey", 1-"pubkey", 2-"msg", 3-"broadcast". all other values are reserved. Nodes shall transport objects with unknown types, too. This will make further protocol changes more easy.

    ?payloaduchar[]
    This field varies depending on the object type. For a detailed description of their content refer to version 2 object types



    Proof of Work
    Generally the POW is done exactly like in version 2

    The "target" (the difficulty of the POW) is defined a little bit lower (more difficult) in version 3. This is, because practice did show, it is to easy to flood the network with data. In addition to that it is possible in version 3 to lower the time to live of a message (for example when doing a live chat) and getting an easier POW for that.



    [​IMG]

    payloadLengthExtraBytes = 1000

    nonceTrialsPerByte = 1000

    Maximum object size
    In version 2 the maximum object size was defined to be 170 MBytes. This object size is totally unrealistic for a normal use (POW), but is perfectly for a network attack. It will be to big to handle for clients with low bandwidth. Currently an average bitmessage "msg" object has the size of 2 kBytes. So version 3 limits the objects to a maximum size of 256 KiB(the payload of the object, starting from the POW nonce can have 262144 bytes at maximum).
    0.4.4
    • Added ability to limit network transfer rate
    • Updated to Protocol Version 3
    • Removed use of memoryview so that we can support python 2.7.3
    • Make use of l10n for localizations
     
    Last edited: Oct 22, 2014
  5. BTPost

    BTPost Old Fart Snow Monkey Moderator

    Nice, thanks for Posting this...
     
  1. melbo
  2. melbo
  3. DarkLight
  4. Witch Doctor 01
  5. melbo
  6. DarkLight
  7. kckndrgn
  8. melbo
  9. BTPost
  10. melbo
survivalmonkey SSL seal        survivalmonkey.com warrant canary
17282WuJHksJ9798f34razfKbPATqTq9E7