bytemaster
|
|
September 11, 2013, 09:42:17 PM |
|
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.
|
|
|
|
greBit
|
|
September 11, 2013, 10:40:51 PM |
|
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
Activity: 12
Merit: 0
|
|
September 11, 2013, 11:01:31 PM |
|
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
|
|
September 12, 2013, 11:42:43 AM |
|
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
Activity: 1596
Merit: 1099
|
|
September 12, 2013, 02:31:19 PM |
|
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 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
|
|
September 12, 2013, 07:59:01 PM |
|
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
|
|
|
|
greBit
|
|
September 12, 2013, 08:55:11 PM |
|
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
|
|
September 12, 2013, 11:30:37 PM |
|
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
|
|
|
|
greBit
|
|
September 13, 2013, 06:52:04 AM |
|
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-mailYeah 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
Activity: 1792
Merit: 1008
/dev/null
|
|
September 15, 2013, 01:21:31 PM |
|
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
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
|
September 23, 2013, 09:18:44 AM |
|
0.4.0 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
|
|
|
|
genjix
Legendary
Offline
Activity: 1232
Merit: 1076
|
|
October 19, 2013, 11:45:50 PM |
|
Did you guys see http://flowingmail.com/ yet? I reached out to the devs & think their project can go far.
|
|
|
|
nimda
|
|
October 22, 2013, 03:34:09 PM |
|
Seems to me like there'd be a loss of anonymity.
|
|
|
|
favdesu
Legendary
Offline
Activity: 1764
Merit: 1000
|
|
October 22, 2013, 04:59:39 PM |
|
I'd rather go with mailpile.is which is already funded and in active development
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
|
November 11, 2013, 05:00:13 AM Last edit: November 11, 2013, 06:14:28 AM by Peter R |
|
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 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.
|
|
|
|
nimda
|
|
November 11, 2013, 06:33:36 PM |
|
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 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.
|
|
|
|
dadach
|
|
November 12, 2013, 02:23:49 PM |
|
Note: If you loose your password, your account is lost! LOSE not LOOSE
|
To DA Moon!!! donations accepted >.< 38nvHaNqF5nv4ifhUyq9CChnBmRs2DSv4r
|
|
|
bitcoin-world.de
Full Member
Offline
Activity: 192
Merit: 100
bitcoin-world.de - The european information source
|
|
November 13, 2013, 06:42:17 PM |
|
Have tested this app. Its very very good. I will bring it to the german community nearer.
|
|
|
|
jago25_98
|
|
November 15, 2013, 10:49:29 PM |
|
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?
|
Bitcoiner since the early days. Crypto YouTube Channel: Trading Nomads | Analyst | News Reporter | Bitcoin Hodler | Support Freedom of Speech!
|
|
|
Vani
|
|
November 16, 2013, 03:34:23 AM |
|
Great program. Use it for almost 2 weeks now!
|
|
|
|
|