Topic: The Holy Grail! I wish I could kiss the author of Bitmessage on his face. - page 10. (Read 92719 times)

Done

E-mail works by trying to figure out where a specific e-mail recipient exists, and trying to route the message to that recipient.

Bitmessage works by encrypting a message with a recipient's address, along with some proof-of-work, and broadcasting it to the entire network, the same way Bitcoin broadcasts transaction information. The recipient just listens to/relays all broadcasts, and if a message if for them, they grab it and decrypt it. Broadcasting for mailing lists works similarly, where a mailing list encrypts the e-mail using its own public address, adds proof-of-work, and also just broadcast the message, but the recipients, instead of listening for messages with their own address, listen for messages from the mailing list address. Once they get it, they grab it and decrypt it with the public mailing list's public address. So you still get anti-spam proof-of-work, but the PoW needs to be done once, even for mailing lists.

There is some support for HashCash in existing spam filters already. I think BTC postage would be a great addition to traditional spam filters because it could allow a sort of permission-based mass mailing. For instance, a user could specify that anyone who spends a specific amount of BTC to an address held by that user would be allowed to send an email with a prescribed hash specified in the postage transaction.

Actually "hashcash" which is the algorithm that Bitcoin itself uses for PoW was invented for *exactly* this purpose but it has never really taken off.

