Bitcoin Forum
July 22, 2019, 10:57:53 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23 24 25 26 27 28 »
  Print  
Author Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin  (Read 89527 times)
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 555

BitShares


View Profile WWW
September 11, 2013, 09:42:17 PM
 #421

I see no reason why BitMessage insists on addresses being a hash of the public key rather than the actual public key.  It isn't like anyone can remember or will manually type in the address.  This would allow you to get rid of the entire discovery step.

I believe this sort of hashing is helpful for spam prevention.  In a network of this type, an identifier is needed for determining whether or not a message is intended for a specific peer, so that the peer can then retrieve and decrypt it.  If a public key is used as an identifier, any peer could simply monitor the network, scrape these keys, and send out spam messages for the user to decrypt.  If a hash is used instead, not only can a peer still identify that a message is for him, but he can reject any messages that fail to decrypt properly, as a result of spam bots not knowing his public key.

With this is in mind, users still need a way of securely sharing public keys, while minimizing spam to the simplest of problems, that problem being whether or not you want to speak to someone.  I propose such a way in the Bitmask paper with regards to permission packets and identity profile messages.  Think of it as using skype, and only accepting communication from either those who have added you to their list of contacts, or vice-versa.

Exactly, this is what we are doing with Project Quixote.  Operates like skype. 

Spam is prevented by proof-of-work and reputation of sender.

https://steemit.com  Blogging is the new Mining
1563793073
Hero Member
*
Offline Offline

Posts: 1563793073

View Profile Personal Message (Offline)

Ignore
1563793073
Reply with quote  #2

1563793073
Report to moderator
1563793073
Hero Member
*
Offline Offline

Posts: 1563793073

View Profile Personal Message (Offline)

Ignore
1563793073
Reply with quote  #2

1563793073
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563793073
Hero Member
*
Offline Offline

Posts: 1563793073

View Profile Personal Message (Offline)

Ignore
1563793073
Reply with quote  #2

1563793073
Report to moderator
1563793073
Hero Member
*
Offline Offline

Posts: 1563793073

View Profile Personal Message (Offline)

Ignore
1563793073
Reply with quote  #2

1563793073
Report to moderator
1563793073
Hero Member
*
Offline Offline

Posts: 1563793073

View Profile Personal Message (Offline)

Ignore
1563793073
Reply with quote  #2

1563793073
Report to moderator
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
September 11, 2013, 10:40:51 PM
 #422

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.
Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

I have attempted to use Freenet's mail... it doesn't work!



I wasn't necessarily suggesting Freenet as a solution, (I for one have developed an irrational loathing of Java), but it does serve as one example of a well reviewed body of research that could be used as a basis for the development of a BitMessage2 protocol. There are plenty of others.
jashper
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
September 11, 2013, 11:01:31 PM
 #423

I see no reason why BitMessage insists on addresses being a hash of the public key rather than the actual public key.  It isn't like anyone can remember or will manually type in the address.  This would allow you to get rid of the entire discovery step.

I believe this sort of hashing is helpful for spam prevention.  In a network of this type, an identifier is needed for determining whether or not a message is intended for a specific peer, so that the peer can then retrieve and decrypt it.  If a public key is used as an identifier, any peer could simply monitor the network, scrape these keys, and send out spam messages for the user to decrypt.  If a hash is used instead, not only can a peer still identify that a message is for him, but he can reject any messages that fail to decrypt properly, as a result of spam bots not knowing his public key.

With this is in mind, users still need a way of securely sharing public keys, while minimizing spam to the simplest of problems, that problem being whether or not you want to speak to someone.  I propose such a way in the Bitmask paper with regards to permission packets and identity profile messages.  Think of it as using skype, and only accepting communication from either those who have added you to their list of contacts, or vice-versa.

Exactly, this is what we are doing with Project Quixote.  Operates like skype.  

Spam is prevented by proof-of-work and reputation of sender.


How do you end up associating a person's user name in the network with a particular public key, without other peers attempting to also claim ownership of the same user name?
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
September 12, 2013, 11:42:43 AM
 #424

How do you end up associating a person's user name in the network with a particular public key, without other peers attempting to also claim ownership of the same user name?

My guess is that this will be done via some namecoin alternative - BitName/BitDNS - https://bitcointalk.org/index.php?topic=250612.0
jgarzik
Legendary
*
Offline Offline

Activity: 1554
Merit: 1005


View Profile
September 12, 2013, 02:31:19 PM
 #425

Exactly, this is what we are doing with Project Quixote.  Operates like skype. 

Spam is prevented by proof-of-work and reputation of sender.

Yawn Smiley  Try fidelity bonds and sacrifices.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
September 12, 2013, 07:59:01 PM
 #426

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.
Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

