Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
August 06, 2013, 03:49:52 AM |
|
Searched but no answer found for this question:
Is it possible to somehow create a 'vanity' BM address? Like BM-2Cyberdyne6hY111lPtD111A111hY111lP for example.
Yes, it's possible, somehow, in the same way you can do it with Bitcoin. No one wrote the software to do it yet.
|
|
|
|
nimda
|
|
August 06, 2013, 03:59:13 AM |
|
Searched but no answer found for this question:
Is it possible to somehow create a 'vanity' BM address? Like BM-2Cyberdyne6hY111lPtD111A111hY111lP for example.
Yes, it's possible, somehow, in the same way you can do it with Bitcoin. No one wrote the software to do it yet. Allow me to laugh maniacally. You can reach me at BM- 2DARKo7LcCvBiXyyabT5vNxgQ32pBqScuk. Behold, my powerful 1h/s+ miner! https://bitmessage.org/forum/index.php?topic=1727.0
|
|
|
|
luv2drnkbr
|
|
August 07, 2013, 10:33:09 AM Last edit: August 07, 2013, 11:36:22 AM by luv2drnkbr |
|
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?
|
|
|
|
nimda
|
|
August 07, 2013, 03:47:43 PM |
|
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!!!!! Actually my script spits out passwords that you import via the Gui (deterministic address). 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?
Run And you'll see the reason. That script doesn't do any validity checking.
|
|
|
|
ffcitatos
Member
Offline
Activity: 71
Merit: 10
|
|
August 09, 2013, 02:02:52 PM |
|
Has anyone been thinking about protecting against compromised computers? Could something akin to Trezor be used to keep the secret info away from the computer memory?
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
August 11, 2013, 08:11:01 AM |
|
I'm using a proxy+incoming and I only get 9 connections? Is this hard coded? I normally get 60+
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
August 21, 2013, 11:12:50 AM |
|
|
|
|
|
|
Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
August 23, 2013, 03:06:48 AM |
|
Based on discussions about this on Bitmessage groups, we believe this was a wa for the original poster of this message to collect Bitmessage user's IP numbers.
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
August 23, 2013, 03:08:31 AM |
|
Hence the unique number and 500
Damn dont click shit
The client should disable links
|
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
|
August 23, 2013, 03:14:11 AM |
|
Damn dont click shit
The client should disable links Just use Tor and/or a VPN.
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
|
August 23, 2013, 03:26:20 AM |
|
The namecoin integration with bitmessage can fix this ... since you can change-up your BM-xxx address in the namecoin blockchain as much as you like (even automate it if you like) whilst you remain contactable at "id/name" ... as long as you control the namecoin keys for "id/name" your correspondents will know they are connecting with you (you'll need to initiate by transferring the "id/name" knowledge in some other out-of-band method like PGP signed mail, fingerprint exchange, etc as OTR does). This fix should provide some measure of forward secrecy, although you will need to be careful then about how you use namecoin to register/update that "id/name" on the namecoin network ... but all that is then the identical modus operandi for using the bitcoin network in way to avoid privacy leaks ...
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
|
August 23, 2013, 01:48:40 PM Last edit: August 24, 2013, 09:15:40 AM by phelix |
|
What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels. Potential donation addresses: atheros, bitcoin100, bitcoineater edit: https://bitcointalk.org/index.php?topic=244656.0 Micropayment channels
|
|
|
|
Rassah
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
August 23, 2013, 02:01:32 PM |
|
What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels.
Potential donation addresses: atheros, bitcoin100, bitcoineater
Too centralized, and would greatly stifle adoption. People expect electronic message systems to be free, and not many would be willing to both have to pay per e-mail, and actually be able to obtain bitcoin in whatever hellhole part of the world they may be in where they would actually need Bitmessage.
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
|
August 23, 2013, 08:18:30 PM |
|
What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels.
Potential donation addresses: atheros, bitcoin100, bitcoineater
Too centralized, and would greatly stifle adoption. People expect electronic message systems to be free, and not many would be willing to both have to pay per e-mail, and actually be able to obtain bitcoin in whatever hellhole part of the world they may be in where they would actually need Bitmessage. How is the bitcoineater address centralized? http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuEWaiting a couple of minutes for every mail is not the best solution either. Also it will not work so well on mobiles. Maybe as a choice.
|
|
|
|
virtualmaster
|
|
August 24, 2013, 08:35:22 AM |
|
What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels.
Potential donation addresses: atheros, bitcoin100, bitcoineater
Too centralized, and would greatly stifle adoption. People expect electronic message systems to be free, and not many would be willing to both have to pay per e-mail, and actually be able to obtain bitcoin in whatever hellhole part of the world they may be in where they would actually need Bitmessage. Both arguments are valid and beside of this the bitcoin chain is to overloaded for this purpose. What about destroying small Namecoin fees ( for ex 0.005 NMC/10 message) or just blocking a small amount of NMC (for ex 0.005 NMC/message) for 1/2 year which would be received back to the same address after that time ?
|
|
|
|
bytemaster
|
|
August 24, 2013, 08:45:17 AM |
|
Three major challenges here:
1) broadcasting of the transaction would in many cases be just as resource intensive as sending your original message in the first place. 2) even if you got the money back there would still be fees 3) Creating dust ultimately means you will be spending these outputs (and paying higher fees) along with some of your other addresses and thus compromise your identity.
I spent a long time trying to find a way to make the system 'for-pay' and not just 'burn' CPU cycles... but then I realized something critical:
1) everyone needs to propagate other peoples messages to hide their own. Therefore, everyone is already doing an even bandwidth barter to simply forward the messages along. Statistical analysis can detect leaches and cut them off. 2) the proof of work should not be required as long as the bandwidth is below a fixed limit. Just like bitcoin limits block production, bitmessage can limit bandwidth consumption on any given channel/stream. With a fixed bandwidth stream and the ability to spawn new streams as necessary to balance load, the proof of work should only become a factor in times of congestion or when there is a need to compete with spam. Of course, spam is just as good as real traffic for hiding in the crowd and as long as the channel/stream you are listening on is within spec for bandwidth usage, there is really no problem what-so-ever.
|
|
|
|
phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
|
August 24, 2013, 09:14:31 AM |
|
What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels.
Potential donation addresses: atheros, bitcoin100, bitcoineater
Too centralized, and would greatly stifle adoption. People expect electronic message systems to be free, and not many would be willing to both have to pay per e-mail, and actually be able to obtain bitcoin in whatever hellhole part of the world they may be in where they would actually need Bitmessage. Both arguments are valid and beside of this the bitcoin chain is to overloaded for this purpose. What about destroying small Namecoin fees ( for ex 0.005 NMC/10 message) or just blocking a small amount of NMC (for ex 0.005 NMC/message) for 1/2 year which would be received back to the same address after that time ? But that would bloat the Namecoin blockchain. Three major challenges here:
1) broadcasting of the transaction would in many cases be just as resource intensive as sending your original message in the first place.
Not at all with micropayment channels: https://bitcointalk.org/index.php?topic=244656.02) even if you got the money back there would still be fees
No fees with micropayment channels besides the initial fee. 3) Creating dust ultimately means you will be spending these outputs (and paying higher fees) along with some of your other addresses and thus compromise your identity.
If you don't lock the fee but donate or destroy there is no spending thus no compromising. I spent a long time trying to find a way to make the system 'for-pay' and not just 'burn' CPU cycles... but then I realized something critical:
1) everyone needs to propagate other peoples messages to hide their own. Therefore, everyone is already doing an even bandwidth barter to simply forward the messages along. Statistical analysis can detect leaches and cut them off. 2) the proof of work should not be required as long as the bandwidth is below a fixed limit. Just like bitcoin limits block production, bitmessage can limit bandwidth consumption on any given channel/stream. With a fixed bandwidth stream and the ability to spawn new streams as necessary to balance load, the proof of work should only become a factor in times of congestion or when there is a need to compete with spam. Of course, spam is just as good as real traffic for hiding in the crowd and as long as the channel/stream you are listening on is within spec for bandwidth usage, there is really no problem what-so-ever.
I thought the whole point was blocking spam...
|
|
|
|
|