I am guessing it would not be too hard to add hashcash to some sort of spam detecting "plugin" software for major email apps (for those interested take a look at https://github.com/ciyam/ciyam/blob/master/src/hashcash.cpp to see how the basic idea works) - if there is a suitable open source C++ mail plugin project in existence then for some BTC I'd be prepared to give it a go.

(as this is rather OT feel free to PM about this)

I don't see much benefit in using something as complex as OT for a simple "unsubscribe" and presumably any responsible organisation should be happy to remove members from their lists (so no need for any contract).

@fellowtraveller (the OP):

I'm in a group which is about 40% people over 50 who don't use the internet. Trying to get them to use Facebook is a chore, in and of itself. When I notified them via Facebook that there was an event coming up, all but one of them said they never got the message.

They rather enjoy being able to keep in touch with one another via email. However, I'm also wondering about the potential for list-service emailing which would allow for multiple recipients based on an opt-in (a proof-of-work opt-in mechanism which might allow them to join a list of recipients who have all agreed using a similar mechanism)?

This would have to be built into the protocol itself, as there are around 2000 members in this group who are in need of listserv-style emailing functions, and when we update they are unwilling to go to a web site (as I said, they barely conceive of email, and I would have to sell them on the idea that this is similar, perhaps even to the point that they would absolutely reject it, but for the simplicity of their use, etc.).

There are reasons for mass emails which aren't actually spam. Church groups, civic clubs, political parties, internal messaging, etc., all benefit from mass emails.

However, I like the idea of preventing spam by requiring a proof-of-work for someone you don't actually know, especially if they don't really want your contact. But what I'm wondering is this: might I suggest that if a pre-existing key exchange has occurred (PGP, Bithash, scrypt, etc.) that there be an opt-in standing agreement which can be revoked by the recipient at any time?

Just an idea. Hope it's not too complex to implement. Not being a programmer, I come up with a lot of those.

What, exactly in your opinion is the issue with the existing implementation recommendation?

What stops the OT server issue colored coins for fiat out of thin air, i.e. not backed by fiat but as debt?

really excited about this. great work fellowtraveler

Thanks, good contribution ... this sounds viable and exactly the area left in OT that needs this kind of thought/work towards implementation. Once we have voting pools and auditing protocol hashed out we are pretty much good to go I think ('just' need the s/ware ).

Great thoughts! Technically a user can audit as easily as anyone else -- I was just referring specifically to parties who have a strong incentive to do so.

I will probably want to talk to you more about this as we start implementing the auditing protocol.

tycoonUA I contacted Atheros about the virus scanner, and he said:


FYI when I run Bitmessage here on my Mac, there is no exe. I just run the python script directly from the command line.

Why not make it possible for users to audit against inflation?


Arrange all still-blinded token IDs in a binary tree of arbitrary geometry. Each token is a leaf node with the hash of the token and its value in it.  Attach to each interior node the hash of its direct child nodes and the sums of their currency values.  The root of this tree is a hash commitment to the whole tree and the sum of all the value it commits to.  This root gets signed by the pool members and broadcast.   Everyone can validate that the root sum value is <= the coin owned by the pool.

Participants could periodically perform queries where they provide their unblinded tokens along with the blinded ones and get back a new blinded token along with a hashtree fragment that proves their prior token was included in the public count.

This is secure so long as users check and nodes can't give different commitment roots to different users.

Wow, I just read this whole thread.  First a massive thanks to Fellow Traveler not only for the work you're doing but also for patiently explaining these integrated concepts in various ways to help people with different partial-understandings understand it a bit better.

For me a question that has probably either been already replied to above that I missed or maybe something those more familiar with colored coins have dealt with already:  The weakest link seems to me to be fiat represented by colored coin.  Are we talking for instance about a generic GBP colored coin, in which case the system is as strong as its least trustworthy issuer, or about branded coins. e.g. if Max Keiser were to agree to put his name to coloured coins and I were to take cash to his representative who took it from me to keep it locked away until redeemed it would mean the people I'm dealing with would need to deem KeiserCoins as dependable?  I'm not saying this is necessarily a weak link in comparison with what we have already but from what I understand it is likely the weakest link in the proposed solution as is.  Have I got the gist of this aspect of it right or have I misunderstood something?

I'm loving the way the whole Open Transactions thing can work especially in conjunction with coins (bit, alt or colored) not even needing to sit on the servers and with the Bitmessage system.  I had not looked into either before this evening and the idea of combining them all with a means of compiling an order book of truly distributed and anonymous p2p system is just beautiful.

Thanks again

PS.  .75 btc sent your way (1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ) towards bringing this to fruition quicker.  Someone above suggested OpenCoinInc might try to buy this out too.  May I request if you do get an offer and are tempted that you first give the community the opportunity to crowdfund a competing bid?

Here is a basic scenario:
I am sitting at home on Friday night and getting my finances ready for the open market down on main street in the morning. I notice that bitcoin has moved upwards on the market and versus USD/Litecoin/etc, so I quickly adjust my breakdown on colored coins and setup 2 possible outcomes for Saturday morning: upwards @ said rate 1 or 2, or downwards @ said rate 3. Now I am all set for the morning to prevent losses during rapid buy/selling of my socks in the alpaca section. No nasty waiting4six or hoping the market movements were low during selloff. Just a quick check and of current prices and switch to my correct pre-arranged till drawer via BMOT.
Everyone who drops by to purchase my socks or buy some bitcoins knows what they are getting, backed by my multi-sig(consortium/reputation).
If the market movements are too volatile, then I may be making more wealth sitting at home than hawking my goods.
This is just one way of arranging OT servers - you decide on the contracts. Breakdown your coinage and OT verifies you are legit or GTFO! No more wondering or con jobs.
Many of the wild-west marketeers are not going to like OT servers because they act as gateways on the *coin and don't allow for huge moves unless your entire pool decides. Nobody pushes around Deepbit or BTC Guild for a reason, he's swinging the biggest club and has built trust. If you knew that certain coins resided in his pools you would go, "That's good enough for me!"

It's also safer than storing the BTC on a ripple gateway. 

The same is in Russia. I guess for private accounts you have to resort to web scrapping.

That's also something that is often limited to business accounts or only in certain countries (German banks often have implemented the HBCI standard). My bank for example tries to rather push it's own branded "apps" instead of allowing an API and there is little to no documentation on what business accounts can get/expect API wise.

Banks are incredibly slow and have no real competition anyways to make them move faster.

I think he meant an API provided by the bank to its clients.

Could you post a link to this API? As far as I understand it, SEPA is just a standard that is used between banks in the SEPA network, not exposed to actual users.

It's just a safe place to store coins, ON THE BLOCKCHAIN, so that an OT server can issue units based on those coins, yet without having the ultimate power to disappear with those coins.

And if the OT server can't steal the actual coins externally on the blockchain, and if it can't forge receipts internally in its own system, then the coins are much more safe than if the transaction server was directly holding them (as we see in the Bitcoin community today.) For example, if your coins are stored at MtGox today, then MtGox ultimately has the power to steal them. They probably won't, but the power is there. But with OT servers, I don't want the server to have such powers. I want to demote the server so that it's merely a cloud commodity, and not an authority.