I recommend asking me for a signature from my GPG key before doing a trade. I will NEVER deny such a request.
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
September 12, 2013, 08:55:11 PM
 #427


Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

Bote?

Leaving implementation details aside, the 10+ years of research solving an extremely similar problem to Bitmessage is worth a cursory glance. Could their protocols not influence the design of BM?
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
September 12, 2013, 11:30:37 PM
 #428


Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email

Bote?

Leaving implementation details aside, the 10+ years of research solving an extremely similar problem to Bitmessage is worth a cursory glance. Could their protocols not influence the design of BM?
Certainly, but I think their lack of adoption is part of the problem Bitmessage tries to solve. It's already possible to reproduce Bitmessage's functionality by sending GPG encrypted anonymous emails over Tor, but almost nobody does.

Bote: https://en.wikipedia.org/wiki/I2P#E-mail

I recommend asking me for a signature from my GPG key before doing a trade. I will NEVER deny such a request.
greBit
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
September 13, 2013, 06:52:04 AM
 #429

Certainly, but I think their lack of adoption is part of the problem Bitmessage tries to solve. It's already possible to reproduce Bitmessage's functionality by sending GPG encrypted anonymous emails over Tor, but almost nobody does.

Bote: https://en.wikipedia.org/wiki/I2P#E-mail

Yeah of course.

My argument is that like encryption, designing an anonymizing P2P protocol is hard to do correctly. We see that BM has a pretty large attack surface and has scalability issues.

It would be nice if the development of BitMessage2 could follow a more scientific approach. Build upon previous and well tested work instead of pulling a scheme out of thin air.
K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
September 15, 2013, 01:21:31 PM
 #430

For example, is there a reason why BM could not be implemented as a reliable-and-anonymous message channel by just building on top of a DHT such as freenet or similar? This would scale far better and we would not need to care about ACKs.
Freenet already has a mail system that does everything Bitmessage does, with stronger privacy protections.

Yes, and I2P has Bote, etc. Problems:

They are much heavier software with slower startup times and higher network load
No one-click setup
Java
Not specifically marketed as secure email
aslong you dont use orcale's java and use openjdk/openjre, java isnt a problem on the privacy/security way. tough i agree it isnt really suitable due to performance, it should be C Smiley

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
HostFat
Staff
Legendary
*
Offline Offline

Activity: 3178
Merit: 1091


I support freedom of choice


View Profile WWW
September 23, 2013, 09:18:44 AM
 #431

0.4.0
Quote
Raised default demanded difficulty from 1 to 2 for new addresses
Added v4 addresses: pubkeys are now encrypted and tagged in the inventory
Use locks when accessing dictionary inventory
Refactored the way inv and addr messages are shared
Give user feedback when disk is full
Added chan true/false to listAddresses results
When replying using chan address, send to whole chan not just sender
Refactored of the way PyBitmessage looks for interesting new objects in large inv messages from peers
Show inventory lookup rate on Network Status tab
Added SqlBulkExecute class so we can update inventory with only one commit
Updated Russian translations
Move duplicated SQL code into helper
Allow specification of alternate settings dir via BITMESSAGE_HOME environment variable
Removed use of gevent. Removed class_bgWorker.py
Added Sip and PyQt to includes in build_osx.py
Show number of each message type processed in the API command clientStatus
Use fast PoW unless we're explicitly a frozen (binary) version of the code
Enable user-set localization in settings
Fix Archlinux package creation
Fallback to language only localization when region doesn't match
Fixed brew install instructions
Added German translation
Made inbox and sent messages table panels read-only
Allow inbox and sent preview panels to resize
Count RE: as a reply header, just like Re: so we don't chain Re: RE:
Fix for traceback on OSX
Added backend ability to understand shorter addresses
Convert 'API Error' to raise APIError()
Added option in settings to allow sending to a mobile device (app not yet done)
Added ability to start daemon mode when using Bitmessage as a module
Improved the way client detects locale
Added API commands: getInboxMessageIds, getSentMessageIds, listAddressBookEntries, trashSentMessageByAckData, addAddressBookEntry, deleteAddressBookEntry, listAddresses2, listSubscriptions
Set a maximum frequency for playing sounds
Show Invalid Method error in same format as other API errors
Update status of separate broadcasts separately even if the sent data is identical
Added Namecoin integration
Internally distinguish peers by IP and port
Inbox message retrieval API functions now also returns read status

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
genjix
Legendary
*
Offline Offline

Activity: 1232
Merit: 1000


View Profile
October 19, 2013, 11:45:50 PM
 #432

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
October 22, 2013, 03:34:09 PM
 #433

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.

