The Holy Grail! I wish I could kiss the author of Bitmessage on his face.

[Cryptoman]

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.)

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

[FreddyFender]

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!"

[thoughtfan]

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?

[gmaxwell]

The only possible crime is inflation, but the gold issuer has an incentive to audit the OT server, which prevents inflation.

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.

[fellowtraveler]

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

Yeah, that is an occasional post over on the Bitmessage forum too. Because the Bitmessage EXE includes Python, PyQt, and OpenSSL, it sets off a lot of virus scanners.

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

[fellowtraveler]

The only possible crime is inflation, but the gold issuer has an incentive to audit the OT server, which prevents inflation.

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.

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.

[marcus_of_augustus]

The only possible crime is inflation, but the gold issuer has an incentive to audit the OT server, which prevents inflation.

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.

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 ).

[fanfare]

really excited about this. great work fellowtraveler

[lexxus]

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

[lebing]

I'm really tired of people confusing IOUs with value.

With cryptocurrency, you can move the Value online, but with fiat currencies, all OT and ripple can move is an IOU for that currency/commodity, and then you've created a central point of failure as people collect their IOUs.

A cryptocurrency P2P exchange we can make right now; overcoming the value problem is the only problem we're stuck on.

To save time, I've summed up the process (with pics!) and streamlined the criteria for a real P2P distributed exchange here: https://bitcointalk.org/index.php?topic=212841.0

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

[VishwaJay]

@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.

[CIYAM]

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

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).

[mmeijeri]

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.

[Rassah]

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?

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.

[Atheros]

Hello everyone

fellowtraveler,
It appears to me that you need an API command in Bitmessage to generate an address from the "Silver_Asset_ID+Server_A_ID+EURO_SEPA" string without actually adding it to the software's collection of addresses; this way Bob or Jorg could then subscribe to the address.
So it appears to me that we need three more API commands:
getDeterministicAddress
addSubscription
deleteSubscription

Shall I add them?

Done

[fellowtraveler]

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?

You are correct that a colored coin issuer is the "weakest link." You do have to trust that the colored coin issuer will ultimately redeem those colored coins back for GBP again.

However…

--- The system described works without colored coins. You can use normal BTC. (There's no reason why you couldn't give a normal BTC to someone in return for legacy funds, instead of a colored coin.)

--- The main advantage of using colored coins is that it eliminates capital gains tax liability. (I'm not a lawyer and that's not legal advice. My point is that if you buy something for $100 and then sell it for $100, there is obviously no gain or loss.)

--- Also keep in mind that certain currencies require an issuer. For example, any gold-backed currency will need an issuer who stores that gold. Any Euro-backed currency will need an issuer who stores those Euros, etc.

--- And in the case of currencies that require an issuer, it's better to issue them first as colored coins, versus having the issuer create them directly on the OT server as IOUs. This is because it breaks the link between the issuer and the transaction server.

--- You see, if the gateway directly runs the server (Ripple) or if the issuer directly issues the currency as IOUs onto the server (OT can do this) then either way, pressure from authorities or criminals can be brought down onto the issuer, regarding that server. (Such as, "Shut that server down, or we'll shoot you!" or "Remove your IOUs from that server, or we'll shoot you!")

--- Whereas, if the issuer issues the currency first as colored coins, then the issuer cannot be held liable for those coins later being traded on various servers by various users. The issuer becomes totally divorced from the transaction servers. Just the same as the Federal Reserve being completely innocent of whatever their dollars are used for, once those dollars enter circulation beyond their reach.

--- Of course, the issuer still needs to provide bank wires in/out as a redemption of last resort, and he will need to follow KYC / AML for those wires, but as long as he does, most people will be able to get in/out of the system by buying/selling the colored coins from each other instead of having to go directly through the issuer. This is very powerful! Therefore I believe that colored coins are very important. Kudos to J.R. Willett!

--- This allows the issuer to operate legally, without any involvement in the operations of the servers themselves.

--- After that, I suggest using OT's basket currencies to distribute the risk of a single currency across multiple issuers, using jurisdictional arbitrage. For example, if there are 20 issuers in various jurisdictions who issue a GBP-based currency, we can combine those on OT into a single basket, such that no one is risking all their money with a single issuer.

--- I'm sure the recent victims of the Liberty Reserve heist, who just had all their money stolen, wish they had considered such possibilities, as I have been for the past few years.

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?

This may sound surprising to you, but I was actually talking to at least one Rippler before they started that company. When I was originally approached, it was regarding business development for Open-Transactions, but later they started the Ripple company instead. I even sent them a document of all my intimate thoughts.

In fact, since they already got to read it, I might as well make that document available to the rest of you as well:

http://ft.vm.to/files/britto/FT-thoughts.pdf

Enjoy!

That is one of the reasons I am Ripple-positive: because my whole goal with OT was to inspire related development based on these concepts. Thus, I view them as one of my "children."

We are all working towards the same goals. May a million currencies bloom!

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

The OT server will not issue colored coins -- currency issuers will. These issuers will be entirely divorced from the transaction server, as described above.

Once a user uploads colored coins (or regular BTC) to an OT server, the coins will not actually be received by that server, but will be stored in a multi-sig voting pool, which prevents that server from having direct control over those coins. Even if the server disappears, the coins are still recoverable.

The transaction server is also incapable of forging receipts internally. As I have said previously, inflation is the only possible crime, but that is prevented through an auditing protocol.

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 sounds like a question better posed to the author of Bitmessage (Atheros.) My own project is for transaction processing, not messaging.

[caveden]

<off-topic>

--- I'm sure the recent victims of the Liberty Reserve heist, who just had all their money stolen

What Liberty Reserve heist? Couldn't find it with Google. You're not confusing it with Liberty Dollar, perhaps?

</off-topic>

[fellowtraveler]

<off-topic>

--- I'm sure the recent victims of the Liberty Reserve heist, who just had all their money stolen

What Liberty Reserve heist? Couldn't find it with Google. You're not confusing it with Liberty Dollar, perhaps?

</off-topic>

Actually I meant what I said.

Have you tried libertyreserve.com lately?

[UncleBobs]

For those asking for hand-holding....

Code:

git clone git://github.com/Fellow-Traveler/Open-Transactions

Just a correction for anyone who tries this, it should read

Code:

git clone git://github.com/FellowTraveler/Open-Transactions.git

Very exciting stuff!

[fellowtraveler]

Thanks! (Corrected in original post.)