Seems to me like there'd be a loss of anonymity.

I recommend asking me for a signature from my GPG key before doing a trade. I will NEVER deny such a request.
favdesu
Legendary
*
Offline Offline

Activity: 1722
Merit: 1000



View Profile WWW
October 22, 2013, 04:59:39 PM
 #434

Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.

I'd rather go with mailpile.is which is already funded and in active development

Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
November 11, 2013, 05:00:13 AM
Last edit: November 11, 2013, 06:14:28 AM by Peter R
 #435

I'm just learning about BitMessage now.  I love the concept of BitMessage: as described in the introduction to the white paper, it fills a very important need.  But, after reading Sections 3 & 4, the "proof of work" for spam mitigation seems wasteful (and annoying to wait 4 min for delivery).  We're asking everyone to waste money (work) to prove they aren't spamming, when perhaps we could just ask them for money (bitcoin) directly to offset the costs of running the service.  Then they can spam all they want because it is profitable to process/store their transmissions.  (EDIT: I see this idea has been discussed earlier in the thread).

I don't have a solution  Cheesy  but there must be some way to create a *free market* for private communication transmission/storage/delivery using bitcoins.

EDIT 2: I'm imagining that Alice broadcasts her message so that it is packaged with a little bitcoin treat that somehow gets unlocked when Bradley downloads it, and the bitcoins get paid out in some fair but competitive way to the nodes that helped out.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
November 11, 2013, 06:33:36 PM
 #436

I'm just learning about BitMessage now.  I love the concept of BitMessage: as described in the introduction to the white paper, it fills a very important need.  But, after reading Sections 3 & 4, the "proof of work" for spam mitigation seems wasteful (and annoying to wait 4 min for delivery).  We're asking everyone to waste money (work) to prove they aren't spamming, when perhaps we could just ask them for money (bitcoin) directly to offset the costs of running the service.  Then they can spam all they want because it is profitable to process/store their transmissions.  (EDIT: I see this idea has been discussed earlier in the thread).

I don't have a solution  Cheesy  but there must be some way to create a *free market* for private communication transmission/storage/delivery using bitcoins.

EDIT 2: I'm imagining that Alice broadcasts her message so that it is packaged with a little bitcoin treat that somehow gets unlocked when Bradley downloads it, and the bitcoins get paid out in some fair but competitive way to the nodes that helped out.  

This is a FAQ (or if it's not an asked question, it at least comes up frequently).

Proof-of-work is NOT for spam mitigation. Just like with email, spam catching is up to the client. This is why I prefer to integrate with Thunderbird.

Proof-of-work is for flood prevention. It makes it costly to try to DoS the network by sending lots of messages.

I recommend asking me for a signature from my GPG key before doing a trade. I will NEVER deny such a request.
dadach
Sr. Member
****
Offline Offline

Activity: 327
Merit: 250



View Profile
November 12, 2013, 02:23:49 PM
 #437

Note: If you loose your password, your account is lost!

LOSE not LOOSE

Wink

To the Moon!!! donations accepted >.< 38nvHaNqF5nv4ifhUyq9CChnBmRs2DSv4r
bitcoin-world.de
Full Member
***
Offline Offline

Activity: 192
Merit: 100

bitcoin-world.de - The european information source


View Profile WWW
November 13, 2013, 06:42:17 PM
 #438

Have tested this app. Its very very good. I will bring it to the german community nearer.
jago25_98
Hero Member
*****
Offline Offline

Activity: 902
Merit: 1000


Crypto Geek


View Profile
November 15, 2013, 10:49:29 PM
 #439

just segfaults for me...

Oh great BitMessage overlords, can a poor non-programmer get a lowly Windows binary of bmgen?

(I have python but I don't know how to find and install "highlevelcrypto" for the error "ImportError: No module named highlevelcrypto".  I know enough to install python but not enough to import/install libraries.)

Edit:  Nevermind!  I just downloaded the bitmessage source code and put bmgen.py into the folder that had highlevelcrypto.py in it.  All worked wonderfully!  I know it's not the most elegant solution, but by God it spits out a vanity address, and I'm happy.  Now I just need to figure out how to import custom addresses....

Edit 2:  Nevermind again, I just opened keys.dat in a text editor and saw that it was pretty obvious how to import addresses.  I'm all set now.  Awesome.  Thank you everybody involved!!!!!

Edit 3:  It seems to do addresses that start with BM-2 or BM-2D really really fast, and everything else is super slow.  Is that some random anomaly on my part?

Crypto supporter!
Vani
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
November 16, 2013, 03:34:23 AM
 #440

Great program. Use it for almost 2 weeks now!

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23 24 25 26 27 28 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!